Fehler Nr. 1: In den Code springen, ohne Anforderungen zu klären
Die Frage kommt. Ihr Instinkt ist, sofort loszucoden, um Tempo und Selbstsicherheit zu zeigen. Das ist fast immer falsch.
Aufgaben in technischen Interviews sind fast nie so einfach, wie sie zuerst erscheinen. Bedingungen sind versteckt, Randfälle werden bewusst weggelassen, und die „richtige" Interpretation hängt oft von Informationen ab, die Sie noch nicht haben. Direkt zu einer Implementierung des Problems zu springen, wie Sie es verstanden haben – bevor Sie bestätigt haben, dass Sie es richtig verstanden haben –, ist der Weg, wie Kandidaten 20 Minuten damit verbringen, das falsche Problem zu lösen.
Wichtiger noch: Interviewer lassen Anforderungen bewusst mehrdeutig, um zu sehen, ob Sie Mehrdeutigkeit erkennen und gute Fragen stellen. Ein Kandidat, der vor dem Coden fragt „Soll ich annehmen, dass das Eingabe-Array sortiert ist?", zeigt dasselbe Urteilsvermögen, das ein guter Ingenieur in echte Projekte einbringt. Ein Kandidat, der stillschweigend annimmt, das Array sei sortiert – und darauf aufbaut –, zeigt das Gegenteil.
Bevor Sie eine einzige Zeile Code schreiben, verbalisieren Sie Ihr Verständnis des Problems und stellen Sie mindestens zwei Klärungsfragen: eine zu Bedingungen (Eingabegröße, erwartete Datentypen, Randfälle) und eine zu Anforderungen (Was soll die Funktion bei leerer Eingabe zurückgeben? Was bei Duplikaten?). Dann bestätigen Sie: „Mein Ziel ist also, X bei gegebenem Y zurückzugeben – stimmt das?" Erst dann beginnen Sie zu coden.
Fehler Nr. 2: Während des Problemlösens stumm bleiben
Das ist der Fehler, der die meisten Angebote kostet, weil er für den Begehenden unsichtbar ist. Sie denken. Angestrengt. Sie machen echte Fortschritte. Aber Sie tun es alles im Kopf, und der Interviewer sieht Ihnen beim stummen Tippen zu, ohne erkennen zu können, ob Sie auf dem richtigen Weg, völlig verloren oder einfach langsam sind.
Technische Interviewer bewerten nicht nur Ihre Lösung – sie bewerten, wie es wäre, mit Ihnen zu arbeiten. Ein Teammitglied, das bei einem schweren Problem verstummt, ist jemand, den man nicht einschätzen, dem man nicht helfen und mit dem man nicht zusammenarbeiten kann. Der stumme Kandidat sendet genau dieses Signal, selbst wenn seine schließliche Lösung korrekt ist.
Denken Sie laut. Sagen Sie, was Sie erwägen und warum Sie es verwerfen: „Ich denke zuerst an einen Brute-Force-Ansatz mit O(n²), nur um Korrektheit herzustellen, dann schaue ich mir die Optimierung an." Sagen Sie, wenn Sie feststecken: „Ich weiß, ich muss verfolgen, welche Elemente ich gesehen habe – ich schwanke zwischen einer Hashmap und einem sortierten Array dafür." Diese Erzählung lässt den Interviewer Ihren Gedankengang sehen, Ihnen helfen, falls Sie vom Kurs abkommen, und Ihren Problemlösungsansatz unabhängig davon bewerten, ob Sie die optimale Lösung finden.
Wenn Stille unter Druck eine Gewohnheit ist, üben Sie mit einem Live-Mock-Interview-Tool – InterviewAce kann markieren, wenn Sie zu ruhig werden, und Sie auffordern, Ihr Denken zu verbalisieren.
Fehler Nr. 3: Ihre Lösung nicht testen oder debuggen
Viele Kandidaten schreiben ihre Lösung, starren sie kurz an und sagen „Ich glaube, das sieht richtig aus" – und geben sie dann ab. Das signalisiert, dass Sie nicht den Instinkt haben, Ihre eigene Arbeit zu testen, was einer der wichtigsten Instinkte in der Softwareentwicklung ist.
Interviewer bei starken Unternehmen haben oft eine stillschweigende Regel: Eine Lösung, die vom Kandidaten nicht getestet wurde, gilt als unvollständig, unabhängig davon, ob sie korrekt erscheint. Sie wollen sehen, dass Sie dieselben Gewohnheiten anwenden, die Sie in einen echten Pull Request einbringen würden.
Nachdem Sie Ihre Lösung geschrieben haben, gehen Sie sie immer manuell mit mindestens zwei Testfällen durch: einem Normalfall und einem Randfall. Gehen Sie jede Zeile durch, verfolgen Sie die Variablenwerte und verifizieren Sie die Ausgabe. Erzählen Sie dabei: „Okay, wenn die Eingabe [3, 1, 4] ist, ist i in diesem Schritt 0 und current_max ist 3, also …" Dieser Prozess fängt echte Bugs ab und zeigt Engineering-Reife. Für Randfälle denken Sie systematisch durch: leere Eingabe, Einzel-Element-Eingabe, lauter gleiche Elemente, negative Zahlen (falls zutreffend) und die maximal mögliche Eingabegröße.
Fehler Nr. 4: Schwache Kommunikation beim System Design
System-Design-Interviews unterscheiden sich von Coding-Interviews in einem entscheidenden Punkt: Es gibt keine einzelne richtige Antwort. Der Interviewer bewertet Ihren Denkprozess, Ihr Bewusstsein für Abwägungen und Ihre Fähigkeit, ein Design-Gespräch zu treiben. Kandidaten, die selbstsicher ein einziges Design präsentieren, ohne Alternativen zu erkunden oder Abwägungen einzuräumen, scheitern oft in System-Design-Runden, selbst wenn ihre Architektur technisch solide ist.
Häufige Versagensmodi: direkt in Komponentendiagramme springen, bevor Anforderungen und Skalierung feststehen; Schlagwörter nutzen („wir verwenden Kafka für den Event-Stream"), ohne die Begründung zu erklären; und Abwägungen nicht erwähnen („eine relationale DB funktioniert hier, aber beim Zehnfachen der aktuellen Skalierung würden wir Schreibkonflikte auf dieser Tabelle sehen").
Strukturieren Sie jede System-Design-Antwort mit demselben fünfstufigen Ansatz: (1) Anforderungen und Bedingungen klären – funktional und nicht-funktional, Skalierungserwartungen. (2) Skalierung schätzen – QPS, Datenvolumen, Lese-/Schreibverhältnis. (3) Ein High-Level-Design vorschlagen – Hauptkomponenten, Datenflüsse. (4) In die interessanten Teile eintauchen – wo immer die Komplexität liegt. (5) Abwägungen und Alternativen besprechen – was Sie gewählt haben und warum Sie die Alternativen nicht gewählt haben.
Machen Sie es sich zur Gewohnheit zu sagen: „Ich habe X über Y wegen der Abwägung Z gewählt." Interviewer auf Senior-Ebene bewerten, ob Sie verstehen, warum Ihr Design die Abwägungen trifft, die es trifft – nicht nur, dass es funktioniert.
Fehler Nr. 5: Aufgeben, statt laut zu denken
Wenn Kandidaten auf eine echte Wand stoßen – sie sehen den Weg nach vorn nicht –, werden sie oft still, erstarren und sagen schließlich „Ich bin nicht sicher, wie ich weitermachen soll". Das legt das Interview lahm und beendet die Chance des Kandidaten, sich zu erholen, selbst wenn er es mit 2 weiteren Minuten strukturierten Denkens herausgefunden hätte.
Hier ist etwas, das die meisten Kandidaten nicht wissen: Die meisten Interviewer wollen Hinweise geben. Sie sind nicht da, um Ihnen beim Scheitern zuzusehen – sie versuchen einzuschätzen, wo Ihre Obergrenze liegt, und ein guter Interviewer führt Sie an einer Blockade vorbei, um zu sehen, wie weit Sie mit Unterstützung kommen. Aber sie können nur helfen, wenn sie wissen, wo Sie feststecken.
Statt bei einer Blockade zu verstummen, schildern Sie Ihre Lage: „Ich weiß, dass ich zwischen den Iterationen einen Zustand verfolgen muss, aber ich sehe nicht sofort die richtige Datenstruktur. Lassen Sie mich überlegen, welche Eigenschaften hier zählen …" Das signalisiert, dass Sie noch im Eingriff sind, gibt dem Interviewer die Öffnung zu helfen und löst oft Ihre eigene Lösung aus – zu artikulieren, wo man feststeckt, bringt häufig die Antwort zutage.
Wenn Sie wirklich einen Hinweis brauchen, bitten Sie direkt und ohne Verlegenheit darum: „Ich glaube, ich brauche hier einen Anstoß – gibt es eine Datenstruktur-Eigenschaft, an die ich denken sollte?" Das ist professionell. Zu verstummen ist es nicht.
Bonus: So bereiten Sie sich vor, damit diese Fehler nicht passieren
Diese Fehler intellektuell zu kennen verhindert sie nicht unter Interviewdruck. Deshalb zählt Üben unter realistischen Bedingungen so viel. Ein paar Prinzipien für die technische Interviewvorbereitung, die funktionieren:
- Üben Sie auf einem Whiteboard oder in einem geteilten Dokument, nicht in Ihrer IDE. Ihre IDE hat Autovervollständigung, Syntax-Highlighting und sofortiges Fehlerfeedback. Interviewplattformen nicht. Üben Sie ohne das Sicherheitsnetz, damit Sie nicht davon abhängig sind.
- Stoppen Sie immer die Zeit. Eine Lösung, die Sie entspannt in 45 Minuten schaffen, kann im Interview 20 Minuten dauern – oder 55. Kennen Sie Ihr tatsächliches Tempo bei mittelschweren Aufgaben, bevor Sie in einer echten Situation sind.
- Machen Sie mindestens 5 Mock-Interviews mit einem menschlichen oder KI-Interviewer – nicht nur Solo-LeetCode. Die Kommunikationsgewohnheiten (laut denken, Anforderungen klären, testen) müssen durch realistisches Üben aufgebaut werden, nicht durch Solo-Coding-Übungen.
- Werten Sie nach jeder Session aus. Welchen dieser fünf Fehler haben Sie gemacht? Wo sind Sie still geworden? Was haben Sie ohne zu fragen angenommen? Jeder Fehler in der Übung ist einer, den Sie im echten Interview nicht machen werden.
Für KI-gestützte technische Interview-Übung bietet InterviewAce Mock-Technikrunden, in denen Sie das laute Denken mit einer KI üben können, die sowohl Ihre Lösung als auch Ihren Kommunikationsprozess bewertet. Kombinieren Sie es mit dem umfassenderen Leitfaden zur Interviewvorbereitung, um auch die Verhaltens- und Logistikseite abzudecken.