Vorbereitung auf Software-Engineer-Interviews: Der vollständige 2026-Leitfaden
Wie ein moderner Software-Engineer-Interview-Prozess 2026 aussieht — Phone-Screen, Coding-Runden, System-Design, Verhaltenstest — mit wiederkehrenden Mustern, den Plattformen, die Recruiter nutzen, und wie ein KI-Assistent die Vorbereitung verändert.
Devon Park
Head of Research, Acedly
Die 2026er SWE-Interview-Schleife, von Anfang bis Ende
Die Struktur eines Software-Engineer-Interview-Prozesses 2026 ist kein Geheimnis. Über etwa hundert Unternehmen, die Ingenieure in Volumen einstellen, taucht der gleiche Fünf-Stufen-Funnel fast jedes Mal auf – wobei die Unterschiede eher kulturell als prozessual sind.
Der Funnel startet mit einem Recruiter-Gespräch von etwa dreißig Minuten. Der Recruiter prüft nicht deine technische Tiefe; vielmehr bestätigt er/sie, dass du existierst, dass die Einstufung plausibel ist, dass der Standort passt, und dass du die Gehaltsspanne kennst. Die meisten Kandidaten bereiten sich zu wenig auf diese Runde vor. Die richtige Vorbereitung ist, deine Antworten auf „warum dieses Unternehmen?" und „warum dieses Team?" perfekt zu beherrschen und eine Ein-Satz-Selbsteinschätzung zu deinem Level bereit zu haben, wenn sie dich nach L4 oder L5 fragen.
Die nächste Runde ist das technische Telefoninterview – sechzig Minuten, typischerweise eine einzelne Coding-Frage auf Coderpad oder HackerRank mit einem Recruiter-Engineer oder einem der Mid-Career-Engineers des Teams. Die Anforderung ist „Kann dieser Kandidat funktionierenden Code schreiben, ohne zu paniken, und seine Logik laut erklären?" Unternehmen wie Google und Meta sind hier sehr streng; Unternehmen, die für weniger verbreitete Skillsets einstellen, sind kulanter.
Das On-Site, jetzt fast immer virtuell, läuft vier bis sechs Runden und dauert etwa fünf Stunden, inklusive Pausen. Die Standard-Zusammensetzung besteht aus zwei oder drei Coding-Panels von jeweils fünfundvierzig bis sechzig Minuten, einer System-Design-Runde von fünfundvierzig Minuten (für L3 in manchen Unternehmen optional, für L4 und höher in den meisten Unternehmen verpflichtend) und einer Verhaltens-Runde von fünfundvierzig Minuten. Manche Unternehmen integrieren ein Hiring-Manager-Interview hier ein; manche machen es zu einem separaten fünften Interview.
Es gibt einige unternehmenssspezifische Besonderheiten, die es wert sind zu kennen, wenn du diese Unternehmen anvisierst:
- Amazon führt parallel ein „bar raiser"-Interview durch – einen Senior-Engineer aus einem anderen Team, der mit Vetorecht in den Loop kommt und diesen gegen Amazons sechzehn Leadership Principles bewertet. Verhaltenskompetenzen sind bei Amazon wichtiger als fast überall sonst.
- Google setzt weiterhin stark auf algorithmische Schwierigkeit. Die Coding-Runden ähneln am meisten LeetCode-Hard-Fragen in der ganzen Industrie, und Google hält an dieser Ausrichtung fest, obwohl andere große Unternehmen lockerer geworden sind.
- Meta arbeitet mit dem sogenannten „Ninja-Code" – kurzen, schnellen Coding-Runden, in denen die Geschwindigkeit der korrekten Implementierung das Hauptzeichen ist. Zwei Fragen in einer fünfundvierzig-Minuten-Runde sind bei Meta normal, aber fast überall sonst ungewöhnlich.
- Stripe integriert Product-Engineering in die Coding-Runden. Die Fragen entsprechen echten Stripe-API-Problemen statt abstrakten LeetCode-Aufgaben. Kandidaten, die nur Patterns trainiert haben, finden die Stripe-Interviews verwirrend.
- ByteDance (und die Auslandsmarke TikTok) hat einen längeren Prozess mit mehreren System-Design-Runden auf Senior-Level und eine starke „Fundamentals"-Runde zu Datenstrukturen und Komplexität, die andere US-Unternehmen größtenteils abgeschafft haben.
Der Loop ist stabil. Was sich in den letzten zwei Jahren geändert hat, ist die Kostenstruktur: mehr virtuelle Runden, mehr KI-Screening am Anfang des Funnels, und bei den Kandidaten eine wachsende Anzahl von Ingenieuren, die während Live-Interviews echtzeitliche Unterstützung nutzen.
Coding-Runden: wie die acht Muster bei FAANG auftauchen
Etwa acht algorithmische Muster decken die meisten Live-Coding-Runden ab – Sliding Window, Two Pointers, BFS/DFS, DP-Familien, Greedy, Binary Search, Heaps und Top-k sowie Graph Traversal (Topological Sort und Union-Find). Die vollständige Taxonomie, kanonische Fragen und der Trainingsplan finden sich in unserem Coding-Interview-Vorbereitungsleitfaden; dieser Abschnitt geht davon aus, dass du diese Arbeit erledigt hast, und behandelt, wie die Muster in FAANG-Tier-SWE-Loops tatsächlich auftauchen.
Telefoninterviews konzentrieren sich auf Sliding Window, Two Pointers und BFS/DFS – Muster, die zu Single-Pass-Linearlösungen führen und dem Interviewer zeigen, wie du eine Invariante im Kopf behältst, während du tippst. Meta und Google stellen DP-Fragen im Telefoninterview-Tier viel häufiger ab als der Rest der Industrie; Amazon und Stripe fast nie.
On-Site-Coding-Panels behandeln Binary Search sowie schwierigere DP-Familien (2D-Grid, Intervall, Tree DP). Stripe und Databricks verpacken diese als Produktprobleme – „wir haben einen Zahlungsrückstand und möchten bis Fristende ausliefern" ist Intervall-DP mit Stripe-Kontext. Metas schnelle Ninja-Code-Runden bevorzugen Kandidaten, die das Muster in den ersten dreißig Sekunden erkennen, denn bei zwei Fragen pro Runde ist Mustererkennung der kritische Faktor, nicht Implementierung.
Senior-Loops (L5+) verwenden Topological Sort und Union-Find als Differenzierer, besonders in Infra- und Platform-Runden. Es wird nicht erwartet, dass du die acht-Zeilen-Union-Find auswendig kannst; vielmehr sollst du das Muster benennen, deine Wahl gegenüber BFS begründen und es in Echtzeit implementieren, ohne den größeren Design-Kontext zu verlieren, den der Interviewer parallel prüft.
Ein Echtzeit-Copilot wie Acedly unterstützt mehr als zwölf Programmiersprachen – Python, JavaScript, TypeScript, Java, C++, Go, Rust, Kotlin, Ruby, SQL, PHP und Scala – was wichtig ist, wenn der Recruiter im Interview sagt „könntest du das stattdessen in Go schreiben?" Mustererkennung ist das Kerntraining unter /coding-interview-prep; die Programmiersprache ist austauschbar.
System-Design: Junior vs Senior Signale
System-Design-Runden belohnen strukturiertes Denken unter Unsicherheit, und der Standard verschiebt sich dramatisch mit dem Levelling. Zu wissen, wie die Runde auf Ihrem Zielleveln aussehen soll, ist die halbe Vorbereitung.
Bei L3 / E3 / Neuabsolventen wird System-Design oft verzichtet oder durch eine „Design-a-Class"-Runde ersetzt, die wirklich objektorientiertes Design ist – einen Parkplatz entwerfen, eine Verkaufsmaschine entwerfen, ein Schachbrett entwerfen. Das Signal ist, ob Sie ein Problem in Klassen mit klaren Verantwortungen zerlegen können, nicht ob Sie die richtige Datenbank nennen können.
Bei L4 / E4 / mittlere Ebene erhalten Sie eine echte Frage zu verteilten Systemen – einen URL-Shortener entwerfen, einen Rate-Limiter entwerfen, einen Benachrichtigungsdienst entwerfen – und der Standard ist, dass Sie eine funktionierende Architektur skizzieren, eine Datenbankwahl treffen und verteidigen können, und den offensichtlichen Engpass identifizieren können. Tiefe wird nicht erwartet; Struktur ist es.
Bei L5 / E5 / Senior steigt der Standard deutlich an. Die Frage (Twitter entwerfen, WhatsApp entwerfen, Uber entwerfen) hat sich nicht geändert, aber der Interviewer erwartet, dass Sie die Runde leiten, Kompromisse ohne Aufforderung nennen, zwei oder drei Komponenten für einen tieferen Einstieg identifizieren und Ausfallmodi sowie betriebliche Bedenken besprechen. Ein Senior-Kandidat, der darauf wartet, dass der Interviewer Folgefragen stellt, ist ein Junior-Kandidat.
Bei L6+ / Staff und darüber dreht sich die Runde um Skalierbarkeit, Organisationsdesign und Migrationspfade. „Twitter entwerfen" wird zu „Sie haben ein funktionierendes Twitter; wie würden Sie es von einer monolithischen Postgres zu einer Sharded-Architektur ohne Ausfallzeit migrieren, und wie würden Sie das Team organisieren, um das zu tun?" Implementierungsdetails sind weniger wichtig; Beurteilung von Technologiewahlmöglichkeiten, Teamstruktur und Risiko ist wichtiger.
Das Fünf-Komponenten-Skelett funktioniert auf jeder Ebene – nur die Tiefe ändert sich. Verwenden Sie es jedes Mal:
- Funktionale Anforderungen – was das System tun muss. Stellen Sie drei oder vier Fragen, um das Problem einzugrenzen.
- Nicht-funktionale Anforderungen und Einschränkungen – Skalierbarkeit, Latenz, Konsistenz, Verfügbarkeit. In Zahlen umrechnen.
- Übergeordnete Architektur – Clients, Load Balancer, Services, Datenbanken, Caches, Warteschlangen. Kästen und Pfeile.
- Tieferer Einstieg in zwei Komponenten – wählen Sie die schwierigen aus und überlegen Sie sich Konsistenz, Partitionierung und Ausfallmodi.
- Kompromisse und Nachfragen – nennen Sie die Schwächen des Designs laut aus, bevor der Interviewer dazu auffordert.
Die ehrliche Leseliste ist kurz. Alex Xu's System Design Interview (Volumen 1 und 2) ist das nächste Äquivalent zu einer lingua franca für die Runde; Designing Data-Intensive Applications von Martin Kleppmann ist das tiefere Buch, das sich bei L5 und darüber auszahlt. Beide sind ihr Gewicht wert; alles andere auf dem Markt ist größtenteils redundant.
Verhaltensrunden: STAR für Ingenieure
Verhaltensrunden sind die Runden, die Ingenieure am häufigsten ablehnen und am häufigsten bereuen, abgelehnt zu haben. Das Signal ist real: Jedes Unternehmen hat Prinzipien oder Werte, die die Runde evaluieren soll, und ein gut vorbereiteter Kandidat schneidet sichtbar besser ab als ein brillanter unvorbereiteter.
Die Prinzipien unterscheiden sich. Amazons sechzehn Leadership Principles sind die strengsten und am weitesten verbreitet – Customer Obsession, Ownership, Bias for Action, Earn Trust, Disagree and Commit, und so weiter. Amazon-Interviewer ordnen Ihre Geschichten explizit den LPs zu und erwarten, dass Sie dasselbe tun. Googles „googleyness" ist vager – Komfort mit Mehrdeutigkeit, intellektuelle Demut, Neigung zur Zusammenarbeit – aber die Runde ist real und eine schwache Leistung kann eine ansonsten starke Schleife ruinieren. Metas „move fast"-Kultur lenkt die Runde zu Geschichten über entscheidende Maßnahmen, Akzeptieren von Kompromissen und Erholung von Fehlern; Schwäche in der Konfliktbewältigung ist ein häufiges Meta-spezifisches Ausschlusskriterium.
Das Format ist konsistent: STAR – Situation, Task, Action, Result. Der Fehler, den die meisten Ingenieure machen, ist zu viel in Action zu investieren und die anderen drei zu unterversorgen. Eine gute STAR-Antwort verbringt etwa zwanzig Prozent ihrer Zeit mit Situation (konkret, begrenzt), zwanzig Prozent mit Task (Ihre spezifische Verantwortung, nicht die des Teams), vierzig bis fünfzig Prozent mit Action (was Sie getan haben, nicht was wir getan haben), und den Rest mit Result (Zahlen wenn möglich).
Sammeln Sie acht bis zehn hochwertige Geschichten im Voraus an, ungefähr abgebildet auf: ein Projekt, das Sie von Anfang bis Ende geleitet haben; ein Konflikt mit einem Kollegen oder Manager; ein Zeitpunkt, an dem Sie eine Frist verpasst haben und was Sie gelernt haben; ein Zeitpunkt, an dem Sie einer Entscheidung nicht zugestimmt haben und was Sie getan haben; ein Zeitpunkt, an dem Sie jemanden mentoriert haben; eine schwierige technische Entscheidung; ein Zeitpunkt, an dem Sie etwas außerhalb Ihrer Rolle übernommen haben; ein Zeitpunkt, an dem Sie unter ungewöhnlichen Einschränkungen abgeliefert haben. Jede Geschichte sollte in drei bis vier Minuten ablaufen und mindestens zwei Folgezweige haben, über die Sie nachgedacht haben.
Ein ausgearbeitetes Beispiel. Der Prompt ist „erzähle mir von einem Zeitpunkt, an dem du mit deinem Manager nicht einverstanden warst." Eine schwache Antwort zitiert eine Funktionsanfrage und endet mit „wir endeten damit, es auf meine Weise zu tun." Eine starke Antwort sagt: „Letztes Jahr waren wir drei Wochen vor dem Start einer Zahlungsmigration. Mein Manager wollte auf Dual-Write-Rollback verzichten. Ich erstellte ein einseitiges Risikodokument mit drei konkreten Ausfallmodi, ging es in einem Einzelgespräch durch, und wir einigten uns darauf, das Dual-Write-Rollback hinzuzufügen, mit den Kosten, den Start um sechs Geschäftstage zu verschieben. Die Migration erfolgte ohne Zwischenfälle; wir nutzten die Dual-Write-Infrastruktur zweimal im nächsten Quartal, um unabhängige Fehler zurückzurollen. Ich lernte, dass die Uneinigkeit der einfache Teil war – das Risiko konkret genug zu machen, um darüber zu argumentieren, war die Arbeit." Vier Minuten, kein Polster, Folgezweige offensichtlich.
Plattformen, die Personalvermittler tatsächlich nutzen
Die Live-Coding-Sandbox ist konzentrierter als Kandidaten annehmen. Zwei Plattformen dominieren professionelle Software-Engineer-Interviews:
Coderpad ist die Live-Collaboration-Sandbox, die die meisten modernen Softwareunternehmen während des eigentlichen On-Site-Interviews nutzen. Sie unterstützt Run-as-you-type für viele Sprachen, ein integriertes Zeichenwerkzeug für System Design und liest sich sauber durch Screen Share. Wenn Sie nur auf LeetCode geübt haben, wird sich Ihre erste Coderpad-Runde langsamer anfühlen als erwartet. Üben Sie darauf, bevor Sie eine echte Interviewserie durchlaufen.
HackerRank ist das dominierende Screening der ersten Runde für große Unternehmen und führt sowohl asynchrone Take-Home-Tests als auch Live-Runden durch. Die Sprachabdeckung ist umfangreich; der Editor ist schwerfälliger als der von Coderpad; die Testfälle sind strenger bei der Eingabeanalyse. Unternehmen im Finanzbereich, in der Beratung und in der traditionellen Technologie verlassen sich immer noch stark darauf.
CodeSignal führt die General Coding Assessment durch, die mehrere große Arbeitgeber als einzige standardisierte Punktzahl nutzen. Die Aufgaben sind zeitgesteuert und vielfältig; Pacing ist die Hauptfähigkeit, die die Runde testet.
LeetCode ist das Trainingstool, nicht das Interview-Tool. Das größte Aufgabenkorpus der Industrie, das Nächste zu einer gemeinsamen Grundlage für Interview-Fragen und die Plattform, deren Editor der Erfahrung, die Sie letztendlich auf Coderpad haben werden, am nächsten kommt.
Eine Handvoll unternehmensabhängiger Tools sind ebenfalls wichtig. Amazon nutzt seinen eigenen Chime-Anruf kombiniert mit einem internen Coding Pad; Google nutzt eine interne Sandbox während On-Site-Interviews; Meta nutzt Coderpad. Die ehrliche Antwort ist, dass die Plattform, auf der Sie am besten zuhause sind, wichtiger ist als welche spezifische Plattform das Unternehmen nutzt, weil sie alle dieselben Grundlagen implementieren.
Wo eine Echtzeit-KI-Unterstützung hilft und wo nicht
Die ehrliche Antwort zur Echtzeit-KI-Unterstützung während Live-Software-Engineer-Runden ist, dass der Wert je nach Rundentyp stark variiert. Die Marketingmitteilung ist oft schamlos in dieser Hinsicht; die Wahrheit ist nuancierter.
| Feature | Telefon-Screening | Coding-Panel | System Design | Verhaltensbezogen |
|---|---|---|---|---|
| Realistische KI-Hilfsqualität | Mittel-hoch | Mittel | Hoch | Hoch |
| Latenzanforderung | Sub-200 ms | Sub-200 ms | Sub-300 ms akzeptabel | Sub-200 ms |
| Verborgenheitsanforderung | Streng — Screen Share verbreitet | Streng — IDE-Share konstant | Streng — Diagramm-Share verbreitet | Streng — Video von Angesicht zu Angesicht |
| Ethischer Komfort | Umstritten | Sehr umstritten | Weniger umstritten | Weniger umstritten |
| Empfohlener Nutzungsmodus | Denkhilfe | nicht empfohlen für wörtliche Übernahme | Denkhilfe | Skript für Story-Abruf |
Coding-Panels sind die am meisten umstrittenen und die Runde, in der der Assistent den geringsten reinen Wert hinzufügt, wenn Sie die Muster tatsächlich geübt haben. Der Assistent kann das Muster aus der Frage identifizieren und eine Anfangsstruktur skizzieren, aber die Eingabe der Lösung liegt immer noch bei Ihnen, und Personalvermittler bei Top-Unternehmen werden zunehmend geschult, um Kandidaten zu erkennen, deren Tipprhythmus nicht ihrer angegebenen Argumentation entspricht. System-Design-Runden sind das Gegenteil — hoher Kontext, langsameres Tempo, der Assistent kann den Trade-off-Baum im Arbeitsspeicher halten, während Sie sprechen, und der Gewinn ist erheblich. Verhaltensbezogene Runden sind, wo sich ein gut vorbereiteter Assistent am meisten auszahlt: Er ruft Ihre hinterlegten Geschichtsnarrative in Ihren eigenen Worten ab und bringt die relevante LP oder den Wert, den die Frage erforscht, an die Oberfläche.
Acedly während einer Live-SWE-Runde
Acedly ist eine Desktop-App, die speziell für Live-Interviews mit Softwareentwicklern konzipiert wurde, die von Menschen durchgeführt werden. Das Produkt läuft auf dem Computer des Kandidaten und liest das Audio des Anrufs sowie, wenn verfügbar, den Inhalt der Coding-Sandbox.
Die Plattformunterstützung umfasst acht auf OS-Ebene verifizierte Oberflächen: Zoom, Microsoft Teams, Google Meet, Webex, Lark, Amazon Chime, Coderpad und HackerRank. Alle acht werden regelmäßig gegen Window-Capture-Ausschluss (NSWindowSharingNone auf macOS, WDA_EXCLUDEFROMCAPTURE auf Windows) getestet; der Verifizierungsstatus wird live im Produkt veröffentlicht.
Die mediane End-to-End-Latenz vom Fragerende bis zum ersten Antwort-Token liegt auf Standard-Hardware bei etwa 98 ms – gemessen wie es sein sollte, vom Mikrofon zur Anzeige, nicht nur die First-Token-Latenz des Modells. Das liegt deutlich unter der 200-ms-Schwelle für menschliche Konversation; unter 250 ms fällt keine sichtbare Verzögerung des Assistenten auf.
Multi-Modell-Routing ist das operative Rückgrat. GPT bearbeitet Verhaltens- und Recruiter-Screening-Runden, bei denen Struktur und Kürze dominieren; Claude bearbeitet System-Design-Runden, bei denen es darauf ankommt, einen umfangreichen Kontext-Trade-off-Baum zu halten; DeepSeek bearbeitet Code-Runden, bei denen Reasoning unter enger Latenz bei algorithmischen Problemen die Hauptfähigkeit ist. Der Benutzer wählt nicht das Modell aus – der Assistent leitet basierend auf dem erkannten Fragetyp weiter.
Die Coding-Plattform-Integration ist das, was Acedly von generischem AI-Chat unterscheidet. Der Assistent liest den Editor auf Coderpad und HackerRank, parst die Problemstellung und stützt seine Antwort auf die Frage und das, was bereits auf dem Bildschirm zu sehen ist. Ein Copilot, der nur auf Audio hört, lässt wichtige Informationen während technischer Runden ungenutzt.
Eine Anmerkung zur Ethik. Acedly ist ein Denkwerkzeug. Es ist kein Ersatz für tatsächliche Vorbereitung, und die Kandidaten, die den meisten Nutzen daraus ziehen, sind diejenigen, die auch ohne ihn gut abschneiden würden – sie nutzen den Assistenten, um die kognitive Belastung während einer kritischen Runde zu bewältigen, nicht um Monate des Mustertrainings und Story-Bankings zu ersetzen, die die Runde tatsächlich belohnt. Ob ein Echtzeit-Assistent in einem bestimmten Interview verwendet wird, ist eine persönliche Entscheidung, und diese Entscheidung liegt beim Kandidaten. Das Produkt ist so gestaltet, dass die Offenbarung ganz bei Ihnen liegt.
Ein 4-Wochen-Plan zur Vorbereitung auf SWE-Interviews
Wenn Sie vier Wochen Zeit vor einem echten Interview-Loop haben, ist der untenstehende Plan eine sinnvolle Aufteilung. Das ist nicht die einzige Möglichkeit, aber die richtige Struktur — Muster zuerst, Systemdesign zweite, Verhaltensthemen dritte, unternehmmensspezifisch zum Schluss.
Woche 1 — Muster-Übung. Zwei Stunden pro Tag. Folgen Sie dem Acht-Muster-Übungs-Plan in unserem Leitfaden zur Vorbereitung auf Coding-Interviews — ein Muster pro Wochentag, sieben bis acht mittelschwere Aufgaben pro Muster auf LeetCode, eine einzeilige Nachbesprechung zu jeder. Das Ziel sind sechzig Aufgaben für die Woche, mit Fokus auf mittlerem Schwierigkeitsgrad. Bis Freitag sollten Sie in der Lage sein, eine Aufgabe zu lesen und das Muster bereits im ersten Satz zu erkennen.
Woche 2 — Systemdesign. Zwei Fälle pro Tag, jeden Wochentag. Nutzen Sie jedes Mal das Fünf-Komponenten-Gerüst. Schreiben Sie jeden Fall auf, als würden Sie ihn für Ihr zukünftiges Ich verfassen — funktionale Anforderungen, Constraints, Architekturdiagramm, ausführliche Notizen, Trade-Offs. Die ersten drei sind schwach; nach dem fünften fühlt sich die Struktur automatisch an. Decken Sie zehn Klassiker ab: URL Shortener, Twitter, WhatsApp, Uber, Dropbox, YouTube, Instagram, Rate Limiter, Distributed Cache, Notification Service.
Woche 3 — Verhaltensthemen und Mocks. Sammeln Sie acht bis zehn Narrative nach der STAR-Vorlage, drei bis vier Minuten lang, mit zwei Follow-up-Varianten pro Story. Ordnen Sie sie den Prinzipien Ihrer drei Top-Zielunternehmen zu. Führen Sie dann zwei bezahlte Mocks mit einem Kollegen oder einer Plattform wie interviewing.io durch — eine Code-fokussiert, eine Systemdesign-fokussiert. Nehmen Sie sich selbst auf; spielen Sie mit 1,5x ab; die Teile, bei denen Sie zusammenzucken, sollten Sie verbessern.
Woche 4 — Unternehmmensspezifisch. Verbringen Sie für jedes Unternehmen in Ihrem Loop einen halben Tag mit seinen spezifischen Besonderheiten. Amazon: Lesen Sie die sechzehn LPs erneut und ordnen Sie jede Story zwei LPs zu. Google: Üben Sie drei oder vier schwierige LeetCode-Fragen. Meta: Üben Sie das Tempo von zwei Fragen in fünfundvierzig Minuten. Stripe: Lesen Sie ihre API-Dokumentation und führen Sie ein kleines End-to-End-Projekt durch. Reservieren Sie die letzten achtundvierzig Stunden für Ruhe. In den letzten zwei Tagen zu viel zu machen hat negative Auswirkungen.
Passen Sie die Gewichte an Ihre Lücken an. Stark in Coding, aber schwach in Systemdesign? Vertauschen Sie Wochen eins und zwei. Seniorkandidat ohne aktuelle LeetCode-Übung? Verdoppeln Sie Woche eins. Konstant ist die Ruheperiode in Woche vier — jeder Kandidat unterschätzt, wie wichtig Schlaf in den letzten achtundvierzig Stunden eines echten Loops ist.