Async-technische interviewvragen die vaardigheden werkelijk onthullen

Het async vraagprobleem

In 2026 wordt bijna elke klassieke algoritme-puzzel die een kandidaat in een async take-home ziet, in seconden door een taalmodel opgelost. Hetzelfde geldt voor het meeste van LeetCode. Hetzelfde voor de canonieke "implementeer een cache" en "bouw een URL-shortener" vragen.

Als uw async-fase nog steeds vragen uit de canon van 2020 interviews-voorbereiding gebruikt, bent u niet het schermen voor engineering-vaardigheden — u bent het schermen voor ChatGPT-toegang. Dit bericht verzamelt vier vraag-formaten die triviale AI-voltooiing weerstaan en echt signaal in een async-instelling produceren.

Format 1: Lees-deze-codebase vragen

De kandidaat krijgt een kleine repository (50–500 regels) en wordt gevraagd iets ermee te doen: een fout vinden, een feature toevoegen, een klasse refactoren, een ontbrekende test schrijven.

Voorbeeld voor een backend-rol:

"Bijgesloten is een klein Express API met een users eindpunt. Er is een fout die ervoor zorgt dat het eindpunt verouderde gegevens retourneert nadat een gebruiker hun profiel bijwerkt. (1) Zoek en fix de fout. (2) Voeg een test toe die het zou hebben gevangen. (3) Schrijf 2–3 zinnen waarin u de onderliggende oorzaak uitlegt."

Waarom het werkt:

• De kandidaat moet code lezen, niet alleen schrijven. AI kan schrijven; de kandidaat moet nog steeds begrijpen.
• De "leg de oorzaak uit" lever is kort maar onthult diepte. AI-gegenereerde uitleg neiging generiek te zijn; echte engineers wijzen naar de specifieke lijn.
• Een live vervolgvraag ("loop me door hoe u de fout hebt gevonden") stort elke AI-enige inzending in.

Format 2: Afwegings-ontwerp vragen

In plaats van "implementeer X", vraag "ontwerp X en schrijf op wat u hebt overwogen."

Voorbeeld voor een senior engineer:

"Ontwerp een eenvoudig tarief limiter voor een intern API met 50 RPS op piek. Implementeer een werkende versie (elke taal) en een 1-paginaREADME uit te leggen: (1) het algoritme dat u hebt gekozen en minstens één alternatief dat u hebt afgewezen, (2) wat u zou veranderen als verkeer naar 5000 RPS groeide, (3) wat u niet behandelt en waarom."

Waarom het werkt:

• De code is het kleine onderdeel. De README is het signaal.
• "Wat u niet behandelt" is de killer-vraag. AI is slecht in grensstellingen toegeven; senior engineers doen het natuurlijk.
• De lever is kort om te lezen (≤15 min voor de reviewer), in tegenstelling tot een 4-uurs project.

Format 3: Debug-deze-mislukking vragen

Geef de kandidaat een slagende test, een falende test en de code onder testen. Vraag hen om de falende test slagen zonder de slagende te breken.

Dit format is moeilijk om met AI te spelen omdat de AI neiging over te herschrijven. Een kandidaat die over minimale wijzigingen redeneert, zal beter presteren dan een kandidaat die een hergegenereerd bestand plakt.

Voorbeeld:

"Bijgesloten is een datumparse-hulpprogramma. De functie handelt correct ISO 8601 datums af (test 1 slaagt). Het handelt geen datums af met gemengde-case maand-afkortingen zoals 12-Mar-2025 (test 2 mislukt). Maak test 2 slagen zonder test 1 te breken. Dien de kleinste patch in die u kunt."

De zin "kleinste patch" doet het werk. Reviewers kunnen een 3-regel diff in 30 seconden lezen.

Format 4: Code-review-stijl vragen

Geef de kandidaat een stuk code met 3–5 problemen van wisselende ernst en vraag hen om een code-review in te dienen.

Voorbeeld voor een midden-niveau rol:

"Bijgesloten is een pull request die een nieuw /checkout eindpunt toevoegt aan onze e-commerce API. Bekijk het alsof het door een collega was ingediend. Vermeld de problemen waarop u zou blokkeren, de problemen die u zou suggereren, en minstens één ding dat de auteur goed deed. Bestel ze op ernst."

Waarom het werkt:

• Engineering is meestal het lezen van andermans code, niet het schrijven van greenfield code. Deze vraag test de werkelijke taak.
• Het oppervlakt oordeel ("zou u blokkeren of gewoon suggereren?"), wat het senior-versus-midden signaal is.
• Het is moeilijk uit te besteden: AI kan duidelijke problemen vlaggen maar rangschikt ze slecht en vangt zelden subtiele problemen.

Wat te vermijden in async vragen

• Zuivere algoritme-puzzels. "Implementeer een schuif venster voor X" — opgelost door AI in seconden, zwak voorspellend van werkprestaties zelfs vóór AI.
• Alles boven de 2 uur. Topkandidaten slaan deze over. Zie de drop-off gegevens op tijdsbudget.
• Generieke CRUD apps. "Bouw een takenlijst met Postgres" — elke kandidaat produceert een bijna identieke inzending.
• Vragen met één juist antwoord. Het async format is het beste in het oppervlakken van oordeel, wat meerdere geldige antwoorden vereist.

Live vervolgvraag

Elke async coderingsoefening moet worden gekoppeld aan een 20-minuuts live vervolgvraag waarbij de kandidaat door hun eigen inzending loopt. Deze enkele stap doet meer voor integriteit dan elk AI-detectiehulpmiddel. In ClarityHire laadt de live kamer automatisch de code van de kandidaat, dus de interviewer arriveert voorbereid.

Koppelingsvragen met rubrices

Een geweldige vraag zonder rubric levert nog steeds inconsistente resultaten. Voor elk vraagformat hierboven schrijft u vooraf een scorerubric met minstens 3 verankerde niveaus (1 = onder bar, 3 = op bar, 5 = boven bar) voordat de eerste inzending aankomt. Zie onze best-practices gids voor de volledige async wervings speelboel.