Das Meta-Coding-Interview: Format, Pads und Vorbereitung
Von Aaron Cao · Aktualisiert am
Meta beschreibt ein 45-minütiges technisches Screening mit etwa 35 Minuten Programmierzeit, das remote in einem kollaborativen Editor oder vor Ort an einem Whiteboard stattfindet. Bewerber berichten häufig von zwei Aufgaben pro Sitzung. Der Editor bietet in der Regel weder Codeausführung noch Autovervollständigung, die Kameras bleiben eingeschaltet, und die Interviewer bewerten Korrektheit, Geschwindigkeit, Codequalität und wie klar du beim Schreiben deine Überlegungen erklärst.
Was genau geschieht in den 45 Minuten?
Der Ablauf ist beim Telefon-Screening und bei den Coding-Runden im Loop von Meta ähnlich: kurze Vorstellungen, eine in ein gemeinsames Pad eingefügte Aufgabenstellung, und schon läuft praktisch die Uhr. Du klärst die Rahmenbedingungen, erläuterst einen Lösungsansatz, schreibst erklärend deinen Code und gehst ihn anschließend anhand von Testfällen manuell durch. Bei zwei Aufgaben in einer Sitzung löst ein starker Bewerber die erste innerhalb von zwanzig Minuten, damit für die zweite wirklich genug Zeit bleibt.
Die Pads sind bewusst schlicht gehalten: häufig ohne Codeausführung, ohne Autovervollständigung und mit minimaler Syntaxhervorhebung. Das ist keine Knausrigkeit; bewertet wird dein Denkprozess, und ein Startknopf würde verschleiern, wessen Überlegungen zur Korrektur geführt haben. Rechne damit, dein eigener Interpreter zu sein und Indizes sowie Grenzfälle laut Schritt für Schritt durchzugehen.
Wo diese Runden in der vollständigen Auswahlpipeline von Meta liegen, zeigt der Überblick über Bewerbungsprozesse bei Unternehmen.
Worauf achten die Interviewer tatsächlich?
Die Sorge gilt hier meist der Stille: Was landet in den Notizen des Interviewers, während du nachdenkst? Ehrlich gesagt halten diese Notizen Signale fest, und Schweigen liefert davon zu wenige. Korrektheit und Geschwindigkeit bilden die sichtbare Hälfte. Die andere Hälfte ist Kommunikation: ob du das Problem vor dem Programmieren abgegrenzt, die für deinen Ansatz entscheidende Abwägung benannt und deinen eigenen Code ohne Aufforderung getestet hast.
Deshalb ist erklärendes Üben effektiver als stilles Abarbeiten. Wer etwas weniger Aufgaben löst, aber hörbar denkt, die Komplexität benennt und sich selbst korrigiert, liefert ein vollständigeres Signalprofil als jemand, der schweigend Lösungen findet. Auch die Vorbereitungshinweise von Meta betonen das; das Format ist darauf ausgelegt, sichtbares Denken zu belohnen.
Das Tool für Probeinterviews führt zeitlich begrenzte Sitzungen mit zwei Aufgaben durch, bei denen du deine Schritte fortlaufend erklärst – die realistischste Übung für das echte Pad.
Wie solltest du dich in den letzten zwei Wochen vorbereiten?
In der Schlussphase geht es um eine möglichst realitätsnahe Vorbereitung, nicht um neue Theorie. Löse Aufgaben in einem schlichten Editor mit deaktivierter oder minimaler Syntaxhervorhebung, sprich jede Lösung laut aus, auch wenn du allein bist, und begrenze Sitzungen mit zwei Aufgaben auf fünfundvierzig Minuten, damit sich diese Dichte normal anfühlt. Gewöhne dich wieder daran, Code von Hand nachzuverfolgen, denn das Pad wird ihn nicht für dich ausführen.
Eine Infrastrukturentwicklerin, deren Loop in zehn Tagen anstand, ist ein typischer Fall. Sie verbrachte die Abende mit Aufgabenpaaren unter Zeitdruck, nahm sich auf, um stille Phasen zu erkennen, und nutzte ihr letztes Wochenende für eine vollständige Loop-Simulation. In den echten Runden waren ihr das Pad, das Tempo und das Erklären bereits vertraut, sodass ihre Aufmerksamkeit den Aufgaben galt; das Transkript auf ihrem eigenen Rechner hielt währenddessen lediglich die Vorgaben des Interviewers präsent.
Klare Grenzen gelten weiterhin: Ein Live-Pad ist eine gemeinsam genutzte Oberfläche, aufgezeichnete oder überwachte Runden sind für jedes Hilfstool tabu, und bei diesem engen Zeitrahmen lässt sich letztlich nur Routine wirklich skalieren. Die Grenzen sind im Themenbereich zur Erkennbarkeit zusammengefasst.