Coding-Interview-Tipps

Wenn dein Instinkt unter Druck ist, sofort mit dem Tippen zu beginnen, dann ist genau das, was dieser Abschnitt korrigiert. Die stärksten Kandidaten verbringen die ersten Minuten damit, überhaupt nicht zu coden, und Interviewer bemerken das.

Beginne damit, das Problem in eigenen Worten zu wiederholen und mit dem Interviewer zu bestätigen. Frage nach den Rahmenbedingungen: Eingabegröße, Wertebereiche, ob die Eingabe sortiert ist, wie mit leeren oder fehlerhaften Eingaben umzugehen ist. Nenne dann deinen geplanten Ansatz und dessen Komplexität, bevor du überhaupt etwas schreibst. Dieser kurze Planungsschritt deckt Missverständnisse früh auf und zeigt strukturiertes Denken, was einen großen Teil der Bewertung ausmacht.

Schweigen ist der häufigste Grund, warum eine eigentlich starke Problemlösung schwach wirkt. Kommentiere fortlaufend, was du gerade schreibst und warum, damit der Interviewer deiner Logik folgen und dich bei Bedarf in die richtige Richtung lenken kann.

Erreiche zuerst eine korrekte Antwort, bevor du eine elegante anstrebst. Eine funktionierende Brute-Force-Lösung ist mehr wert als eine elegante Idee, die nie kompiliert, und du kannst optimieren, sobald etwas funktioniert. Schreibe in kleinen, testbaren Schritten, verwende klare Variablennamen, und wenn du feststeckst, sag laut, was du gerade überlegst, statt zu verstummen. Interviewer geben häufig Hinweise, aber nur, wenn sie hören können, wo du gerade stehst.

Eine Lösung ist nicht fertig, wenn sie kompiliert; sie ist fertig, wenn du versucht hast, sie zum Scheitern zu bringen. Gehe deinen Code mit einer normalen Eingabe durch, dann mit bewusst schwierigen: leere Eingabe, ein einzelnes Element, Duplikate, negative Zahlen, der größte von den Rahmenbedingungen erlaubte Fall.

Stell dir eine Frontend-Ingenieurin vor, die sich für eine Position auf mittlerer Ebene bewirbt, eine funktionierende Two-Pointer-Lösung schreibt und dann unaufgefordert ein leeres Array und ein Array mit einem einzelnen Element durchgeht und die Laufzeit als O(n) angibt. Diese letzte Minute des Selbsttests und der Komplexitätsanalyse entscheidet oft zwischen einer Einstellung und einem Vielleicht, weil sie signalisiert, dass die Ingenieurin ihre eigenen Fehler auch im Job selbst finden wird. Nenne die Zeit- und Speicherkomplexität laut, auch ohne danach gefragt zu werden.

Tipps zu lesen ist leicht; sie unter Nervosität umzusetzen nicht. Die Lösung ist das Üben unter Bedingungen, die der Realität nahekommen: ein laufender Timer, die Lösung laut ausgesprochen und keine Pausen, um etwas nachzuschlagen. Überprüfe nach jeder Übungsaufgabe nicht nur, ob du sie gelöst hast, sondern auch, ob du geklärt, laut erklärt und getestet hast, denn genau diese Gewohnheiten werden bewertet.

Zeitlich begrenzte, laut gesprochene Runden gegen einen KI-Interviewer sind eine Möglichkeit, diesen Reflex aufzubauen; du kannst sie mit dem Mock-Interview-Tool durchführen. Eine Warnung, die es wert ist, wiederholt zu werden: echte Coding-Runden finden oft in einem beobachteten, geteilten Editor statt oder werden aufgezeichnet, sodass währenddessen kein Live-Assistent sicher ist, und das Ziel des Übens ist, keinen zu brauchen. Weitere Antworten zu Coding-Runden findest du im Themenhub Interviewarten, und Übungsanleitungen im Themenhub Mock-Interviews.