Synes du ikke, det er mærkeligt, at når du planlægger at skifte job og oplever behovet for at gå til en samtale, så tænker du først "jeg skal forberede mig til samtalen". Du skal arbejde med opgaver på HackerRank, læse Crack the Coding Interview, lære, hvordan ArrayList fungerer, og hvad der adskiller den fra LinkedList. Åh ja, og de kan også spørge om sortering, og det vil helt klart være uprofessionelt at sige, at quick sort sandsynligvis vil være det bedste valg.
Men vent, du programmerer jo 8 timer om dagen, løser interessante og ikke-trivielle opgaver, og på dit nye job vil du stort set lave det samme. Alligevel er det nødvendigt at forberede sig på en eller anden måde til samtalen, ikke ved at forfine dine daglige færdigheder, men ved at lære det, du ikke har haft brug for på dit nuværende job, og som du nok heller ikke vil få brug for på det næste. I dit forsvar, om at computer science ligger i vores blod, og at vi, hvis vi bliver vækket om natten, skal kunne skrive bredden af et træ med lukkede øjne på en pude, selv uden at være vågen, vil jeg svare, at hvis jeg skulle arbejde i et circus, og min hovedtrick skulle være netop det — så måske ja, så er jeg enig. Den færdighed skal testes.
Men hvorfor skulle man teste irrelevante færdigheder til det nuværende job? Bare fordi det er blevet populært? Fordi Google gør det? Eller fordi din kommende teamleder måtte lære alle sorteringsmetoder, før han gik til samtalen, og nu mener, at "hver god programmør skal kunne recitere implementeringen af at finde en palindrom i en streng fra hukommelsen".
Så, du er ikke Google. Hvad Google har råd til, kunne normale virksomheder ikke. Google har, efter at have analyseret data fra deres medarbejdere, konkluderet, at netop i deres tilfælde klarer ingeniører med en olympisk baggrund deres opgaver godt. Desuden, når de bygger rekrutteringsprocessen, kan de tillade sig at tage risikoen for, at de måske ikke ansætter flere gode ingeniører, fordi de ikke kan løse matematiske opgaver så let. Men for dem er det ikke et problem, der er mange, der ønsker at arbejde i Google, og stillingen vil blive besat.
Lad os nu kigge ud af vinduet, og hvis der stadig står ingeniører foran dit kontor, der ønsker at arbejde for dig, og dine udviklere oftere søger på stackoverflow efter den nyeste Spring-annotation de skal bruge, snarere end nuancerne i rangordningsalgoritmer, så er det tydeligt, at det er tid for dig at overveje, om du skal kopiere Google.
Hvad nu hvis Google svigtede denne gang og ikke gav et svar? Hvad skal man så gøre? Tjek nøjagtigt det, som udvikleren vil lave i arbejdet. Hvad værdsætter du hos udviklere?
Opret kriterier for, hvem du ønsker at ansætte, og udvikle tests, der netop tester disse færdigheder.
ThoughtWorks
Hvad har ThoughtWorks med det at gøre? Her fandt jeg et eksempel på et perfekt interview. Hvem er ThoughtWorks? Kort sagt, det er et High-End konsulentfirma med kontorer over hele verden, fra Kina og Singapore til Amerika, der har beskæftiget sig med udviklingsrådgivning i cirka 25 år og har deres eget Science-afdeling, ledet af Martin Fowler. Hvis du søger efter en liste over 10 bøger, som man skal læse som Software Engineer, vil nok 2-3 af dem være skrevet af folk fra ThoughtWorks, som f.eks. Refactoring af Martin Fowler og Building Microservices: Designing Fine-Grained Systems af Sam Newman eller Building Evolutionary Architectures.
af Patrick Kua, Rebecca Parsons, Neal Ford.
Virksomhedens forretning er baseret på at levere ret dyre tjenester, men kunden betaler for den fremragende kvalitet, der skabes af ekspertise, interne standarder og selvfølgelig mennesker. Derfor er det livsvigtigt at ansætte de rigtige mennesker her.
Hvem er så de rigtige mennesker? Selvfølgelig er det forskellige for hver. ThoughtWorks har bestemt, at for deres forretningsmodel er de vigtigste kriterier for udviklere:
- Evnen til at arbejde i par. Det er netop evnen og ikke erfaring eller kunnen. Ingen forventer, at folk kommer, der har praktiseret Pair programming i 5 år. Men det at være åben for andres meninger og kunne lytte - det er en nødvendig færdighed.
- Evnen til at skrive tests, og ideelt set praktisere TDD.
- Forstå SOLID og OOP og være i stand til at anvende dem.
- Præsentere sin mening. Som konsulent skal man arbejde med kundens udviklere, med andre konsulenter, og der er ikke meget nytte i, hvis en person kan gøre noget godt, men helt ude af stand til at formidle det til de øvrige teammedlemmer.
Det er nu vigtigt at vurdere netop disse færdigheder hos kandidaten. Og her vil jeg gerne dele min erfaring med at gå til samtale hos ThoughtWorks. Jeg vil sige med det samme, at jeg gik til samtale i Singapore og bestod, men rekrutteringsprocessen er standardiseret og vil ikke adskille sig meget fra land til land.
Trin 0. HR
Som det ofte er tilfældet, en 20 minutters samtale med HR. Jeg vil ikke dvæle ved det, jeg vil blot sige, at jeg aldrig før har mødt en HR-ansvarlig, der kunne tale i 15 minutter om udviklingskulturen i virksomheden, hvorfor de bruger TDD, og hvorfor parprogrammering er vigtigt. Normalt falder HR'er hen på dette spørgsmål og fortæller, at deres proces er almindelig: udviklerne udvikler, testerne tester, og lederne holder styr på det.
Trin 1. Hvor dygtig er du til OOP, TDD?
1,5 time før samtalen fik jeg tilsendt en opgave om at lave en simulator til Mars Rover.
Opgaven Mars roverEt hold af robot-rovere skal landes af NASA på en plateau på Mars. Dette plateau, som er bemærkelsesværdigt rektangulært, skal navigeres af roveren, så dens ombordkameraer kan få en fuldstændig oversigt over det omkringliggende terræn, som skal sendes tilbage til Jorden. En rovers position og lokation repræsenteres af en kombination af x- og y-koordinater og et bogstav, der repræsenterer en af de fire kardinalretninger. Plateauet er opdelt i et gitter for at forenkle navigationen. En eksempelposition kunne være 0, 0, N, hvilket betyder, at roveren befinder sig i det nederste venstre hjørne og vender mod nord. For at kontrollere en rover sender NASA en simpel streng af bogstaver. De mulige bogstaver er 'L', 'R' og 'M'. 'L' og 'R' får roveren til at dreje 90 grader til venstre eller højre henholdsvis, uden at flytte sig fra sin nuværende plads. 'M' betyder at flytte et gridpunkt fremad og bevare den samme retning.
Antag, at kvadratet direkte nord for (x, y) er (x, y+1).
INDDATA:
Den første linje af input er de øverste højre koordinater af plateauet, de nederste venstre koordinater antages at være 0,0.
Resten af input er information vedrørende de rover, der er blevet sendt ud. Hver rover har to linjer med input. Den første linje giver roverens position, og den anden linje er en række instruktioner, der fortæller roveren, hvordan den skal udforske plateauet. Positionen består af to heltal og et bogstav adskilt af mellemrum, der svarer til x- og y-koordinaterne og roverens orientering.
Hver rover vil blive afsluttet sekventielt, hvilket betyder, at den anden rover ikke vil begynde at bevæge sig, før den første er færdig med at bevæge sig.
UDDATA:
Output for hver rover skal være dens endelige koordinater og retning.
NOTER:
Implementer blot kravene ovenfor og bevis, at en støvsuger fungerer ved at skrive enhedstest for den.
At skabe en form for brugergrænseflade er uden for omfanget.
At løse problemet ved at følge en TDD (Test Drevet Udvikling) tilgang vil være at foretrække.
I den korte tid, der er til rådighed, er vi mere bekymrede over kvalitet end fuldstændighed.
*Jeg kan ikke offentliggøre den opgave, jeg fik tilsendt, da det er en gammel opgave, der blev givet for flere år siden. Men tro mig, princippet er stadig det samme.
Det er vigtigt at understrege vurderingskriterierne. Hvor mange gange har du været i situationer, hvor ting, der er vigtige for kandidaten, slet ikke har haft betydning ved vurderingen og omvendt? Ikke alle tænker som dig, men mange kan adoptere dine værdier og følge dem, hvis de præsenteres klart. Så ud fra vurderingskriterierne er det straks klart, at de vigtigste færdigheder på dette stadium er
- TDD;
- Evnen til at anvende OOP og skrive vedligeholdelseskode;
- færdigheder inden for parprogrammering
Så jeg blev advaret om, at jeg skulle bruge de 1.5 timer på at tænke over, hvordan jeg ville gå til opgaven, i stedet for at skrive kode. Koden skal vi skrive sammen.
Da vi talte sammen, gav drengene en kort introduktion til, hvem de er, og hvad de laver, og foreslog at starte udviklingen.
Under hele interviewet følte jeg ikke én gang, at jeg var til samtale. Det føles som om, du udvikler kode i et team. Hvis du sidder fast et sted, hjælper de, rådgiver, diskuterer, endda diskuterer indbyrdes, hvordan det bedst kan gøres. Under en samtale glemte jeg, hvordan jeg i JUnit 5 kan teste, at en metode kaster en undtagelse — de foreslog at fortsætte med at skrive testen, mens en af dem googler, hvordan man gør det.
Kun få timer efter interviewet modtog jeg konstruktiv feedback — hvad jeg gjorde godt, og hvad der kunne forbedres. I mit tilfælde blev jeg rost for at bruge Sealed-klasser som et alternativ til nul-objektet; for at have skrevet pseudokode om, hvordan jeg gerne ville styre roverens funktioner, og dermed fået en skitse af de klasser, der i det mindste blev involveret i robotens API.
Trin 2. Fortæl os
En uge før interviewet blev jeg bedt om at forberede en præsentation om et emne, der interesserede mig. Formatet er enkelt og velkendt: 15 minutters præsentation, 15 minutters spørgsmål og svar.
Jeg valgte Clean Architecture af Uncle Bob. Og igen blev jeg interviewet af et par personer. Det var min første erfaring med at præsentere på engelsk, og jeg må sige, at hvis jeg havde været i en stressende situation — så ville jeg ikke have klaret det. Men på den anden side, havde jeg aldrig følelsen af, at jeg var til intervju. Alt var som normalt — jeg fortalte, og de lyttede opmærksomt. Selv den traditionelle spørgerunde lignede ikke et interview, det var tydeligt, at spørgsmålene blev stillet, fordi de virkelig var interesserede i min præsentation.
Et par timer efter interviewet fik jeg feedback — præsentationen var meget nyttig, og de havde oprigtigt nydt at lytte.
Trin 3. Produktions Kvalitet Kode
Ved at informere om, at dette var det sidste trin i de tekniske interviews, blev jeg bedt om at gøre koden klar til produktion derhjemme og derefter sende koden til gennemgang og planlægge et interview, hvor kravene til opgaven ville ændre sig, og koden ville kræve modificeringer. For at skynde mig frem kan jeg sige, at kodens gennemgang udføres blindt; gennemgangerne kender hverken den position, som kandidaten søger, ser ikke CV'et, og ser endda ikke hans navn.
Samtale, og igen et par fyre på den anden side af skærmen. Alt som til den første samtale: det vigtigste er at huske på TDD, fortælle hvad du gør og hvorfor. Hvis du ikke har praktiseret TDD før, så anbefaler jeg at begynde med det med det samme, ikke fordi det er nødvendigt i virksomheder, men fordi det gør dit liv betydeligt nemmere og reducerer dit stressniveau, hvis du vil. Kan du huske, hvordan du måtte panisk lede efter en fejl ved hjælp af debuggeren, som kun kunne reproduceres gennem browseren, mens du ikke kunne få den til at vise sig ved testene? Forestil dig nu, at du skal fange en sådan fejl under en samtale — et par grå hår er sikret for dig. Hvad får vi med TDD? Ændrede koden og pludselig indser du, at testene nu er røde, og at du ikke kan finde fejlen ved første forsøg? Okay, vi siger til interviewerne “Ups”, trykker Ctrl-Z og begynder at tage små skridt fremad. Ja, evnen til at udvikle ved hjælp af TDD skal udvikles i dig, evnen til at gå efter målet, så du har permanent grønne tests og ikke røde halvdagen, fordi “du har en stor refactoring”. Det er præcis den samme færdighed som at kunne skrive vedligeholdelseskode eller performant kode.
Så hvor godt din kode kan ændres afhænger af, hvilken design du oprindeligt har lagt, hvor enkelt det er, og hvor gode dine tests er.
Efter interviewet fik jeg feedback nogle timer senere. På dette tidspunkt indså jeg, at jeg næsten var i mål, og der var kun lidt tilbage til “mødet med Fowler”.
Trin 4. Finalen. Tilstrækkeligt tekniske spørgsmål. Vi vil vide, hvem du er!
Ærligt talt, blev jeg lidt forvirret over denne problemstilling. Hvordan kan man forstå, hvilken slags person jeg er efter en times samtale? Og hvordan kan man gøre det, når jeg taler på et sprog, der ikke er mit modersmål, og, må jeg sige, ret klodset og ubehjælpeligt. Ved tidligere interviews fandt jeg det lettere at fortælle om mig selv end at besvare spørgsmål, og skylden ligger hos min accent. I det mindste var en af interviewerne asiat — og deres accent er, lad os sige, ret speciel for et europæisk øre. Derfor besluttede jeg mig for at tage en proaktiv tilgang — forberedte en præsentation om mig selv og foreslog at præsentere mig selv med denne præsentation i begyndelsen af interviewet. Hvis de accepterer, vil der i det mindste være færre spørgsmål til mig, og hvis de afviser tilbuddet — ja, så er tre timer af mit liv brugt på præsentationen ikke en så høj pris. Men hvad skal jeg skrive i præsentationen? Biografi — Født her og der, hvornår, gik i skole, afsluttede universitet — hvem er egentlig interesseret i det?
Hvis man søger lidt om kulturen hos Thoughtworks, kan man finde en artikel af Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], hvor der beskrives Tre Søjler: Bæredygtig Forretning, Softwar Excellence og Social Retfærdighed.
Antag, at Software Excellence allerede er blevet vurderet hos mig. Der resterede at vise Bæredygtig Forretning og Social Retfærdighed.
Jeg besluttede mig for at lægge fokus på det sidste.
For at starte fortalte jeg, hvorfor ThoughtWorks er vigtigt for mig — jeg læste Martin Fowlers blog allerede på universitetet, deraf min kærlighed til Clean code.
Projekter kan også præsenteres fra forskellige vinkler. Jeg har udviklet software til medicin, der gjorde livet lettere for patienter, og ifølge rygter har det endda reddet et liv. Jeg har også udviklet software til banker, hvilket også er en slags forenkling af borgernes liv. Især hvis denne bank anvendes af omkring 70% af landets befolkning. Det handler ikke om Sberbank eller engang Rusland.
Vil du vide mere om mig? Okay. Min hobby er fotografering; jeg har på en eller anden måde haft et kamera i hånden i ca. 10 år, og jeg har billeder, som jeg ikke skammer mig over at vise. Også, i en periode, hjalp jeg et katteinternat: jeg fotograferede katte, der havde brug for et permanent hjem. Og med gode fotos er det meget lettere at finde et hjem til en kat. Jeg har nok taget billeder af omkring hundrede katte 🙂
I sidste ende var 80% af præsentationen fyldt med katte.
Lige efter præsentationen skrev HR til mig, at han endnu ikke kendte resultaterne af interviewet, men at hele kontoret allerede var imponerede over kattene.
I sidste ende fik jeg feedback — alle var tilfredse med mig som person.
Men HR nævnte i den afsluttende samtale taktfuldt, at Social Justice er meget godt og nødvendigt, men ikke alle projekter er sådan. Og han spurgte, om det skræmte mig. Så jeg overdrevede lidt med Social Justice, det kan ske 🙂
Resultat
Som resultat arbejder jeg allerede i flere måneder i Singapore hos Thoughtworks, og jeg ser, at mange virksomheder her også adopterer "bedste interviewpraksis" fra Google, ved at bruge noter og Whiteboard til kodning, selvom viden længere end Spring, Symfony, RubyOnRails (det nødvendige understreges) ikke kræves i arbejdet. Ingeniører tager en uges ferie før interviewet for at "forberede sig".
I Thoughtworks er der ud over rimelige krav til kandidaten også fokus på følgende principper:
Joy of Interviewing. Som begge parter. Faktisk, hvis du vil have de bedste medarbejdere (hvem ønsker ikke det?), så er interviewet ikke et marked, hvor man vælger slaver, men en vurdering, hvor både arbejdsgiveren og kandidaten bedømmer hinanden. Og hvis kandidaten forbinder behagelige følelser med virksomheden, er det meget sandsynligt, at han vælger netop denne virksomhed.
Multiple interviewers to mitigate bias. I Thoughtworks er parprogrammering standarden de facto. Og hvis denne praksis kan anvendes i andre områder, forsøger TW at gøre det. På hver fase gennemføres interviewet af 2 personer. På den måde vurderer mindst 8 personer hver enkelt, og TW forsøger at vælge interviewere med forskellige baggrunde, forskellige retninger (ikke kun teknikere) og køn.
Som resultat vil beslutningen om ansættelse blive truffet baseret på meningen fra mindst 8 personer, og ingen har ret til at have det afgørende ord.
Attribute-based hiring I stedet for at træffe en beslutning baseret på, om kandidaten "kan lide" jobbet, er der udviklet en formular for hver rolle og hvert trin, som inkluderer de vurderede attributter. Det anbefales at evaluere ikke kun en persons erfaring med en bestemt færdighed, men også evnen til at anvende den. Hvis en kandidat ikke har haft mulighed for at bruge færdigheder som TDD, men alligevel forsøger at anvende dem, og lytter til råd om korrekt brug – så har de alle chancer for at bestå interviewet.
Uddannelsesbeviser ikke påkrævet TW kræver ikke obligatoriske certifikater eller uddannelse i Computer Science fra kandidaten. Kun færdigheder vurderes.
Dette er det første interview, jeg har haft med udenlandske virksomheder, som jeg ikke skulle forberede mig til. Efter hvert trin følte jeg mig ikke udmattet som en citron; tværtimod var jeg glad for, at jeg kunne anvende bedste praksis, og at folk på den anden side af skærmen værdsætter det og anvender dem hver dag.
Efter nogle måneder kan jeg sige, at forventningerne er blevet opfyldt fuldt ud. Hvad adskiller ThoughtWorks fra almindelige virksomheder? I en almindelig virksomhed kan du finde gode udviklere og venlige mennesker, men i TW er koncentrationen af dem meget højere.
Hvis du ønsker at slutte dig til ThoughtWorks, kan du se åbne stillinger
Jeg vil også anbefale at tage et kig på interessante jobmuligheder:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastuktur: , ,
(Jeg vil gerne advare dig om, at dette er et referralslink. Hvis du bliver ansat i TW, vil jeg få en dejlig bonus). Vælg det kontor, der passer dig bedst; det er ikke nødvendigt kun at begrænse sig til Europa, da TW hvert andet år med glæde vil flytte dig til et andet land, da det er en del af ThoughtWorks' politik, der sikrer, at kulturen spreder sig og homogeniseres.
Tøv ikke med at stille spørgsmål i kommentarerne eller bede mig om at anbefale dig.
Hvis emnet virker interessant, vil jeg skrive om, hvordan det er at arbejde i ThoughtWorks og hvordan livet er i Singapore.
Kilde: habr.com
