Technisches Interview: So bestehst du das Coding-Interview

Neulich saß ich mit einem extrem talentierten Entwickler aus München beim Kaffee, der mir völlig frustriert erzählte, wie er bei einem großen deutschen Tech-Unternehmen im Live-Coding eiskalt aussortiert wurde, obwohl er privat komplexe Open-Source-Projekte pflegt. Er hatte schlicht schweigend vor sich hingepuzzelt und einen kleinen Tippfehler übersehen, was die Interviewer als Planlosigkeit interpretiert haben. Solche Geschichten höre ich in meiner täglichen Arbeit als Bewerbungsexperte ständig, denn genau hier liegt die größte Hürde im Recruiting-Prozess.

Du hast die erste Hürde genommen. Dein Lebenslauf hat überzeugt, das Erstgespräch mit dem Recruiter war locker, doch jetzt kommt der Teil, vor dem die meisten Softwareentwickler in Deutschland, Österreich und der Schweiz wirklich zittern: das technische Interview. Viele glauben, es ginge hier nur darum, eine perfekte Lösung in den Editor zu hämmern. Das ist der erste fatale Irrtum. Ich habe über 4.500 Bewerbungen begleitet und gesehen, wie Leute mit Bestnoten an einfachen Aufgaben gescheitert sind, während solide Entwickler mit einer klaren Struktur Jobs bei Firmen wie SAP, Zalando oder kleinen Tech-Perlen in München und Zürich bekommen haben.

In den nächsten Absätzen reißen wir die Fassade der großen Tech-Interviews ein. Ich zeige dir genau, wie Firmen im DACH-Raum prüfen, ob du wirklich programmieren kannst oder nur Framework-Namen auswendig gelernt hast. Wir reden über den Ablauf, die psychologische Komponente des lauten Denkens und die No-Gos, die dich sofort aus dem Rennen werfen. Wer sich hier nicht vorbereitet, verliert gegen jemanden, der vielleicht weniger fachliches Wissen hat, aber weiß, wie man ein technisches Problem kommunikativ verkauft.

Es gibt keine Abkürzung, aber es gibt ein System. Vergiss alles, was du über akademische Prüfungen an der Uni weißt. Ein Coding-Interview ist eine Simulation der Zusammenarbeit. Wenn du das begreifst, hast du den psychologischen Vorteil auf deiner Seite. Setzen wir uns an die Tasten und schauen uns an, was wirklich zählt, wenn der Compiler läuft und zwei Senior-Entwickler mit verschränkten Armen auf deinen Bildschirm schauen.

Der Ablauf eines typischen Coding-Interviews im DACH-Raum

Vergiss die Klischees aus dem Silicon Valley, wo jeder Kandidat erst einmal eine binäre Baumstruktur invertieren muss. In Deutschland, Österreich und der Schweiz ist man oft pragmatischer, aber nicht weniger fordernd. Ein typischer Termin dauert zwischen 60 und 90 Minuten. Die erste Viertelstunde gehört meistens deinem Hintergrund. Du erklärst Projekte, die du realisiert hast. Hier wird geprüft, ob du die Tiefe deiner Architektur verstehst. Wenn du sagst, dass ihr Mikroservices genutzt habt, musst du erklären können, warum das sinnvoll war und wo die Schmerzen lagen. Wer hier nur nachplappert, was der Architekt vorgegeben hat, verliert sofort an Glaubwürdigkeit.

Danach folgt der Kern: die Live-Coding-Session. Entweder nutzt die Firma Tools wie CoderPad, HackerRank oder sie lassen dich einfach dein eigenes IDE teilen. Oft starten Firmen mit einer Aufwärmaufgabe. Das kann eine einfache String-Manipulation sein oder das Filtern einer Liste. Der Fehler, den viele machen, ist, diese Phase zu unterschätzen. Sie programmieren hektisch los, machen einen Tippfehler und geraten in Panik. Die Aufwärmphase ist dazu da, dass du dich an die Umgebung gewöhnst und die Interviewer deinen Denkstil kennenlernen. Es geht nicht um die Geschwindigkeit, sondern um die Sauberkeit des ersten Entwurfs.

