Felix Rieseberg, hiring manager bij Anthropic, stelt dat het traditionele programmeerinterview irrelevant is geworden omdat AI-tools zoals Claude nu beter zijn in het oplossen van deze specifieke puzzels. Dit creëert een kans voor junior engineers: de barrière van jarenlange opgebouwde kennis van frameworks en libraries is weggevallen, waardoor 'honger' en drive belangrijker zijn dan anciënniteit.
Rieseberg adviseert junior engineers om hun 'onwetendheid' als kracht te gebruiken om blinde vlekken en inefficiënties in een organisatie te spotten. Hij raadt hen specifiek aan om:
- Te focussen op zakelijke impact in plaats van alleen de backlog af te werken.
- Radicale, ambitieuze ideeën te bedenken.
- Snel werkende prototypes te bouwen (met AI) om ideeën direct te bewijzen zonder lange bureaucratische processen.
- Eén goed idee centraal te stellen in plaats van te veel functies in één prototype.
- Gebruik te maken van hun empathie voor de eindgebruiker.
De auteur concludeert dat de rol van de software engineer verandert en dat hij nu in portfolio's zoekt naar smaak, empathie en principieel denken in plaats van naar resultaten uit algoritmische tests.
Honger verslaat anciënniteit: Advies voor junior engineers
Deze maand heb ik het traditionele programmeerinterview terzijde geschoven. Als hiring manager bij Anthropic ben ik gestopt met het vragen aan kandidaten om deze tests te doen. Het heeft een goede tijd gehad: het vermogen om snel problemen te definiëren en elegante oplossingen te vinden was een zwakke, maar nuttige voorspeller voor hoe succesvol je in mijn teams zou zijn. Kleine programmeeruitdagingen in echte code vertelden ons iets betekenisvols over kandidaten.
Dat is niet langer waar. Er is geen meer zin in het geven van een kleine React-uitdaging dan in het overhoren van mensen over assembly; Claude is inmiddels beter in beide. Onze meest impactvolle bouwers zijn succesvol, ongeacht hoe goed ze zijn in deze tests.
Ondanks de alomtegenwoordigheid was het programmeerinterview nooit populair. Ik vermoed dat ervaren engineers nog steeds sterke reacties zullen hebben op het verdwijnen ervan — al is het maar vanwege wat het zegt over de evolutie van onze rollen. Er is veel geschreven over hoe AI een uitdaging vormt voor junior developers, vooral voor degenen die proberen een baan te vinden. Nu ik junior developers een tijdje met AI heb zien werken, heb ik een hoopvoller perspectief: impact wordt minder beperkt door hoeveel jaren aan opgebouwde kennis van frameworks en libraries je hebt verzameld.
Ik zie engineers die relatief nieuw zijn, mensen inhalen die waarschijnlijk betere programmeurs zijn en al veel langer meedraaien. Honger verslaat anciënniteit.
Dit bericht is mijn beste advies voor junior engineers, hoewel "junior" het verkeerde woord is. Het is eigenlijk bedoeld voor engineers zonder sociaal kapitaal, status of macht.
Visie zonder stem
Ten eerste moet je zowel je voordeel als je handicap kennen.
Een frisse blik, zelfs een naïeve, wordt al lang als krachtig beschouwd. Toen ik bij Stripe kwam, smeekte oprichter Patrick Collison ons nieuwkomers om goed op te letten aan dingen die we vreemd vonden. Zijn weddenschap was dat nieuwkomers wrijving en kansen zouden opmerken die ervaren krachten allang niet meer zagen.
In 1991 schreef James March dat organisaties afhankelijk zijn van het "handhaven van een instroom van de naïven en onwetenden". Toen Orson Welles werd gevraagd hoe hij het vertrouwen kreeg om shots te proberen die niemand eerder had geprobeerd, zei hij: "Onwetendheid, pure onwetendheid — je weet dat er geen zelfvertrouwen is dat daaraan kan tippen. Pas als je iets weet over een beroep, denk ik, word je timide of voorzichtig."
Toen ik bij Notion kwam, hield een van mijn interviews in dat ik een architectuur voor een offline-modus moest ontwerpen. Ik was verbijsterd toen ik hoorde dat ze dit een "trick"-interview noemden, omdat een offline-modus als onmogelijk werd beschouwd. Het datamodel was te complex om eenvoudig een volledige Notion-werkruimte te synchroniseren, en het downloaden van individuele pagina's was een gebruikerservaring die CEO Ivan Zhao nooit zou toestaan. De complexiteit van het datamodel bleek waar te zijn; de weerstand van de oprichter niet. Mensen beschouwden dit als zo'n algemene kennis dat niemand het had gecontroleerd. Ik, een onwetende nieuwkomer, wist niet beter dan om het gewoon te vragen.
Het is gemakkelijk om anekdotes zoals deze te lezen en te denken dat mensen slechte beslissingen namen. Ik kan niet genoeg benadrukken hoe moeilijk het is om deze fouten op te merken wanneer je degene bent die ze maakt. Kort na mijn start bij Notion wilde ik teams uitrusten met grote televisies om live dashboards te tonen. Ik stuitte op organisatorische muren, faalde, en vond het niet belangrijk genoeg om er een hele strijd over te beginnen.
Een jaar later kwam Ji Pei als nieuwe medewerker binnen met hetzelfde idee. Ik spotte hem en zei dat hij zich geen moeite zou moeten doen; ik had het al geprobeerd. Hij had het al gevraagd. De televisies stonden de volgende dag. Ergens in dat jaar was ik de ervaren kracht geworden.
Het enige probleem met al die "onwetende macht": niemand geeft om wat je vindt. De meeste techbedrijven hebben lagen van middenmanagement om grotere bedrijfsdoelen te vertalen naar uitvoering. Structureel zijn bedrijven vaak gebouwd rond het idee dat een paar mensen individuele ideeën groen licht geven of blokkeren. In een wereld waarin uitvoering duur is, moet je normaal gesproken je weg naar een bepaalde sociale status banen voordat de hele organisatie een "weddenschap" plaatst op jouw idee. Organogrammen veranderen meestal in een slakkentempo, dus zelfs bedrijven die in AI geloven, verwachten vaak dat junior mensen simpelweg hun taken sneller uitvoeren, in plaats van ambitieus bedrijfsdoelen na te jagen.
Nou, goed nieuws: uitvoering is niet langer duur.
Wat te doen
- Kies voor zakelijke impact boven de backlog: In 2011, vóór het tijdperk van AI-coding, schreef Patrick McKenzie: "engineers worden aangenomen om zakelijke waarde te creëren, niet om dingen te programmeren." Hij adviseerde om je te hechten aan de delen van een bedrijf die geld verdienen. Begin daar: begrijp wat je bedrijf daadwerkelijk probeert te bereiken (of, in een groter bedrijf, wat jouw groep of afdeling doet). Zoek vervolgens naar de juiste hoogte — begrijpen welke doelen de manager van jouw manager heeft, is vaak een nuttige graadmeter.
- Kies een radicaal idee: Bedenk een paar ideeën die, indien succesvol, de kansen dat je organisatie die doelen bereikt drastisch zouden verbeteren. Wees ambitieus!
- Bouw het in een weekend: Ik heb gezien hoe kleine groepen en solo-engineers het gebruikelijke proces van het schrijven van productvereisten-documenten (PRD's), het verkrijgen van instemming en het lobbyen voor tijd bij designers of productmanagers passeerden door een werkend prototype te bouwen.
- Focus op één goed idee: In mijn ervaring maken juniors vaak de fout om meerdere ideeën in één prototype te proppen, waardoor drie uitstekende ideeën verborgen raken tussen 20 slechte. Als je prototype het creëren van een nieuwe programmeertaal, een backend en op eenzelfde manier mobiele apps omvat, zul je niet succesvol zijn. Het doel van het creëren van een werkend prototype is om een idee zo goed te communiceren dat de leiding snel zowel de kans als het feit dat jij degene bent die ermee aan de slag kan, begrijpt.
- Maak gebruik van je frisse perspectief: Als je werkt aan iets dat gebruikersgericht is, heb je een unieke hoeveelheid empathie voor gebruikers en dus een veel beter gevoel voor hoe het product wel of niet voor hen werkt. Mijn collega's bij Slack en Notion hadden moeite om te internaliseren hoe het is om Slack of Notion als externe gebruiker te gebruiken.
Als je werkt aan infrastructuur of tooling, heb je het voordeel dat je nooit alle redenen hebt geleerd waarom dingen als "onmogelijk" worden beschouwd.
De toekomst is veelbelovend
Ik denk niet dat het programmeerinterview terug zal komen. Het is makkelijk om sentimenteel te worden, gezien hoeveel kopieën van "Algorithms and Data Structures" zijn gekocht in de hoop op goede banen en een betere toekomst — of hoe de dood van het programmeerinterview een andere mijlpaal is in software engineering die een nieuw abstractieniveau bereikt.
Tegelijkertijd, als een langdurige hater van promoties op basis van anciënniteit, kan ik niet anders dan optimistisch zijn. Ik heb al mijn deel gezien van populaire apps en producten die op deze manier zijn gemaakt.
Bij Anthropic waren mensen zo gewend om Claude Code als command-line interface (CLI) te gebruiken, dat het twee relatief nieuwe engineers (Anthony Morris en Alice Zhao) kostte om in één weekend een werkend prototype neer te zetten. De eerste publieke versie werd ongeveer acht dagen later uitgebracht. Je zult niet verrast zijn te horen dat een goede grafische interface voor Claude Code een zeer populair product is.
Ik ben waarschijnlijk niet de enige manager die probeert uit te vinden hoe je interviews afneemt voor mensen die goed bouwen met AI. Ik ben daar nog niet helemaal uit — maar ik scan cv's en portfolio's op kleine prototypes die smaak, empathie en principieel denken vertonen. Als je iets beters hebt gevonden, hoor ik het graag.
***
Afbeelding bij dit bericht is van J. M. W. Turner, “The Fighting Temeraire” (1839)
Honger verslaat anciënniteit: Advies voor junior engineers
Deze maand heb ik het traditionele programmeerinterview terzijde geschoven. Als hiring manager bij Anthropic ben ik gestopt met het vragen aan kandidaten om deze tests te doen. Het heeft een goede tijd gehad: het vermogen om snel problemen te definiëren en elegante oplossingen te vinden was een zwakke, maar nuttige voorspeller voor hoe succesvol je in mijn teams zou zijn. Kleine programmeeruitdagingen in echte code vertelden ons iets betekenisvols over kandidaten.
Dat is niet langer waar. Er is geen meer zin in het geven van een kleine React-uitdaging dan in het overhoren van mensen over assembly; Claude is inmiddels beter in beide. Onze meest impactvolle bouwers zijn succesvol, ongeacht hoe goed ze zijn in deze tests.
Ondanks de alomtegenwoordigheid was het programmeerinterview nooit populair. Ik vermoed dat ervaren engineers nog steeds sterke reacties zullen hebben op het verdwijnen ervan — al is het maar vanwege wat het zegt over de evolutie van onze rollen. Er is veel geschreven over hoe AI een uitdaging vormt voor junior developers, vooral voor degenen die proberen een baan te vinden. Nu ik junior developers een tijdje met AI heb zien werken, heb ik een hoopvoller perspectief: impact wordt minder beperkt door hoeveel jaren aan opgebouwde kennis van frameworks en libraries je hebt verzameld.
Ik zie engineers die relatief nieuw zijn, mensen inhalen die waarschijnlijk betere programmeurs zijn en al veel langer meedraaien. Honger verslaat anciënniteit.
Dit bericht is mijn beste advies voor junior engineers, hoewel "junior" het verkeerde woord is. Het is eigenlijk bedoeld voor engineers zonder sociaal kapitaal, status of macht.
Visie zonder stem
Ten eerste moet je zowel je voordeel als je handicap kennen.
Een frisse blik, zelfs een naïeve, wordt al lang als krachtig beschouwd. Toen ik bij Stripe kwam, smeekte oprichter Patrick Collison ons nieuwkomers om goed op te letten aan dingen die we vreemd vonden. Zijn weddenschap was dat nieuwkomers wrijving en kansen zouden opmerken die ervaren krachten allang niet meer zagen.
In 1991 schreef James March dat organisaties afhankelijk zijn van het "handhaven van een instroom van de naïven en onwetenden". Toen Orson Welles werd gevraagd hoe hij het vertrouwen kreeg om shots te proberen die niemand eerder had geprobeerd, zei hij: "Onwetendheid, pure onwetendheid — je weet dat er geen zelfvertrouwen is dat daaraan kan tippen. Pas als je iets weet over een beroep, denk ik, word je timide of voorzichtig."
Toen ik bij Notion kwam, hield een van mijn interviews in dat ik een architectuur voor een offline-modus moest ontwerpen. Ik was verbijsterd toen ik hoorde dat ze dit een "trick"-interview noemden, omdat een offline-modus als onmogelijk werd beschouwd. Het datamodel was te complex om eenvoudig een volledige Notion-werkruimte te synchroniseren, en het downloaden van individuele pagina's was een gebruikerservaring die CEO Ivan Zhao nooit zou toestaan. De complexiteit van het datamodel bleek waar te zijn; de weerstand van de oprichter niet. Mensen beschouwden dit als zo'n algemene kennis dat niemand het had gecontroleerd. Ik, een onwetende nieuwkomer, wist niet beter dan om het gewoon te vragen.
Het is gemakkelijk om anekdotes zoals deze te lezen en te denken dat mensen slechte beslissingen namen. Ik kan niet genoeg benadrukken hoe moeilijk het is om deze fouten op te merken wanneer je degene bent die ze maakt. Kort na mijn start bij Notion wilde ik teams uitrusten met grote televisies om live dashboards te tonen. Ik stuitte op organisatorische muren, faalde, en vond het niet belangrijk genoeg om er een hele strijd over te beginnen.
Een jaar later kwam Ji Pei als nieuwe medewerker binnen met hetzelfde idee. Ik spotte hem en zei dat hij zich geen moeite zou moeten doen; ik had het al geprobeerd. Hij had het al gevraagd. De televisies stonden de volgende dag. Ergens in dat jaar was ik de ervaren kracht geworden.
Het enige probleem met al die "onwetende macht": niemand geeft om wat je vindt. De meeste techbedrijven hebben lagen van middenmanagement om grotere bedrijfsdoelen te vertalen naar uitvoering. Structureel zijn bedrijven vaak gebouwd rond het idee dat een paar mensen individuele ideeën groen licht geven of blokkeren. In een wereld waarin uitvoering duur is, moet je normaal gesproken je weg naar een bepaalde sociale status banen voordat de hele organisatie een "weddenschap" plaatst op jouw idee. Organogrammen veranderen meestal in een slakkentempo, dus zelfs bedrijven die in AI geloven, verwachten vaak dat junior mensen simpelweg hun taken sneller uitvoeren, in plaats van ambitieus bedrijfsdoelen na te jagen.
Nou, goed nieuws: uitvoering is niet langer duur.
Wat te doen
- Kies voor zakelijke impact boven de backlog: In 2011, vóór het tijdperk van AI-coding, schreef Patrick McKenzie: "engineers worden aangenomen om zakelijke waarde te creëren, niet om dingen te programmeren." Hij adviseerde om je te hechten aan de delen van een bedrijf die geld verdienen. Begin daar: begrijp wat je bedrijf daadwerkelijk probeert te bereiken (of, in een groter bedrijf, wat jouw groep of afdeling doet). Zoek vervolgens naar de juiste hoogte — begrijpen welke doelen de manager van jouw manager heeft, is vaak een nuttige graadmeter.
- Kies een radicaal idee: Bedenk een paar ideeën die, indien succesvol, de kansen dat je organisatie die doelen bereikt drastisch zouden verbeteren. Wees ambitieus!
- Bouw het in een weekend: Ik heb gezien hoe kleine groepen en solo-engineers het gebruikelijke proces van het schrijven van productvereisten-documenten (PRD's), het verkrijgen van instemming en het lobbyen voor tijd bij designers of productmanagers passeerden door een werkend prototype te bouwen.
- Focus op één goed idee: In mijn ervaring maken juniors vaak de fout om meerdere ideeën in één prototype te proppen, waardoor drie uitstekende ideeën verborgen raken tussen 20 slechte. Als je prototype het creëren van een nieuwe programmeertaal, een backend en op eenzelfde manier mobiele apps omvat, zul je niet succesvol zijn. Het doel van het creëren van een werkend prototype is om een idee zo goed te communiceren dat de leiding snel zowel de kans als het feit dat jij degene bent die ermee aan de slag kan, begrijpt.
- Maak gebruik van je frisse perspectief: Als je werkt aan iets dat gebruikersgericht is, heb je een unieke hoeveelheid empathie voor gebruikers en dus een veel beter gevoel voor hoe het product wel of niet voor hen werkt. Mijn collega's bij Slack en Notion hadden moeite om te internaliseren hoe het is om Slack of Notion als externe gebruiker te gebruiken.
Als je werkt aan infrastructuur of tooling, heb je het voordeel dat je nooit alle redenen hebt geleerd waarom dingen als "onmogelijk" worden beschouwd.
De toekomst is veelbelovend
Ik denk niet dat het programmeerinterview terug zal komen. Het is makkelijk om sentimenteel te worden, gezien hoeveel kopieën van "Algorithms and Data Structures" zijn gekocht in de hoop op goede banen en een betere toekomst — of hoe de dood van het programmeerinterview een andere mijlpaal is in software engineering die een nieuw abstractieniveau bereikt.
Tegelijkertijd, als een langdurige hater van promoties op basis van anciënniteit, kan ik niet anders dan optimistisch zijn. Ik heb al mijn deel gezien van populaire apps en producten die op deze manier zijn gemaakt.
Bij Anthropic waren mensen zo gewend om Claude Code als command-line interface (CLI) te gebruiken, dat het twee relatief nieuwe engineers (Anthony Morris en Alice Zhao) kostte om in één weekend een werkend prototype neer te zetten. De eerste publieke versie werd ongeveer acht dagen later uitgebracht. Je zult niet verrast zijn te horen dat een goede grafische interface voor Claude Code een zeer populair product is.
Ik ben waarschijnlijk niet de enige manager die probeert uit te vinden hoe je interviews afneemt voor mensen die goed bouwen met AI. Ik ben daar nog niet helemaal uit — maar ik scan cv's en portfolio's op kleine prototypes die smaak, empathie en principieel denken vertonen. Als je iets beters hebt gevonden, hoor ik het graag.
***
Afbeelding bij dit bericht is van J. M. W. Turner, “The Fighting Temeraire” (1839)
Groetjes,