Hvordan jeg kom til ThoughtWorks eller et eksempelintervju

Føles det ikke merkelig at når du skal bytte arbeidsplass og må forberede deg til intervju, tenker du først "jeg må forberede meg til intervjuet". Du må løse oppgaver på HackerRank, lese Crack the Coding Interview, pugge hvordan en ArrayList fungerer og hvordan den skiller seg fra LinkedList. Åh ja, de kan sikkert spørre om sortering, og det vil åpenbart være uprofesjonelt å si at quick sort mest sannsynlig vil være det beste valget.
Men vent litt, du programmerer jo åtte timer om dagen, løser interessante og komplekse oppgaver, og på den nye arbeidsplassen kommer du til å gjøre pluss-minus det samme. Likevel må du forberede deg på intervjuet, ikke bare finpusse daglige ferdigheter, men lære det du ikke har hatt bruk for verken i din nåværende jobb eller sannsynligvis vil ha bruk for i den neste. Til dine innvendinger om at datavitenskap ligger i blodet vårt, og at vi vil kunne skrive bredde-først-søk med lukkede øyne på et putevar selv om vi er halvsovende, vil jeg svare at dersom jeg skulle ansette i et sirkus, og min hovedtricks var nettopp dette — så ja, jeg ville vært enig. Jeg må teste denne ferdigheten.

Men hvorfor sjekke irrelevante ferdigheter for den nåværende jobben? Bare fordi det har blitt trendy? Fordi Google gjør det? Eller fordi din fremtidige teamleder måtte lære seg alle sorteringsmetodene før han gikk til intervju og nå mener at “hver god programmør bør kunne implementere palindromdeteksjon i en streng uten å tenke".

Så, du er ikke Google (c). Hva Google kan tillate seg, kan ikke ordinære selskaper. Google, etter å ha analysert dataene fra sine ansatte, kom frem til at for hans spesifikke oppgaver, er ingeniører med olympisk bakgrunn godt kvalifisert. Videre, når de bygger utvelgelsesprosessen, kan de tillate seg å ta risikoen for at de kanskje ikke ansetter noen gode ingeniører fordi de ikke kan løse matematiske oppgaver like lett. Men for dem er det ikke et problem, mange ønsker å jobbe i Google, stillingen vil bli besatt.
La oss nå se ut av vinduet, og hvis det fortsatt står ingeniører utenfor kontoret ditt som ønsker å jobbe for deg, og hvis utviklerne dine oftere søker på stackoverflow etter hvilken ny Spring-annotasjon de må bruke, i stedet for detaljene i rangeringalgoritmene, er det på tide å vurdere om det er fornuftig å kopiere Google.

Hva gjør du hvis Google denne gangen sviktet og ikke ga et svar? Sjekk nøyaktig det utvikleren skal gjøre på jobben. Hva verdsetter du hos utviklerne?
Lag kriterier for hvem du ønsker å ansette, og utvikle tester som sjekker nettopp disse ferdighetene.

ThoughtWorks

Hva har ThoughtWorks med dette å gjøre? Her fant jeg et eksempel på et forbilledlig intervju. Hvem er ThoughtWorks? Kort sagt, det er et høyere konsulentfirma med kontorer over hele verden fra Kina og Singapore til de amerikanske kontinentene, som har drevet med rådgivning innen utvikling i omtrent 25 år, og har sin egen forskningsavdeling ledet av Martin Fowler. Hvis du søker etter en liste med 10 bøker som er must-reads for programvareingeniører, vil kanskje 2–3 av dem være skrevet av folk fra ThoughtWorks, som for eksempel Refactoring av Martin Fowler og Building Microservices: Designing Fine-Grained Systems av Sam Newman eller Building Evolutionary Architectures.
av Patrick Kua, Rebecca Parsons, Neal Ford.

Selskapets virksomhet er bygget på å tilby kostbare tjenester, men kunden betaler for fenomenal kvalitet, som er et resultat av ekspertise, interne standarder og selvfølgelig menneskene. Derfor er det helt nødvendig å ansette de rette folkene.
Hvilke folk er de rette? Selvfølgelig er det opp til hver enkelt. ThoughtWorks har definert at for deres forretningsmodell er de viktigste kriteriene for utviklere:

