Verkar det inte konstigt för dig att när du ska byta jobb och behovet uppstår att klara en intervju, är det första du tänker "du måste förbereda dig för intervjun." Lös problem på HackerRank, läs Crack the coding interview, memorera hur ArrayList fungerar och hur den skiljer sig från LinkedList. Åh ja, de kanske också frågar om sortering, och det skulle uppenbarligen vara oprofessionellt att säga att snabb sortering med största sannolikhet skulle vara det bästa valet.
Men vänta, du programmerar 8 timmar om dagen, löser intressanta och icke-triviala problem, och på ditt nya jobb kommer du att göra samma sak, plus eller minus. Men ändå, för att klara en intervju, måste du på något sätt ytterligare förbereda dig, inte ens finslipa dina dagliga färdigheter, utan lära dig något som du inte behövde på ditt nuvarande jobb och sannolikt inte kommer att behöva vid ditt nästa. Till dina invändningar att datavetenskap är i vårt blod, och om du väcker oss mitt i natten, är vi skyldiga att med slutna ögon på ett örngott skriva en promenad runt ett träds bredd utan att ens återfå medvetandet, jag kommer att svara att om jag får jobb på cirkusen, och min huvudsakliga trick skulle vara just detta - så kanske ja, jag håller med. Denna färdighet måste testas.
Men varför testa färdigheter som är irrelevanta för ditt nuvarande jobb? Bara för att det blev på modet? För att Google gör detta? Eller för att din framtida teamledare var tvungen att lära sig alla sorteringsmetoder innan intervjun och nu tror han att "varje bra programmerare måste kunna utantill implementeringen av att hitta en palindrom i en sträng."
Tja, du är inte Google (c). Vad Google har råd med kan inte vanliga företag. Google, efter att ha analyserat sina anställdas data, kom till slutsatsen att ingenjörer med Olympiad-bakgrund är bra på att hantera sina specifika uppgifter. Genom att utforma sin urvalsprocess kan de dessutom ha råd att ta risken att de kanske inte anställer några bra ingenjörer eftersom de inte lätt kan lösa matematiska problem. Men detta är inget problem för dem, det är många som vill jobba på Google, tjänsten kommer att läggas ner.
Låt oss nu titta ut genom fönstret, och om ingenjörerna som vill arbeta för dig framför ditt kontor ännu inte har satt upp ett tältläger och dina utvecklare oftare tittar på stackoverflow efter vad nästa vårkommentar behöver installeras, snarare än krångligheterna med rankningsalgoritmer, så är det tydligen dags för dig att fundera på om du ska kopiera Google.
Tja, om Google misslyckades den här gången och inte gav något svar, vad ska du göra? Kontrollera exakt vad utvecklaren kommer att göra på jobbet. Vad värdesätter du hos utvecklare?
Gör kriterier för vem du vill anställa och utveckla tester som testar just dessa färdigheter.
Thoughtworks
Vad har ThoughtWorks med detta att göra? Det var här jag hittade ett exempel på en modellintervju för mig själv. Vilka är ThoughtWorks? Kort sagt, detta är ett high-end konsultföretag med kontor över hela världen, från Kina, Singapore till de amerikanska kontinenterna, som har konsulterat inom utvecklingsområdet i cirka 25 år, har en egen Science-division, som leds av Martin Fowler. Om du letar efter en lista med 10 böcker som måste läsas för en mjukvaruingenjör, så kanske 2-3 av dem kommer att skrivas av killarna från ThoughtWorks, som Refactoring By Martin Fowler och Building Microservices: Designing Fine-Grained Systems av Sam Newman eller Building Evolutionary Architectures
av Patrick Kua, Rebecca Parsons, Neal Ford.
Företagets verksamhet bygger på att tillhandahålla ganska dyra tjänster, men kunden betalar för fenomenal kvalitet som består av expertis, interna standarder och förstås människor. Därför är det viktigt att anställa rätt personer här.
Vilken typ av människor har rätt? Naturligtvis finns det olika för alla. ThoughtWorks har bestämt att de viktigaste kriterierna för deras affärsmodell för utvecklare är:
- Förmåga att utvecklas i par. Det är förmåga, inte erfarenhet eller skicklighet. Ingen förväntar sig att människor som har tränat parprogrammering i 5 år kommer att komma. Men att vara mottaglig för andras åsikter och att kunna lyssna är en nödvändig färdighet.
- Förmåga att skriva tester och helst träna TDD
- Förstå SOLID och OOP och kunna tillämpa dem.
- Presentera din åsikt. Som konsult måste man jobba med kundens utvecklare, med andra konsulter, och det är inte så stor nytta om en person vet hur man gör något bra, men helt oförmögen att förmedla det till resten av teamet.
Nu är det viktigt att utvärdera just dessa färdigheter hos kandidaten. Och här vill jag berätta om min erfarenhet av att intervjua på ThoughtWorks. Jag kommer genast att säga att jag åkte till Singapore och godkände, men rekryteringsprocessen är enhetlig och kommer inte att skilja sig mycket från land till land.
Steg 0. HR
Som ofta händer, en 20 minuters intervju med HR. Jag ska inte uppehålla mig vid det, jag ska bara säga att jag aldrig har träffat en HR-person som kunde prata i 15 minuter om utvecklingskulturen i företaget, varför de använder TDD, varför parprogrammering. Vanligtvis vill personalen i den här frågan och säger att deras process är normal: utvecklare utvecklar, testare testar, chefer kör.
Steg 1. Hur bra är du på OOP, TDD?
1.5 timme innan intervjuns början fick jag en uppgift att göra en Mars Rover-simulator.
Mars rover uppdragEn grupp robotar ska landsättas av NASA på en platå på Mars. Denna platå, som är konstigt rektangulär, måste navigeras av rovers så att deras kameror ombord kan få en fullständig bild av den omgivande terrängen för att skicka tillbaka till jorden. En rovers position och plats representeras av en kombination av x- och y-koordinater och en bokstav som representerar en av de fyra kardinalkompasspunkterna. Platån är uppdelad i ett rutnät för att förenkla navigeringen. Ett exempel på position kan vara 0, 0, N, vilket betyder att rover är i det nedre vänstra hörnet och vänd mot norr. För att kontrollera en rover skickar NASA en enkel rad bokstäver. De möjliga bokstäverna är 'L', 'R' och 'M'. 'L' och 'R' får roveraren att snurra 90 grader åt vänster eller höger, utan att flytta från sin nuvarande plats. 'M' betyder att gå framåt en rutnätspunkt och behålla samma kurs.
Antag att kvadraten direkt norr från (x, y) är (x, y+1).
INMATNING:
Den första inmatningsraden är de övre högra koordinaterna för platån, de nedre vänstra koordinaterna antas vara 0,0.
Resten av inmatningen är information som hänför sig till de rovers som har utplacerats. Varje rover har två inmatningslinjer. Den första raden anger roverns position, och den andra raden är en serie instruktioner som berättar för rovern hur han ska utforska platån. Positionen består av två heltal och en bokstav separerade med mellanslag, motsvarande x- och y-koordinaterna och roverns orientering.
Varje rover kommer att avslutas sekventiellt, vilket innebär att den andra rover inte kommer att börja röra sig förrän den första har slutat röra sig.
PRODUKTION:
Utdata för varje rover bör vara dess slutliga koordinater och kurs.
ANMÄRKNINGAR:
Implementera helt enkelt kraven ovan och bevisa att en dammsugare fungerar genom att skriva enhetstester för den.
Det går inte att skapa någon form av användargränssnitt.
Att lösa problemet genom att följa en TDD-metod (Test Driven Development) kommer att föredras.
På den korta tiden som finns är vi mer måna om kvalitet än om fullständighet.
*Jag kan inte lägga upp uppgiften som skickades till mig, detta är en gammal uppgift som gavs för flera år sedan. Men tro mig, i grunden förblir allt detsamma.
Jag vill särskilt uppmärksamma utvärderingskriterierna. Hur många gånger har du stött på en situation där saker som är viktiga för en kandidat är helt oviktiga under revisionen och vice versa. Alla tänker inte på samma sätt som du, men många kan acceptera och följa dina värderingar om de är tydliga. Så från utvärderingskriterierna är det omedelbart klart att de viktigaste färdigheterna i detta skede är
- TDD;
- Förmåga att använda OOP och skriva underhållbar kod;
- para programmeringsförmågor
Så jag blev varnad för att spendera de 1.5 timmarna på att tänka på hur jag skulle göra uppgiften, istället för att skriva kod. Vi kommer att skriva koden tillsammans.
När vi ringde berättade killarna kort vilka de är och vad de gör och erbjöd sig att börja utveckla.
Under hela intervjun hade jag aldrig en enda känsla av att jag blev intervjuad. Det finns en känsla av att man utvecklar kod i ett team. Om du fastnar någonstans hjälper de, ger råd, diskuterar, till och med argumenterar med varandra om hur man bäst gör det. Vid intervjun glömde jag hur man kontrollerar i JUnit 5 att en metod ger ett undantag - de erbjöd sig att fortsätta skriva testet, medan en av dem googlade hur man gör det.
Bokstavligen några timmar efter intervjun fick jag konstruktiv feedback - vad jag gillade och vad jag inte gjorde. I mitt fall fick jag beröm för att jag använde Sealed-klasser som ett alternativ till null-objektet; för det faktum att jag innan jag skrev koden skrev i pseudokod hur jag skulle vilja styra rover, och fick därmed en skiss på klasserna, åtminstone de som är involverade i robotens API.
Steg 2: Berätta för oss
En vecka före intervjun blev jag ombedd att förbereda en presentation om något ämne som intresserade mig. Formatet är enkelt och välbekant: 15 minuters presentation, 15 minuter att svara på frågor.
Jag valde Clean Architecture av Uncle Bob. Och återigen blev jag intervjuad av ett par personer. Det här var min första erfarenhet av att presentera på engelska, och om jag hade varit i en stressig situation hade jag kanske inte orkat. Men återigen, jag hade aldrig en enda känsla av att jag var på en intervju. Allt är som vanligt – jag säger till dem, de lyssnar noga. Till och med den traditionella frågestunden var inte som en intervju, det var tydligt att frågorna inte ställdes för att ”sjunka”, utan de som verkligen intresserade dem i min presentation.
Ett par timmar efter intervjun fick jag feedback - presentationen var väldigt användbar och de tyckte verkligen om att lyssna.
Steg 3. Produktionskvalitetskod
Efter att ha varnat för att detta var det sista steget av tekniska intervjuer blev jag ombedd att föra koden hemma till ett produktionsfärdigt tillstånd, sedan skicka koden för granskning och schemalägga intervjuer där kraven för uppgiften skulle ändras och koden skulle kräver modifiering. När jag blickar framåt kan jag säga att kodgranskningen genomförs blint, granskarna känner inte till tjänsten som kandidaten söker, de ser inte hans CV, de ser inte ens hans namn.
Telefonen ringde och återigen stod det ett par killar på andra sidan monitorn. Allt är detsamma som vid den första intervjun: huvudsaken är att inte glömma TDD, berätta vad du gör och varför. Om du inte har tränat TDD tidigare så rekommenderar jag att börja göra det direkt, inte för att det är nödvändigt på företag utan för att det förenklar ditt liv avsevärt, minskar din stressnivå om du vill. Kommer du ihåg hur du frenetiskt var tvungen att söka med en debugger efter ett fel som bara kan återskapas via webbläsaren, men du kan inte återskapa det med tester? Föreställ dig nu att du måste fånga ett sådant misstag under en intervju - du är garanterad ett par gråa hårstrån. Vad får vi med TDD? Vi ändrade koden och insåg oväntat att nu är testerna röda, men vad är felet vi inte kan ta reda på första gången? Okej, vi säger "Hoppsan" till intervjuarna, trycker på Ctrl-Z och börjar ta små steg framåt. Och ja, du måste utveckla förmågan att utvecklas med hjälp av TDD i dig själv, förmågan att gå mot målet så att dina tester är permanent gröna och inte röda på en halv dag, eftersom "du har mycket refaktorering." Detta är exakt samma färdighet som att skriva underhållbar kod, eller skriva produktiv kod.
Så hur väl din kod kan ändras beror på vilken design du har i åtanke till att börja med, hur enkelt det är och hur bra dina tester är.
Efter intervjun fick jag feedback inom några timmar. I det här skedet insåg jag att jag nästan var klar och det var väldigt lite kvar tills jag "träffade Fowler."
Etapp 4. Final. Nog med tekniska frågor. Vi vill veta vem du är!
För att vara ärlig, blev jag något förbryllad över denna formulering av frågan. Hur kan du förstå vilken typ av person jag är i en timmes samtal? Och ännu mer, hur kan du förstå detta när jag talar ett språk som inte är mitt modersmål, och, ärligt talat, väldigt uselt och tungt. I tidigare intervjuer var det lättare för mig personligen att prata snarare än att svara på frågor, och accenten var att skylla på. Åtminstone en av intervjuarna var asiatisk – och deras accent, ja, låt oss bara säga, är något specifik för det europeiska örat. Därför bestämde jag mig för att ta ett proaktivt förhållningssätt - förbereda en presentation om mig själv och i början av intervjun erbjuda att prata om mig själv med denna presentation. Om de håller med, så kommer det åtminstone att finnas färre frågor för mig, om de tackar nej till erbjudandet, ja, 3 timmar av mitt liv som spenderas på en presentation är inte ett så högt pris. Men vad ska du skriva i din presentation? Biografi - Född där, på den tiden, gick i skolan, tog examen från universitetet - men vem bryr sig?
Om du Googlar lite om Thoughtworks-kulturen hittar du en artikel av Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] som beskriver de 3 pelarna: Sustainable Business, Software Excellence, and Social Justice.
Låt oss anta att Software Excellence redan har kontrollerats för mig. Det återstår att visa hållbart företagande och social rättvisa.
Dessutom bestämde jag mig för att fokusera på det senare.
Till att börja med berättade jag för honom varför ThoughtWorks – jag läste Martin Fowlers blogg på college, därav min kärlek till Clean code.
Projekt kan också presenteras från olika vinklar. Han utvecklade också mjukvara för medicin som förenklade patienters liv, och till och med, enligt rykten, räddade ett liv. Jag utvecklade även mjukvara för banker, vilket också gjorde livet lättare för medborgarna. Särskilt om denna bank används av 70 % av landets befolkning. Det här handlar inte om Sberbank och inte ens om Ryssland.
Vill du veta mer om mig? OK. Min hobby är fotografering, på ett eller annat sätt har jag hållit en kamera i mina händer i ungefär 10 år, det finns fotografier som jag inte skäms för att visa. En gång hjälpte jag också ett katthem: jag fotograferade katter som behövde ett permanent hem. Och med bra fotografier är det mycket lättare att placera en katt. Jag fotade säkert hundra katter :)
Till slut var 80 % av min presentation fylld av katter.
Direkt efter presentationen skrev HR till mig att han ännu inte visste resultatet av intervjun, men hela kontoret var redan imponerat av katterna.
Till sist väntade jag på feedback - jag tillfredsställde alla som person.
Men under det avslutande samtalet sa HR taktfullt att Social Rättvisa är väldigt bra och nödvändigt, men alla projekt är inte så här. Och han frågade om det skrämde mig. I allmänhet gick jag lite överdrivet med social rättvisa, det händer :)
Totalt
Som ett resultat av detta har jag arbetat i Singapore på Thoughtworks i flera månader nu, och jag ser att även här använder många företag "bästa intervjupraxis" från Google, använder löv och Whiteboard för kodning, trots att de har mer kunskap än Spring, Symfony, RubyOnRails (Stryk under vad som är nödvändigt) krävs inte i arbetet. Ingenjörer tar en vecka ledigt före en intervju för att "förbereda sig".
På Thoughtworks är, förutom tillräckliga krav på kandidaten, följande principer i framkant:
Glädje att intervjua. Dessutom för båda sidor. Faktum är att om du vill få den bästa personalen (och vem gör inte det?), då är en intervju inte en marknad där slavar väljs, utan en show där både arbetsgivaren och kandidaten utvärderar varandra. Och om en kandidat associerar trevliga känslor med ett företag, är det troligt att han kommer att välja just detta företag
Flera intervjuare för att mildra partiskhet. På Thoughtworks är parprogrammering de facto standarden. Och om denna praxis kan tillämpas på andra områden, försöker TW göra det. Vid varje steg genomförs intervjun av 2 personer. Således bedöms varje person av minst 8 personer, och TW försöker välja ut intervjuare med olika bakgrund, olika riktningar (inte bara tekniker) och kön.
I slutändan kommer anställningsbeslutet att fattas baserat på åsikter från minst 8 personer, och ingen har en utslagsröst.
Attributbaserad anställning Istället för att fatta ett beslut baserat på en kandidats tycke och smak, utvecklas ett formulär för varje roll och varje steg som inkluderar de egenskaper som bedöms. Samtidigt, när man bedömer, rekommenderas det starkt att inte utvärdera erfarenhet av en viss färdighet, utan förmågan att tillämpa den. Således, om en kandidat inte kunde tillämpa några färdigheter, såsom TDD, men ändå försöker tillämpa dem, lyssnar på råd om hur man använder dem korrekt, har han alla chanser att klara intervjun.
Utbildningsbevis krävs inte TW kräver ingen certifiering eller utbildning i datavetenskap. Endast färdigheter bedöms.
Det här är den första intervjun jag har haft med utländska företag som jag inte behövt förbereda mig på. Efter varje steg kände jag mig inte utmattad, men tvärtom var jag glad att jag kunde tillämpa de bästa metoderna, att folk på andra sidan monitorn uppskattade det och tillämpade dem varje dag.
Efter flera månader kan jag säga att mina förväntningar uppfylldes till fullo. Hur skiljer sig ThoughtWorks från ett vanligt företag? I ett vanligt företag kan du hitta bra utvecklare och trevliga människor, men i TW är deras koncentration borta från listorna.
Om du är intresserad av att gå med i ThoughtWorks kan du se våra lediga tjänster
Jag föreslår också att uppmärksamma intressanta lediga platser:
Ledande mjukvaruingenjör: , , ,
Senior mjukvaruutvecklare: , , ,
Mjukvaruingenjör: , ,
Senior dataingenjör:
Kvalitetsanalytiker:
Infrastruktur: , ,
(Jag vill ärligt varna dig för att länken är en remisslänk, om du går till TW får jag en fin bonus). Välj ett kontor du gillar, du behöver inte begränsa dig till Europa, trots allt kommer TW vartannat år gärna flytta dig till ett annat land, eftersom... detta är en del av ThoughtWorks policy, så kulturen sprids och homogeniseras.
Ställ gärna frågor i kommentarerna eller be mig om rekommendationer.
Om ämnet verkar intressant kommer jag att skriva om hur det är att jobba på ThoughtWorks och hur livet är i Singapore.
Källa: will.com