McKinsey Solve Common Mistakes: Traps That Eliminate Candidates

McKinsey Solve is the digital assessment that replaced the paper Problem Solving Test (PST) at most offices around 2020. It is now the global default, though a few offices may still run the classic PST. Solve eliminates roughly 70% of candidates before they ever reach a case interview — and the surprising part is that most eliminations have little to do with raw problem-solving ability.

Solve is not a multiple-choice quiz. It is a set of two gamified simulations — typically Ecosystem Building and Red Rock Study, with Sea Wolf or Plant Defense appearing occasionally — run back-to-back in roughly 60 to 81 minutes. Critically, an algorithm scores how you work: your decision path, the order of your actions, and your click-and-timing telemetry, not merely the final state you land on. That single fact reshapes which mistakes are fatal.

This guide catalogs the 10 most common Solve mistakes, grouped by where they happen, with a concrete fix for each.

The Solve Error Landscape

Unlike the old PST, where nearly half of all errors were simple data misreads, Solve failures cluster around a misunderstanding of the game itself: what it rewards, how each mini-game works, and how the clock is spent.

mindmap
  root((Solve Errors))
    Scoring-Model Blind Spots
      Optimizing answer not process
      Random clicking to explore
      Assuming clean final state saves you
    Ecosystem Building
      Trial-and-error before reading constraints
      Ignoring food-chain and resource limits
      Over-optimizing one move
    Red Rock Study
      Chasing distractor data
      Misreading exhibits across phases
    Time and Mindset
      Losing the per-game clock
      Panicking after a bad start
      Facing an unfamiliar interface cold

Understanding where your errors come from is the first step to eliminating them. Most candidates we coach improve fastest not by learning more content, but by changing how they interact with the game.

Category 1: Scoring-Model Blind Spots

These are the mistakes that come from not understanding that Solve watches your process. They are the most dangerous because you can produce a “correct” outcome and still score poorly.

Mistake #1: Treating Solve Like a Pass/Fail Quiz

The most common conceptual error is assuming Solve grades only whether your final ecosystem survives or your final answer is right. It does not. The algorithm records your decision path — which actions you took, in what order, and how efficiently you reached the outcome. Two candidates can build a stable ecosystem and receive very different scores because one arrived through reasoned steps and the other through churn.

Fix: Treat every action as a scored move. Before you touch anything, form a hypothesis: “I expect this species to fit because it satisfies X.” Deliberate, ordered moves read as competent decision-making. Frantic activity that happens to work reads as luck.

Mistake #2: Random Clicking to “Explore” the Interface

Because the interface is unfamiliar, candidates often click around to see what happens. On a process-scored assessment, this is recorded. High volumes of undirected clicks, rapid undo-redo loops, and erratic timing all signal that you are guessing rather than reasoning — and guessing is penalized.

Fix: Explore the interface before test day with an official practice version or a faithful simulation, not during the scored session. Once the clock starts, every click should have a reason. If you need to check something, check it once, deliberately, and move on.

Mistake #3: Assuming a Clean Final State Erases a Messy Path

Some candidates spend the first two-thirds of a game thrashing, then tidy everything up at the end and assume the final screenshot is what counts. The telemetry already captured the thrashing. A clean ending does not overwrite a chaotic middle.

Fix: Get the path right from the first move, not the last. If you realize early that your approach is wrong, correct it with a clear, reasoned pivot — one visible decision — rather than a long series of small trial-and-error adjustments.

Category 2: Ecosystem Building Mistakes

Ecosystem Building asks you to assemble a viable ecosystem for a given location by selecting species that satisfy a set of constraints — food-chain relationships, resource limits, and terrain suitability among them. Most mistakes here come from acting before understanding.

Mistake #4: Diving Into Trial-and-Error Before Reading the Constraints

The single biggest Ecosystem trap is placing species first and checking whether they work second. The constraints — what each species eats, how much of a resource it needs, and where it can live — are given to you before you build. Candidates who ignore them and iterate by guesswork burn moves, generate noisy telemetry, and often still fail to build a stable system.

Fix: Spend the first few minutes reading and mapping the constraints before placing anything. Sketch the food chain and the resource limits on scratch paper. When you finally build, you are executing a plan, not searching for one.

Mistake #5: Ignoring Food-Chain and Resource Limits

Even candidates who read the rules sometimes select species that look appealing individually but violate the system’s balance — a predator with no viable prey, or a set of species that collectively exceeds the available resources. The ecosystem then collapses, and the collapse plus the path that caused it are both scored.

Fix: Validate every selection against the whole system, not in isolation. For each species, confirm three things: it has a food source within your set, it fits the terrain, and adding it keeps total resource demand within the limit. If any of the three fails, it does not belong.

Mistake #6: Over-Optimizing One Move and Running Out of Clock

Perfectionists get trapped fine-tuning a single decision — swapping one species in and out repeatedly to chase a marginally better fit — and run out of time before the whole ecosystem is complete. An incomplete system scores worse than a complete, reasonable one.

