Das Coding-Interview bei Meta: Format, Editor und Übung

Der Ablauf ist bei Meta sowohl im Telefoninterview als auch in den Onsite-Coding-Runden gleich: eine kurze Vorstellung, eine Aufgabenstellung wird in einen gemeinsamen Editor eingefügt, und die Zeit läuft praktisch ab diesem Moment. Du klärst Rahmenbedingungen, erläuterst einen Lösungsansatz, schreibst Code, während du laut erklärst, und gehst ihn anschließend von Hand an Testfällen durch. Bei zwei Aufgaben in einer Sitzung schafft ein starker Kandidat die erste in unter zwanzig Minuten, um der zweiten wirklich Raum zu lassen.

Die Editoren sind bewusst schlicht gehalten: oft ohne Ausführung, ohne Autovervollständigung, mit minimaler Syntaxhervorhebung. Das ist keine Sparsamkeit; bewertet wird dein Denkprozess, und ein Ausführen-Button würde verwischen, wessen Überlegung die Lösung tatsächlich hervorgebracht hat. Erwarte, dein eigener Interpreter zu sein und Indizes sowie Grenzfälle laut durchzugehen.

Wo diese Runden im gesamten Auswahlprozess von Meta stehen, ist im Hub zu Interviewprozessen nach Unternehmen beschrieben.

Die Angst hier gilt meist der Stille: was in den Notizen des Interviewers passiert, während du nachdenkst. Die ehrliche Antwort lautet, dass die Notizen Signale erfassen, und Stille lässt diese Signale verhungern. Korrektheit und Geschwindigkeit sind nur die sichtbare Hälfte. Die andere Hälfte ist Kommunikation: ob du das Problem vor dem Programmieren eingegrenzt hast, ob du den Kompromiss benannt hast, der deinen Ansatz bestimmt hat, und ob du deinen eigenen Code ungefragt getestet hast.

Deshalb schlägt lautes Üben stilles Pauken. Ein Kandidat, der etwas weniger Aufgaben löst, dabei aber hörbar denkt, die Komplexität benennt und sich selbst korrigiert, liefert ein vollständigeres Signalprofil als jemand, der still löst. Metas eigene Vorbereitungshinweise sagen genau das; das Format ist darauf ausgelegt, sichtbares Denken zu belohnen.

Das Mock-Interview-Tool bietet zeitlich begrenzte Sitzungen mit zwei Aufgaben, bei denen man laut mitdenkt, und kommt damit dem echten gemeinsamen Editor am nächsten.

In der Spätphase der Vorbereitung geht es um Formattreue, nicht um neue Theorie. Löse Aufgaben in einem schlichten Editor mit ausgeschalteter oder minimaler Syntaxhervorhebung, sprich jede Lösung laut aus, auch allein, und begrenze Sitzungen auf fünfundvierzig Minuten mit zwei Aufgaben, damit diese Dichte zur Normalität wird. Baue die Gewohnheit wieder auf, Code von Hand nachzuvollziehen, denn der Editor wird ihn nicht für dich ausführen.

Eine Infrastruktur-Ingenieurin zehn Tage vor ihrer Onsite-Runde ist ein typischer Fall. Sie verbrachte Abende mit zeitlich begrenzten Aufgabenpaaren, nahm sich selbst auf, um stille Passagen zu erkennen, und nutzte ihr letztes Wochenende für eine vollständige Simulation einer ganzen Onsite-Runde. In den echten Runden waren ihr Editor, Tempo und lautes Erklären bereits vertraut, sodass ihre Aufmerksamkeit vollständig den Aufgaben galt; das Transkript auf ihrem eigenen Rechner hielt während der Arbeit lediglich die Vorgaben des Interviewers sichtbar fest.

Ehrliche Grenzen gelten weiterhin: Ein Live-Editor ist eine für beide Seiten sichtbare Fläche, aufgezeichnete oder überwachte Runden liegen außerhalb des Einsatzbereichs jedes Hilfstools, und die dichte Taktung bedeutet, dass am Ende wirklich nur deine eigene Routine skaliert. Diese Grenzen sind auf der Themenseite Erkennbarkeit zusammengefasst.