McKinsey Solve hat den papierbasierten PST in den meisten Büros um 2020 abgelöst. Es handelt sich um zwei spielerisch gestaltete Mini-Spiele – Ecosystem Building und Red Rock Study – die in etwa 60–81 Minuten absolviert werden, wobei ein Algorithmus Ihren Entscheidungsweg und das Click-Timing bewertet, nicht nur Ihre Endergebnisse. Rund 70 % der Kandidaten werden ausgeschieden. Die meisten scheitern nicht an mangelnder Analysefähigkeit, sondern daran, dass sie vermeidbare Fehler wiederholen: wahllos klicken, Einschränkungen übersehen, Ablenkungsdaten nachjagen und die Zeit für einen einzigen Schritt verschwenden. Dieser Leitfaden beschreibt die 10 Fallen und die jeweilige Lösung.
McKinsey Solve ist das digitale Assessment, das den papierbasierten Problem Solving Test (PST) in den meisten Büros um 2020 abgelöst hat. Es ist inzwischen der globale Standard, obwohl einige Büros möglicherweise noch den klassischen PST durchführen. Solve scheidet etwa 70 % der Kandidaten aus, bevor sie jemals ein Case-Interview erreichen – und das Überraschende daran ist, dass die meisten Ausscheidungen wenig mit reiner Problemlösungsfähigkeit zu tun haben.
Solve ist kein Multiple-Choice-Quiz. Es handelt sich um zwei gamifizierte Simulationen – typischerweise Ecosystem Building und Red Rock Study, wobei gelegentlich Sea Wolf oder Plant Defense erscheinen – die nacheinander in etwa 60 bis 81 Minuten absolviert werden. Entscheidend ist, dass ein Algorithmus bewertet, wie Sie arbeiten: Ihren Entscheidungsweg, die Reihenfolge Ihrer Aktionen und Ihre Klick- und Timing-Telemetrie – nicht nur den finalen Zustand, den Sie erreichen. Dieser eine Umstand verändert grundlegend, welche Fehler fatal sind.
Dieser Leitfaden katalogisiert die 10 häufigsten Solve-Fehler, gruppiert nach dem Zeitpunkt ihres Auftretens, mit einer konkreten Lösung für jeden einzelnen.
Die Solve-Fehlerübersicht
Anders als beim alten PST, bei dem fast die Hälfte aller Fehler einfache Datenfehllektüren waren, konzentrieren sich Solve-Misserfolge auf ein Missverständnis des Spiels selbst: was es belohnt, wie jedes Mini-Spiel funktioniert und wie die Zeit genutzt wird.
mindmap
root((Solve-Fehler))
Bewertungsmodell-Blindstellen
Antwort statt Prozess optimieren
Zufälliges Klicken zum Erkunden
Annehmen, dass ein sauberer Endzustand rettet
Ecosystem Building
Versuch und Irrtum vor dem Lesen der Regeln
Nahrungskette und Ressourcenlimits ignorieren
Einen Zug überoptimieren
Red Rock Study
Ablenkungsdaten nachjagen
Exhibits über Phasen hinweg falsch lesen
Zeit und Mindset
Den spielinternen Countdown verlieren
Nach einem schlechten Start in Panik geraten
Unbekannte Benutzeroberfläche unvorbereitet antreffen
Zu verstehen, woher Ihre Fehler kommen, ist der erste Schritt zu ihrer Beseitigung. Die meisten Kandidaten, die wir coachen, verbessern sich am schnellsten nicht dadurch, dass sie mehr Inhalte lernen, sondern dadurch, dass sie ihre Interaktion mit dem Spiel verändern.
Kategorie 1: Bewertungsmodell-Blindstellen
Dies sind die Fehler, die entstehen, weil man nicht versteht, dass Solve Ihren Prozess beobachtet. Sie sind die gefährlichsten, weil Sie ein „richtiges" Ergebnis erzielen und dennoch schlecht abschneiden können.
Fehler Nr. 1: Solve wie ein Bestehen/Nicht-Bestehen-Quiz behandeln
Der häufigste konzeptionelle Fehler ist die Annahme, Solve bewertet nur, ob Ihr finales Ökosystem überlebt oder Ihre endgültige Antwort richtig ist. Das tut es nicht. Der Algorithmus zeichnet Ihren Entscheidungsweg auf – welche Aktionen Sie durchgeführt haben, in welcher Reihenfolge und wie effizient Sie das Ergebnis erreicht haben. Zwei Kandidaten können ein stabiles Ökosystem aufbauen und sehr unterschiedliche Bewertungen erhalten, weil einer durch überlegte Schritte dorthin gelangte und der andere durch Chaos.
Lösung: Behandeln Sie jede Aktion als bewerteten Zug. Bevor Sie irgendetwas anfassen, formulieren Sie eine Hypothese: „Ich erwarte, dass diese Art passt, weil sie X erfüllt." Überlegte, geordnete Züge werden als kompetente Entscheidungsfindung gewertet. Hektische Aktivität, die zufällig funktioniert, wird als Glück gewertet.
Fehler Nr. 2: Zufälliges Klicken zum „Erkunden" der Benutzeroberfläche
Da die Benutzeroberfläche unbekannt ist, klicken Kandidaten häufig herum, um zu sehen, was passiert. Bei einem prozessbewerteten Assessment wird dies aufgezeichnet. Hohe Mengen ungerichteter Klicks, schnelle Rückgängig-Wiederholen-Schleifen und unregelmäßiges Timing signalisieren allesamt, dass Sie raten statt zu schlussfolgern – und Raten wird bestraft.
Lösung: Erkunden Sie die Benutzeroberfläche vor dem Testtag mit einer offiziellen Übungsversion oder einer originalgetreuen Simulation, nicht während der bewerteten Sitzung. Sobald die Uhr läuft, sollte jeder Klick einen Grund haben. Wenn Sie etwas überprüfen müssen, tun Sie es einmal, bewusst, und gehen Sie weiter.
Fehler Nr. 3: Annehmen, dass ein sauberer Endzustand einen chaotischen Weg auslöscht
Manche Kandidaten verbringen die ersten zwei Drittel eines Spiels mit Herumprobieren, räumen dann alles auf und gehen davon aus, dass der finale Screenshot zählt. Die Telemetrie hat das Herumprobieren bereits erfasst. Ein sauberes Ende überschreibt keine chaotische Mitte.
Lösung: Sorgen Sie dafür, dass der Weg vom ersten Zug an stimmt, nicht erst vom letzten. Wenn Sie früh merken, dass Ihr Ansatz falsch ist, korrigieren Sie ihn mit einem klaren, begründeten Schwenk – einer sichtbaren Entscheidung – anstatt einer langen Reihe kleiner Versuch-und-Irrtum-Anpassungen.
Kategorie 2: Ecosystem-Building-Fehler
Beim Ecosystem Building werden Sie aufgefordert, ein funktionsfähiges Ökosystem für einen bestimmten Standort zusammenzustellen, indem Sie Arten auswählen, die eine Reihe von Einschränkungen erfüllen – darunter Nahrungskettenbeziehungen, Ressourcenlimits und Geländeeignung. Die meisten Fehler entstehen hier durch Handeln vor dem Verstehen.
Fehler Nr. 4: Versuch und Irrtum beginnen, bevor die Einschränkungen gelesen wurden
Die größte Falle beim Ecosystem Building ist, Arten zuerst zu platzieren und dann zu prüfen, ob sie funktionieren. Die Einschränkungen – was jede Art frisst, wie viel einer Ressource sie benötigt und wo sie leben kann – werden Ihnen vor dem Aufbau mitgeteilt. Kandidaten, die sie ignorieren und durch Raten iterieren, verbrauchen Züge, erzeugen unübersichtliche Telemetrie und schaffen es oft trotzdem nicht, ein stabiles System aufzubauen.
Lösung: Verbringen Sie die ersten Minuten damit, die Einschränkungen zu lesen und zu kartieren, bevor Sie irgendetwas platzieren. Skizzieren Sie die Nahrungskette und die Ressourcenlimits auf Konzeptpapier. Wenn Sie schließlich bauen, führen Sie einen Plan aus, anstatt nach einem zu suchen.
Fehler Nr. 5: Nahrungsketten- und Ressourcenlimits ignorieren
Selbst Kandidaten, die die Regeln lesen, wählen manchmal Arten aus, die einzeln attraktiv wirken, aber das Gleichgewicht des Systems verletzen – ein Raubtier ohne geeignete Beute oder eine Gruppe von Arten, die gemeinsam die verfügbaren Ressourcen überschreitet. Das Ökosystem kollabiert dann, und sowohl der Kollaps als auch der Weg, der ihn verursacht hat, werden bewertet.
Lösung: Validieren Sie jede Auswahl gegen das Gesamtsystem, nicht isoliert. Bestätigen Sie für jede Art drei Dinge: Sie hat eine Nahrungsquelle innerhalb Ihrer Auswahl, sie passt zum Gelände, und ihre Hinzufügung hält den gesamten Ressourcenbedarf innerhalb des Limits. Wenn eines der drei nicht zutrifft, gehört sie nicht dazu.
Fehler Nr. 6: Einen Zug überoptimieren und die Zeit verlieren
Perfektionisten geraten in die Falle, eine einzelne Entscheidung feinzujustieren – eine Art wiederholt auszutauschen, um eine geringfügig bessere Passung zu erzielen – und laufen aus der Zeit, bevor das gesamte Ökosystem vollständig ist. Ein unvollständiges System wird schlechter bewertet als ein vollständiges, vernünftiges.
Lösung: Streben Sie zunächst nach einer vollständigen, vertretbaren Lösung und verfeinern Sie nur, wenn noch Zeit bleibt. Setzen Sie sich einen groben internen Kontrollpunkt: Wenn Sie nach ein paar Minuten noch an derselben Entscheidung arbeiten, treffen Sie Ihre beste Wahl und gehen Sie weiter. Ein fertiges Ökosystem, das Sie begründen können, schlägt ein halb aufgebautes „perfektes".
Kategorie 3: Red-Rock-Study-Fehler
Red Rock Study präsentiert ein mehrphasiges Forschungsszenario, das auf der Interpretation von Daten und dem Ziehen von Schlussfolgerungen über mehrere Phasen hinweg aufgebaut ist. Die Fallen hier spiegeln klassische Case-Interview-Datenfehler wider, aber das Informationsvolumen und das zeitlich begrenzte Format verstärken sie.
Fehler Nr. 7: Ablenkungsdaten nachjagen
Red Rock enthält absichtlich Informationen, die relevant erscheinen, aber keinen Einfluss auf die anstehende Entscheidung haben. Kandidaten, die versuchen, jeden gezeigten Datenpunkt zu verwenden, verschwenden Zeit und bauen ihre Argumentation oft auf Rauschen auf. Ablenkungsdaten zu identifizieren und beiseitezulegen ist Teil dessen, was das Spiel misst.
Lösung: Definieren Sie vor der Analyse die spezifische Frage, die jede Phase stellt. Ziehen Sie dann nur die Daten heran, die diese Frage voranbringen. Wenn ein Diagramm oder eine Zahl Ihre Antwort nicht verändert, notieren Sie es und lassen Sie es – zwingen Sie es nicht in Ihre Argumentation.
Fehler Nr. 8: Exhibits über Phasen hinweg falsch lesen
Da Informationen über Phasen und Bildschirme verteilt sind, verlieren Kandidaten den Überblick, welche Zahl woher stammt, oder übertragen eine Annahme aus einer frühen Phase in eine spätere, wo sie nicht mehr gilt. Unter Zeitdruck kann eine einzige falsch zugeordnete Zahl zu einer falschen Schlussfolgerung führen.
Lösung: Führen Sie während des Fortschritts eine kurze laufende Notiz der wichtigsten Zahlen und ihrer Herkunft. Wenn eine neue Phase das Szenario neu rahmt, prüfen Sie, ob Ihre früheren Annahmen noch zutreffen, bevor Sie sie wiederverwenden.
Kategorie 4: Zeit- und Mindset-Fehler
Die letzte Kategorie befasst sich mit der Verwaltung der beiden Spiele als Ganzes – der Uhr und Ihrem Kopf.
Fehler Nr. 9: Den spielinternen Countdown verlieren
Bei etwa 60–81 Minuten, die auf zwei Mini-Spiele aufgeteilt sind, ist Zeitdisziplin alles. Kandidaten, die das erste Spiel zu lange laufen lassen – weil es sich vertrauter anfühlt oder weil sie ein perfektes Ergebnis anstreben – kommen mit zu wenig Zeit beim zweiten Spiel an und schneiden bei beiden schlecht ab.
Lösung: Planen Sie die Zeit ein, bevor Sie beginnen, und werfen Sie an festen Kontrollpunkten einen Blick darauf. Behandeln Sie das Zeitkontingent jedes Spiels als harte Grenze. Beide Spiele mit überlegter, vollständiger Arbeit abzuschließen schlägt es, eines perfekt zu meistern und das andere aufzugeben. Unser Solve-Zeitmanagement-Leitfaden schlüsselt diese Planung Schritt für Schritt auf.
Fehler Nr. 10: Nach einem schlechten Start in Panik geraten (bei einer unbekannten Benutzeroberfläche)
Viele Kandidaten begegnen der Benutzeroberfläche zum ersten Mal während der bewerteten Sitzung, erleiden einen frühen Rückschlag und geraten in eine Abwärtsspirale – sie klicken schneller, geben ihren Plan auf und erzeugen genau die unregelmäßige Telemetrie, die der Algorithmus bestraft. Der schlechte Start ist selten für sich allein fatal; die Panikreaktion ist es.
Lösung: Üben Sie mit dem tatsächlichen Spielformat, bis die Benutzeroberfläche langweilig ist. Vertrautheit beseitigt die Überraschung, die Panik auslöst. Wenn während des Spiels etwas schiefläuft, halten Sie fünf Sekunden inne, kehren Sie zu Ihrem Plan zurück und führen Sie Ihren nächsten Zug bewusst aus. Erholung ist ebenfalls ein bewertetes Verhalten, und ein ruhiger, überlegter Schwenk wird weit besser bewertet als ein hektisches Herumprobieren.
Das Solve-Entscheidungs-Framework
Verbinden Sie Bewusstsein mit einer einfachen spielinternen Routine, die Ihren Prozess sauber und bewertbar hält:```mermaid flowchart TD A[“Neues Spiel oder neue Phase”] –> B[“Zuerst Einschränkungen und Frage lesen”] B –> C[“Plan skizzieren: Nahrungskette / Schlüsseldaten”] C –> D{“Bereit zum Handeln?”} D –>|Ja| E[“Einen bewussten, begründeten Zug machen”] D –>|Nein| B E –> F{“Funktioniert wie erwartet?”} F –>|Ja| G[“Mit dem nächsten Zug fortfahren”] F –>|Nein| H[“Ein klarer Kurswechsel, kein Trial-and-Error”] H –> G G –> I{“Vollständig und Zeit verbleibend?”} I –>|Vollständig| J[“Verfeinern, wenn die Zeit es erlaubt”] I –>|“Wenig Zeit”| K[“Besten vertretbaren Stand sichern, weitermachen”]
## Ihr 5-Tage-Übungsprogramm zur Fehlerbehebung
Wenn Ihre Solve-Sitzung näher rückt, zielt dieses fokussierte Programm darauf ab, wie Sie mit den Spielen interagieren – und nicht auf reinen Inhalt:
| Tag | Schwerpunkt | Aktivität |
|-----|-------------|-----------|
| 1 | Benutzeroberfläche | Führen Sie einmal eine originalgetreue Solve-Simulation durch. Ziel: alle Überraschungen durch die Benutzeroberfläche beseitigen |
| 2 | Ökosystem | Üben Sie, Einschränkungen zu lesen und die Nahrungskette zu kartieren, *bevor* Sie beginnen zu bauen. Kein Trial-and-Error |
| 3 | Red Rock | Üben Sie ein Datenszenario. Schreiben Sie für jede Phase zuerst die Frage, und markieren Sie dann Ablenkungsdaten |
| 4 | Zeit und Prozess | Führen Sie beide Spiele unter strikter Zeitvorgabe durch. Verfolgen Sie Ihre Klickmuster – streben Sie nach Bedachtheit, nicht nach Hektik |
| 5 | Vollständige Simulation | Absolvieren Sie eine zeitgesteuerte Sitzung unter Prüfungsbedingungen. Überprüfen Sie, wo Ihr Vorgehen unübersichtlich wurde und warum |
Das Ziel ist nicht, Antworten auswendig zu lernen – die Szenarien variieren –, sondern Ihren *Prozess* unter Zeitdruck ruhig, geordnet und vollständig zu gestalten.
## Wichtigste Erkenntnisse
- Solve wird prozessbasiert bewertet: Der Algorithmus liest Ihren Entscheidungsweg und das Klick-Timing – zufälliges Klicken und ein ordentlicher Abschlussbildschirm retten Sie nicht
- Ecosystem Building belohnt das Lesen der Einschränkungen und das Kartieren der Nahrungskette, bevor Sie eine einzige Spezies platzieren
- Red Rock Study enthält absichtlich Ablenkungsdaten – definieren Sie die Frage jeder Phase und ziehen Sie nur das heran, was sie beantwortet
- Die Zeitvorgabe pro Spiel ist eine harte Grenze; eine vollständige, vernünftige Lösung für beide Spiele schlägt eine perfekte Lösung für eines und eine abgebrochene für das andere
- Die meisten Panikspiralen lassen sich darauf zurückführen, dass man die Benutzeroberfläche unvorbereitet antrifft – üben Sie im echten Format, bis es langweilig wird
- Ein 5-tägiges Programm mit Fokus auf Interaktionsgewohnheiten schlägt wochenlange unstrukturierte Übung
## Wie es weitergeht
Beginnen Sie mit dem Format selbst. Wenn Sie unsicher sind, ob Ihr Büro Solve oder den älteren PST verwendet, lesen Sie unseren [vollständigen McKinsey-Solve-Vorbereitungsleitfaden](/en/guides/mckinsey-pst-solve-preparation/) für die büroweise Übersicht und die vollständige Spielbeschreibung.
Um die Zeitfehler gezielt zu beheben, arbeiten Sie unseren [McKinsey-Solve-Zeitmanagement-Leitfaden](/en/guides/mckinsey-pst-time-management/) durch und legen Sie Ihr Budget pro Spiel vor dem Testtag fest.
Wenn der ältere PST für Sie noch relevant ist, behandelt unser [McKinsey-Problem-Solving-Test-Strategieleitfaden](/en/guides/mckinsey-problem-solving-test-strategy/) die Multiple-Choice-Fragetypen und das Tempo.
CasesCoach AI Mock Interview und sein Feedback machen genau diese Fehler sichtbar – die zufälligen Klicks, die übersehenen Einschränkungen, die Zeitüberschreitungen – *vor* dem Testtag, wenn Sie sie noch beheben können. Der kostenlose Plan umfasst 3 Übungsfälle plus AI Mock; Pro schaltet 835+ Fälle und mehrere AI-Mock-Sitzungen frei, damit Sie den Prozess so lange üben können, bis er zur zweiten Natur wird. Probieren Sie das [AI Mock Interview](/account?tab=mock&lang=en) aus oder vergleichen Sie die Optionen auf der [Preisseite](/pricing/).