Tot 2024 namen we mensen aan zoals de meeste bedrijven nog steeds doen. Een take-home of een demoproject, wat programmeervragen, een gesprek over wat ze hadden gebouwd. Het werkte omdat het bouwen zelf moeilijk was. Als iemand een nette, werkende applicatie had opgeleverd, zei dat iets.
Het is niet moeilijk meer. Het gevolg is puur mechanisch: elke take-home die we in onze laatste wervingsrondes kregen, zag er hetzelfde uit. Elke take-home was door een model geschreven, en op het scherm zie je het verschil niet. Teams die er nog op leunen, filteren in feite alleen op kandidaten die bereid zijn een avond lang een agent aan te sturen.
LeetCode-achtige tests hebben het tegenovergestelde probleem. Ze meten iets reëels, maar wat ze meten is patroonherinnering onder tijdsdruk, en dat was zelfs voor de tools veranderden al geen goede voorspeller voor senior werk. Je leert niet hoe een senior engineer omgaat met een schema-wijziging door te kijken hoe ze een binaire boom omdraaien. Erger nog: de herinnering die deze tests belonen is precies het werk dat agents hebben overgenomen. Je zou het hardst selecteren op de vaardigheid die het minst telt.
Wat er in één zin is stukgegaan: wervingsprocessen waren gebouwd om uitvoer te beoordelen, en uitvoer zegt niets meer over de persoon. Geen van beide formats laat de fundamenten meer zien, en geen van beide laat de agent-vaardigheden zien. Daarom hebben we beide vervangen door twee werksessies in een echte codebase, één zonder agents en één mét, waarbij we kijken hoe mensen daadwerkelijk werken.
Geen van beide sessies staat op zichzelf. Het zijn fase drie en vier van een langer proces: CV-screening op basis van een rubric en een kennismakingsgesprek van dertig minuten komen ervoor, een cultuurinterview en referenties erna, want als de meeste code door agents wordt geschreven, is de manier waarop iemand context deelt en samenwerkt met de mensen om hen heen minstens zo belangrijk als technische vaardigheden.
De eerste sessie test de fundamenten, zonder AI. De kandidaat krijgt een codebase die ze nog niet hebben gezien, een aantal echte tickets, waarvan één een productie-bug, en zestig minuten. Het is een gewone werksessie, geen test: ze pakken de tickets op en gaan aan de slag, terwijl wij kijken. Code schrijven is makkelijk geworden, maar begrijpen hoe een systeem in elkaar past niet, en als de fundamenten er niet zijn, heeft de kandidaat niets om de uitvoer van een agent tegen te valideren. Goed werk heeft specifieke kenmerken: de dataflow en faalmodi lezen voordat je code aanraakt, de productie-bug als eerste pakken en kunnen zeggen wat die raakt, de oorzaak vinden in plaats van het symptoom, de test toevoegen die de bug had moeten vangen. Deze ronde pikt mensen eruit die een LLM hebben doorgesluisd gedurende een paar jaar remote werk, wat vaker voorkomt dan de industrie graag toegeeft. Het is ook waar we erachter komen of ze vloeiend over een systeemontwerp kunnen praten in het Engels, wat we strenger op screenen dan de meeste.
De tweede sessie heeft dezelfde vorm van werk met de tegenovergestelde beperking: een nieuwe set tickets, en welke AI-codeertools de kandidaat normaal ook zou gebruiken. Nu kijken we wat ze doen wanneer een agent het meeste doet, beoordeeld op zes criteria: of ze verifiëren wat de agent produceert, hoe ze de tools orkestreren, of ze werk in stukken opdelen voordat ze genereren, hoe ze prompt en context inrichten, hoe ze debuggen, en of ze bijhouden wat ze allemaal zijn begonnen. Of ze eerst plannen, of ze teruglezen wat er uitkomt, en of ze een wijziging kunnen uitleggen die ze niet zelf hebben getypt.
Deze tweede sessie is waar een recente kandidaat met dertien jaar ervaring instortte. Zijn CV zag er goed uit en de fundamentensessie verliep goed. Daarna mocht hij agents gebruiken, en vanaf dat moment stopte hij met lezen. Elke wijziging werd geaccepteerd, elke prompt kreeg een 'ga maar verder', en hij sloot tickets af zonder ze te controleren. De meeste bedrijven hadden hem aangenomen. Wij ook, twee jaar geleden, omdat de meeste processen het uur dat wij zagen nooit te zien krijgen. Als je nog steeds filtert op take-homes en coderingstests, komt hij nu door je sollicitatieprocedure heen, en je komt erachter wanneer zijn code review bereikt.
Als je je eigen proces opnieuw opbouwt, is de twee-sessiestructuur het principe dat de moeite waard is om over te nemen, meer dan welke specifieke taak ook. Fundamenten zonder de agent, omdat die verificatie mogelijk maken. Echt werk met de agent, omdat dat het werk is. De onderdelen van werving die nooit over het artefact gingen - de screening, het cultuurinterview, de referenties - behouden hun oude rol; als er al iets is, telt het referentiegesprek nu zwaarder.
En als je een leverancier beoordeelt in plaats van een kandidaat, geldt dezelfde logica met één aanvulling: vraag het proces te zien. Elk bureau dat engineers plaatst moet je kunnen laten zien wat ze testen, hoe het wordt gescoord en waarom mensen afvallen. Wij publiceren ons proces volledig. Een vetproces dat publicatie niet kan doorstaan, mat de verkeerde dingen.
Het volledige proces, met beide scorecards en voorbeelden van goede en slechte antwoorden per sessie, staat in The Next 10X Engineer. Wil je weten hoe jouw huidige hiring zich verhoudt tot die van andere leaders, dan staat de Engineering Leader Benchmark open.