In der zweiten Hälfte der Coding-Session wird es komplexer. Hier kommen Business-Logiken ins Spiel, die nah an der Realität der Firma sind. Ein E-Commerce-Riese aus Berlin lässt dich vielleicht einen Warenkorb-Validator bauen, während eine Bank in Frankfurt sehen will, wie du Währungstransaktionen mit Fließkommazahlen vermeidest. Zum Abschluss gibt es fast immer eine Fragerunde. Unterschätze niemals die Qualität deiner Rückfragen. Wer fragt, wie das Team mit technischer Schuld umgeht oder wie Code-Reviews ablaufen, zeigt Professionalität. Wer keine Fragen hat, wirkt desinteressiert oder arrogant.

Warum lautes Denken deine Lebensversicherung ist

Das ist der wichtigste Punkt überhaupt. Wenn du schweigend vor dem Bildschirm sitzt, bist du für die Interviewer eine Blackbox. Sie wissen nicht, ob du gerade kurz vor der Lösung stehst oder absolut keinen Plan hast. Im DACH-Raum legen wir Wert auf Teamfähigkeit. Programmieren ist eine soziale Tätigkeit. Wenn du laut denkst, gibst du den Interviewern die Chance, dich zu korrigieren oder dir einen Hinweis zu geben. Stell dir vor, du wählst einen falschen Sortieralgorithmus. Wenn du leise bist, implementierst du ihn und scheiterst. Wenn du sagst, dass du Quicksort in Erwägung ziehst, obwohl der Speicherbedarf höher sein könnte, kann der Interviewer dich lenken und sagen, dass Speicher für diesen Anwendungsfall kein Problem ist.

Lautes Denken bedeutet nicht, jeden Tastendruck zu kommentieren. Es bedeutet, deine Annahmen und Strategien offenzulegen. Du solltest formulieren, welche Grenzfälle du im Kopf hast, wie beispielsweise leere Eingaben, null-Werte oder extrem große Datensätze. Ein Satz wie: "Bevor ich anfange zu tippen, skizziere ich kurz meinen Plan: Erst validiere ich die Eingabe, dann iteriere ich über die Liste und speichere die Ergebnisse in einer Map", wirkt Wunder. Es zeigt, dass du strukturiert arbeitest und nicht einfach wild Code in den Editor wirfst, in der Hoffnung, dass es funktioniert.

Zudem baut lautes Denken eine Brücke. Das Interview verwandelt sich von einer Prüfungssituation in eine gemeinsame Problemlösung. Das ist genau das Gefühl, das du vermitteln willst. Du willst, dass die Interviewer merken, dass man mit dir hervorragend acht Stunden am Tag zusammenarbeiten kann. Wer stumm bleibt, wirkt wie ein Einzelgänger, der im Homeoffice verschwindet und keine Updates gibt. In modernen agilen Teams ist das ein Kündigungsgrund, bevor der Vertrag überhaupt unterschrieben ist.

Algorithmen und Datenstrukturen: Was du wirklich wissen musst

Man hört oft, dass man im Arbeitsalltag nie wieder einen Graph-Algorithmus braucht. Das mag stimmen, aber im Interview sind sie das Werkzeug, um dein logisches Verständnis zu testen. Du musst keine Wettbewerbs-Programmierung betreten, aber die Grundlagen müssen sitzen wie im Schlaf. In DACH-Interviews steht meist die Effizienz im Vordergrund. Du solltest den Unterschied zwischen einer ArrayList und einer LinkedList kennen. Du solltest wissen, wann eine Hashmap Sinn macht (was fast immer der Fall ist, wenn es um Geschwindigkeit bei der Suche geht) und wann ein Set die bessere Wahl ist.

Die Big-O-Notation ist kein akademischer Ballast. Wenn du eine Lösung präsentierst, die eine quadratische Laufzeit aufweist, musst du das begründen können. Die Standardfrage der Interviewer lautet fast immer, ob man das schneller machen kann. Wenn du dann nicht weißt, wie man durch den Einsatz von zusätzlichem Speicher die Zeit reduziert, hast du ein Problem. Besonders bei Firmen in Städten wie Zürich oder München, wo die Gehälter hoch sind, ist das Verständnis für Performance nicht verhandelbar.

Ein konkretes Beispiel aus der Praxis: Ein Kandidat sollte in einem Frankfurter FinTech doppelte Einträge in einer Liste von Millionen Transaktionen finden. Er wählte eine doppelte For-Schleife. Das funktioniert technisch, dauert aber bei großen Datenmengen ewig. Die richtige Antwort wäre der Einsatz eines HashSets gewesen, um die Laufzeit drastisch zu senken. Der Kandidat wusste das eigentlich, kam aber unter Druck nicht darauf, weil er die Basics nicht regelmäßig geübt hatte. Übe auf Plattformen wie LeetCode, aber konzentriere dich auf die einfachen und mittleren Aufgaben. Die schweren Aufgaben sind oft Zeitverschwendung für normale Web- oder App-Entwickler-Rollen.

