Pair-Programming-Interviews: was bewertet wird, wenn Sie nicht allein sind
Die übliche Annahme lautet: Sie werden beobachtet. Tatsächlich arbeitet jemand mit Ihnen, und fast alles, was gut bewertet wird, folgt daraus, diesen Unterschied zu bemerken.
Der teuerste Irrtum
Die meisten kommen mit der Annahme an, der Interviewer sei ein Prüfer, der zufällig im Raum sitzt — also gelte es, Kompetenz vorzuführen und keine Lücke zu zeigen. Unter dieser Annahme stellt man keine Fragen, denn Fragen sieht nach Nichtwissen aus. Und man denkt nicht laut, denn halbfertige Gedanken wirken unfertig.
Es ist genau umgekehrt. In einer Pair-Runde ist der Interviewer vierzig Minuten lang ein Kollege, und gemessen wird, wie es ist, mit Ihnen zu arbeiten. Ihr Schweigen ist keine Souveränität — es ist jemand, mit dem sich schlecht paaren lässt.
Nutzen Sie ihn, und zwar hörbar
Eine Pair-Sitzung gibt Ihnen etwas, das eine Einzelrunde nicht hat: ein zweites Gehirn, das die Antwort schon kennt. Wer das gut nutzt, tut dreierlei immer wieder.
Annahmen prüfen, bevor man darauf aufbaut. „Ich gehe davon aus, dass diese IDs eindeutig sind — ist das sicher?“ Zehn Sekunden, und zwanzig Minuten in die falsche Richtung sind gespart.
Eine Wahl anbieten statt zu raten. „Ich kann das mit einem Dictionary machen oder vorher sortieren. Sortieren liest sich einfacher, das Dictionary ist schneller. Was ist Ihnen hier wichtiger?“ Das ist keine Unentschlossenheit — so entsteht Arbeit tatsächlich.
Und Hinweise annehmen, ohne zu diskutieren. Wenn jemand fragt „und wenn die Liste leer ist?“, ist die Antwort keine Verteidigung. Sie lautet „guter Punkt“ plus eine Guard-Klausel.
Tippen ist nicht die Arbeit
Ein häufiges Muster: Der Kandidat tippt dreißig Minuten gleichmäßig, produziert etwas, das fast läuft, und bekommt negatives Feedback. Der Interviewer konnte der Begründung nicht folgen, also gab es außer dem Artefakt nichts zu bewerten — und das Artefakt war unfertig.
Das Gegenteil schneidet besser ab: weniger Code, mehr Erzählung, häufige Checkpoints. „Gut, damit ist der Hauptpfad abgedeckt. Bevor ich weitermache — soll ich fehlerhafte Eingaben behandeln, oder reicht der Happy Path erst mal?“
Diese Frage leistet echte Arbeit. Sie zeigt, dass Sie den Fall kennen, respektiert die Uhr und macht den Interviewer zum Beteiligten an Scope-Entscheidungen statt zum Zuschauer.
Wenn Sie anderer Meinung sind
Es kommt vor: Der Interviewer schlägt etwas vor, das Sie für falsch halten. Beide Extreme verlieren. Stilles Mitmachen liest sich als fehlende Meinung. Sich eingraben liest sich als jemand, der im Team anstrengend wird.
Der richtige Zug ist, den Dissens konkret und billig zu machen. „Ich glaube, das bricht, wenn die Eingabe schon sortiert ist — darf ich es an diesem Fall ausprobieren?“ Jetzt ist es ein Zwei-Minuten-Experiment statt eines Streits, und wer am Ende recht hat, ist egal: Sie haben gezeigt, wie Sie technische Meinungsverschiedenheiten lösen. Und genau das wird eigentlich gefragt.
Die letzten fünf Minuten
Die meisten tippen am Ende schneller und hoffen, fertig zu werden. Nicht fertig zu werden ist normal und selten fatal; nicht erklärt zu haben ist schlimmer.
Bessere Nutzung der Zeit: aufhören und sagen, wo Sie stehen. „Für den Standardfall läuft das. Mit zehn Minuten mehr würde ich Duplikate behandeln, und zwar über ein Seen-Set an dieser Stelle.“
Damit haben Sie gezeigt, dass Sie wissen, was fehlt und wie Sie es fertigstellen würden — und das ist der Großteil dessen, was das Fertigwerden ohnehin bewiesen hätte.
Was mitgeschrieben wird
Interviewer bewerten in Pair-Runden meist entlang einer kurzen Rubrik, und darin geht es selten um den Algorithmus. Wiederkehrend sind Kommunikation, Zusammenarbeit, Umgang mit Feedback und Debugging unter Druck.
Kommunikation ist nicht Redegewandtheit. Es geht darum, ob die zuschauende Person Ihren nächsten Schritt vorhersagen kann. Kann sie es, sind Sie lesbar; kann sie es nicht, sieht alles nach Raten aus, auch wenn es keines ist.
Den Umgang mit Feedback unterschätzen Kandidaten am stärksten. Der Interviewer wird Sie mindestens einmal unterbrechen, oft mit etwas, das Sie schon wussten. Notiert wird, ob die Unterbrechung Sie defensiv gemacht hat und wie schnell das Gespräch zur Arbeit zurückkehrte.
Debugging ist der Teil, den man sehen will
In einer Pair-Runde kommt fast immer der Moment, in dem der Code nicht das tut, was Sie erwartet haben. Dieser Moment ist kein Rückschlag im Interview — oft ist er sein Sinn.
Die schwache Variante ist, so lange etwas zu ändern, bis die Ausgabe richtig aussieht. Die starke ist, vor jedem Eingriff eine Hypothese zu bilden: „Der Zähler ist um eins zu hoch, und die Schleife läuft von null bis n inklusive — ich tippe auf die Grenze. Ich prüfe das mit n gleich eins.“
Erst die Hypothese aussprechen, dann testen. Zwei Sätze, und Sie haben eine Methode gezeigt statt eines Reflexes.
Die ersten zwei Minuten aufsetzen
Bevor Sie etwas schreiben, tun Sie drei Dinge laut: das Problem wiederholen, die Form der Eingabe bestätigen und sagen, was Sie zuerst machen. Das kostet neunzig Sekunden und ändert den Ton der ganzen Sitzung.
Es gibt dem Interviewer außerdem früh die Gelegenheit, Sie umzulenken. Das tun sie meist, wenn man sie lässt — und eine Korrektur in Minute zwei ist gratis, dieselbe Korrektur in Minute zwanzig kostet die Runde.
Ist die Aufgabenstellung mehrdeutig, ist diese Mehrdeutigkeit meist Absicht. Danach zu fragen ist keine Verzögerung: Es ist das Erste, was geprüft wird.
Wo ein Copilot hineinpasst
Interview Copilot verfolgt die Runde in Echtzeit und legt eine Struktur auf Ihren Bildschirm, während die andere Person noch spricht: worum die Frage wirklich geht, welche Einschränkung zählt und welcher Trade-off es wert ist, laut gesagt zu werden. Kein Skript zum Ablesen: ein Gerüst, von dem aus Sie in eigenen Worten sprechen.
FAQ
Was ist ein Pair-Programming-Interview?
Eine Runde, in der Sie gemeinsam mit dem Interviewer etwas bauen, statt beim Lösen eines Rätsels beobachtet zu werden. Er schreibt womöglich selbst Code, schlägt Richtungen vor oder spielt einen Teamkollegen. Bewertet wird die Zusammenarbeit: ob Sie erklären, zuhören, nützlich widersprechen und Impulse aufnehmen.
Was wird in einer Pair-Programming-Runde tatsächlich bewertet?
Ob die Arbeit mit Ihnen produktiv ist. Konkret: ob Sie Ihre Absicht aussprechen, ob Sie nutzen, was Ihr Gegenüber anbietet, ob Sie mit einem Grund widersprechen statt nachzugeben oder zu ignorieren, und ob Ihr Code für jemand anderen in Echtzeit verständlich bleibt.
Soll ich widersprechen, wenn ich den Interviewer für falsch halte?
Ja, mit Grund und Vorschlag. „Das funktioniert, macht aber einen zusätzlichen Durchlauf über die Liste — schaffen wir es in einem?“ ist die gesuchte Antwort. Stilles Mitmachen und stilles Übergehen schneiden beide schlecht ab.
Wie viel sollte ich tippen?
Weniger, als Sie denken. Bewertet wird nicht das Tippen, sondern Entscheidungen. Lange stille Tippstrecken erzeugen keinerlei Belege — kommentieren Sie laufend, was Sie schreiben und warum.