7 întrebări pentru interviul tehnic

Înainte să începem, ține cont că ceea ce povestesc eu aici e valabil atunci când ai ceva experiență, nu când ești la început. Întrebările astea sunt menite să te ajute să înțelegi dacă ți-ar plăcea să lucrezi acolo sau nu.

În primul rând ce vreau să înțelegi, sau să conștientizezi e că interviul nu e un “test” doar pentru tine. Ci și pentru compania respectivă. Și tu îi evaluezi pe ei, e o evaluare de ambele părți. Ține minte asta de fiecare dată când mergi la un interviu pentru că te va ajuta.

Ca să fii pregătit, trebuie să te gândești la întrebările astea din timp, pentru că acolo pe loc îți va fi greu să le formulezi. Le mai poți ajusta în funcție de discuțiile din timpul interviului, dar în principiu ar trebui să le ai pregătite.

De asemenea pe parcurs e posibil să primești răspuns la unele întrebări înainte de a întreba. Pentru că în general oamenii cu care dai interviul vor începe prin a-ți da detalii despre echipă, proiecte, modul de lucru etc.

Bun și acum hai să vedem câteva întrebări pe care eu le pun, bineînțeles în funcție de context, de discuția avută până în momentul respectiv șamd.

1. Câți membri are viitoarea echipă și care sunt rolurile lor?

În felul ăsta o să-ți faci o idee și despre task-urile pe care o să le ai. Sau mai bine zis, ce o să fie nevoie să faci în timpul “ciclului de dezvoltare”. Dacă ți se spune că în echipă sunt doar programatori, ar trebui să deduci de aici că probabil va fi nevoie să faci un pic și pe business analyst-ul cât și tester și cel mai probabil și DevOps. Adică te vei ocupa cam de toate, culegerea de cerințe, dezvoltare, testare și deploy.

Totodată ar trebui să-ți dea un semnal de alarmă treaba asta, pentru că indiferent cât de priceput ai fi, e greu să înglobezi toate rolurile astea.

2. Care este modul de lucru al echipei? (agile, waterfall etc.)

Cred că în zilele noastre majoritatea firmelor să zicem “serioase”, folosesc agile, dar nu știi niciodată așa că e mai bine să întrebi înainte.

Zic că ar fi de preferat să eviți echipele care încă folosesc waterfall. Cred totuși că e doar o preferință personală, dar eu n-aș vrea să mai lucrez cu waterfall, pentru că simt că se pune mai multă presiune la început. Nu mai multă, ci foarte multă, pentru că se presupune că la începutul proiectului ar trebui să înțelegi foarte bine care sunt cerințele clientului și ce anume are nevoie.

3. Cum și cât interacționează membri echipei între ei?

Asta e o întrebare care te va ajuta să-ți dai seama de dinamica echipei, dar și despre modul cum sunt atribuite task-urile în echipă. Sau cât de apropiați sunt membri echipei unii de ceilalți, ca și activitate pe proiect, nu social vorbind.

Deși nu-mi place pair programming-ul în general, dacă ai o echipă cu oameni mai sociabili, mai deschiși, care se ajută în general unii pe alții, va fi mai plăcut decât dacă ar fi fiecare pentru el și n-ai avea pe cine să întrebi ceva atunci cănd ai avea nevoie.

4. Care este nivelul de code coverage al proiectului/proiectelor?

Dacă nu știi ce-i ăla Code Coverage, el reprezintă procentul de linii de cod care sunt atinse de teste unitare.

E posibil ca răspunsul la întrebarea asta să-l primești înainte să apuci să întrebi, dar dacă nu se întâmplă asta, e un lucru foarte important de știut care îți va da câteva indicii despre calitatea codului proiectelor. Dacă răspunsul va fi 0%, respectiv “noi nu scriem teste aici, dar dacă vrei poți tu să scrii”, nu e un semn bun. Înseamnă că fiecare scrie cum vrea și nimeni nu pune accent pe calitate.

Asta înseamnă că există posibilitatea ca modificarea unei funcționalități să fie extrem de dificilă și să ducă la mai multe modificări sau refactorizări în lanț. Așa îți vei face o idee și despre technical debt, indirect fără să mai întrebi.

Nu zic acum că nu poți scrie cod curat fără teste, bineînțeles că poți, dar în experiența mea lucrul ăsta nu se întâmplă.

5. Cum se face deploy-ul?

Aici ai 2 posibilități de răspuns: manual sau automat printr-un pipeline de CD. Dacă deploy-ul nu e făcut automat, ce trebuie să știi e că va trebui să ai nervi de oțel atunci când faci un release. Dacă îl faci tu, că poate există o persoană dedicată de DevOps care face asta, depinde. Dar dacă deploy-ul îl faci tu, pregătește-te să-ți bați capul cu proceduri complicate, configurări și probleme de infrastructură greu de detectat și rezolvat.

În cazul meu, ăsta e un mare turn-off în cazul în care se face manual și aș fugi de asta. Poate doar dacă lucrezi pe un proiect mic și simplu și cu o infrastructură destul de “deschisă”, sau permisivă, să spunem.

6. Cât de ușor este să testezi manual aplicația? Dar să faci debug?

Aici poți să-ți faci o idee despre ceea ce înseamnă prerequisites și cât de rapid va fi ritmul în dezvoltare. Dacă ai tot timpul nevoie să ceri nu știu ce drepturi de acces, sau conturi dedicate, sau să pui aplicația pe nu știu care environment ca să poți testa un feature mic, nu-i a bună.

În mod ideal, ai vrea să poți testa manual aplicația pe environmentul de development și să poți face debug și toate cele. În cazul în care nu se întâmplă asta, în funcție de dificultate, task-urile îți vor lua de la 2 până la câteva ori mai mult.

7. Cât timp îi trebuie unui membru nou al echipei până să preia un task?

Poți de asemenea să menționezi că te referi “în medie”, pentru că asta depinde evident și de experiența omului nou. Unui junior îi va lua în mod cert mai mult decât cuiva cu 15 ani experiență să preia un task și să îl ducă la final mai mult sau mai puțin pe cont propriu. Poți să faci referire la nivelul tău de experiență pentru că asta te interesează defapt.

Astea sunt câteva întrebări pe care le-ai putea pune ca să-ți faci o idee despre cum funcționează echipa, care este nivelul de calitate al proiectelor, nivelul de complexitate, learning curve-ul pentru oamenii noi șamd.

Evident că din contextul discuției poți deduce mult mai multe întrebări de atât, dar pentru mine astea sunt câteva întrebări cheie la care aș vrea mereu să am răspunsuri.

E și un pic de subiectivism aici, pentru că ceea ce nu-mi place mie, altuia s-ar putea să-i facă plăcere, ca exemplu să-și bată capul cu tracing pe server atunci când aplicația are un comportament diferit după un release. Fiecare cu preferințele lui.

Așa că întrebările astea sunt ca un fel de pointers, dar bazate pe experiența și pe preferințele mele.