• Evnen til parprogrammering. Det er evnen, ikke erfaring eller ferdigheter. Ingen forventer at folk som praktiserer parprogrammering i fem år, skal dukke opp. Men å være åpen for andres meninger, kunne lytte – det er en nødvendig ferdighet.
• Kunne skrive tester, og ideelt sett praktisere TDD.
• Forstå SOLID og OOP og kunne anvende dem.
• Presentere sine meninger. Som konsulent må man jobbe med utviklerne til kunden, med andre konsulenter, og det er ikke mye nytte i at en person kan gjøre noe bra, men er helt ute av stand til å formidle dette til de andre medlemmene av teamet.

Nå er det viktig å vurdere nettopp disse ferdighetene hos kandidaten. Jeg vil gjerne dele min erfaring fra intervjuet hos ThoughtWorks. Jeg kan si med én gang at jeg ble intervjuet i Singapore og klarte det, men rekrutteringsprosessen er standardisert og vil ikke variere mye fra land til land.

Fase 0. HR

Som det ofte skjer, var det et 20 minutters intervju med HR. Jeg vil ikke gå nærmere inn på dette, men jeg må si at jeg aldri før har møtt en HR-representant som kunne snakke i 15 minutter om utviklingskulturen i selskapet, hvorfor de bruker TDD, og hvorfor parprogrammering er viktig. Vanligvis pleier HR-er å bli stille om dette temaet og sier at prosessen deres er vanlig: utviklere utvikler, testere tester, og ledere overvåker.

Fase 1. Hvor god er du i OOP, TDD?

1,5 time før intervjuet fikk jeg tilsendt en oppgave om å lage en simulator for Mars Rover.

Oppgaven for Mars roverEt team av robotrovere skal settes ned av NASA på et platå på Mars. Dette platået, som er bemerkelsesverdig rektangulært, må navigeres av roverne slik at deres innebygde kameraer kan få en fullstendig oversikt over det omkringliggende terrenget for å sende tilbake til jorden. En rovers posisjon og beliggenhet representeres av en kombinasjon av x- og y-koordinater og et bokstav som representerer en av de fire kardinalretningene. Platået er delt inn i et rutenett for å forenkle navigering. Et eksempel på posisjon kan være 0, 0, N, som betyr at rover står nederst til venstre og vender mot nord. For å kontrollere en rover sender NASA en enkel streng av bokstaver. Mulige bokstaver er 'L', 'R' og 'M'. 'L' og 'R' får rover til å snu 90 grader til venstre eller høyre, henholdsvis, uten å bevege seg fra nåværende sted. 'M' betyr å bevege seg framover ett rutenettpunkt og opprettholde samme retning.
Anta at kvadratene direkte nord for (x, y) er (x, y+1).
INNGANG:
Den første linjen av inngangen er de øvre høyre koordinatene til platået, de nedre venstre koordinatene antas å være 0,0.
Resten av inngangen er informasjon om roverne som har blitt satt ut. Hver rover har to linjer med inngang. Den første linjen gir roverens posisjon, og den andre linjen er en serie instruksjoner som forteller rover hvordan den skal utforske platået. Posisjonen er sammensatt av to heltall og en bokstav delt med mellomrom, som tilsvarer x- og y-koordinatene og roverens orientering.
Hver rover vil bli ferdig sekvensielt, noe som betyr at den andre rover ikke vil begynne å bevege seg før den første er ferdig.
UTGANG:
Utmatningen for hver rover skal være dens endelige koordinater og retning.
NOTATER:
Implementer ganske enkelt kravene ovenfor og bevis at en støvsuger fungerer ved å skrive enhetstester for den.
Å lage noen form for brukergrensesnitt ligger utenfor omfanget.
Å løse problemet ved å følge en TDD (Test Driven Development) tilnærming vil bli foretrukket.
I den korte tiden vi har tilgjengelig, er vi mer opptatt av kvalitet enn fullstendighet.
*Jeg kan ikke dele oppgaven som ble sendt til meg, det er en gammel oppgave som ble gitt for flere år siden. Men tro meg, prinsippene er fremdeles de samme.

