Nu ți se pare ciudat că atunci când vrei să schimbi locul de muncă și trebuie să participi la un interviu, te gândești în primul rând "trebuie să mă pregătesc pentru interviu". Să rezolvi probleme pe HackerRank, să citești Crack the Coding Interview, să înveți cum funcționează ArrayList și cu ce se deosebește aceasta de LinkedList. Ah da, ar putea să te întrebe despre sortări, iar a spune că quick sort ar fi cel mai bun tip de sortare ar fi, clar, neprofesionist.
Dar stai, tu programezi 8 ore pe zi, rezolvi probleme interesante și neobișnuite, iar la noul loc de muncă o vei face cam pe aceeași linie. Totuși, pentru a trece interviul trebuie să te pregătești suplimentar, nu doar să îți rafinezi abilitățile zilnice, ci să înveți ceea ce nu ți-a fost necesar la locul actual de muncă și, cel mai probabil, nici la următorul. La obiecțiile tale că știința computerelor e în sângele nostru, și că dacă ne trezești din somn, trebuie să putem scrie fără să ne gândim pe o pernă algoritmul de parcurgere în lățime a unui arbore, voi răspunde că dacă aș aplica la un circ și trucul meu principal ar fi asta — atunci da, aș fi de acord. Trebuie să verific această abilitate.
Dar de ce să testezi abilități nerelevante pentru actualul loc de muncă? Doar pentru că este la modă? Pentru că Google face așa? Sau pentru că viitorul tău lider de echipă a învățat toate metodele de sortare înainte să treacă interviul și acum consideră că „fiecare bun programator ar trebui să știe pe de rost implementarea găsirii unui palindrom într-un string”.
Așadar, nu ești Google (c). Ce poate Google să își permită, companiile obișnuite nu pot. Google, analizând datele angajaților săi, a ajuns la concluzia că exact angajații cu un trecut olimpic se descurcă bine cu sarcinile specifice. Mai mult, construind procesul de selecție, își pot permite să își asume riscul că nu vor angaja câțiva ingineri buni pentru că nu știu să rezolve atât de ușor probleme matematice. Dar pentru ei nu e o problemă, există mulți doritori să lucreze la Google, poziția se va ocupa.
Acum să privim pe fereastră, și dacă în fața biroului vostru nu au fost încă înființate tabere de ingineri care vor să lucreze pentru voi, iar dezvoltatorii voștri caută mai des pe stackoverflow ce anotare Spring trebuie să folosească, în loc de detaliile algoritmilor de clasificare, atunci, se pare, că este timpul să vă gândiți dacă merită să copiați Google.
Bine, dacă de această dată Google v-a dezamăgit și nu a oferit un răspuns, ce să faceți? Să verificați exact ce va face dezvoltatorul în muncă. Ce apreciați la dezvoltatori?
Stabiliți criteriile pentru cine doriți să angajați și dezvoltați teste care verifică exact aceste abilități.
ThoughtWorks
Și ce legătură are ThoughtWorks? Aici am găsit un exemplu de interviu exemplar. Cine sunt ThoughtWorks? Pe scurt, aceasta este o companie de consultanță de înaltă calitate cu birouri în întreaga lume, de la China și Singapore până la continentele americane, care oferă consultanță în domeniul dezvoltării de aproximativ 25 de ani, având un departament științific condus de Martin Fowler. Dacă căutați o listă cu 10 cărți pe care trebuie să le citiți pentru inginerii software, probabil 2-3 dintre ele vor fi scrise de oamenii de la ThoughtWorks, cum ar fi Refactoring de Martin Fowler și Building Microservices: Designing Fine-Grained Systems by Sam Newman sau Building Evolutionary Architectures.
de Patrick Kua, Rebecca Parsons, Neal Ford.
Modelul de afaceri al companiei se bazează pe furnizarea de servicii destul de scumpe, dar clientul plătește pentru o calitate fenomenală, care constă din expertiză, standarde interne și, desigur, oameni. De aceea, este vital să angajezi oamenii potriviți.
Cine sunt însă oamenii potriviți? Desigur, fiecare are standardele sale. ThoughtWorks a definit că pentru modelul lor de afaceri, cele mai importante criterii pentru dezvoltatori sunt:
- Capacitatea de a lucra în pereche. Exact, capacitatea, nu experiența sau abilitatea. Nimeni nu se așteaptă ca oamenii să vină deja cu 5 ani de experiență în programarea în pereche. Dar să fii receptiv la opiniile altora, să știi să asculți — aceasta este o abilitate necesară.
- Capacitatea de a scrie teste, iar idealul ar fi practicarea TDD.
- Să înțeleagă SOLID și OOP și să știe să le aplice.
- Să își prezinte opinia. Consultantul trebuie să lucreze cu dezvoltatorii clientului, cu alți consultanți și nu este de mare folos dacă cineva știe să facă ceva bine, dar este complet incapabil să comunice asta celorlalți membri ai echipei.
Acum este important să evaluăm aceste abilități la candidat. Și aici vreau să povestesc despre experiența mea la interviul de angajare la ThoughtWorks. Voi spune din start că am fost la interviu în Singapore și am reușit, dar procesul de recrutare este unificat și nu va varia semnificativ de la o țară la alta.
Etapa 0. HR
Așa cum se întâmplă adesea, interviul cu HR-ul durează 20 de minute. Nu mă voi opri asupra lui, voi menționa doar că nu am întâlnit niciodată un HR care să poată vorbi 15 minute despre cultura de dezvoltare din companie, de ce aplică TDD, de ce programarea în pereche. De obicei, la această întrebare HR-ii devin mai tăcuți și povestesc că procesul lor este obișnuit: dezvoltatorii dezvoltă, testeri testează, managerii conduc.
Etapa 1. Cât de bine te descurci cu OOP, TDD?
Cu 1.5 ore înainte de interviu mi s-a trimis o sarcină de a crea un simulator pentru Mars Rover.
Sarcina Mars roverO echipă de roveri robotizați urmează să fie aterizată de NASA pe un platou pe Marte. Acest platou, care este curioasă rectangular, trebuie navigat de roveri astfel încât camerele lor onboard să obțină o vedere completă a terenului din jur pentru a trimite înapoi pe Pământ. Poziția și locația unui rover sunt reprezentate printr-o combinație de coordonate x și y și o literă care reprezintă una dintre cele patru puncte cardinale. Platoul este împărțit într-o grilă pentru a simplifica navigarea. O poziție exemplu ar putea fi 0, 0, N, ceea ce înseamnă că roverul este în colțul din stânga jos și se îndreaptă spre Nord. Pentru a controla un rover, NASA trimite un simplu șir de litere. Literele posibile sunt 'L', 'R' și 'M'. 'L' și 'R' fac roverul să se rotească cu 90 de grade la stânga sau la dreapta, respectiv, fără a se mișca din locul său curent. 'M' înseamnă să se deplaseze înainte cu un punct de grilă, păstrând aceeași direcție.
Presupunem că pătratul direct la Nord de (x, y) este (x, y+1).
INPUT:
Prima linie de input este coordonatele superioare-drepte ale platoului, coordonatele inferioare-stânga fiind presupuse a fi 0,0.
Restul inputului se referă la informațiile privind roverii care au fost desfășurați. Fiecare rover are două linii de input. Prima linie oferă poziția roverului, iar a doua linie este o serie de instrucțiuni care spun roverului cum să exploreze platoul. Poziția este compusă din două întregi și o literă separate prin spații, corespunzătoare coordonatelor x și y și orientării roverului.
Fiecare rover va fi terminat secvențial, ceea ce înseamnă că al doilea rover nu va începe să se miște până când primul nu și-a terminat mișcările.
OUTPUT:
Ieşirea pentru fiecare rover ar trebui să fie coordonatele finale și orientarea acestuia.
NOTES:
Implementați pur și simplu cerințele de mai sus și dovediți că un aspirator funcționează prin scrierea de teste unitare pentru acesta.
Crearea oricărei forme de interfață utilizator este în afara domeniului de aplicare.
Rezolvarea problemei urmând o abordare TDD (Test Driven Development) va fi preferată.
În timpul scurt disponibil, suntem mai preocupați de calitate decât de completitudine.
*Nu pot publica sarcina pe care mi-au trimis-o, este o sarcină veche, care a fost dată cu câțiva ani în urmă. Dar credeți-mă, principiul a rămas același.
Este important să ne concentrăm asupra criteriilor de evaluare. Câteodată te confrunți cu situații în care aspecte esențiale pentru candidatul respectiv nu au nicio relevanță în procesul de verificare și invers. Nu toată lumea gândește la fel ca tine, dar mulți pot adopta valorile tale dacă acestea sunt formulate clar. Așadar, din criteriile de evaluare se înțelege imediat că cele mai importante abilități în această etapă sunt
- TDD;
- Capacitatea de a utiliza OOP și de a scrie cod întreținut;
- abilitățile de programare în pereche
Așadar, am fost avertizat să dedic aceste 1,5 ore gândindu-mă la modul în care voi aborda sarcina, nu la scrierea codului. Codul va fi scris împreună.
Când ne-am sunat, băieții mi-au explicat pe scurt cine sunt și cu ce se ocupă și au propus să începem dezvoltarea.
În întreaga durată a interviului nu am avut niciodată senzația că mă aflu într-un interviu. Există o senzație că dezvolți cod împreună cu o echipă. Dacă te blochezi undeva — ei te ajută, îți oferă sfaturi, discută, chiar și se contrazic între ei despre modul în care ar fi mai bine să facă. La interviu am uitat cum să verific în JUnit 5 că o metodă aruncă o excepție — ei au propus să continui să scriu testul, în timp ce unul dintre ei căuta pe Google cum să facă asta.
La câteva ore după interviu am primit un feedback constructiv — ce a plăcut și ce nu. În cazul meu, am fost lăudat pentru utilizarea claselor Sealed ca alternativă la obiectul null; pentru că înainte de a scrie codul am scris pseudocod despre cum aș dori să controlez roverul, și astfel am obținut o schiță a claselor, cel puțin a celor implicate în API-ul robotului.
Etapa 2. Spune-ne
Cu o săptămână înainte de interviu, am fost rugat să pregătesc o prezentare despre orice temă care mă interesează. Formatul este simplu și familiar: 15 minute de prezentare, 15 minute de răspunsuri la întrebări.
Am ales Clean Architecture de la Uncle Bob. Și din nou, am fost intervievat de câțiva oameni. A fost prima mea experiență de prezentare în engleză și, probabil, dacă aș fi fost într-o situație stresantă - nu aș fi făcut față. Dar, din nou, nu am avut niciodată senzația că sunt la un interviu. Totul a fost ca de obicei - eu povestesc, ei ascultă cu atenție. Chiar și sesiunea tradițională de întrebări și răspunsuri nu a semănat cu un interviu, era evident că întrebările erau formulate nu pentru a „sufoca”, ci pentru că le interesa cu adevărat prezentarea mea.
La câteva ore după interviu am primit feedback - prezentarea a fost foarte utilă și ei au avut o plăcere sinceră să o asculte.
Etapa 3. Cod de Calitate pentru Produse
Anunțând că aceasta este ultima etapă a interviurilor tehnice, am fost rugat să finalizez acasă codul pentru a fi gata pentru producție, după care să trimit codul pentru revizuire și să stabilesc interviuri, în care cerințele pentru sarcină se vor schimba și codul va necesita modificări. Ca să-mi anticiphez răspunsul, pot spune că revizuirea codului se face fără a avea informații, revizorii nu știu nici poziția pentru care candidează candidatul, nu văd CV-ul său, nici nu știu numele său.
Conversație telefonică și, din nou, câțiva băieți de cealaltă parte a monitorului. Totul ca la primul interviu: cel mai important este să nu uiți de TDD, să explici ce faci și de ce. Dacă nu ai practicat TDD înainte, îți recomand să începi imediat să o faci, nu pentru că este necesar în companii, ci pentru că îți simplifică considerabil viața și îți reduce nivelul de stres, dacă vrei. Îți amintești cum trebuia să cauți disperat cu debugger-ul o eroare care apare doar în browser și nu poți să o reproduci cu teste? Acum imaginează-ți că trebuie să depistezi o astfel de eroare în timpul interviului — câteva fire de păr alb îți sunt asigurate. Ce ne oferă TDD? Schimbi codul și, surprinzător, observi că testează sunt eșuate, iar eroarea nu o poți identifica din prima? Ok, spunem intervievatorilor „Ups”, apăsăm Ctrl-Z și începem să avansăm cu pași mici. Și da, abilitatea de a dezvolta folosind TDD trebuie cultivată, abilitatea de a merge spre obiectiv astfel încât testele tale să fie permanent verzi și nu roșii câteva ore pentru că „ai un refactoring complex”. Este exact aceeași abilitate ca și capacitatea de a scrie cod întreținut sau performant.
Așadar, cât de bine se poate adapta codul tău la schimbări depinde de designul pe care l-ai implementat inițial, cât de simplu este acesta și cât de bune sunt testele tale.
După interviu, am primit feedback în câteva ore. În acest moment, am realizat că practic am trecut și mai rămânea foarte puțin până la „întâlnirea cu Fowler”.
Etapa 4. Final. O mulțime de întrebări tehnice. Vrem să știm cine ești!
Sincer, această abordare m-a lăsat puțin confuz. Cum poți să îți dai seama ce fel de om sunt eu în doar o oră de conversație? Și cu atât mai mult, cum poți înțelege asta, când vorbesc într-o limbă care nu îmi este maternă și, sincer, nu o stăpânesc foarte bine? La interviurile anterioare, mi-a fost mai ușor să povestesc decât să răspund la întrebări, iar accentul a fost de vină. Cel puțin unul dintre intervievatori era asiatic — iar accentul lor, să spunem așa, este puțin specific pentru urechea europeană. Așa că am decis să adopt o abordare proactivă — să pregătesc o prezentare despre mine și să le propun să vorbesc despre mine folosind această prezentare la începutul interviului. Dacă vor accepta — atunci vor fi cu siguranță mai puține întrebări pentru mine, iar dacă vor refuza oferta — ei bine, 3 ore din viața mea consacrate unei prezentări nu sunt un preț atât de mare. Dar ce ar trebui să scriu în prezentare? O biografie — M-am născut acolo, atunci, am mers la școală, am terminat universitatea — cui îi pasă de asta?
Dacă faci puțin research despre cultura Thoughtworks, vei găsi un articol de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], în care sunt descriși cei 3 Piloni: Afaceri Sustenabile, Excelență în Software și Justiție Socială.
Presupunem că Excelența în Software a fost deja verificată. Rămâne să demonstrez Afaceri Sustenabile și Justiție Socială.
În plus, am decis să pun accentul pe ultimul.
Mai întâi am explicat de ce ThoughtWorks — citeam blogul lui Martin Fowler din facultate, de aici și dragostea mea pentru Cod Curat.
Proiectele pot fi prezentate din diferite perspective. Am dezvoltat software pentru medicină, care a simplificat viața pacienților și, după cum se zvonește, a salvat o viață. Am dezvoltat și software pentru bănci, care, de asemenea, a simplificat viața cetățenilor. În special dacă această bancă este utilizată de aproximativ 70% din populația țării. Nu mă refer la Sberbank și nici măcar la Rusia.
Vrei să afli mai multe despre mine? Ok. Hobby-ul meu este fotografia, de ceva vreme am mereu un aparat foto în mână, am fotografii pe care nu îmi este prea rușine să le arăt. De asemenea, o perioadă am ajutat un adăpost pentru pisici: am fotografiat pisici care aveau nevoie de un cămin permanent. Și cu fotografii bune, este mult mai ușor să găsești o familie pentru o pisică. Probabil am fotografiat în jur de o sută de pisici 🙂
În cele din urmă, 80% din prezentare era despre pisici.
Imediat după prezentare, HR-ul mi-a scris că încă nu știe rezultatele interviului, dar întreaga echipă este impresionată de pisici.
În cele din urmă, am așteptat feedback-ul — am satisfăcut pe toți ca persoană.
Dar HR-ul, în timpul discuției finale, a menționat cu delicatețe că Justiția Socială este foarte bine și necesară, dar nu toate proiectele sunt așa. Și a întrebat dacă mă sperie acest lucru. În general, am exagerat puțin cu Justiția Socială, se mai întâmplă 🙂
Rezultatul
Ca urmare, lucrez deja de câteva luni în Singapore la Thoughtworks, observ că și aici multe companii adoptă "cele mai bune practici de interviu" din Google, folosind foi și Whiteboard pentru codare, având în vedere că cunoștințele dincolo de Spring, Symfony, RubyOnRails (subiectul necesar) nu sunt necesare la locul de muncă. Inginerii iau o săptămână liberă înainte de interviu pentru a "se pregăti".
La Thoughtworks, pe lângă cerințele adecvate pentru candidați, se pun în frunte astfel de principii:
Bucuria Interviului. Asta este valabil pentru ambele părți. Cu adevărat, dacă doriți să obțineți cele mai bune talente (și cine nu își dorește?), interviul nu este o piață unde se aleg sclavi, ci o întâlnire unde atât angajatorul, cât și candidatul se evaluează reciproc. Și dacă candidatul asociază compania cu emoții plăcute — este foarte probabil că va alege exact această companie.
Intervievatori multipli pentru a reduce prejudecățile. La Thoughtworks, programarea în pereche este standard de facto. Și dacă această practică poate fi aplicată în alte domenii, TW încearcă să o facă. La fiecare etapă, interviul este condus de 2 persoane. Astfel, fiecare persoană este evaluată de cel puțin 8 oameni, iar TW se străduiește să aleagă intervievatori cu diverse backgrounduri, din diferite domenii (nu doar tehnici) și sexe.
În cele din urmă, decizia de angajare va fi luată pe baza opiniei a cel puțin 8 persoane, iar nimeni nu are drept de vot decisiv.
Angajarea bazată pe atribute În loc să ia o decizie pe baza „îmi place / nu-mi place” a candidatului, pentru fiecare rol și pentru fiecare etapă a fost elaborat un formular care include atributele evaluate. În acest sens, se recomandă foarte mult să se evalueze nu experiența într-o anumită abilitate, ci capacitatea de a o aplica. Astfel, dacă un candidat nu a avut ocazia să aplice anumite abilități, cum ar fi TDD, dar totuși face eforturi să le aplice, ascultă sfaturile privind utilizarea corectă - are toate șansele să treacă interviul.
Certificatul de educație nu este necesar TW nu cere de la candidat certificatul sau educația obligatorie în știința calculatoarelor. Se evaluează doar abilitățile.
Acesta a fost primul interviu, din cele pe care le-am avut la companii străine, pentru care nu a trebuit să mă pregătesc. După fiecare etapă, nu m-am simțit ca o lămâie stoarsă, dimpotrivă, am fost bucuros că pot aplica cele mai bune practici, că oamenii de cealaltă parte a monitorului apreciază asta și le aplică și ei în fiecare zi.
După câteva luni, pot spune că așteptările s-au îndeplinit complet. Ce diferențiază ThoughtWorks de o companie obișnuită? Într-o companie obișnuită poți găsi dezvoltatori buni și oameni plăcuți, dar în TW concentrația lor este incredibil de mare.
Dacă doriți să vă alăturați ThoughtWorks, puteți vizualiza locurile de muncă disponibile
De asemenea, vă sugerez să acordați atenție locurilor de muncă interesante:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastructură: , ,
(Vreau să vă avertizez că linkul este de referință, dacă ajungeți la TW, voi primi un bonus plăcut). Alegeți biroul care vă place, nu trebuie să fiți limitați doar la Europa, în fond, la fiecare 2 ani TW va fi fericit să vă mute într-o altă țară, deoarece aceasta este parte din politica ThoughtWorks, astfel cultura se răspândește și se uniformizează.
Nu ezitați să puneți întrebări în comentarii sau să-mi cereți să vă recomand.
Dacă subiectul vi se pare interesant, voi scrie despre cum este să lucrezi la ThoughtWorks și cum este viața în Singapore.
Sursa: habr.com