Umgang mit Fehlern und Blockaden während der Live-Session

Jeder macht Fehler. Auch Senior-Entwickler mit 20 Jahren Erfahrung bauen Bugs ein. Das Interview ist kein Test auf Fehlerfreiheit, sondern ein Test auf Fehlerkultur. Wenn dein Code nicht kompiliert oder ein Test fehlschlägt, ist das kein Weltuntergang. Der größte Fehler ist es, den Bug zu ignorieren oder nervös alles zu löschen und von vorne anzufangen. Atme tief durch. Schau dir die Fehlermeldung an. Lies sie laut vor. Das zeigt, dass du hervorragende Debugging-Fähigkeiten besitzt.

Wenn du absolut nicht weiterweißt, sei ehrlich, aber professionell. Sag nicht, dass du das nicht kannst. Sag stattdessen, dass du gerade an einem Punkt stehst, an dem du überlegen musst, wie du dieses spezifische API-Problem löst. Erkläre, dass du das normalerweise in der Dokumentation nachschlagen würdest, aber vermutest, dass Ansatz X oder Y funktionieren könnte, und frage den Interviewer, welchen Weg er in dieser Architektur bevorzugt. Das zeigt, dass du lösungsorientiert bist und deine Grenzen kennst. Ein guter Interviewer wird dir eine kleine Hilfestellung geben.

Ein wichtiger Trick: Teste deinen Code manuell, bevor du den Run-Button drückst. Geh die Zeilen mit einem Beispielwert im Kopf durch und erkläre, was bei einer bestimmten Eingabe in welcher Zeile passiert. Wenn du den Fehler selbst findest, bevor das System oder der Interviewer es tut, sammelst du massive Pluspunkte. Es beweist Sorgfalt und ein tiefes Verständnis für den Kontrollfluss. Interviewer lieben Entwickler, die ihren eigenen Code kritisch hinterfragen.

Clean Code und Best Practices: Mehr als nur Logik

In der DACH-Region haben wir eine starke Tradition für Ingenieurskunst. Das gilt auch für Software. Es reicht nicht, dass der Code funktioniert, er muss wartbar sein. Viele Kandidaten schreiben undefinierbare, kurze Variablennamen. Das ist tödlich. Benenne deine Variablen so, dass man den Code wie ein Buch lesen kann. Aussagekräftige Namen für Listen, Validierungen oder Counter sind Gold wert. Wenn du Zeit hast, modularisiere deinen Code und packe Logik in kleine, private Methoden, statt eine riesige Mammut-Funktion zu schreiben.

Ein weiteres Thema ist Fehlerbehandlung. Was passiert, wenn die API nichts zurückgibt oder der String leer ist? Wer defensives Programmieren betreibt, zeigt, dass er für die echte Produktion entwickelt und nicht nur für den Testlauf. Setze sinnvolle Kommentare, aber nur dort, wo der Code nicht ohnehin für sich selbst spricht. In einem Gespräch bei einem großen Logistiker in Hamburg wurde ein Kandidat abgelehnt, weil sein Code zwar perfekt funktionierte, aber so unleserlich war, dass das gesamte Team den Code später nicht warten wollte.

Denk auch an automatisierte Tests. Du musst im Interview vielleicht keine komplette Testsuite schreiben, aber du solltest erwähnen, welche Unit-Tests du schreiben würdest. Die Erwähnung von Tests für Grenzfälle wie leere Warenkörbe oder negative Preise zeigt, dass du Qualitätssicherung im Blut hast. Das unterscheidet den Bastler vom professionellen Software-Ingenieur.

Die Psychologie des Interviewers verstehen

Interviewer sind oft selbst Entwickler, die eigentlich viel zu tun haben und hoffen, dass du die Lösung für ihre Personalprobleme bist. Sie sind nicht deine Feinde. Sie wollen, dass du gut bist, damit die Suche endlich ein Ende hat. Aber sie haben auch Angst davor, jemanden einzustellen, der das Team verlangsamt oder technisch nicht mithalten kann. Dein Ziel ist es, diese Angst zu nehmen. Du strahlst Sicherheit aus, indem du ruhig bleibst, strukturiert vorgehst und freundlich kommunizierst.