Det er viktig å merke seg vurderingskriteriene. Hvor mange ganger har du støtt på situasjoner der viktige ting for kandidaten ikke er viktige ved vurdering, og omvendt? Ikke alle tenker som deg, men mange kan akseptere dine verdier og følge dem hvis de blir klart angitt. Så, ut fra vurderingskriteriene, blir det tydelig at de viktigste ferdighetene på dette stadiet er

• TDD;
• Evne til å bruke OOP og skrive vedlikeholdbar kode;
• ferdigheter i parprogrammering

Så, jeg ble advart om at jeg skulle bruke de 1,5 timene på å tenke på hvordan jeg skal gjøre oppgaven, og ikke på å skrive kode. Koden skal vi skrive sammen.

Da vi snakket sammen, forklarte gutta kort hvem de var og hva de drev med, og foreslo å begynne utviklingen.

I løpet av hele intervjuet følte jeg aldri at jeg var på et intervju. Det føltes som om du utviklet kode i et team. Hvis du satt fast et sted — de hjelper, gir råd, diskuterer, til og med krangler med hverandre om hva som er best å gjøre. Under intervjuet glemte jeg hvordan jeg skulle sjekke i JUnit 5 at en metode kaster en Exception — de foreslo å fortsette å skrive testen, mens en av dem googlet hvordan dette skulle gjøres.

Bokstavelig talt noen timer etter intervjuet fikk jeg konstruktiv tilbakemelding — hva de likte og hva de ikke likte. I mitt tilfelle fikk jeg ros for bruken av Sealed-klasser som et alternativ til null-objektet; for det faktum at jeg før jeg skrev koden skrev pseudokoden om hvordan jeg ønsket å kontrollere rover, og dermed fikk jeg et utkast av klassene, i det minste de som er involvert i robotens API.

Trinn 2. Fortell oss

En uke før intervjuet ble jeg bedt om å forberede en presentasjon om et tema som interesserte meg. Formatet er enkelt og kjent: 15 minutters presentasjon, 15 minutters spørsmål og svar.
Eg valde Clean Architecture by Uncle Bob. Og igjen ble jeg intervjuet av et par personer. Dette var min første erfaring med å presentere på engelsk, og jeg må si at hvis jeg hadde vært i en stressende situasjon, ville jeg ikke klart det. Men igjen, jeg hadde aldri følelsen av at jeg var på et intervju. Alt var som vanlig — jeg forteller, de lytter nøye. Selv den tradisjonelle spørsmåls- og svarsesjonen lignet ikke på et intervju, det var tydelig at spørsmålene ikke ble stilt for å «svekke» meg, men var spørsmål som virkelig interesserte dem i presentasjonen min.

Et par timer etter intervjuet fikk jeg tilbakemelding — presentasjonen var veldig nyttig, og de fikk ekte glede av å lytte.

Trinn 3. Produksjonskvalitetskode

Etter å ha advart om at dette er det siste trinnet i de tekniske intervjuene, ble jeg bedt om å gjøre koden klar for produksjon hjemme, før jeg sendte koden til gjennomgang og satte opp et intervju der kravene til oppgaven ville endres og koden ville kreve modifikasjoner. For å komme til poenget, kan jeg si at kodereviewet skjer blindt; gjennomgangere vet verken hvilken stilling kandidaten søker på, ser ikke CV-en hans, og vet ikke engang navnet hans.

Samtale, og igjen et par gutter på den andre siden av skjermen. Alt som under det første intervjuet: husk å snakke om TDD, forklare hva du gjør og hvorfor. Hvis du ikke har praktisert TDD før, anbefaler jeg å begynne umiddelbart, ikke fordi det er nødvendig i selskapene, men fordi det betydelig forenkler livet ditt, reduserer stressnivået om du vil. Husk hvordan du måtte lete febrilsk etter feilen med debuggeren, som kun forekom i nettleseren, mens du ikke kunne reprodusere den med tester? Nå kan du forestille deg å måtte fange en slik feil under intervjuet - du vil garantert få et par grå hår. Hva får vi med TDD? Har du endret koden og innser plutselig at testene nå er røde, men du klarer ikke å forstå feilen med første forsøk? Greit, vi sier til intervjueren “Oops”, trykker Ctrl-Z og begynner å ta små skritt fremover. Og ja, evnen til å utvikle med TDD må du jobbe med, evnen til å nå målet slik at testene dine forblir permanent grønne, og ikke røde i halve dagen, fordi “du har en stor refaktorering”. Dette er akkurat den samme ferdigheten som å skrive vedlikeholdbar kode, eller ytelseseffektiv kode.

