Dyzet e pesë minuta, një editor i përbashkët, një i panjohur që shikon çdo tast dhe një problem që nuk e ke parë kurrë: të kthesh së prapthi një listë të lidhur, të gjesh nënvargun me shumën më të madhe. Pa dokumentacion, pa kërkim, ndonjëherë as autocompletim. Dhe për më tepër të kërkojnë të "mendosh me zë të lartë". Ky është live coding-u, dhe në shumë procese përzgjedhjeje është ende momenti që vendos gjithçka.
Unë jam kundër. Jo sepse është i vështirë, por sepse mat gjënë e gabuar. Kam bërë intervista nga të dyja anët e tavolinës, dhe në një artikull tjetër kam shkruar si do t'i ndryshoja pyetjet teknike në epokën e IA-së. Këtu shkoj drejt në temë: pse live coding-u klasik nuk funksionon, çfarë u pranoj atyre që e mbrojnë dhe çfarë do të bëja në vend të tij.
Për cilin live coding flas
Së pari, një dallim. Jam kundër ushtrimit algoritmik me kohë, të vëzhguar drejtpërdrejt, pa mjete, mbi një problem që nuk ka lidhje me punën, rezultati i të cilit vendos vetë nëse vazhdon apo jo. Nuk jam kundër punës së përbashkët me një kandidat mbi një detyrë realiste, me dokumentacion dhe mjete në dispozicion, për të parë si arsyeton. Duken e njëjta gjë, por nuk janë: do t'i kthehem në fund.
Mat stresin, jo aftësinë
Nuk është thjesht një përshtypje. Në vitin 2020 disa studiues të North Carolina State University dhe të Microsoft publikuan një studim të kontrolluar me 48 studentë të informatikës: gjysma zgjidhi një problem në tabelë përpara një intervistuesi, gjysma vetëm, në një dhomë private. Ata që vëzhgoheshin dhanë rezultate më shumë se dy herë më të dobëta. Autorët vënë në dukje se formati i ngjan në mënyrë shqetësuese Trier Social Stress Test, një protokolli që përdoret në psikologji pikërisht për të shkaktuar stres.
Studimi është i vogël dhe është bërë me studentë, prandaj nuk e marr si ligj. Por konfirmon atë që e di mirë kushdo që ka kaluar një intervistë: nën vëzhgim memoria e punës ngushtohet, humbet fija, gabon gjëra banale që në kushte normale nuk do t'i gaboje kurrë. Rezultati nuk i përgjigjet pyetjes "a di të programojë?", por një tjetre: "sa mirë programon ndërsa dikush e gjykon drejtpërdrejt?". Dhe në punën e vërtetë kjo situatë nuk ekziston.
Puna e vërtetë nuk i ngjan një live coding-u
| Në live coding | Në punën e vërtetë |
|---|---|
| 45 minuta për një problem të paparë | Orë ose ditë, me kohë për ta kuptuar problemin |
| Pa dokumentacion dhe pa kërkim | Dokumentacioni, kërkimi dhe shembujt gjithmonë të hapur |
| Asistenti IA i ndaluar | Asistenti IA në editor, çdo ditë |
| Një i panjohur që shikon çdo tast | Përqendrim, dhe review-ja vjen më pas |
| Algoritme nga libri | Leximi i kodit ekzistues, integrimi i API-ve, korrigjimi i bug-eve |
| Ka rëndësi të arrish te një zgjidhje | Kanë rëndësi lexueshmëria, testet dhe mirëmbajtja në kohë |
Kush do të punësohet do t'i kalojë ditët duke lexuar kod të shkruar nga të tjerë, duke zgjedhur një librari, duke kuptuar pse një test dështon vetëm në CI. Ta vlerësosh për aftësinë për të implementuar përmendsh një algoritëm, në gjysmë ore dhe nën sytë e dikujt, do të thotë të matësh një aftësi që do ta përdorë rrallë, në kushte në të cilat nuk do të punojë kurrë.
Shpërblen kë stërvitet për formatin, jo kë punon mirë
Live coding-u algoritmik është bërë një disiplinë më vete, me platforma, kurse dhe qindra ushtrime për t'u përsëritur derisa t'i njohësh me shikim të parë. Kush ka javë të lira për t'u stërvitur vjen i përgatitur. Kush punon me kohë të plotë, ka familje ose thjesht e kalon kohën duke ndërtuar software të vërtetë në vend që të zgjidhë enigma, nis në disavantazh. Në fund intervista përzgjedh mbi të gjitha përgatitjen për intervistën.
Dhe penalizon në mënyrë sistematike disa njerëz: kush vuan nga ankthi, kush është neurodivergjent, kush e bën intervistën në një gjuhë që nuk është e tija dhe duhet të mendojë me zë të lartë ndërsa përkthen në kokë. Asnjë nga këto nuk thotë diçka për mënyrën si ai person do të shkruajë kod në një ekip.
I kushton edhe kompanisë
Zakonisht flitet për kandidatin, shumë më pak për kompaninë. Çdo negativ i rremë është një zhvillues i aftë i refuzuar sepse u bllokua për dhjetë minuta. Dhe kush ka përvojë dhe alternativa, shpesh, një proces me live coding e shmang krejtësisht: kompania ata kandidatë as nuk i sheh.
Ka edhe një efekt më pak të dukshëm. Duke vëzhguar dikë nën presion, intervistuesi përfundon duke vlerësuar sigurinë më shumë se përmbajtjen: kush flet me lehtësi duket më i zoti se kush hesht dhe mendon. Është një paragjykim që ekziston në çdo intervistë, por ky format e përforcon.
Çfarë u pranoj atyre që e mbrojnë
- Të verifikosh që një person di vërtet të programojë është e ligjshme. Një CV mund të fryhet, dhe sot edhe një ushtrim për ta bërë në shtëpi mund ta zgjidhë një IA.
- Detyrat e gjata për në shtëpi kanë një kosto reale: orë pune të papaguar, shpesh në disproporcion me pozicionin.
- Live coding-u është i lirë dhe uniform: i njëjti ushtrim për të gjithë, një orë dhe mbaron.
Janë kundërshtime serioze. Por përgjigjja ndaj "duhet t'i verifikojmë aftësitë" nuk mund të jetë një format që i mat keq. Duhet një format që verifikon të njëjtën gjë pa pjesën që e shtrembëron rezultatin.
Çfarë do të bëja në vend të tij
- Code review mbi kod real. Një fragment i besueshëm, me një bug dhe disa zgjedhje të diskutueshme, për ta komentuar sikur të ishte pull request-i i një kolegu. Shihet menjëherë kush e kupton kodin, dhe askush nuk duhet të shkruajë nën diktim.
- Projekti i kandidatit. Një repository, një punë e mëparshme, një projekt personal: "më shpjego këtë zgjedhje", "çfarë do të ndryshoje sot?". Një përvojë e jetuar u qëndron pesë pyetjeve thelluese; një histori e mësuar përmendsh bie që te e dyta.
- Një detyrë e shkurtër për në shtëpi, e ndjekur nga një diskutim. Dy ose tre orë maksimumi, të paguara nëse është e mundur, dhe pastaj një bisedë ku kandidati shpjegon dhe ndryshon zgjidhjen e vet. Nëse e ka shkruar një IA dhe ai nuk e kupton, mjaftojnë pak minuta pyetjesh për ta vënë re.
- Pair programming mbi një detyrë realiste. Nëse vërtet duam të shohim dikë duke shkruar kod: një repository i vogël i vërtetë, dokumentacioni dhe IA të lejuara, asnjë kronometër mbi rezultatin. Intervistuesi punon me kandidatin në vend që ta mbikëqyrë.
- Një seancë debugging-u. Një test që dështon dhe koha për të kuptuar pse: është gjëja më e afërt me një ditë normale pune.
Nëse live coding-u mbetet, të paktën kështu
E kuptoj që jo të gjitha kompanitë do ta ndryshojnë procesin nga një ditë në tjetrën. Nëse live coding-u mbetet, ka disa rregulla minimale që e bëjnë më pak të padrejtë:
- të njoftohen paraprakisht formati, kohëzgjatja dhe gjuha;
- të zgjidhet një problem i lidhur me punën, jo një enigmë nga libri;
- të lejohen dokumentacioni dhe kërkimi, si në çdo ditë normale;
- të vlerësohet arsyetimi, jo vetëm rezultati përfundimtar;
- t'i lihen kandidatit disa minuta për të lexuar dhe menduar në heshtje përpara se t'i kërkohet të flasë.
Dhe nëse kandidati je ti
Mund të kërkosh, me mirësjellje, një alternativë: një code review, diskutimin e një projekti tënd, një detyrë të shkurtër për në shtëpi. Jo të gjitha kompanitë do të pranojnë, por të kërkosh nuk kushton asgjë. Dhe përgjigjja të tregon shumë për mënyrën si punojnë: një kompani që nuk di të shpjegojë pse përdor një format të caktuar, ndoshta nuk e ka pyetur kurrë veten.
Në përmbledhje
Jam kundër live coding-ut klasik sepse mat si e përballon një person stresin e të qenit i vëzhguar, jo si punon. Është një marrëveshje e keqe për kandidatin dhe edhe për kompaninë, që refuzon njerëz të aftë dhe përzgjedh ata që janë stërvitur për formatin. Alternativat ekzistojnë dhe verifikojnë të njëjtën gjë, pra nëse një person di të programojë, pa e shtrembëruar rezultatin. Kam mbledhur ide të tjera për rinovimin e intervistave teknike në këtë artikull, dhe nëse po përgatitesh për një intervistë, pyetjet teknike të organizuara sipas nivelit i gjen te udhëzuesi me 25 pyetje intervistash për frontend/Angular.
