Vindt u het niet vreemd dat wanneer u van baan wilt veranderen en u moet solliciteren, u in eerste instantie denkt: 'ik moet me voorbereiden op het sollicitatiegesprek'? Oefenen met problemen op HackerRank, het boek Crack the Coding Interview lezen, leren hoe een ArrayList werkt en wat het onderscheid is met een LinkedList. Oh ja, ze kunnen ook vragen naar sorteermethoden, en het zou zeker onprofessioneel zijn om te zeggen dat quick sort waarschijnlijk de beste keuze zal zijn.
Maar wacht even, u programmeert toch 8 uur per dag, lost interessante en niet-triviale problemen op, en op uw nieuwe werkplek zult u min of meer hetzelfde doen. En toch, om een sollicitatiegesprek te doorstaan, moet u op de een of andere manier extra voorbereiden, niet alleen uw dagelijkse vaardigheden verfijnen, maar ook dingen leren die u op uw huidige werkplek niet nodig hebt gehad en die waarschijnlijk ook niet nodig zullen zijn op uw volgende. Op uw tegenargumenten dat computerwetenschappen in ons bloed zitten, en dat als je ons midden in de nacht wakker maakt, we blindelings een breedte-eerste doorloop van een boom moeten kunnen schrijven zonder zelfs maar bij bewustzijn te zijn, zal ik antwoorden dat als ik solliciteer bij een circus en mijn belangrijkste truc precies dat is ā dan ja, dan ga ik akkoord. Het is noodzakelijk om deze vaardigheid te testen.
Maar waarom vaardigheden testen die niet relevant zijn voor uw huidige werk? Alleen omdat het in de mode is? Omdat Google dat doet? Of omdat uw toekomstige teamleider alle sorteermethoden moest leren voor het sollicitatiegesprek en nu denkt dat 'iedere goede programmeur uit zijn hoofd de implementatie van het vinden van een palindroom in een string moet kennen'.
Dus, u bent niet Google. Wat Google zich kan veroorloven, kunnen gewone bedrijven niet. Google kwam, na de gegevens van zijn werknemers te hebben geanalyseerd, tot de conclusie dat specifiek voor hen, ingenieurs met een Olympisch verleden goed presteren bij hun specifieke taken. Bovendien, door het selectieproces op te bouwen, kunnen ze zich de luxe permitteren om het risico te nemen dat ze misschien een paar goede ingenieurs niet aannemen omdat ze niet zo gemakkelijk wiskundige problemen kunnen oplossen. Maar voor hen is dat geen probleem, er zijn velen die bij Google willen werken en de positie zal worden ingevuld.
Laten we nu eens naar buiten kijken. Als er nog steeds ingenieurs voor uw kantoor staan die bij u willen werken, en als uw ontwikkelaars vaker op Stack Overflow op zoek zijn naar de nieuwste Spring-annotatie in plaats van naar de fijnere details van rangschikkingsalgoritmes, dan is het duidelijk tijd om na te denken of het wel verstandig is om Google te kopiƫren.
Goed, als Google deze keer ons in de steek liet en geen antwoord gaf, wat te doen? Controleer precies wat de ontwikkelaar zal doen op het werk. Wat waardeert u in ontwikkelaars?
Stel de criteria op voor wie u wilt aannemen en ontwikkel tests die precies deze vaardigheden beoordelen.
ThoughtWorks
Wat heeft ThoughtWorks hiermee te maken? Dit is waar ik voor mezelf een voorbeeld vond van een model sollicitatiegesprek. Wie zijn ThoughtWorks? Kort gezegd, het is een high-end adviesbedrijf met kantoren over de hele wereld, van China en Singapore tot de Amerikaanse continenten, dat al ongeveer 25 jaar advies geeft op het gebied van softwareontwikkeling. Het heeft zijn eigen wetenschappelijk team, geleid door Martin Fowler. Als u een lijst zoekt van de 10 boeken die elke software engineer moet lezen, zullen er zeker 2-3 van die boeken van ThoughtWorks-leden zijn, 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.
Het bedrijfsmodel van het bedrijf is gebaseerd op het leveren van vrij dure diensten, maar de klant betaalt voor fenomenale kwaliteit, die voortkomt uit expertise, interne normen en natuurlijk mensen. Daarom is het van levensbelang om de juiste mensen aan te nemen.
Wie zijn dan de juiste mensen? Natuurlijk is dat voor iedereen anders. ThoughtWorks heeft vastgesteld dat voor hun bedrijfsmodel de belangrijkste criteria voor ontwikkelaars zijn:
- De capaciteit voor pair programming. Het is daadwerkelijk de capaciteit, niet de ervaring of de vaardigheid. Niemand verwacht dat mensen komen die al vijf jaar aan pair programming doen. Maar ontvankelijk zijn voor andermans mening, kunnen luisteren ā dat is een noodzakelijke vaardigheid.
- In staat zijn om tests te schrijven, idealiter TDD te praktiseren.
- SOLID en OOP begrijpen en in staat zijn deze toe te passen.
- Je mening kunnen presenteren. Als consultant moet je samenwerken met de ontwikkelaars van de klant, met andere consultants, en het heeft weinig zin als iemand iets goed kan doen, maar helemaal niet in staat is om dat aan de andere teamleden over te brengen.
Het is nu belangrijk om deze vaardigheden bij de kandidaat te beoordelen. Hier wil ik mijn ervaring delen met het sollicitatieproces bij ThoughtWorks. Ik zal meteen zeggen dat ik in Singapore ben geweest en ben aangenomen, maar het wervingsproces is gestandaardiseerd en zal niet veel verschillen van land tot land.
Fase 0. HR
Zoals vaak het geval is, was er een gesprek van 20 minuten met HR. Ik zal daar niet verder op ingaan, maar ik kan alleen zeggen dat ik nog nooit een HR heb ontmoet die 15 minuten kon praten over de ontwikkelingscultuur binnen het bedrijf, waarom ze TDD toepassen, en waarom pair programming. Gewoonlijk vervaagt HR op dit punt en vertellen ze dat het proces normaal is: ontwikkelaars ontwikkelen, testers testen, en managers ondersteunen.
Fase 1. Hoe goed ben je in OOP, TDD?
1.5 uur voor het interview kreeg ik de opdracht om een simulator voor Mars Rover te maken.
Opdracht Mars RoverEen team van robotische rovers moet door NASA op een plateau op Mars worden geland. Dit plateau, dat opmerkelijk rechthoekig is, moet door de rovers worden genavigeerd zodat hun onboard camera's een volledig uitzicht op het omliggende terrein kunnen krijgen en naar de aarde kunnen terugsturen. 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 cardinale kompasrichtingen vertegenwoordigt. Een voorbeeldpositie kan 0, 0, N zijn, wat betekent dat de rover zich in de linkerbenedenhoek bevindt en naar het noorden kijkt. Om een rover te besturen, stuurt NASA een eenvoudige reeks letters. De mogelijke letters zijn 'L', 'R' en 'M'. 'L' en 'R' laten de rover respectievelijk 90 graden naar links of rechts draaien, zonder van zijn huidige plaats te bewegen. 'M' betekent vooruit gaan met ƩƩn gridpunt en dezelfde richting behouden.
Neem aan dat het vierkant direct ten noorden van (x, y) (x, y+1) is.
INVOER:
De eerste lijn van de invoer zijn de coƶrdinaten van de rechterbovenhoek van het plateau, de linkerbenedenhoek wordt aangenomen als 0,0.
De rest van de invoer betreft informatie over de rovers die zijn ingezet. Elke rover heeft twee lijnen van invoer. De eerste lijn geeft de positie van de rover aan, en de tweede lijn is een reeks instructies die de rover vertelt hoe hij het plateau moet verkennen. De positie bestaat uit twee integers en een letter, gescheiden door spaties, die overeenkomen met de x- en y-coƶrdinaten en de oriƫntatie van de rover.
Elke rover zal achtereenvolgens worden afgerond, wat betekent dat de tweede rover niet begint te bewegen totdat de eerste is geƫindigd.
UITVOER:
De uitvoer voor elke rover moet zijn uiteindelijke coƶrdinaten en richting zijn.
OPMERKINGEN:
Implementeer eenvoudig de vereisten hierboven en bewijs dat een stofzuiger werkt door er unit tests voor te schrijven.
Het maken van enige vorm van gebruikersinterface valt buiten de scope.
Het oplossen van het probleem volgens een TDD (Test Driven Development) benadering heeft de voorkeur.
In de beperkte tijd die we hebben, zijn we meer bezorgd over kwaliteit dan over volledigheid.
*Ik kan de opdracht die ik kreeg niet delen, het is een oude opdracht die enkele jaren geleden werd gegeven. Maar geloof me, principieel is alles hetzelfde gebleven.
Het is belangrijk om de beoordelingscriteria onder de aandacht te brengen. Hoe vaak heeft u wel niet meegemaakt dat belangrijke zaken voor een kandidaat helemaal niet relevant zijn bij de beoordeling, en omgekeerd? Niet iedereen denkt hetzelfde als u, maar velen kunnen uw waarden accepteren en volgen als ze duidelijk zijn geformuleerd. Dus, uit de beoordelingscriteria blijkt meteen dat de belangrijkste vaardigheden in deze fase zijn
- TDD;
- Het vermogen om OOP te gebruiken en onderhoudbare code te schrijven;
- vaardigheden in pair programming
Dus, ik werd gewaarschuwd om deze 1,5 uur te besteden aan nadenken over hoe ik de taak ga aanpakken, in plaats van het schrijven van code. De code zullen we samen schrijven.
Toen we belden, vertelden de jongens kort wie ze zijn en wat ze doen, en stelden voor om met de ontwikkeling te beginnen.
Tijdens het hele interview heb ik nooit het gevoel gehad dat ik op een sollicitatiegesprek was. Het voelt alsof je code schrijft in een team. Als je ergens vastloopt, helpen ze je, geven advies, discussiƫren, zelfs ruziƫn met elkaar over de beste aanpak. Tijdens het interview vergat ik hoe ik in JUnit 5 kon controleren of een methode een uitzondering gooit - zij stelden voor om door te gaan met het schrijven van de test, terwijl een van hen zocht naar hoe dit te doen.
Al enkele uren na het sollicitatiegesprek ontving ik constructieve feedback - wat goed was en wat niet. In mijn geval werd ik geprezen voor het gebruik van Sealed classes als alternatieve oplossing voor object null; dat ik voordat ik de code schreef pseudo-code had geschreven over hoe ik de rover wilde aansturen, en zo een schets van de klassen had gekregen, althans diegene die betrokken zijn bij de API van de robot.
Fase 2. Vertel ons
Een week voor het sollicitatiegesprek werd ik gevraagd om een presentatie voor te bereiden over een onderwerp dat me interesseert. Het format is eenvoudig en vertrouwd: 15 minuten presentatie, 15 minuten vraag-en-antwoordsessie.
Ik heb Clean Architecture by Uncle Bob gekozen. En opnieuw interviewde een paar mensen me. Dit was mijn eerste ervaring met presenteren in het Engels, en als ik in een stressvolle situatie had gezeten, had ik het waarschijnlijk niet gered. Maar nogmaals, ik had nooit het gevoel dat ik op een sollicitatiegesprek was. Het was zoals gewoonlijk ā ik vertel, zij luisteren aandachtig. Zelfs de traditionele vragen- en antwoordenronde leek niet op een interview; het was duidelijk dat de vragen niet werden gesteld om me 'te laten zinken', maar interesse toonden in mijn presentatie.
Enkele uren na het interview ontving ik feedback ā de presentatie was zeer waardevol en ze hadden oprecht genoten van het luisteren.
Stap 3. Productiekwaliteit Code
Met de waarschuwing dat dit de laatste stap van de technische sollicitatiegesprekken was, werd me gevraagd om de code thuis in een production-ready staat te brengen, waarna ik de code moest indienen voor een review en sollicitaties moest plannen, waarbij de eisen voor de taak zouden veranderen en de code aanpassing zou vereisen. Vooruitlopend kan ik zeggen dat de code-review blind gebeurt, de reviewers weten niet welk functie de kandidaat nastreeft, zien zijn CV niet en kennen zelfs zijn naam niet.
Een telefoongesprek en opnieuw een paar jongens aan de andere kant van het scherm. Het is allemaal zoals bij het eerste interview: vergeet niet over TDD te praten, vertel wat je doet en waarom. Als je eerder geen TDD hebt toegepast, raad ik je aan nu meteen te beginnen, niet omdat het noodzakelijk is in bedrijven, maar omdat het je leven aanzienlijk vergemakkelijk. Vergeet niet hoe je wanhopig naar een bug zocht die alleen in de browser reproduceerbaar is, maar die je niet met tests kunt reproduceren? Stel je nu voor dat je zo'n fout tijdens een interview moet achterhalen ā dan ben je gegarandeerd een paar grijze haren rijker. Wat biedt TDD ons? Je hebt de code aangepast en tot je verbazing zie je nu dat de tests falen, maar je kunt niet meteen begrijpen waar de fout zit? OkĆ©, je zegt tegen de interviewers: āOepsā, drukt op Ctrl-Z en begint kleine stapjes vooruit te zetten. En ja, het vermogen om te ontwikkelen met TDD moet je in jezelf cultiveren, het vermogen om je doel te bereiken zodat je tests permanent groen zijn en niet de hele dag rood omdat āje een grote refactor hebtā. Dit is net zo'n vaardigheid als het schrijven van onderhouden code of prestatiegerichte code.
Dus hoe goed je code aanpassingen kan weerstaan, hangt af van het ontwerp dat je oorspronkelijk hebt neergelegd, hoe eenvoudig het is en hoe goed je tests zijn.
Na het gesprek ontving ik feedback binnen enkele uren. Op dat moment realiseerde ik me dat ik praktisch was aangenomen en dat er nog maar een klein beetje overbleef voor de āontmoeting met Fowlerā.
Fase 4. De finale. Genoeg technische vragen. We willen weten wie je bent!
Eerlijk gezegd, zal deze vraagstelling me een beetje verbazen. Hoe kan iemand begrijpen wat voor persoon ik ben na slechts Ć©Ć©n uur gesprek? En nog meer, hoe is dat mogelijk als ik spreek in een taal die niet mijn moedertaal is, en, openlijk gezegd, nogal gebrekkig en onhandig? Tijdens eerdere interviews vond ik het gemakkelijker om iets te vertellen dan om op vragen te antwoorden, en dat kwam vooral door mijn accent. Tenminste Ć©Ć©n van de interviewers was Aziatisch ā hun accent is, laten we zeggen, behoorlijk specifiek voor Europese oren. Daarom besloot ik een proactieve benadering te hanteren ā een presentatie over mezelf voor te bereiden en aan het begin van het gesprek voor te stellen om over mezelf te vertellen met behulp van deze presentatie. Als ze akkoord gaan, zullen er in ieder geval minder vragen aan mij gesteld worden; als ze het aanbod afwijzen ā ach, drie uur van mijn leven besteed aan de presentatie is niet zo'n hoge prijs. Maar wat moet ik in de presentatie schrijven? Mijn biografie ā Geboren daar, toen, naar school gegaan, universiteit afgerond ā wie heeft daar interesse in?
Als je een beetje googelt over de cultuur van Thoughtworks, kun je een artikel van Martin Fowler vinden [https://martinfowler.com/bliki/ThreePillars.html], waarin de 3 Pijlers worden beschreven: Duurzaam Bedrijf, Software Uitmuntendheid en Sociale Rechtvaardigheid.
Stel dat mijn Software Uitmuntendheid al is gecontroleerd. Nu moet ik Duurzaam Bedrijf en Sociale Rechtvaardigheid laten zien.
Ik besloot me vooral op het laatste te concentreren.
Om te beginnen legde ik uit waarom ThoughtWorks ā ik las al in de universiteit de blog van Martin Fowler, vandaar mijn liefde voor Clean Code.
Projecten kunnen ook vanuit verschillende perspectieven worden gepresenteerd. Ik heb software ontwikkeld voor de gezondheidszorg, die het leven van patiƫnten vereenvoudigde, en volgens geruchten zelfs een leven heeft gered. Ook heb ik software ontwikkeld voor banken, wat ook een soort vereenvoudiging van het leven van de burgers is. Vooral als ongeveer 70% van de bevolking van het land gebruik maakt van die bank. En het gaat hier niet over Sberbank en zelfs niet over Rusland.
Wil je meer over mij weten? OkĆ©. Mijn hobby is fotografie; ik houd al ongeveer 10 jaar een camera in mijn handen en heb foto's die ik niet al te moeilijk vind om te tonen. Ook hielp ik een tijdlang een dierenasiel: ik fotografeerde katten die een permanent huis nodig hadden. Met goede foto's is het veel gemakkelijker om een kat een nieuw huis te geven. Ik heb waarschijnlijk zo'n honderd katten gefotografeerd š.
Uiteindelijk was 80% van mijn presentatie gevuld met katten.
Directly after the presentation, HR contacted me saying they still don't know the results of the interview, but the whole office is already impressed with the cats.
In the end, I received feedback ā I satisfied everyone as a person.
However, HR tactfully mentioned in the final conversation that Social Justice is very good and necessary, but not all projects align with that. They asked if this concerns me. In general, I may have gone a bit overboard with Social Justice, it happens š
Conclusie
As a result, I have been working in Singapore at Thoughtworks for several months now, and I see that many companies here are adopting the 'best interview practices' from Google, using sheets and Whiteboards for coding, despite the fact that knowledge beyond Spring, Symfony, and RubyOnRails (underline as needed) is not required for work. Engineers take a week off before interviews to 'prepare.'
At Thoughtworks, in addition to reasonable requirements for candidates, the following principles are prioritized:
Joy of Interviewing. Indeed, if you want to attract the best talents (and who doesnāt?), then the interview should not be a marketplace for choosing slaves, but a meeting where both the employer and the candidate evaluate each other. If a candidate associates pleasant emotions with the company, it is quite likely that they will choose that company.
Multiple interviewers to mitigate bias. At Thoughtworks, pair programming is the de facto standard. If this practice can be applied to other areas, TW strives to do so. At each stage, the interview is conducted by 2 people. Thus, every individual is evaluated by at least 8 people, and TW tries to select interviewers with different backgrounds, various specialties (not just tech), and genders.
Ultimately, the decision to hire will be based on the opinions of at least 8 people, and no one has the right to a decisive vote.
Attribute-based hiring In plaats van een beslissing te nemen op basis van de 'leuk of niet leuk' van de kandidaat, is er voor elke rol en voor elke fase een formulier ontwikkeld waarin de te beoordelen attributen zijn opgenomen. Bij evaluaties wordt sterk aangeraden niet te kijken naar de ervaring in een bepaalde vaardigheid, maar naar het vermogen om deze toe te passen. Op deze manier, als een kandidaat geen kans heeft gehad om bepaalde vaardigheden, zoals TDD, toe te passen, maar desondanks probeert deze toe te passen en advies over het juiste gebruik aanhoort, heeft hij alle kans om de sollicitatie te doorstaan.
Opleiding certificaten niet vereist TW vereist van de kandidaat geen verplichte certificaten of een opleiding in Computer Science. Alleen vaardigheden worden beoordeeld.
Dit is het eerste interview dat ik heb gehad bij buitenlandse bedrijven waarvoor ik me niet hoefde voor te bereiden. Na elke fase voelde ik me niet als een uitgeperste citroen, maar was ik blij dat ik de beste praktijken kon toepassen, dat de mensen aan de andere kant van het scherm dit waarderen en deze ook dagelijks toepassen.
Na enkele maanden kan ik zeggen dat de verwachtingen volledig zijn waargemaakt. Wat maakt ThoughtWorks anders dan een gewoon bedrijf? In een gewoon bedrijf vind je goede ontwikkelaars en aangename mensen, maar bij TW is hun concentratie ongeƫvenaard.
Als je je bij ThoughtWorks wilt aansluiten, kun je de openstaande vacatures bekijken
Ik raad ook aan om een kijkje te nemen naar interessante vacatures:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastructuur: , ,
(Ik wil je eerlijk waarschuwen dat de link referral is, als je naar TW gaat, ontvang ik een leuke bonus). Kies een kantoor dat je leuk vindt, je hoeft je niet alleen tot Europa te beperken, want elke 2 jaar is TW blij om je naar een ander land te verhuizen, aangezien dit deel uitmaakt van het beleid van ThoughtWorks, waardoor de cultuur zich verspreidt en gemiddeld wordt.
Aarzel niet om vragen te stellen in de reacties of mij te vragen om je aan te bevelen.
Als het onderwerp interessant leek, zal ik schrijven over hoe het is om bij ThoughtWorks te werken en hoe het leven in Singapore is.
Bron: habr.com