Så, hvor godt koden din kan endres, avhenger av hvilken design du opprinnelig la inn, hvor enkel den er og hvor gode testene dine er.

Etter intervjuet fikk jeg tilbakemelding etter noen timer. På dette stadiet forstod jeg at jeg nesten hadde bestått, og det var bare lite igjen før “møtet med Fowler”.

Trinn 4. Finale. Nok tekniske spørsmål. Vi vil vite hvem du er!

Ærlig talt, så har denne formuleringen av spørsmålet forvirret meg litt. Hvordan kan man forstå hva slags person jeg er etter en times samtale? Og enda mer, hvordan kan de forstå det når jeg snakker på et språk som ikke er mitt morsmål, og, for å være helt ærlig, ganske dårlig og klønete? På tidligere intervjuer har det vært lettere for meg å fortelle enn å svare på spørsmål, og skylden ligger på aksenten. Minst én av intervjuerne var asiat — og deres aksent kan, la oss si, være noe spesiell for et europeisk øre. Derfor bestemte jeg meg for å ta en proaktiv tilnærming — forberede en presentasjon om meg selv og i begynnelsen av intervjuet tilby å fortelle om meg selv med denne presentasjonen. Hvis de aksepterer — så vil det i det minste være færre spørsmål til meg, hvis de avslår — vel, tre timer av livet mitt brukt på presentasjonen er ikke så høy pris. Men hva skal jeg skrive i presentasjonen? Biografi — Jeg ble født der og da, gikk på skole, avsluttet universitetet — hvem bryr seg egentlig om det?

Hvis man googler litt om kulturen i Thoughtworks, kan man finne en artikkel av Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], der de 3 PILLARS blir beskrevet: Bærekraftig forretningsdrift, programvarekvalitet og sosial rettferdighet.

La oss anta at programvarekvalitet allerede er sjekket. Det gjenstår å vise bærekraftig forretningsdrift og sosial rettferdighet.

Jeg bestemte meg for å fokusere mest på det siste.

For å starte med, forklarte jeg hvorfor ThoughtWorks — jeg leste Martin Fowlers blogg allerede på universitetet, derav min kjærlighet til Clean Code.

Prosjektene kan også presenteres fra forskjellige vinkler. Jeg har utviklet programvare for helsevesenet som har gjort livet enklere for pasientene, og ifølge ryktene reddet det til og med ett liv. Jeg har også utviklet programvare for banker, som også er en form for forenkling av hverdagen for borgere. Spesielt hvis den banken brukes av omtrent 70% av landets befolkning. Det handler ikke om Sberbank og ikke en gang om Russland.

Ønsker du å vite mer om meg? Ok. Hobbyen min er fotografering, jeg har hatt et kamera i hånden i omtrent 10 år, og jeg har bilder som jeg ikke skammer meg over å vise. Jeg har også en periode hjulpet et kattehjem: jeg tok bilder av kattene som trengte et permanent hjem. Med gode bilder er det mye lettere å finne et hjem for en katt. Jeg har sannsynligvis fotografert rundt hundre katter 🙂

Til slutt hadde jeg fylt 80% av presentasjonen med katter.

Umiddelbart etter presentasjonen fikk jeg en beskjed fra HR om at de fortsatt ikke vet resultatene fra intervjuet, men hele kontoret er allerede imponert over kattene.

Til slutt fikk jeg tilbakemelding — jeg tilfredsstilte alle som person.

Men HR nevnte i den avsluttende samtalen taktfullt at sosial rettferdighet er veldig bra og nødvendig, men ikke alle prosjekter er slik. Og spurte om det skremmer meg. Jeg overdrevet litt med sosial rettferdighet, det skjer 🙂

