De founder-gids voor het aannemen van een developer
Neem aan voor de beslissingen die je product nodig heeft, niet voor de langste lijst technologieën.
Een developer aannemen is lastig als je het werk niet met vertrouwen kunt beoordelen. Een verzorgd cv, snelle antwoorden en een lange lijst technologieën geven geruststelling zonder het echte risico te verkleinen.
Je hoeft niet technisch genoeg te worden om een perfect interview te voeren. Je moet een proces maken waarin goed oordeel zichtbaar en zwak oordeel moeilijk te verbergen wordt.
Definieer de baan rond het komende jaar
Begin niet met een algemene vacature voor een full-stackdeveloper die van een andere startup is gekopieerd. Beschrijf de productfase, beslissingen en omgeving die deze persoon erft.
Een vroeg product heeft misschien iemand nodig die onduidelijkheid kan terugbrengen tot een klein, onderhoudbaar systeem. Een groeiend product vraagt iemand die betrouwbaarheid verbetert zonder levering stil te zetten. Een team met een sterke technische lead kan een veelbelovende junior begeleiden. Een solo-founder zonder technische steun kan dat meestal niet.
Noem de eerste drie uitkomsten die de nieuwe persoon moet bezitten. Bijvoorbeeld: een bestaande applicatie stabiliseren, één gevalideerde workflow uitbrengen en een betrouwbaar deploymentproces maken. Zulke uitkomsten zijn nuttiger dan een checklist frameworks.
Scheid essentiële kennis van technologie die geleerd kan worden. Fundamenten, communicatie en eigenaarschap gaan tussen stacks mee. Ervaring met exact dezelfde library vaak niet.
Senioriteit gaat over zelfstandigheid
Jaren ervaring zijn een onvolmaakte maat. Senioriteit wordt zichtbaar in de omvang en onzekerheid van beslissingen die iemand verantwoord kan afhandelen.
Een senior developer herkent ontbrekende eisen, legt afwegingen uit, verkleint scope, verwacht operationele problemen en vraagt hulp voordat een risico duur wordt. Die persoon schrijft niet alleen sneller code. Hij of zij verkleint de hoeveelheid onnodige code en verbetert de beslissingen eromheen.
Een junior kan uitstekend zijn wanneer het werk helder is en ervaren review beschikbaar. Zonder die steun wordt de founder ongemerkt productmanager, technische lead en kwaliteitssysteem tegelijk.
Wees eerlijk over de begeleiding die je bedrijf kan bieden. Iemand goedkoop aannemen die alleen op papier zelfstandig is, wordt vaak de dure keuze.
Gebruik een echt gesprek
Technische trivia beloont geheugen en interviewtraining. Het zegt weinig over hoe iemand met jouw product omgaat.
Geef een realistische situatie met onvolledige informatie. Vraag hoe de kandidaat een nieuwe workflow zou aanpakken, een onbetrouwbare functie zou onderzoeken of zou kiezen tussen snelle implementatie en meer flexibiliteit. Laat de kandidaat vragen stellen.
Luister naar structuur. Worden gebruiker en risico verduidelijkt? Komen aannames boven tafel? Kan de kandidaat afwegingen zonder jargon uitleggen? Weet die wat kan wachten? Ziet die het verschil tussen een omkeerbare keuze en een gevaarlijke?
Sterke kandidaten maken het probleem vaak kleiner voordat ze de oplossing groter maken.
Beoordeel werk met context
Codevoorbeelden kunnen helpen, maar context is belangrijk. Vraag wat de kandidaat zelf bezat, welke beperkingen er waren, wat fout ging en wat die nu anders zou doen.
Houd een praktische opdracht kort en relevant. Betaal voor substantieel werk. De opdracht moet denkwerk, codehelderheid, testgewoonten en communicatie tonen, geen gratis productwerk opleveren.
Laat een vertrouwde senior het resultaat beoordelen als je dat zelf niet kunt. Vraag om uitleg in bedrijfstaal: is de aanpak begrijpelijk? Zijn belangrijke risico’s behandeld? Kan een ander verder? Hoeveel toezicht heeft deze persoon nodig?
Eén review voorspelt niet alles, maar is beter dan beoordelen op visuele glans.
Test communicatie direct
Een developer legt herhaaldelijk onzekerheid, vertraging en afwegingen uit. Behandel communicatie als onderdeel van de technische functie.
Vraag na de opdracht een korte schriftelijke update: wat is af, wat blijft over, welke aannames zijn gedaan en wat moet daarna gebeuren? Let op of problemen zichtbaar worden gemaakt of verstopt.
Sterke communicatie is niet altijd zelfverzekerd. Het is een juiste status, nuttige vragen en vroege waarschuwing. Wees voorzichtig met kandidaten die iedere planning beloven, complexiteit wegwuiven of vorige teams overal de schuld van geven.
Let ook op respectvol tegenspreken. Je hebt iemand nodig die een onveilige snelkoppeling of onnodige functie bevraagt, niet iemand die iedere founderimpuls uitvoert.
Maak eigenaarschap concreet
Spreek vóór de start af:
- Waar code en documentatie staan.
- Hoe wijzigingen worden beoordeeld en uitgebracht.
- Wie cloud- en externe accounts beheert.
- Welke kwaliteitscontroles verplicht zijn.
- Hoe productiestoringen worden behandeld.
- Welke beschikbaarheid wordt verwacht.
- Hoe prioriteiten worden bepaald.
- Welke kennis nooit bij één persoon mag blijven.
Dit is extra belangrijk bij freelancers en softwarebureaus, maar medewerkers hebben dezelfde duidelijkheid nodig. Goed eigenaarschap voorkomt dat je te laat ontdekt dat toegang, deployment of kritieke kennis ontbreekt.
Vraag referenties naar gedrag
Vraag een referentie niet alleen of iemand “goed” is. Vraag wat zichtbaar gebeurde.
Welk werk handelde de kandidaat zelfstandig af? Hoe reageerde die op veranderde plannen? Kwam slecht nieuws vroeg? Hoeveel review was nodig? Zou de referentie een kritisch systeem aan deze persoon toevertrouwen? In welke omgeving presteert de kandidaat het best?
De antwoorden kunnen een sterke kandidaat tonen die niet bij jouw fase past. Dat is geen moreel oordeel. Iemand die uitstekend werkt in een gestructureerd team kan worstelen als eerste technische hire. Een goede startupgeneralist kan ongelukkig worden in een smalle rol.
Haast niet omdat ontwikkeling stilstaat
Urgentie laat founders de lat verlagen precies wanneer de rol veel invloed heeft. Een zwakke hire voegt fragiele code toe, vertraagt de roadmap en maakt de volgende hire moeilijker.
Gebruik waar passend een korte betaalde proef of een strak eerste project. Geef toegang in verhouding tot het opgebouwde vertrouwen. Beoordeel vroeg werk snel. Plan een helder beslismoment in plaats van te hopen dat twijfels verdwijnen.
De juiste developer zet niet alleen tickets om in code. Die helpt het bedrijf betere technische beslissingen te nemen met de beschikbare tijd, kennis en middelen. Neem aan voor dat oordeel en bouw een proces waarin je het werkelijk kunt zien.