Vindt u het niet vreemd dat wanneer u van baan gaat veranderen en u moet solliciteren, het eerste waar u aan denkt is: "Ik moet me voorbereiden op het sollicitatiegesprek." Los problemen op HackerRank op, lees het Crack the coding-interview, onthoud hoe ArrayList werkt en hoe het verschilt van LinkedList. Oh ja, ze kunnen ook vragen naar sorteren, en het zou ronduit onprofessioneel zijn om te zeggen dat snel sorteren waarschijnlijk de beste keuze is.
Maar wacht eens even, je programmeert 8 uur per dag, lost interessante en niet-triviale problemen op, en op je nieuwe baan zul je ongeveer hetzelfde doen. Maar om het sollicitatiegesprek te doorstaan, moet u zich toch op de een of andere manier voorbereiden. Het gaat er niet zozeer om uw dagelijkse vaardigheden aan te scherpen, maar om te leren wat u bij uw huidige baan niet nodig had en bij uw volgende baan waarschijnlijk ook niet nodig zult hebben. Op uw bezwaren dat computerwetenschappen in ons bloed zit en dat we, als we midden in de nacht wakker zouden worden, met onze ogen dicht op een kussensloop ter breedte van een boom zouden moeten schrijven zonder zelfs maar bij bewustzijn te komen, zal ik antwoorden dat als ik een baan zou krijgen in een circus en mijn belangrijkste truc precies dit zou zijn, dan ben ik het misschien wel met u eens. Deze vaardigheid moet getest worden.
Maar waarom zou je vaardigheden testen die niet relevant zijn voor de huidige baan? Omdat het mode werd? Omdat Google het zo doet? Of omdat je toekomstige teamleider alle sorteermethoden moest leren vóór het interview en nu denkt dat “elke goede programmeur de implementatie van het vinden van een palindroom in een string uit zijn hoofd moet kennen.”
Nou, jij bent niet Google (c). Wat Google kan, kunnen gewone bedrijven niet. Google kwam na analyse van de gegevens van zijn werknemers tot de conclusie dat ingenieurs met een Olympiade-achtergrond, specifiek voor hen en voor de taken die zij uitvoeren, goed zijn in het verwerken van die gegevens. Bovendien kunnen ze bij het ontwerpen van hun selectieproces het risico lopen dat ze een paar goede ingenieurs mislopen, omdat ze wiskundige problemen niet zo makkelijk kunnen oplossen. Maar voor hen is het geen probleem, er zijn veel mensen die bij Google willen werken, de functie zal worden ingevuld.
Laten we eens naar buiten kijken. Als er nog steeds geen engineers voor je kantoor staan die voor je willen werken, en je ontwikkelaars vaker op StackOverflow zoeken naar de volgende Spring-annotatie die ze moeten plaatsen dan naar de details van rangschikkingsalgoritmes, dan is het hoogstwaarschijnlijk tijd om na te denken of het de moeite waard is om Google te kopiëren.
Oké, als Google ons deze keer in de steek heeft gelaten en ons geen antwoord heeft gegeven, wat moeten we dan doen? Controleer precies wat de ontwikkelaar op het werk gaat doen. Wat vind je belangrijk bij ontwikkelaars?
Stel criteria op voor wie u wilt aannemen en ontwikkel testen die precies die vaardigheden testen.
ThoughtWorks
Wat heeft ThoughtWorks hiermee te maken? Hier vond ik een voorbeeld van een modelinterview voor mezelf. Wie zijn ThoughtWorks? Kortom, het is een high-end adviesbureau met kantoren over de hele wereld, van China en Singapore tot het Amerikaanse continent, dat al ongeveer 25 jaar adviesdiensten levert op het gebied van ontwikkeling en een eigen wetenschappelijke afdeling heeft, onder leiding van Martin Fowler. Als je op zoek gaat naar een lijst met 10 boeken die een software-engineer absoluut moet lezen, dan zijn er waarschijnlijk 2-3 geschreven door de jongens van ThoughtWorks, zoals Refactoring van Martin Fowler en Building Microservices: Designing Fine-Grained Systems van Sam Newman of Building Evolutionary Architectures
door Patrick Kua, Rebecca Parsons, Neal Ford.
De kernactiviteit van het bedrijf is het leveren van vrij dure diensten, maar de klant betaalt voor fenomenale kwaliteit. Die kwaliteit is afhankelijk van expertise, interne normen en natuurlijk mensen. Het is dus van cruciaal belang om de juiste mensen aan te nemen.
Wat voor mensen hebben gelijk? Natuurlijk heeft iedereen zijn eigen ding. ThoughtWorks stelde vast dat de belangrijkste criteria voor hun bedrijfsmodel voor ontwikkelaars waren:
- Vermogen om zich in paren te ontwikkelen. Het gaat juist om vaardigheid, niet om ervaring of kunde. Niemand verwacht dat mensen die al 5 jaar pair programming beoefenen, ooit zullen komen. Maar openstaan voor de mening van anderen en kunnen luisteren, is een noodzakelijke vaardigheid.
- Vermogen om tests te schrijven en idealiter TDD te oefenen
- Begrijp SOLID en OOP en weet hoe je ze kunt toepassen.
- Geef uw mening. Een consultant moet samenwerken met de ontwikkelaars van de klant en met andere consultants. Het heeft niet veel zin als iemand iets goed kan, maar dit absoluut niet kan overbrengen aan de rest van het team.
Nu is het belangrijk om deze specifieke vaardigheden bij de kandidaat te beoordelen. En hier wil ik het hebben over mijn interviewervaring bij ThoughtWorks. Ik zeg meteen dat ik naar Singapore ben gegaan en geslaagd ben, maar het wervingsproces is gestandaardiseerd en verschilt niet veel van land tot land.
Fase 0.HR
Zoals wel vaker gebeurt, een gesprek van 20 minuten met HR. Ik ga er niet te lang bij stilstaan, maar ik zeg alleen dat ik nog nooit een HR-medewerker heb ontmoet die 15 minuten kon praten over de ontwikkelingscultuur in het bedrijf, waarom ze TDD gebruiken en waarom pair programming. Meestal raken HR-medewerkers ontmoedigd als ze deze vraag krijgen en zeggen dat hun proces normaal is: ontwikkelaars ontwikkelen, testers testen en managers sturen aan.
Fase 1. Hoe goed bent u in OOP en TDD?
1.5 uur voordat het interview begon, kreeg ik de opdracht om een Mars Rover-simulator te maken.
Marsrover-missieNASA gaat een team van robotrovers laten landen op een plateau op Mars. Dit plateau, dat opvallend rechthoekig is, moet door de rovers worden bestuurd, zodat de camera's aan boord een compleet beeld van het omliggende terrein kunnen krijgen en dit naar de aarde kunnen sturen. De positie en locatie van een rover worden weergegeven door een combinatie van x- en y-coördinaten en een letter die een van de vier hoofdwindstreken vertegenwoordigt. Het plateau is opgedeeld in een raster om de navigatie te vereenvoudigen. Een voorbeeldpositie zou 0, 0, N kunnen zijn. Dit betekent dat de rover zich in de linker benedenhoek bevindt en naar het noorden is gericht. Om een rover te besturen, verstuurt NASA een eenvoudige reeks letters. De mogelijke letters zijn 'L', 'R' en 'M'. Met 'L' en 'R' draait de rover respectievelijk 90 graden naar links of rechts, zonder van zijn huidige positie te veranderen. 'M' betekent: ga één rasterpunt vooruit en behoud dezelfde koers.
Veronderstel dat het vierkant direct ten noorden van (x, y) gelijk is aan (x, y+1).
INVOER:
De eerste invoerregel bestaat uit de coördinaten rechtsboven van het plateau, de coördinaten linksonder worden verondersteld 0,0 te zijn.
De rest van de invoer betreft informatie over de rovers die zijn ingezet. Elke rover heeft twee invoerregels. De eerste regel geeft de positie van de rover aan en de tweede regel bevat een reeks instructies over hoe de rover het plateau moet verkennen. De positie bestaat uit twee gehele getallen en een letter, gescheiden door spaties. Deze getallen komen overeen met de x- en y-coördinaten en de oriëntatie van de rover.
Elke rover wordt in een bepaalde volgorde afgemaakt, wat betekent dat de tweede rover pas gaat rijden als de eerste klaar is met rijden.
OUTPUT:
De uitvoer voor elke rover moet de uiteindelijke coördinaten en koers zijn.
OPMERKINGEN:
Implementeer eenvoudig de bovenstaande vereisten en bewijs dat een stofzuiger werkt door er unittests voor te schrijven.
Het maken van een gebruikersinterface valt buiten het bestek.
Het oplossen van het probleem door middel van een TDD-aanpak (Test Driven Development) heeft de voorkeur.
In de korte tijd die we hebben, hechten we meer waarde aan kwaliteit dan aan volledigheid.
*Ik kan de opdracht die naar mij is gestuurd niet plaatsen. Het is een oude opdracht die een aantal jaar geleden is gegeven. Maar geloof me, in de basis blijft alles hetzelfde.
Ik wil graag speciale aandacht besteden aan de evaluatiecriteria. Hoe vaak hebt u een situatie meegemaakt waarin zaken die voor de kandidaat belangrijk zijn, tijdens het screeningsproces totaal onbelangrijk zijn en vice versa? Niet iedereen denkt hetzelfde als jij, maar velen kunnen jouw waarden omarmen en volgen als ze duidelijk op papier staan. Uit de evaluatiecriteria blijkt dus direct dat de belangrijkste vaardigheden in deze fase zijn:
- TDD-tijd;
- Vermogen om OOP te gebruiken en onderhoudbare code te schrijven;
- vaardigheden in pair-programmering
Ik werd dus gewaarschuwd dat ik die 1.5 uur moest besteden aan nadenken over hoe ik de taak zou uitvoeren, en niet aan het schrijven van code. We schrijven de code samen.
Toen we belden, legden de jongens kort uit wie ze waren en wat ze deden. Ze stelden voor dat we met de ontwikkeling zouden beginnen.
Tijdens het hele interview had ik geen enkel moment het gevoel dat ik werd geïnterviewd. Het voelt alsof je in een team code ontwikkelt. Als je ergens vastloopt, helpen ze je, geven ze advies, overleggen ze en discussiëren ze zelfs onderling over de beste manier om het aan te pakken. Tijdens het sollicitatiegesprek was ik vergeten hoe ik in JUnit 5 kon controleren of een methode een Exception genereert. Ze stelden voor dat ik door zou gaan met het schrijven van de test, terwijl een van hen op Google uitzocht hoe het moest.
Letterlijk een paar uur na het interview kreeg ik constructieve feedback: wat ik leuk vond en wat niet. In mijn geval kreeg ik complimenten voor het gebruik van Sealed-klassen als alternatief voor het null-object; om pseudocode te schrijven over hoe ik de rover wil besturen voordat ik de code schrijf, en zo een schets te krijgen van de klassen, althans die welke betrokken zijn bij de robot-API.
Stap 2: Vertel het ons
Een week voor het interview werd mij gevraagd om een presentatie voor te bereiden over een onderwerp dat mij interesseerde. Het format is eenvoudig en bekend: 15 minuten presentatie, 15 minuten vragen beantwoorden.
Ik heb gekozen voor Clean Architecture van Uncle Bob. En opnieuw werd ik door een paar mensen geïnterviewd. Dit was mijn eerste keer dat ik in het Engels presenteerde. Als ik in een stressvolle situatie was geweest, had ik het waarschijnlijk niet gered. Maar nogmaals, ik had geen moment het gevoel dat ik op een sollicitatiegesprek was. Alles verloopt zoals gewoonlijk: ik vertel het verhaal, zij luisteren aandachtig. Zelfs de traditionele vraag- en antwoordsessie leek niet op een interview, het was duidelijk dat de vragen niet waren gesteld om hen te 'laten zinken', maar juist om de vragen te stellen die hen echt interesseerden in mijn presentatie.
Een paar uur na het interview kreeg ik feedback: de presentatie was erg nuttig en ze hadden er echt van genoten om ernaar te luisteren.
Fase 3. Productiekwaliteitscode
Nadat ik was gewaarschuwd dat dit de laatste fase van de technische interviews was, werd mij gevraagd om de code thuis gereed te maken voor productie. Daarna zou ik de code ter beoordeling opsturen en interviews inplannen, waarbij de vereisten voor de taak zouden veranderen en de code aangepast moest worden. Als ik vooruitkijk, kan ik zeggen dat de codebeoordeling blind wordt uitgevoerd. De beoordelaars weten niet op welke functie de kandidaat solliciteert, zien zijn cv niet en zien zelfs zijn naam niet.
Ik belde en weer stonden er een paar mannen aan de andere kant van de monitor. Alles is zoals bij het eerste gesprek: het belangrijkste is dat je TDD niet vergeet, dat je vertelt wat je doet en waarom. Als je TDD nog niet eerder hebt beoefend, raad ik je aan om er meteen mee te beginnen. Niet omdat het verplicht is in bedrijven, maar omdat het je leven een stuk makkelijker maakt en je stressniveau verlaagt. Weet je nog hoe je koortsachtig naar een fout in een debugger moest zoeken die alleen via een browser werd gereproduceerd, maar dat je deze niet met tests kon reproduceren? Stel je nu eens voor dat je tijdens een sollicitatiegesprek op zo'n fout stuit: je krijgt er gegarandeerd grijze haren van. Wat krijgen we met TDD? U hebt de code gewijzigd en besefte plotseling dat de tests nu rood zijn, maar u kunt de eerste keer niet achterhalen wat de fout is? Oké, we zeggen “Oeps” tegen de interviewers, drukken op Ctrl-Z en beginnen kleine stapjes vooruit te zetten. En ja, je moet de vaardigheid ontwikkelen om te ontwikkelen met behulp van TDD, de vaardigheid om naar het doel toe te werken, zodat je tests permanent groen zijn en niet een halve dag rood, omdat "je een grote refactoring hebt." Het is precies dezelfde vaardigheid als het kunnen schrijven van onderhoudbare of productieve code.
Hoe goed uw code kan worden gewijzigd, hangt af van het ontwerp dat u oorspronkelijk hebt geïmplementeerd, hoe eenvoudig het is en hoe goed uw tests zijn.
Na het interview ontving ik binnen een paar uur feedback. Op dat moment besefte ik dat ik er bijna was en dat er nog maar heel weinig over was tot de “ontmoeting met Fowler”.
Fase 4. Finale. Genoeg technische vragen. Wij willen weten wie jij bent!
Eerlijk gezegd was ik enigszins verbaasd over de manier waarop de vraag werd gesteld. Hoe kun je in één uur praten begrijpen wat voor persoon ik ben? En nog belangrijker, hoe kan iemand dit begrijpen als ik een taal spreek die niet mijn moedertaal is en, eerlijk gezegd, ook nog eens heel slecht en met een mond vol tanden sta? In eerdere interviews vond ik het makkelijker om te praten dan om vragen te beantwoorden. Mijn accent is daar debet aan. Minstens één van de interviewers was Aziatisch en zijn of haar accent was, laten we zeggen, een beetje specifiek voor de Europese oren. Daarom besloot ik een proactieve aanpak te hanteren: ik bereidde een presentatie over mezelf voor en bood aan om aan het begin van het sollicitatiegesprek in deze presentatie iets over mezelf te vertellen. Als ze akkoord gaan, heb ik in ieder geval minder vragen. Als ze het aanbod afslaan, dan is 3 uur van mijn leven die ik aan een presentatie besteed, niet zo'n hoge prijs. Maar wat moet je dan in je presentatie schrijven? Biografie - Geboren daar, naar school gegaan, afgestudeerd aan de universiteit - wie maalt erom?
Als je een beetje op Google zoekt naar de cultuur van Thoughtworks, kun je een artikel vinden van Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] waarin de 3 pijlers worden beschreven: duurzaam ondernemen, software-excellentie en sociale rechtvaardigheid.
Laten we ervan uitgaan dat Software Excellence al voor mij is gecontroleerd. Het blijft een kwestie van duurzaam ondernemen en sociale rechtvaardigheid.
Bovendien besloot ik mij op het laatste te concentreren.
Om te beginnen legde ik uit waarom ThoughtWorks zo populair is. Toen ik nog op de universiteit zat, las ik de blog van Martin Fowler. Vandaar mijn liefde voor schone code.
Projecten kunnen ook vanuit verschillende invalshoeken worden gepresenteerd. Ook ontwikkelde hij software voor de geneeskunde die het leven van patiënten makkelijker maakte en volgens geruchten zelfs één mensenleven redde. Ook heb ik software voor banken ontwikkeld, wat het leven voor burgers makkelijker maakt. Zeker als je bedenkt dat 70% van de bevolking van het land gebruikmaakt van deze bank. Dit gaat niet over Sberbank of zelfs over Rusland.
Wil je meer over mij weten? OK. Mijn hobby is fotografie. Ik heb al ongeveer 10 jaar een camera in mijn handen en er zijn foto's die ik niet schroom om te laten zien. Ook heb ik ooit een kattenasiel geholpen: ik maakte foto's van katten die een permanent thuis nodig hadden. En met goede foto’s is het veel gemakkelijker om een thuis voor een kat te vinden. Ik heb zeker honderd katten gefotografeerd :)
Uiteindelijk bestond mijn presentatie voor 80% uit katten.
Direct na de presentatie schreef HR mij dat hij de uitslag van het interview nog niet wist, maar het hele kantoor was al onder de indruk van de katten.
Uiteindelijk heb ik gewacht op feedback. Ik heb iedereen als persoon tevreden gesteld.
Maar tijdens het laatste gesprek legde HR op tactvolle wijze uit dat sociale rechtvaardigheid heel goed en noodzakelijk is, maar dat niet alle projecten zo zijn. En hij vroeg of het mij bang maakte. Over het algemeen ben ik een beetje over de schreef gegaan met sociale rechtvaardigheid, dat gebeurt 🙂
Totaal
Daarom werk ik nu al een aantal maanden in Singapore bij Thoughtworks en zie ik dat veel bedrijven hier de ‘interview best practices’ van Google overnemen. Ze gebruiken folders en Whiteboard voor het coderen, ondanks het feit dat kennis van meer dan Spring, Symfony en RubyOnRails (onderstreep waar van toepassing) niet vereist is voor de baan. Ingenieurs nemen een week vrij vóór een sollicitatiegesprek om zich voor te bereiden.
Bij Thoughtworks staan, naast de adequate eisen waaraan kandidaten moeten voldoen, de volgende principes voorop:
Het plezier van interviewen. En bovendien, voor beide partijen. Als je het beste personeel wilt krijgen (en wie wil dat nou niet?), dan is het interview geen markt waar slaven worden geselecteerd, maar een bezichtiging, waarbij zowel de werkgever als de kandidaat elkaar beoordelen. En als een kandidaat prettige emoties associeert met een bedrijf, is de kans groot dat hij voor dat bedrijf kiest.
Meerdere interviewers om vooringenomenheid te beperken. Bij Thoughtworks is pair programming de feitelijke standaard. En als deze praktijk ook op andere gebieden kan worden toegepast, dan probeert TW dat te doen. In elke fase wordt het interview door 2 personen afgenomen. Elke persoon wordt dus door minimaal 8 personen beoordeeld en TW probeert interviewers te selecteren met verschillende achtergronden, verschillende vakgebieden (niet alleen technici) en geslachten.
Uiteindelijk wordt de beslissing over het aannemen van iemand gebaseerd op de meningen van minimaal 8 personen. Niemand heeft het laatste woord.
Werving op basis van kenmerken In plaats van dat een beslissing wordt genomen op basis van wat een kandidaat wel of niet leuk vindt, wordt er voor elke rol en voor elke fase een formulier ontwikkeld met daarin de te beoordelen eigenschappen. Tegelijkertijd is het bij de beoordeling sterk aan te raden om niet de ervaring met een bepaalde vaardigheid te beoordelen, maar het vermogen om deze toe te passen. Als een kandidaat dus niet de kans heeft gehad om vaardigheden als TDD toe te passen, maar toch probeert om ze toe te passen en luistert naar adviezen over hoe ze op de juiste manier te gebruiken, dan heeft hij een grote kans om het sollicitatiegesprek te doorstaan.
Onderwijscertificaten niet vereist TW vereist niet dat kandidaten verplichte certificeringen of opleidingen in computerwetenschappen hebben. Er wordt alleen naar vaardigheden gekeken.
Dit is het eerste sollicitatiegesprek bij een buitenlands bedrijf waar ik me niet op hoefde voor te bereiden. Na elke fase had ik niet het gevoel dat ik als een citroen werd uitgeknepen, maar juist dat ik blij was dat ik best practices kon toepassen, dat mensen aan de andere kant van de monitor dat waardeerden en ze ook elke dag toepasten.
Na enkele maanden kan ik zeggen dat mijn verwachtingen volledig zijn uitgekomen. Waarin verschilt ThoughtWorks van een gewoon bedrijf? In een normaal bedrijf vind je goede ontwikkelaars en aardige mensen, maar bij TW is de concentratie enorm.
Als u geïnteresseerd bent om bij ThoughtWorks te komen werken, kunt u hier de openstaande vacatures bekijken
Ik raad u ook aan om aandacht te besteden aan interessante vacatures:
Hoofd software-engineer: , , ,
Senior software-ingenieur: , , ,
Software ontwikkelaar: , ,
Senior Data-ingenieur:
Kwaliteitsanalist:
Infrastructuur: , ,
(Ik wil je eerlijk waarschuwen dat de link een verwijzingslink is. Als je naar TW gaat, ontvang ik een leuke bonus.) Kies een kantoor dat bij je past. Je hoeft je niet te beperken tot Europa. TW verhuist je immers graag elke 2 jaar naar een ander land. Dat is onderdeel van het beleid van ThoughtWorks, waardoor de cultuur zich verspreidt en homogener wordt.
Stel gerust uw vragen in de reacties of vraag mij om u aan te bevelen.
Als je het onderwerp interessant vindt, schrijf ik over hoe het is om bij ThoughtWorks te werken en hoe het is om in Singapore te wonen.
Bron: www.habr.com
