Vindt u het niet vreemd dat wanneer u op het punt staat van baan te veranderen en de noodzaak zich voordoet om te slagen voor een sollicitatiegesprek, het eerste wat u denkt is ‘u moet zich voorbereiden op het sollicitatiegesprek’. Los problemen op HackerRank op, lees Crack the coding interview, onthoud hoe ArrayList werkt en hoe het verschilt van LinkedList. Oh ja, ze zouden ook kunnen vragen naar sorteren, en het zou uiteraard onprofessioneel zijn om te zeggen dat snel sorteren hoogstwaarschijnlijk de beste keuze zou zijn.
Maar wacht, je programmeert 8 uur per dag, lost interessante en niet-triviale problemen op, en op je nieuwe baan zul je hetzelfde doen, plus of min. Maar toch, om te slagen voor een sollicitatiegesprek, moet je je op de een of andere manier extra voorbereiden, niet eens je dagelijkse vaardigheden aanscherpen, maar iets leren dat je niet nodig had bij je huidige baan en waarschijnlijk niet nodig zal hebben bij je volgende baan. Op uw bezwaren dat informatica in ons bloed zit, en als u ons midden in de nacht wakker maakt, zijn we verplicht om met onze ogen dicht op een kussensloop een wandeling rond de breedte van een boom te schrijven zonder zelfs maar bij bewustzijn te komen, ik zal antwoorden dat als ik een baan in het circus krijg, en mijn belangrijkste ding zou precies dit zijn - dan ben ik het er misschien wel mee eens. Deze vaardigheid moet worden getest.
Maar waarom zou u vaardigheden testen die niet relevant zijn voor uw huidige baan? Alleen maar omdat het in de mode is? Omdat Google dit doet? Of omdat jouw toekomstige teamleider vóór het interview alle sorteermethoden moest leren en nu gelooft dat “elke goede programmeur de implementatie van het vinden van een palindroom in een string uit zijn hoofd moet kennen.”
Nou, jij bent Google niet (c). Wat Google zich kan veroorloven, kunnen gewone bedrijven niet. Google kwam, na analyse van de gegevens van zijn medewerkers, tot de conclusie dat ingenieurs met een Olympiade-achtergrond goed zijn in het uitvoeren van hun specifieke taken. Bovendien kunnen ze zich door het ontwerpen van hun selectieproces het risico veroorloven dat ze niet een paar goede ingenieurs in dienst nemen, omdat ze wiskundeproblemen niet gemakkelijk kunnen oplossen. Maar voor hen is dit geen probleem, er zijn veel mensen die bij Google willen werken, de functie komt te vervallen.
Laten we nu eens uit het raam kijken, en als voor uw kantoor de ingenieurs die voor u willen werken nog geen tentenkamp hebben opgezet, en uw ontwikkelaars vaker op stackoverflow kijken voor wat de volgende lente-annotatie moet worden geïnstalleerd, in plaats van de complexiteit van rangschikkingsalgoritmen, dan is het blijkbaar tijd dat u erover nadenkt of u Google moet kopiëren.
Welnu, als Google deze keer faalde en geen antwoord gaf, wat moet je dan doen? Controleer precies wat de ontwikkelaar op het werk gaat doen. Wat waardeer je in ontwikkelaars?
Maak criteria voor wie u wilt aannemen en ontwikkel tests die precies deze vaardigheden testen.
ThoughtWorks
Wat heeft ThoughtWorks hiermee te maken? Hier vond ik een voorbeeld van een modelinterview voor mezelf. Wie zijn ThoughtWorks? Kortom, dit is een High-End adviesbureau met vestigingen over de hele wereld, van China, Singapore tot de Amerikaanse continenten, dat al zo’n 25 jaar advies geeft op het gebied van ontwikkeling, een eigen Science divisie heeft, onder leiding van Martin Fowler. Als je op zoek bent naar een lijst met 10 boeken die je als software-ingenieur moet lezen, dan zijn er misschien twee tot drie geschreven door de jongens van ThoughtWorks, zoals Refactoring door Martin Fowler en Building Microservices: Designing Fine-Grained Systems door Sam Newman of het bouwen van evolutionaire architecturen
door Patrick Kua, Rebecca Parsons, Neal Ford.
De activiteiten van het bedrijf zijn gebaseerd op het leveren van vrij dure diensten, maar de klant betaalt voor fenomenale kwaliteit, die bestaat uit expertise, interne normen en natuurlijk mensen. Daarom is het inhuren van de juiste mensen hier van cruciaal belang.
Wat voor soort mensen hebben gelijk? Natuurlijk zijn er voor iedereen verschillende. ThoughtWorks heeft vastgesteld dat de belangrijkste criteria voor hun businessmodel voor ontwikkelaars zijn:
- Mogelijkheid om zich in paren te ontwikkelen. Het gaat om bekwaamheid, niet om ervaring of vaardigheid. Niemand verwacht dat er mensen zullen komen die al 5 jaar met Pair programmeren bezig zijn, maar ontvankelijk zijn voor de mening van anderen en kunnen luisteren is een noodzakelijke vaardigheid.
- Mogelijkheid om tests te schrijven en idealiter TDD te oefenen
- Begrijp SOLID en OOP en kan deze toepassen.
- Presenteer uw mening. Als consultant moet je samenwerken met de ontwikkelaars van de klant, met andere consultants, en het heeft niet veel nut als iemand iets goed weet te doen, maar het totaal niet kan overbrengen op de rest van het team.
Nu is het belangrijk om deze specifieke vaardigheden bij de kandidaat te evalueren. En hier wil ik het hebben over mijn ervaring met solliciteren bij ThoughtWorks. Ik zal meteen zeggen dat ik naar Singapore ben gegaan en ben geslaagd, maar het rekruteringsproces is uniform en zal van land tot land niet veel verschillen.
Fase 0. HR
Zoals vaak gebeurt, een interview van 20 minuten met HR. Ik zal er niet bij stilstaan, ik zal alleen zeggen dat ik nog nooit een HR-persoon heb ontmoet die 15 minuten kon praten over de ontwikkelingscultuur in het bedrijf, waarom ze TDD gebruiken, waarom pair programming. Meestal blijven HR's op deze vraag ingaan en zeggen dat hun proces normaal is: ontwikkelaars ontwikkelen, testers testen, managers sturen.
Fase 1. Hoe goed ben je in OOP, TDD?
1.5 uur voor aanvang van het interview kreeg ik de opdracht om een Mars Rover-simulator te maken.
Marsrover-missieEen team robotwagens zal door NASA op een plateau op Mars worden geland. Dit plateau, dat merkwaardig rechthoekig is, moet door de rovers worden genavigeerd, zodat hun camera's aan boord een volledig beeld van het omringende terrein kunnen krijgen en naar de aarde kunnen worden teruggestuurd. De positie en locatie van een rover wordt weergegeven door een combinatie van x- en y-coördinaten en een letter die een van de vier windstreken vertegenwoordigt. Het plateau is opgedeeld in een raster om de navigatie te vereenvoudigen. Een voorbeeldpositie zou 0, 0, N kunnen zijn, wat betekent dat de rover zich in de linkerbenedenhoek bevindt en naar het noorden gericht is. Om een rover te besturen, stuurt NASA een eenvoudige reeks letters. De mogelijke letters zijn 'L', 'R' en 'M'. 'L' en 'R' zorgen ervoor dat de rover respectievelijk 90 graden naar links of rechts draait, zonder van zijn huidige plek te bewegen. 'M' betekent één roosterpunt vooruit gaan en dezelfde koers aanhouden.
Neem aan dat het vierkant direct ten noorden van (x, y) (x, y+1) is.
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 is informatie met betrekking tot de rovers die zijn ingezet. Elke rover heeft twee invoerlijnen. De eerste regel geeft de positie van de rover aan, en de tweede regel is een reeks instructies die de rover vertellen hoe hij het plateau moet verkennen. De positie bestaat uit twee gehele getallen en een letter, gescheiden door spaties, die overeenkomen met de x- en y-coördinaten en de oriëntatie van de rover.
Elke rover wordt opeenvolgend afgewerkt, wat betekent dat de tweede rover pas begint te bewegen als de eerste klaar is met bewegen.
OUTPUT:
De uitvoer voor elke rover moet de uiteindelijke coördinaten en richting zijn.
OPMERKINGEN:
Implementeer eenvoudigweg de bovenstaande vereisten en bewijs dat een stofzuiger werkt door er unit-tests voor te schrijven.
Het creëren van welke vorm van gebruikersinterface dan ook valt buiten het bereik.
Het oplossen van het probleem door het volgen van een TDD-aanpak (Test Driven Development) heeft de voorkeur.
In de korte beschikbare tijd zijn wij meer bezorgd over kwaliteit dan over volledigheid.
*Ik kan de opdracht die mij is toegestuurd niet plaatsen, dit is een oude opdracht die enkele jaren geleden is gegeven. Maar geloof me, fundamenteel blijft alles hetzelfde.
Ik zou vooral de aandacht willen vestigen op de evaluatiecriteria. Hoe vaak bent u niet een situatie tegengekomen waarbij zaken die voor een kandidaat belangrijk zijn tijdens de audit totaal onbelangrijk zijn en omgekeerd. Niet iedereen denkt op dezelfde manier als jij, maar velen kunnen jouw waarden accepteren en volgen als deze duidelijk worden geformuleerd. Uit de evaluatiecriteria blijkt dus meteen dat de belangrijkste vaardigheden in dit stadium zijn
- TDD;
- Mogelijkheid om OOP te gebruiken en onderhoudbare code te schrijven;
- programmeervaardigheden combineren
Ik werd dus gewaarschuwd om die 1.5 uur te besteden aan het nadenken over hoe ik de taak ging uitvoeren, in plaats van code te schrijven. Samen schrijven we de code.
Toen we aan de telefoon kwamen, vertelden de jongens ons kort wie ze zijn en wat ze doen en boden ze aan om met de ontwikkeling te beginnen.
Gedurende het gehele interview heb ik geen moment het gevoel gehad dat ik geïnterviewd werd. Er heerst het gevoel dat je in teamverband code ontwikkelt. Als je ergens vastloopt, helpen, adviseren, overleggen en discussiëren ze zelfs met elkaar over hoe je dat het beste kunt doen. Tijdens het interview vergat ik hoe ik in JUnit 5 moest controleren of een methode een uitzondering genereert - ze boden aan om door te gaan met het schrijven van de test, terwijl een van hen aan het googlen was hoe het moest.
Letterlijk een paar uur na het interview kreeg ik constructieve feedback: wat ik leuk vond en wat niet. In mijn geval werd ik geprezen omdat ik Sealed-klassen gebruikte als alternatief voor het nulobject; voor het feit dat ik, voordat ik de code schreef, in pseudocode schreef hoe ik de rover wilde besturen, en zo een schets ontving van de klassen, tenminste die welke betrokken zijn bij de API van de robot.
Stap 2: Vertel het ons
Een week voor het interview werd mij gevraagd een presentatie voor te bereiden over elk onderwerp dat mij interesseerde. Het format is eenvoudig en vertrouwd: 15 minuten presenteren, 15 minuten beantwoorden van vragen.
Ik heb gekozen voor Clean Architecture van Uncle Bob. En opnieuw werd ik door een paar mensen geïnterviewd. Dit was mijn eerste ervaring met presenteren in het Engels, en als ik in een stressvolle situatie had gezeten, had ik het misschien niet aankunnen. Maar nogmaals, ik heb nooit het gevoel gehad dat ik bij een sollicitatiegesprek was. Alles is zoals gewoonlijk - ik vertel het ze, ze luisteren aandachtig. Zelfs de traditionele vraag-en-antwoordsessie leek niet op een interview; het was duidelijk dat de vragen niet werden gesteld om te ‘zinken’, maar om de vragen die hen echt interesseerden in mijn presentatie.
Een paar uur na het interview kreeg ik feedback: de presentatie was erg nuttig en ze luisterden met veel plezier.
Fase 3. Productiekwaliteitscode
Nadat ik had gewaarschuwd dat dit de laatste fase van de technische interviews was, werd mij gevraagd om de code thuis in een productieklare staat te brengen, de code vervolgens ter beoordeling op te sturen en interviews te plannen waarin de vereisten voor de taak zouden veranderen en de code zou veranderen. wijziging vereisen. Vooruitkijkend kan ik zeggen dat de codereview blindelings wordt uitgevoerd, de reviewers weten niet op welke functie de kandidaat solliciteert, ze zien zijn cv niet, ze zien niet eens zijn naam.
De telefoon ging en opnieuw stonden er een paar jongens aan de andere kant van de monitor. Alles is hetzelfde als bij het eerste interview: het belangrijkste is om TDD niet te vergeten, te vertellen wat je doet en waarom. Als je TDD nog niet eerder hebt beoefend, dan raad ik aan om er meteen mee te beginnen, niet omdat het nodig is in bedrijven, maar omdat het je leven aanzienlijk vereenvoudigt en je stressniveau vermindert als je wilt. Weet je nog hoe je verwoed met een debugger moest zoeken naar een fout die alleen via de browser kon worden gereproduceerd, maar je deze niet met tests kunt reproduceren? Stel je nu voor dat je tijdens een sollicitatiegesprek zo'n fout zult moeten opmerken - je hebt gegarandeerd een paar grijze haren. Wat krijgen we met TDD? We hebben de code gewijzigd en realiseerden ons onverwachts dat de tests nu rood zijn, maar wat is de fout die we de eerste keer niet kunnen achterhalen? Oké, we zeggen “Oeps” tegen de interviewers, druk op Ctrl-Z en begin kleine stapjes vooruit te zetten. En ja, je moet het vermogen ontwikkelen om jezelf te ontwikkelen met behulp van TDD, het vermogen om naar het doel te gaan, zodat je tests permanent groen zijn, en niet een halve dag rood, omdat “je veel refactoring hebt.” Dit is precies dezelfde vaardigheid als het schrijven van onderhoudbare code of het schrijven van productieve code.
Hoe goed uw code kan worden gewijzigd, hangt dus af van het ontwerp dat u in gedachten heeft, hoe eenvoudig het is en hoe goed uw tests zijn.
Na het interview kreeg ik binnen een paar uur feedback. In dit stadium besefte ik dat ik bijna klaar was en dat er nog maar heel weinig over was totdat ik ‘Fowler ontmoette’.
Etappe 4. Finale. Genoeg technische vragen. Wij willen weten wie jij bent!
Eerlijk gezegd was ik enigszins verbaasd over deze formulering van de vraag. Hoe kun je in één uur gesprek begrijpen wat voor soort persoon ik ben? En nog belangrijker: hoe kun je dit begrijpen als ik een taal spreek die niet mijn moedertaal is, en, eerlijk gezegd, erg belabberd en met veel mond vol tanden. In eerdere interviews was het voor mij persoonlijk makkelijker om te praten dan om vragen te beantwoorden, en dat lag aan het accent. Minstens één van de interviewers was Aziatisch - en hun accent is, laten we zeggen, enigszins specifiek voor het Europese oor. Daarom besloot ik een proactieve aanpak te volgen: een presentatie over mezelf voorbereiden en aan het begin van het interview aanbieden om met deze presentatie over mezelf te praten. Als ze ermee instemmen, zullen er in ieder geval minder vragen voor mij zijn; als ze het aanbod afwijzen, nou, drie uur van mijn leven aan een presentatie besteden is niet zo'n hoge prijs. Maar wat moet u in uw presentatie schrijven? Biografie - Daar geboren, destijds naar school gegaan, afgestudeerd aan de universiteit - maar wat maakt het uit?
Als je een beetje googelt over de Thoughtworks-cultuur, vind je een artikel van Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] waarin de drie pijlers worden beschreven: duurzaam ondernemen, uitmuntende software en sociale rechtvaardigheid.
Laten we aannemen dat Software Excellence al voor mij is gecontroleerd. Rest ons nog om duurzaam ondernemen en sociale rechtvaardigheid te laten zien.
Bovendien besloot ik me op dat laatste te concentreren.
Om te beginnen vertelde ik hem waarom ThoughtWorks: ik las de blog van Martin Fowler toen ik op de universiteit zat, vandaar mijn liefde voor schone code.
Projecten kunnen ook vanuit verschillende invalshoeken worden gepresenteerd. Hij ontwikkelde ook software voor de geneeskunde die de levens van patiënten vereenvoudigde en, volgens geruchten, zelfs één leven redde. Ook ontwikkelde ik software voor banken, wat het leven van burgers ook makkelijker maakte. Vooral als deze bank door 70% van de bevolking van het land wordt gebruikt. Dit gaat niet over Sberbank en zelfs niet over Rusland.
Wil je meer over mij weten? OK. Mijn hobby is fotografie, op de een of andere manier houd ik al zo'n 10 jaar een camera in mijn handen, er zijn foto's die ik niet te beschaamd vind om te laten zien. Ook heb ik ooit een kattenasiel geholpen: ik fotografeerde katten die een permanent huis nodig hadden. En met goede foto's is het veel gemakkelijker om een kat te plaatsen. Ik heb waarschijnlijk honderd katten gefotografeerd :)
Uiteindelijk bestond 80% van mijn presentatie uit katten.
Direct na de presentatie schreef HR mij dat hij de resultaten van het interview nog niet kende, maar dat het hele kantoor al onder de indruk was van de katten.
Uiteindelijk wachtte ik op feedback - ik stelde iedereen als persoon tevreden.
Maar tijdens het laatste gesprek zei HR tactvol dat sociale rechtvaardigheid heel goed en noodzakelijk is, maar niet alle projecten zijn zo. En hij vroeg of ik er bang van werd. Over het algemeen ging ik een beetje overboord met sociale rechtvaardigheid, het gebeurt :)
Totaal
Als gevolg hiervan werk ik nu al een aantal maanden in Singapore bij Thoughtworks, en ik zie dat hier te veel bedrijven de “beste interviewpraktijken” van Google overnemen, waarbij ze bladeren en Whiteboard gebruiken voor codering, ondanks dat ze meer kennis hebben dan Spring. Symfony, RubyOnRails (onderstreep wat nodig is) is niet vereist in het werk. Ingenieurs nemen vóór een sollicitatiegesprek een week vrij om zich ‘voor te bereiden’.
Bij Thoughtworks staan, naast adequate eisen aan de kandidaat, de volgende uitgangspunten voorop:
Vreugde van interviewen. Bovendien voor beide partijen. Als je het beste personeel wilt hebben (en wie wil dat niet?), dan is een sollicitatiegesprek geen markt waar slaven worden uitgekozen, maar een show 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 dit specifieke bedrijf kiest
Meerdere interviewers om vooringenomenheid te verminderen. Bij Thoughtworks is pair programming de de facto standaard. En als deze praktijk op andere gebieden kan worden toegepast, probeert TW dat te doen. In elke fase wordt het interview afgenomen door 2 personen. Elke persoon wordt dus door minimaal 8 personen beoordeeld en TW probeert interviewers te selecteren met verschillende achtergronden, verschillende richtingen (niet alleen techneuten) en geslacht.
Uiteindelijk wordt de aanwervingsbeslissing genomen op basis van de mening van ten minste acht mensen, en niemand heeft een doorslaggevende stem.
Aanwerving op basis van kenmerken In plaats van een beslissing te nemen op basis van de voorkeuren of antipathieën van een kandidaat, wordt voor elke rol en elke fase een formulier ontwikkeld met daarin de eigenschappen die worden beoordeeld. Tegelijkertijd wordt het ten zeerste aanbevolen om bij de beoordeling niet de ervaring met een bepaalde vaardigheid te evalueren, maar het vermogen om deze toe te passen. Dus als een kandidaat geen enkele vaardigheden, zoals TDD, kon toepassen, maar hij toch probeert ze toe te passen, luistert naar advies over hoe hij ze correct kan gebruiken, heeft hij alle kans om te slagen voor het sollicitatiegesprek.
Onderwijscertificaten niet vereist TW vereist geen certificering of opleiding in computerwetenschappen. Alleen vaardigheden worden beoordeeld.
Dit is het eerste interview dat ik heb gehad met buitenlandse bedrijven waarvoor ik me niet hoefde voor te bereiden. Na elke fase voelde ik mij niet uitgeput, maar integendeel, ik was blij dat ik de best practices kon toepassen, dat mensen aan de andere kant van de monitor het waardeerden en elke dag toepasten.
Na enkele maanden kan ik zeggen dat mijn verwachtingen volledig zijn ingelost. Waarin verschilt ThoughtWorks van een regulier bedrijf? In een gewoon bedrijf kun je goede ontwikkelaars en aardige mensen vinden, maar in TW is hun concentratie buiten de hitlijsten.
Als je geïnteresseerd bent om je bij ThoughWorks aan te sluiten, kun je onze openstaande vacatures bekijken
Ik stel ook voor om aandacht te besteden aan interessante vacatures:
Hoofdsoftware-ingenieur: , , ,
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 je leuk vindt, je hoeft je niet te beperken tot Europa, TW verhuist je immers elke 2 jaar graag naar een ander land, want... dit maakt deel uit van het ThoughtWorks-beleid, dus de cultuur wordt verspreid en gehomogeniseerd.
Stel gerust vragen in de reacties of vraag mij om aanbevelingen.
Als het onderwerp je interessant lijkt, zal ik schrijven over hoe het is om bij ThoughtWorks te werken en hoe het leven in Singapore is.
Bron: www.habr.com