Ein unterschätzter Aspekt ist die Sympathie. Wenn du die ganze Zeit belehrend wirkst oder jede Anmerkung des Interviewers abblockst, wirst du nicht eingestellt, egal wie brillant dein Code ist. Wir nennen das den Test auf Teamkompatibilität. In Firmen in der Schweiz oder im Süden Deutschlands ist die Unternehmenskultur oft sehr familiär oder zumindest auf Harmonie bedacht. Sei ein angenehmer Gesprächspartner. Wenn der Interviewer einen Witz macht, lach kurz, und zeig dich offen für andere Meinungen zu einer Library.

Vergiss nicht, dass das Interview eine zweiseitige Angelegenheit ist. Du prüfst auch die Firma. Wie reagieren sie auf deine Fragen? Sind sie genervt, wenn du nach ihrer Pipeline fragst? Wenn die Interviewer selbst unvorbereitet wirken oder dich herablassend behandeln, ist das eine rote Flagge für das spätere Arbeitsverhältnis. Ein gutes Interview fühlt sich wie ein Fachgespräch unter Kollegen an, nicht wie ein strenges Verhör.

Die Vorbereitung: Zahlen, Daten, Fakten

Du kannst Coding-Interviews nicht durch das bloße Lesen von Blogs meistern. Du musst tippen. Ich empfehle meinen Kunden immer eine Vorbereitungszeit von mindestens zwei bis vier Wochen vor dem ersten großen Termin. Nutze Plattformen wie LeetCode oder Exercism. Konzentriere dich auf die Sprachen, die in der Stellenausschreibung stehen. Wenn die Firma Java nutzt, solltest du die neuesten Features der aktuellen Versionen kennen. Wenn es um React geht, solltest du Hooks im Schlaf beherrschen.

Recherchiere die Firma auf Plattformen wie Kununu oder Glassdoor. Oft schreiben Bewerber dort genau rein, welche Aufgaben sie lösen mussten. In Berlin ist es zum Beispiel sehr üblich, dass Startups Hausaufgaben vergeben, während die großen Konzerne eher auf Live-Coding oder Whiteboard-Sessions setzen. Bereite dich auf beides vor. Wenn du ein Take-Home-Assignment bekommst, investiere Zeit in eine saubere README-Datei und erkläre dort deine Design-Entscheidungen. Das ist oft wichtiger als der Code selbst. Falls dir die Zeit oder der Nerv fehlt: professionellen Bewerbungsservice.

Ein praktischer Tipp: Nimm dich selbst beim Lösen einer Aufgabe auf und sprich dabei laut. Wenn du dir das Video danach ansiehst, wirst du merken, wie oft du zögerst oder wo du unsicher wirkst. Das ist hartes Training, aber es wirkt. Meine Erfahrung mit über 4.500 Bewerbern zeigt deutlich: Diejenigen, die den Prozess der Selbstanalyse durchlaufen, haben eine doppelt so hohe Zusagequote wie die, die einfach nur gut programmieren können.

Wenn du merkst, dass du trotz technischer Brillanz immer wieder in der letzten Runde scheiterst oder erst gar keine Einladungen von den Top-Tech-Firmen im DACH-Raum bekommst, kann eine strukturierte Unterstützung den entscheidenden Unterschied machen. Mein Ansatz in der persönlichen Beratung zielt darauf ab, diese Lücken zwischen Fachwissen und Selbstdarstellung zu schließen. Wir schauen uns gemeinsam an, wo deine Kommunikation hakt und wie wir deinen Werdegang so aufbereiten, dass die Entscheider keine andere Wahl haben, als dich einzuladen.

Was wir aus diesen Praxis-Erfahrungen mitnehmen

Das technische Interview ist keine Hürde, die man nur mit Glück überspringt. Es ist ein Handwerk, das man lernen kann. Es geht um die Kombination aus soliden Informatik-Grundlagen, sauberem Coding-Stil und einer exzellenten Kommunikation. Wer im DACH-Raum punkten will, muss nicht der schnellste Coder der Welt sein, aber er muss derjenige sein, dem man zutraut, komplexe Probleme im Team zu lösen. Bereite dich auf die Standard-Algorithmen vor, gewöhne dir das laute Denken an und bleib menschlich. Wenn du diese Punkte beachtest, verliert das Coding-Interview seinen Schrecken und wird zu einer echten Chance.

Lass uns am besten direkt mal deinen aktuellen Vorbereitungsstand analysieren und schauen, wie wir deine Präsentation für die nächste Live-Session auf ein ganz neues Level heben können.