Virker det ikke rart for deg at når du skal bytte jobb og behovet oppstår for å bestå et intervju, er det første du tenker "du må forberede deg til intervjuet." Løs problemer på HackerRank, les Crack the coding interview, memorer hvordan ArrayList fungerer og hvordan den skiller seg fra LinkedList. Å ja, de kan også spørre om sortering, og det vil åpenbart være uprofesjonelt å si at rask sortering mest sannsynlig vil være det beste valget.
Men vent, du programmerer 8 timer om dagen, løser interessante og ikke-trivielle problemer, og på den nye jobben din vil du gjøre det samme, pluss eller minus. Men ikke desto mindre, for å bestå et intervju, må du på en eller annen måte forberede deg i tillegg, ikke engang finpusse de daglige ferdighetene dine, men lære noe du ikke trengte på din nåværende jobb, og som neppe vil trenge på din neste. Til dine innvendinger om at informatikk er i blodet vårt, og hvis du vekker oss midt på natten, er vi forpliktet til å skrive med lukkede øyne på et putevar en tur rundt i bredden av et tre uten engang å komme til bevissthet, vil svare at hvis jeg får jobb i sirkuset, og trikset mitt ville vært akkurat dette - så kanskje ja, jeg er enig. Denne ferdigheten må testes.
Men hvorfor teste ferdigheter som er irrelevante for din nåværende jobb? Bare fordi det ble mote? Fordi Google gjør dette? Eller fordi din fremtidige teamleder måtte lære alle sorteringsmetodene før intervjuet, og nå mener han at «enhver god programmerer må kunne utenat implementeringen av å finne et palindrom i en streng».
Vel, du er ikke Google (c). Det Google har råd til, kan ikke vanlige selskaper. Google, etter å ha analysert dataene til sine ansatte, kom til den konklusjonen at ingeniører med olympiadebakgrunn er gode til å håndtere sine spesifikke oppgaver. Ved å designe utvelgelsesprosessen kan de dessuten tillate seg å ta risikoen for at de kanskje ikke ansetter noen få gode ingeniører fordi de ikke lett kan løse matematiske problemer. Men dette er ikke et problem for dem, det er mange som ønsker å jobbe hos Google, stillingen vil bli nedlagt.
La oss nå se ut av vinduet, og hvis ingeniørene som ønsker å jobbe for deg foran kontoret ditt ennå ikke har satt opp en teltleir, og utviklerne dine ser oftere på stackoverflow for hva neste vårkommentar må installeres, i stedet for vanskelighetene med rangeringsalgoritmer, så er det tilsynelatende på tide at du tenker på om du bør kopiere Google.
Vel, hvis Google denne gangen mislyktes og ikke ga noe svar, hva bør du gjøre? Sjekk nøyaktig hva utvikleren vil gjøre på jobben. Hva verdsetter du hos utviklere?
Lag kriterier for hvem du ønsker å ansette og utvikle tester som tester akkurat disse ferdighetene.
Thought
Hva har ThoughtWorks med dette å gjøre? Det var her jeg fant et eksempel på et modellintervju for meg selv. Hvem er ThoughtWorks? Kort fortalt er dette et High-End konsulentselskap med kontorer over hele verden, fra Kina, Singapore til de amerikanske kontinentene, som har drevet rådgivning innen utvikling i ca. 25 år, har sin egen Science-divisjon, ledet av Martin Fowler. Hvis du ser etter en liste over 10 må-lese-bøker for en programvareingeniør, så vil kanskje 2-3 av dem være skrevet av gutta fra ThoughtWorks, som Refactoring By 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å å levere ganske dyre tjenester, men kunden betaler for fenomenal kvalitet, som består av kompetanse, interne standarder og selvfølgelig mennesker. Derfor er det viktig å ansette de rette personene her.
Hva slags mennesker har rett? Selvfølgelig er det forskjellige for alle. ThoughtWorks har bestemt at de viktigste kriteriene for deres forretningsmodell for utviklere er:
- Evne til å utvikle seg i par. Det er evne, ikke erfaring eller ferdighet. Ingen forventer at folk som har praktisert parprogrammering i 5 år vil komme. Men å være mottakelig for andres meninger og å kunne lytte er en nødvendig ferdighet.
- Evne til å skrive tester, og ideelt sett øve på TDD
- Forstå SOLID og OOP og kunne anvende dem.
- Presenter din mening. Som konsulent må du jobbe med byggherrens utviklere, med andre konsulenter, og det er ikke mye nytte om en person vet hvordan man gjør noe godt, men er helt ute av stand til å formidle det til resten av teamet.
Nå er det viktig å evaluere disse spesielle ferdighetene hos kandidaten. Og her vil jeg fortelle om min erfaring med å intervjue hos ThoughtWorks. Jeg vil si med en gang at jeg dro til Singapore og bestod, men rekrutteringsprosessen er enhetlig og vil ikke variere mye fra land til land.
Trinn 0. HR
Som ofte skjer, et 20-minutters intervju med HR. Jeg skal ikke dvele ved det, jeg vil bare si at jeg aldri har møtt en HR-person som kunne snakke i 15 minutter om utviklingskulturen i selskapet, hvorfor de bruker TDD, hvorfor parprogrammering. Vanligvis vil HR-er på dette spørsmålet og si at prosessen deres er normal: utviklere utvikler, testere tester, ledere kjører.
Trinn 1. Hvor god er du i OOP, TDD?
1.5 time før intervjustart fikk jeg tilsendt en oppgave om å lage en Mars Rover-simulator.
Mars rover oppdragEn gruppe med robotrovere skal landes av NASA på et platå på Mars. Dette platået, som er merkelig rektangulært, må navigeres av roverne slik at kameraene deres ombord kan få en fullstendig oversikt over det omkringliggende terrenget for å sende tilbake til jorden. En rovers posisjon og plassering er representert av en kombinasjon av x- og y-koordinater og en bokstav som representerer ett av de fire kardinalkompasspunktene. Platået er delt opp i et rutenett for å forenkle navigeringen. Et eksempelposisjon kan være 0, 0, N, som betyr at roveren er nederst i venstre hjørne og vendt mot nord. For å kontrollere en rover sender NASA en enkel rekke med bokstaver. De mulige bokstavene er 'L', 'R' og 'M'. 'L' og 'R' får roveren til å spinne henholdsvis 90 grader til venstre eller høyre, uten å flytte seg fra det nåværende stedet. 'M' betyr å gå ett rutenettpunkt fremover, og opprettholde samme kurs.
Anta at kvadratet rett nord fra (x, y) er (x, y+1).
INNGANG:
Den første inndatalinjen er de øvre høyre koordinatene til platået, de nedre venstre koordinatene antas å være 0,0.
Resten av innspillet er informasjon knyttet til rovere som er utplassert. Hver rover har to inngangslinjer. Den første linjen viser roverens posisjon, og den andre linjen er en serie instruksjoner som forteller roveren hvordan han skal utforske platået. Posisjonen består av to heltall og en bokstav atskilt med mellomrom, tilsvarende x- og y-koordinatene og roverens orientering.
Hver rover vil bli ferdig sekvensielt, noe som betyr at den andre roveren ikke begynner å bevege seg før den første er ferdig med å bevege seg.
PRODUKSJON:
Utgangen for hver rover skal være dens endelige koordinater og kurs.
NB:
Bare implementer kravene ovenfor og bevis at en støvsuger fungerer ved å skrive enhetstester for den.
Å lage noen form for brukergrensesnitt er utenfor omfanget.
Å løse problemet ved å følge en TDD (Test Driven Development) tilnærming vil bli foretrukket.
På den korte tiden som er tilgjengelig, er vi mer opptatt av kvalitet enn fullstendighet.
*Jeg kan ikke legge ut oppgaven som ble sendt til meg, dette er en gammel oppgave som ble gitt for flere år siden. Men tro meg, i utgangspunktet forblir alt det samme.
Jeg vil spesielt gjøre oppmerksom på evalueringskriteriene. Hvor mange ganger har du vært i en situasjon hvor ting som er viktige for en kandidat er helt uviktige under tilsynet og omvendt. Ikke alle tenker på samme måte som deg, men mange kan akseptere og følge verdiene dine hvis de er tydelig uttalt. Så fra evalueringskriteriene er det umiddelbart klart at de viktigste ferdighetene på dette stadiet er
- TDD;
- Evne til å bruke OOP og skrive vedlikeholdbar kode;
- par programmeringsevner
Så jeg ble advart om å bruke de 1.5 timene på å tenke på hvordan jeg skulle gjøre oppgaven, i stedet for å skrive kode. Vi skal skrive koden sammen.
Da vi kom på telefonen fortalte gutta oss kort hvem de er og hva de gjør og tilbød oss å starte utviklingen.
Under hele intervjuet hadde jeg aldri en eneste gang følelsen av at jeg ble intervjuet. Det er en følelse av at du utvikler kode i et team. Hvis du blir sittende fast et sted, hjelper de, gir råd, diskuterer, til og med argumenterer med hverandre om hvordan det best kan gjøres. På intervjuet glemte jeg hvordan jeg sjekket i JUnit 5 at en metode gir et unntak - de tilbød seg å fortsette å skrive testen, mens en av dem googlet hvordan de skulle gjøre det.
Bokstavelig talt noen timer etter intervjuet fikk jeg konstruktive tilbakemeldinger - hva jeg likte og hva jeg ikke likte. I mitt tilfelle fikk jeg ros for å bruke Sealed-klasser som et alternativ til null-objektet; for det faktum at jeg før jeg skrev koden skrev i pseudokode hvordan jeg ønsker å styre roveren, og fikk dermed en skisse av klassene, i hvert fall de som er involvert i robotens API.
Trinn 2: Fortell oss
En uke før intervjuet ble jeg bedt om å forberede en presentasjon om ethvert tema som interesserte meg. Formatet er enkelt og kjent: 15 minutter presentasjon, 15 minutter svar på spørsmål.
Jeg valgte Clean Architecture av onkel Bob. Og igjen ble jeg intervjuet av et par personer. Dette var min første erfaring med å presentere på engelsk, og kanskje, hvis jeg hadde vært i en stressende situasjon, ville jeg ikke ha klart å takle det. Men igjen, jeg hadde aldri følelsen av at jeg var på et intervju. Alt er som vanlig - jeg forteller dem, de lytter nøye. Selv den tradisjonelle spørsmål og svar-sesjonen var ikke som et intervju; det var tydelig at spørsmålene ikke ble stilt for å "synke", men de som virkelig interesserte dem i presentasjonen min.
Et par timer etter intervjuet fikk jeg tilbakemelding – presentasjonen var veldig nyttig og de likte virkelig å lytte.
Trinn 3. Produksjonskvalitetskode
Etter å ha advart om at dette var siste fase av tekniske intervjuer, ble jeg bedt om å bringe koden hjemme til en produksjonsklar tilstand, deretter sende koden for gjennomgang og planlegge intervjuer der kravene til oppgaven ville endres og koden ville krever modifikasjon. Når jeg ser fremover, kan jeg si at kodegjennomgangen gjennomføres i blinde, anmelderne vet ikke hvilken stilling kandidaten søker på, de ser ikke CV-en hans, de ser ikke engang navnet hans.
Telefonen ringte, og igjen var det et par karer på den andre siden av skjermen. Alt er det samme som ved det første intervjuet: det viktigste er ikke å glemme TDD, fortell hva du gjør og hvorfor. Hvis du ikke har praktisert TDD før, så anbefaler jeg å begynne å gjøre det umiddelbart, ikke fordi det er nødvendig i bedrifter, men fordi det forenkler livet ditt betydelig, reduserer stressnivået ditt om du vil. Husker du hvordan du febrilsk måtte søke med en debugger etter en feil som bare kan reproduseres gjennom nettleseren, men du kan ikke reprodusere den med tester? Tenk deg nå at du må ta en slik feil under et intervju - du er garantert et par grå hår. Hva får vi med TDD? Vi endret koden og innså uventet at nå er testene røde, men hva er feilen vi ikke kan finne ut første gang? Ok, vi sier "Oops" til intervjuerne, trykker Ctrl-Z og begynner å ta små skritt fremover. Og ja, du må utvikle evnen til å utvikle deg ved å bruke TDD i deg selv, evnen til å gå mot målet slik at testene dine er permanent grønne, og ikke røde på en halv dag, fordi "du har mye refactoring." Dette er nøyaktig samme ferdighet som å skrive vedlikeholdbar kode, eller skrive produktiv kode.
Så hvor godt koden din kan endres avhenger av hvilket design du har i tankene til å begynne med, hvor enkelt det er og hvor gode testene dine er.
Etter intervjuet fikk jeg tilbakemelding i løpet av noen timer. På dette stadiet skjønte jeg at jeg nesten var ferdig og det var veldig lite igjen før jeg «møtte Fowler».
Etappe 4. Finale. Nok tekniske spørsmål. Vi vil vite hvem du er!
For å være ærlig, ble jeg litt forundret over denne formuleringen av spørsmålet. Hvordan kan du forstå hva slags person jeg er i en times samtale? Og enda mer, hvordan kan du forstå dette når jeg snakker et språk som ikke er mitt morsmål, og, ærlig talt, veldig elendig og tungemålt. I tidligere intervjuer var det lettere for meg personlig å snakke fremfor å svare på spørsmål, og aksenten hadde skylden. Minst en av intervjuerne var asiatisk – og aksenten deres, vel, la oss bare si, er noe spesifikk for det europeiske øret. Derfor bestemte jeg meg for å ta en proaktiv tilnærming - forberede en presentasjon om meg selv og i begynnelsen av intervjuet tilby å snakke om meg selv med denne presentasjonen. Hvis de er enige, vil det i det minste være færre spørsmål for meg; hvis de avslår tilbudet, vel, 3 timer av livet mitt brukt på en presentasjon er ikke så høy pris. Men hva bør du skrive i presentasjonen din? Biografi - Født der, på den tiden, gikk på skole, ble uteksaminert fra universitetet - men hvem bryr seg?
Hvis du Googler litt om Thoughtworks-kulturen, finner du en artikkel av Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] som beskriver de 3 pilarene: Sustainable Business, Software Excellence, and Social Justice.
La oss anta at Software Excellence allerede er sjekket for meg. Det gjenstår å vise bærekraftig virksomhet og sosial rettferdighet.
Dessuten bestemte jeg meg for å fokusere på sistnevnte.
Til å begynne med fortalte jeg ham hvorfor ThoughtWorks – jeg leste Martin Fowlers blogg på college, derav min kjærlighet til Clean code.
Prosjekter kan også presenteres fra ulike vinkler. Han utviklet også programvare for medisin som forenklet livet til pasienter, og til og med, ifølge ryktene, reddet ett liv. Jeg utviklet også programvare for banker, som også gjorde livet enklere for innbyggerne. Spesielt hvis denne banken brukes av 70 % av landets befolkning. Dette handler ikke om Sberbank og ikke engang om Russland.
Vil du vite om meg? OK. Hobbyen min er fotografering, på en eller annen måte har jeg holdt et kamera i hendene i ca 10 år, det er bilder jeg ikke er så flau til å vise. En gang hjalp jeg også et kattehjem: Jeg fotograferte katter som trengte et permanent hjem. Og med gode bilder er det mye lettere å plassere en katt. Jeg har sikkert fotografert hundre katter :)
Til slutt var 80 % av presentasjonen min fylt med katter.
Rett etter presentasjonen skrev HR til meg at han ennå ikke visste resultatet av intervjuet, men hele kontoret var allerede imponert over kattene.
Til syvende og sist ventet jeg på tilbakemelding – jeg tilfredsstilte alle som person.
Men under den siste samtalen sa HR taktfullt at sosial rettferdighet er veldig bra og nødvendig, men ikke alle prosjekter er slik. Og han spurte om det skremte meg. Generelt gikk jeg litt over bord med sosial rettferdighet, det skjer :)
Total
Som et resultat har jeg jobbet i Singapore hos Thoughtworks i flere måneder nå, og jeg ser at også her tar mange bedrifter i bruk «beste intervjupraksis» fra Google, bruker blader og tavle for koding, til tross for at de har mer kunnskap enn Spring, Symfony, RubyOnRails ( Understrek det som er nødvendig) er ikke nødvendig i arbeidet. Ingeniører tar en uke fri før et intervju for å "forberede seg."
Hos Thoughtworks er, i tillegg til tilstrekkelige krav til kandidaten, følgende prinsipper i forkant:
Intervjuglede. Dessuten for begge sider. Faktisk, hvis du ønsker å få det beste personellet (og hvem gjør ikke det?), så er ikke et intervju et marked der slaver blir valgt, men et show hvor både arbeidsgiver og kandidat vurderer hverandre. Og hvis en kandidat forbinder hyggelige følelser med et selskap, er det sannsynlig at han vil velge akkurat dette selskapet
Flere intervjuere for å dempe skjevheter. Hos Thoughtworks er parprogrammering de facto-standarden. Og hvis denne praksisen kan brukes på andre områder, prøver TW å gjøre det. På hvert trinn gjennomføres intervjuet av 2 personer. Dermed blir hver person vurdert av minst 8 personer, og TW prøver å velge ut intervjuere med ulik bakgrunn, ulik retning (ikke bare teknologer) og kjønn.
Til syvende og sist vil ansettelsesbeslutningen bli tatt basert på meningene til minst 8 personer, og ingen har en avgjørende stemme.
Attributtbasert ansettelse I stedet for å ta en beslutning basert på en kandidats liker eller misliker, utvikles et skjema for hver rolle og hvert trinn som inkluderer egenskapene som vurderes. Samtidig, når du vurderer, er det sterkt anbefalt å vurdere ikke erfaring i en viss ferdighet, men evnen til å anvende den. Derfor, hvis en kandidat ikke var i stand til å bruke noen ferdigheter, for eksempel TDD, men likevel prøver å bruke dem, lytter til råd om hvordan de skal brukes riktig, har han alle muligheter til å bestå intervjuet.
Utdanningsbevis ikke nødvendig TW krever ingen sertifisering eller utdanning i informatikk. Kun ferdigheter vurderes.
Dette er det første intervjuet jeg har hatt med utenlandske selskaper som jeg ikke trengte å forberede meg på. Etter hvert trinn følte jeg meg ikke utslitt, men tvert imot, jeg var glad for at jeg kunne bruke de beste praksisene, at folk på den andre siden av skjermen satte pris på det og brukte dem hver dag.
Etter flere måneder kan jeg si at forventningene mine ble fullt ut innfridd. Hvordan er ThoughtWorks forskjellig fra et vanlig selskap? I et vanlig selskap kan du finne gode utviklere og hyggelige mennesker, men i TW er konsentrasjonen deres utenfor listene.
Hvis du er interessert i å bli med i ThoughtWorks, kan du se våre ledige stillinger
Jeg foreslår også å ta hensyn til interessante ledige stillinger:
Ledende programvareingeniør: , , ,
Senior programvareingeniør: , , ,
Programvare ingeniør: , ,
Senior dataingeniør:
Kvalitetsanalytiker:
Infrastruktur: , ,
(Jeg vil ærlig advare deg om at lenken er en henvisningslenke, hvis du går til TW, vil jeg motta en hyggelig bonus). Velg et kontor du liker, du trenger ikke begrense deg til Europa, tross alt, hvert annet år vil TW gjerne flytte deg til et annet land, fordi... dette er en del av ThoughtWorks-politikken, så kulturen spres og homogeniseres.
Still gjerne spørsmål i kommentarfeltet eller be meg om anbefalinger.
Hvis temaet virker interessant, vil jeg skrive om hvordan det er å jobbe i ThoughtWorks og hvordan livet er i Singapore.
Kilde: www.habr.com