Een van de vele dingen die me dwarszitten op LinkedIn is de "hoe te interviewen ontwikkelaars" post. Er zijn tonnen van hen, en ze vallen bijna allemaal in drie kampen:
In de loop der jaren heb ik tientallen keren geïnterviewd en ingehuurd. honderden van ontwikkelaars voor verschillende bedrijven - van Microsoft en Dell tot kleine startups. Ik had ook een voormalig leven als een onderzoekspsycholoog gespecialiseerd in psychometrie (de wetenschap van het meten van mentale capaciteiten). Dus ik heb het proces gezien van elke kant.
Schrijven code is vaak geen sociale activiteit. Tuurlijk - zachte vaardigheden belangrijk. Maar ze zijn vaak orthogonaal aan de praktijk van het schrijven van code om echte gebruikersproblemen op te lossen.
Dus hoe interview je iemand voor een baan dat is Meestal Over het schrijven van code?
Ons beroep is ook rijk aan impositorsyndroom Ik heb het gezien in mezelf en talloze anderen. al Voelt het als een oplichter?
En we zijn vaak een sociaal lastig stelletje Een interview dat allebei stressvol is. en vereist live probleemoplossing is een recept voor een ramp.
Hoe interview je iemand die nerveus is, ongemakkelijk of al aan zichzelf twijfelt?
Waag het niet. start Tenzij hun ervaring klopt, dat respecteert hun tijd. en De jouwe.
Maak het proces duidelijk en menselijk.
Be op tijd. Angst pieken tijdens het wachten. Als ze te laat zijn, geef ze een paar minuten - de kans is groot dat ze niet in back-to-back vergaderingen zoals je bent.
Vraag jezelf af: Pasten ze temperamentvol in het team? Een briljante codeur die een eikel is, is een netto verlies.
Na jaren van Fibonacci vragen en gekoppelde lijst marathons, leerde ik één kern waarheid:
Coders praten graag over code die ze kennen.
Dat is het geheim. En het werkt alleen als de interviewer echt begrijpt wat er getoond wordt. Als je het kader (Engular, React, wat dan ook) niet kent - nog steeds prima. Focus op structuur, helderheid, naamgeving, intentie.
Dus vertel ze van tevoren Vijf dagen is eerlijk... dat je de code wilt bespreken die ze geschreven hebben... geen druk... geen truc. Laat me iets zien waar je over kunt praten.
Misschien hebben ze geen GitHub dat is ok. Een persoonlijke of werk knipsel is prima. Het doel is niet om geniaal te vinden. Het is om te vinden eigendom.
Je neemt geen mensen aan op basis van hoeveel vrije tijd iemand heeft.
I Persoonlijk verlaten codering interviews dezer dagen. Het maakt me MASSIVELY angstig - hoewel ik heb gebouwd honderden systemen. Het is unnecessary.
Dit is waarom deze aanpak beter is:
Junior-kandidaten mayunit synonyms for matching user input Een kleine praktische test - maar hou het menselijk. Maak ze niet refactor een 4.000-line legacy bestand.
Vraag naar loops, voorwaarden, basisprincipes in de echte wereld.
Design patronen? Veel mensen gebruiken ze dagelijks zonder de naam te kennen. Raak niet opgehangen op labels.
Logische puzzels? Nooit nodig gehad in echt werk. Nooit gezien een echt nut om te weten hoeveel piano tuners bestaan in New York.
Of de kandidaat de rol krijgt of niet - follow-up.
Als ze het niet snapten: Leg uit waarom. Geef ze iets nuttigs om weg te nemen.
Als ze het hebben gekregen: Vertel ze wat ze nu kunnen verwachten. Laat ze ademen.
Want uiteindelijk:
Een interview moet onthullen vermogen - niet beschermen ego. Het zou waarde moeten toevoegen - zelfs als het antwoord nee is.
Het meest accurate interview dat ik ooit heb gevonden is eenvoudig: Laat kandidaten praten over code waar ze trots op zijn. Want in code, toont eerlijkheid. Druk verbergt het.
Wanneer mensen verlaten uw interview gevoel gerespecteerd zelfs wanneer afgewezen . . Je hebt al iets opgebouwd dat de moeite waard is om mee te doen.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.
