Hoe Voer Je Een Software Engineer Mock Interview Uit
Door Aaron Cao · Bijgewerkt op

Oefen telkens één ronde onder echte tijdsdruk, met de tools die de echte ronde gebruikt, en met een interviewer die je onderbreekt. Beoordeel structuur, communicatie en herstel, niet alleen of je de optimale oplossing bereikte. Een mock die nooit misgaat, oefent het moeilijke deel niet.
Wat dekt een realistische software engineer mock?
Je hebt waarschijnlijk al veel problemen opgelost en voelt je toch niet klaar, en de reden is meestal dat alleen maar oplossen niet is wat de ronde meet. Dit onderdeel scheidt de drie rondes die een software engineering-traject gebruikt, omdat elke ronde een andere voorbereiding vereist en ze mengen de sessie verspilt.
- Coding. 35 tot 45 minuten, één of twee problemen, hardop denken terwijl je typt. Het oefendoel is het verwoorden van een oplossing die je nog aan het vormen bent.
- System design. 45 tot 60 minuten, een open opdracht, geen verduidelijking tenzij je erom vraagt. Het oefendoel is het afbakenen van het probleem voordat je het ontwerpt.
- Behavioral. 45 minuten projectverhalen met kritische vervolgvragen. Het oefendoel is de derde vervolgvraag overleven over een beslissing die je betreurt.
Doe er per sessie één. Een volledige loop van drie uur voelt productief, maar levert nauwelijks bruikbare feedback op, omdat je bij ronde drie vooral vermoeidheid oefent in plaats van vaardigheid. Wil je liever de vragenbank dan de mechaniek, dan vind je die op een aparte pagina in de mock interviews-hub.
Hoe voer je er zelf één uit?
Solo mocks mislukken op een voorspelbare manier: je kiest een probleem dat je kunt oplossen, stopt de timer als je vastloopt, en eindigt met een goed gevoel. Dat is stuk voor stuk het tegenovergestelde van de echte omstandigheden. Reproduceer in plaats daarvan de beperkingen.
- Kies niet je eigen probleem. Pak er een van een lijst die je nog niet hebt gelezen, of laat iemand anders kiezen. Zelf kiezen betekent iets comfortabels kiezen.
- Start de timer en stop hem nooit. Vastgelopen tijd is data. Pauzeren haalt precies de druk weg waarvoor je oefent.
- Match de tooling. Als de ronde een gedeelde editor gebruikt zonder autocomplete, zonder run-knop en zonder testsuite, oefen dan daar.
- Praat tegen een lege kamer. Het voelt absurd en het is het meest waardevolle onderdeel. Stil problemen oplossen traint een vaardigheid die niemand beoordeelt.
- Neem het op. Jezelf terugkijken is onaangenaam en toont je stopwoordjes, terugkrabbelen en het moment waarop je stil viel.
- Ontwerp eerst zonder diagramtool. Veel design-rondes zijn niet meer dan een spraakoproep en een leeg document.
Het enige dat een solo mock niet kan bieden, is onderbreking, en onderbreking is grotendeels wat een echte ronde moeilijk maakt. Een AI-interviewer kan precies dat gat opvullen: hij stelt de vervolgvraag terwijl je midden in een zin zit en wacht niet beleefd tot je klaar bent. De mock interview-modus voert de rondes op deze manier uit.
Welke feedback moet je verzamelen?
De meeste mensen ronden een mock af en noteren een eindoordeel, dat een week later nutteloos is. Verzamel specifieke observaties die gekoppeld zijn aan gedrag dat je kunt veranderen.
- Tijd tot de eerste verduidelijkende vraag. Duurt het langer dan negentig seconden, dan los je het verkeerde probleem op.
- Langste stilte. Alles boven de twintig seconden vraagt in plaats daarvan om een hardop uitgesproken vulzin.
- Heb je je aanpak benoemd voordat je begon te typen? Ja of nee, elke keer.
- Hoe herstelde je toen je vastliep? Het probleem herformuleerd, een kleiner geval geprobeerd, of bevroren.
- Kwam de complexiteitsbespreking op verzoek of uit jezelf? Uit jezelf scoort beter.
- Voor design: heb je de scope bepaald voordat je ging tekenen? Eerst beperkingen en schaal, dan pas vakjes.
Een backend engineer die zich voorbereidde op een senior traject deed twaalf mocks en slaagde voor ze allemaal, maar zakte vervolgens voor de echte coding-ronde nadat ze vier minuten stil was gevallen bij een onbekende variant. Haar mocks hadden nooit een probleem bevat dat ze niet kon oplossen, dus ze had het enige dat écht misging nooit geoefend. Ze veranderde één regel, liet problemen boven haar niveau toe, en het stilteprobleem kwam meteen naar boven.
Hoeveel mocks zijn genoeg, en wat kunnen ze niet oplossen?
Er is geen magisch getal, en na een bepaald punt levert meer volume niets meer op. Een bruikbaar patroon is twee of drie mocks per rondetype, verspreid over twee weken, waarbij de review ertussenin belangrijker is dan de sessies zelf. Zes mocks zonder review is erger dan drie met zorgvuldige aantekeningen.
Wees duidelijk over de grenzen. Een mock kan je niet vertellen welk probleem je krijgt, kan de stijl van je interviewer niet voorspellen en kan het daadwerkelijk kennen van de stof niet vervangen. Wat het wel verbetert is de uitvoeringslaag: praten terwijl je denkt, scope bepalen voordat je bouwt, en hardop herstellen als je vastloopt. Dat draagt volledig over, en het zijn ook de dingen die lezen je niet kan leren.
Oefenen en live assistentie zijn verschillende vragen met verschillende antwoorden. Oefenen is onomstreden. Assistentie tijdens een echt interview hangt af van het format en de regels van de werkgever, en bij gedeelde schermen of proctored coding-rondes valt het volledig buiten bereik. De eerlijke grenzen staan op de detectability-hub.
FAQ
Hoeveel mock interviews moet een software engineer doen?
Kan ik een nuttig mock interview doen zonder partner?
Moeten mock-problemen op mijn niveau liggen of moeilijker zijn?
Helpen mock interviews bij system design-rondes?
Is een mock interview hetzelfde als LeetCode oefenen?
Gerelateerde vragen
- Hoe organiseer je een realistisch mock interview voor product managers?
- Welke vragen moet een software-engineer oefenen in mocksollicitaties?
- Hoe doe ik een mock-interview alleen, zonder oefenpartner?
- Bestaat er een gratis AI-oefengesprek, en wat omvat de gratis versie?
- Welke gedragsgerichte vragen moet je oefenen in een mock-interview?
- Verbeteren oefengesprekken de prestaties bij sollicitatiegesprekken echt?