Resultat

Som resultat har jeg allerede jobbet noen måneder i Singapore hos Thoughtworks, jeg ser at mange selskaper her også tar i bruk "beste praksiser for intervjuer" fra Google, ved å bruke notatark og Whiteboard for koding, selv om kunnskap utover Spring, Symfony, RubyOnRails (sett pris på) ikke er nødvendig i jobben. Ingeniørene tar en ukes ferie før intervjuet for å "forberede seg".

Hos Thoughtworks, i tillegg til rimelige krav til kandidaten, settes slike prinsipper i sentrum:
Glede ved intervjuering. Dette gjelder for begge parter. Hvis du virkelig ønsker å få de beste talentene (og hvem ønsker ikke det?), så er intervjuet ikke en markedsplass hvor man velger slaver, men en vurdering hvor både arbeidsgiver og kandidat vurderer hverandre. Og hvis kandidaten assosierer positive følelser med selskapet, er det høyst sannsynlig at de velger akkurat dette selskapet.

Flere intervjuere for å redusere skjevhet. Hos Thoughtworks er parprogrammering standard praksis. Og hvis denne praksisen kan brukes i andre områder, prøver TW å gjøre det. I hver fase gjennomføres intervjuet av to personer. På denne måten vurderes hver person av minst 8 personer, og TW forsøker å velge intervjuere med forskjellig bakgrunn, ulike retninger (ikke bare tekniske) og kjønn.

Som et resultat vil avgjørelsen om ansettelse bli tatt basert på meninger fra minst 8 personer, og ingen har rett til å ha en avgjørende stemme.

Attributt-basert ansettelse I stedet for at træffe beslutninger baseret på, om kandidaten 'kan lide' noget eller ej, er der udviklet en formular til hver rolle og hver fase, der inkluderer de evaluerede attributter. Ved evalueringen anbefales det stærkt at vurdere ikke erfaringen med en bestemt færdighed, men evnen til at anvende den. Så hvis en kandidat ikke har haft mulighed for at anvende visse færdigheder, som TDD, men alligevel forsøger at anvende dem og lytter til råd om korrekt brug, har han alle chancer for at bestå interviewet.

Uddannelsesbeviser er ikke påkrævet TW kræver ikke, at kandidaten har obligatoriske certifikater eller uddannelse inden for Computer Science. Kun færdigheder vurderes.

Dette er den første interviewprocedure, jeg har gennemgået i udenlandske virksomheder, som jeg ikke behøvede at forberede mig til. Efter hver fase følte jeg mig ikke udmattet, men derimod glad for, at jeg kan bruge de bedste metoder, 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 helt er opfyldt. Hvad adskiller ThoughtWorks fra en almindelig virksomhed? I en almindelig virksomhed kan du finde gode udviklere og venlige mennesker, men i TW er deres koncentration tårnhøj.

Hvis du ønsker at slutte dig til ThoughtWorks, kan du se åbne stillinger her
Jeg foreslår også at tage et kig på interessante stillinger:
Lead Software Engineer: Tyskland, London, Madrid, Singapore
Senior Software Engineer: Sydney, Tyskland, Manchester, Bangkok
Software Engineer: Sydney, Barcelona, Milano
Senior Data Engineer: Milano
Quality Analyst: Tyskland Kina
Infrastruktur: Tyskland, London, Chile
(Jeg vil ærligt advare om, at linket er et referral-link. Hvis du kommer til TW, vil jeg få en dejlig bonus). Vælg det kontor, du holder af; du behøver ikke kun at begrænse dig til Europa. I sidste ende vil TW hvert andet år være glade for at flytte dig til et andet land, da det er en del af ThoughtWorks' politik, hvorigennem kulturen spredes og udlignes.

Tøv ikke med at stille spørgsmål i kommentarerne eller bede mig om at anbefale dig.
Hvis emnet virkede interessant, vil jeg skrive om, hvordan det er at arbejde hos ThoughtWorks, og hvordan det er at bo i Singapore.

Kilde: habr.com