Fix: Aim for a complete, defensible solution first, then refine only if time remains. Set a rough internal checkpoint: if you are still on the same decision after a couple of minutes, lock in your best choice and move forward. A finished ecosystem you can justify beats a half-built “perfect” one.

Category 3: Red Rock Study Mistakes

Red Rock Study presents a multi-phase research scenario built around interpreting data and drawing conclusions across several stages. The traps here echo classic case-interview data errors, but the volume of information and the timed format amplify them.

Mistake #7: Chasing Distractor Data

Red Rock deliberately includes information that looks relevant but does not bear on the decision at hand. Candidates who try to use every data point they are shown waste time and often build reasoning on noise. Learning to identify and set aside distractor data is part of what the game measures.

Fix: Before analyzing, define the specific question each phase is asking. Then pull only the data that moves that question forward. If a chart or figure does not change your answer, note it and leave it — do not force it into your reasoning.

Mistake #8: Misreading Exhibits Across Phases

Because information is spread across phases and screens, candidates lose track of which figure came from where, or carry an assumption from an early phase into a later one where it no longer holds. Under time pressure, a single misattributed number can cascade into a wrong conclusion.

Fix: Keep a short running note of the key figures and where each came from as you progress. When a new phase reframes the scenario, re-check whether your earlier assumptions still apply before reusing them.

Category 4: Time and Mindset Mistakes

The final category is about managing the two games as a whole — the clock and your head.

Mistake #9: Losing the Per-Game Clock

With roughly 60–81 minutes split across two mini-games, time discipline is everything. Candidates who let the first game run long — because it feels more comfortable or because they are chasing a perfect result — arrive at the second game with too little time and score poorly on both.

Fix: Budget the clock before you start and glance at it at fixed checkpoints. Treat each game’s time allotment as a hard boundary. Finishing both games with reasoned, complete work beats acing one and abandoning the other. Our Solve time management guide breaks this budgeting down step by step.

Mistake #10: Panicking After a Bad Start (on an Unfamiliar Interface)

Many candidates meet the interface for the first time during the scored session, hit an early setback, and spiral — clicking faster, abandoning their plan, and generating exactly the erratic telemetry the algorithm penalizes. The bad start is rarely fatal on its own; the panic response is.

Fix: Practice on the actual game format until the interface is boring. Familiarity removes the surprise that triggers panic. If something does go wrong mid-game, pause for five seconds, return to your plan, and make your next move deliberately. Recovery is a scored behavior too, and a calm, reasoned pivot reads far better than a scramble.

The Solve Decision Framework

Combine awareness with a simple in-game routine that keeps your process clean and scorable:

flowchart TD
    A[New game or phase] --> B[Read constraints and the question first]
    B --> C[Sketch the plan: food chain / key data]
    C --> D{Ready to act?}
    D -->|Yes| E[Make one deliberate, reasoned move]
    D -->|No| B
    E --> F{Working as expected?}
    F -->|Yes| G[Continue to next move]
    F -->|No| H[One clear pivot, not trial-and-error]
    H --> G
    G --> I{Complete and time remaining?}
    I -->|Complete| J[Refine only if clock allows]
    I -->|Time short| K[Lock in best defensible state, move on]

Your 5-Day Solve Error Drill

If your Solve session is approaching, this focused drill targets how you interact with the games rather than pure content:

Day	Focus	Activity
1	Interface	Run through a faithful Solve simulation once. Goal: remove all surprise from the interface
2	Ecosystem	Practice reading constraints and mapping the food chain before building. No trial-and-error
3	Red Rock	Practice a data scenario. For each phase, write the question first, then flag distractor data
4	Time and process	Run both games under a strict clock. Track your click patterns — aim for deliberate, not frantic
5	Full simulation	Complete a timed session under exam conditions. Review where your path got messy and why

The goal is not to memorize answers — the scenarios vary — but to make your process calm, ordered, and complete under time pressure.

Key Takeaways

• Solve is process-scored: the algorithm reads your decision path and click-timing, so random clicking and a tidy final screen do not save you
• Ecosystem Building rewards reading constraints and mapping the food chain before you place a single species
• Red Rock Study includes distractor data on purpose — define each phase’s question, then pull only what answers it
• The per-game clock is a hard boundary; a complete, reasonable solution to both games beats a perfect one and an abandoned one
• Most panic spirals trace back to meeting the interface cold — practice on the real format until it is boring
• A 5-day drill focused on interaction habits beats weeks of unfocused practice

What’s Next

Start with the format itself. If you are unsure whether your office runs Solve or the legacy PST, read our complete McKinsey Solve preparation guide for the office-by-office picture and the full game breakdown.

To fix the clock mistakes specifically, work through our McKinsey Solve time management guide and build your per-game budget before test day.

If a legacy PST is still on your table, our McKinsey problem solving test strategy guide covers the multiple-choice question types and pacing.

CasesCoach AI Mock Interview and its feedback surface these exact mistakes — the random clicks, the missed constraints, the clock overruns — before test day, when you can still fix them. The free plan includes 3 practice cases plus AI Mock; Pro unlocks 835+ cases and multiple AI Mock sessions so you can rehearse the process until it is second nature. Try the AI Mock Interview or compare options on the pricing page.