Asynchrone technische Interviewfragen, die wirklich Skill zeigen
Das async-Frageproblem
2026 wird fast jedes klassische Algorithmus-Puzzle, das eine Bewerberin in einem async-Take-home sieht, in Sekunden von einem Sprachmodell gelöst. Genauso ein Großteil von LeetCode. Genauso die kanonischen „implementiere einen Cache" und „bau einen URL-Shortener".
Wenn deine async-Stage immer noch Fragen aus dem 2020er-Interview-Prep-Kanon nutzt, screenst du keine Engineering-Fähigkeit — du screenst nach ChatGPT-Zugang. Dieser Post sammelt vier Fragenformate, die triviale KI-Komplettierung erschweren und in einem async-Setting echtes Signal produzieren.
Format 1: Read-this-codebase-Fragen
Die Bewerberin bekommt ein kleines Repository (50–500 Zeilen) und soll damit etwas tun: einen Bug finden, ein Feature ergänzen, eine Klasse refaktorieren, einen fehlenden Test schreiben.
Beispiel für eine Backend-Rolle:
„Anhängend ist eine kleine Express-API mit einem
users-Endpoint. Es gibt einen Bug, der dafür sorgt, dass der Endpoint nach einem Profile-Update veraltete Daten zurückgibt. (1) Finde und behebe den Bug. (2) Ergänze einen Test, der ihn gefangen hätte. (3) Schreibe 2–3 Sätze zur eigentlichen Ursache."
Warum es funktioniert:
- Die Bewerberin muss Code lesen, nicht nur schreiben. KI kann schreiben; die Bewerberin muss immer noch verstehen.
- Das „erklär die Ursache"-Deliverable ist kurz, zeigt aber Tiefe. KI-generierte Erklärungen sind generisch; echte Engineers zeigen auf die spezifische Zeile.
- Eine Live-Folgefrage („wie hast du den Bug gefunden?") lässt jede KI-only-Einreichung kollabieren.
Format 2: Tradeoff-Design-Fragen
Statt „implementiere X" frag „designe X und schreib auf, was du erwogen hast."
Beispiel für eine Senior-Engineer:
„Designe einen einfachen Rate Limiter für eine interne API mit 50 RPS Peak. Implementiere eine funktionierende Version (beliebige Sprache) plus eine 1-Seiten-README, die erklärt: (1) den Algorithmus, den du gewählt hast, und mindestens eine Alternative, die du verworfen hast, (2) was du ändern würdest, wenn der Traffic auf 5000 RPS steigt, (3) was du nicht behandelst und warum."
Warum es funktioniert:
- Der Code ist der kleine Teil. Die README ist das Signal.
- „Was du nicht behandelst" ist die Killerfrage. KI gibt Limits ungern zu; Senior-Engineers tun es natürlich.
- Das Deliverable ist kurz zu lesen (≤15 Min für die Reviewerin), anders als ein 4-Stunden-Projekt.
Format 3: Debug-this-failure-Fragen
Gib der Bewerberin einen grünen Test, einen roten Test und den Code unter Test. Bitte sie, den roten Test grün zu bekommen, ohne den grünen zu brechen.
Dieses Format ist schwer mit KI zu spielen, weil KI dazu neigt, alles zu überschreiben. Eine Bewerberin, die über minimale Änderungen nachdenkt, schlägt eine, die eine regenerierte Datei pastet.
Beispiel:
„Anhängend ist ein Date-Parsing-Utility. Die Funktion verarbeitet ISO-8601-Daten korrekt (Test 1 grün). Sie handhabt keine Daten mit gemischten Monatsabkürzungen wie
12-Mar-2025(Test 2 rot). Mach Test 2 grün, ohne Test 1 zu brechen. Reiche den kleinstmöglichen Patch ein."
Der Ausdruck „kleinstmöglicher Patch" macht die Arbeit. Reviewerinnen lesen einen 3-Zeilen-Diff in 30 Sekunden.
Format 4: Code-Review-Style-Fragen
Gib der Bewerberin ein Code-Stück mit 3–5 Issues unterschiedlicher Schwere und bitte sie, ein Code-Review zu schreiben.
Beispiel für eine Mid-Level-Rolle:
„Anhängend ist ein Pull Request, der einen neuen
/checkout-Endpoint zu unserer E-Commerce-API hinzufügt. Reviewe ihn, als hätte ihn eine Kollegin eingereicht. Liste die Issues, auf denen du blockierst, die Issues, die du nur vorschlagen würdest, und mindestens eine Sache, die der Autor gut gemacht hat. Nach Schwere ordnen."
Warum es funktioniert:
- Engineering ist hauptsächlich das Lesen von fremdem Code, nicht das Schreiben von Greenfield-Code. Diese Frage testet den eigentlichen Job.
- Sie macht Urteilsvermögen sichtbar („blockieren oder nur vorschlagen?"), das Senior-vs-Mid-Signal.
- Sie ist schwer auszulagern: KI flaggt offensichtliche Issues, rankt sie aber schlecht und fängt subtile Issues selten.
Was in async-Fragen zu vermeiden ist
- Reine Algorithmus-Puzzles. „Implementiere ein Sliding Window für X" — in Sekunden von KI gelöst, schon vor KI schwach prädiktiv.
- Alles über 2 Stunden. Top-Bewerberinnen überspringen das. Siehe die Drop-off-Daten zum Zeitbudget.
- Generische CRUD-Apps. „Bau eine Todo-Liste mit Postgres" — jede Bewerberin produziert eine fast identische Einreichung.
- Fragen mit einer richtigen Antwort. Das async-Format zeigt am besten Urteil, was mehrere valide Antworten braucht.
Live nachfassen
Jede async-Coding-Aufgabe sollte mit einem 20-Minuten-Live-Follow-up gepaart sein, in dem die Bewerberin durch ihre eigene Einreichung läuft. Dieser eine Schritt tut mehr für die Integrität als jedes KI-Erkennungstool. In ClarityHire lädt der Live-Raum den eingereichten Code automatisch, sodass die Interviewerin vorbereitet ankommt.
Fragen mit Rubriken paaren
Eine gute Frage ohne Rubrik produziert immer noch inkonsistente Ergebnisse. Für jedes Format oben pre-schreibe eine Bewertungs-Rubrik mit mindestens 3 verankerten Stufen (1 = unter Niveau, 3 = auf Niveau, 5 = über Niveau), bevor die erste Einreichung eintrifft. Siehe unseren Best-Practice-Leitfaden für das vollständige async-Hiring-Playbook.