McKinsey Solve Strategy: Winning Ecosystem Building & Red Rock Study

For years the McKinsey Problem Solving Test (PST) was a 26-question written exam you could beat by drilling question types. That test is retired. Since around 2020, McKinsey screens candidates with Solve, a digital, game-based assessment that is now the global default (a few offices may still run the legacy PST). Solve has no multiple-choice question types, so a “strategy by question type” no longer exists. What matters now is how you play the two modules that make up almost every session — and how the scoring engine reads the way you play them.

What Solve Is, and How It Scores

A Solve session is two mini-games completed in roughly 60–81 minutes. The two you are most likely to see are Ecosystem Building and Red Rock Study. Some candidates get variants such as Sea Wolf or Plant Defense, but the core pairing dominates, and the reasoning skills transfer across all of them.

The single most important thing to understand is how Solve scores you. It is algorithmic and process-based. The engine captures your decision path — the sequence of choices you make — along with click and timing telemetry. It is not a simple “count the right answers” exam. Two candidates can reach a similar end state and score very differently because one showed a clean, deliberate reasoning path and the other flailed. This has three direct consequences:

• Guessing is penalized. Random clicking to fill in an answer, which was harmless on the old PST, works against you here. The engine can distinguish a reasoned choice from a blind one.
• Your process is the product. How you gather information, in what order, and how consistently you act on it all feed the score.
• The cut is steep. Roughly 70% of candidates are eliminated at this stage, so a merely “finished” session is not enough — the path has to be coherent.

Solve sits between resume screening and first-round case interviews. Both stages reward the same underlying skills: structured thinking, data interpretation, and disciplined decision-making under time pressure.

flowchart LR
    A[Resume Screen] --> B[Solve Assessment]
    B --> C{Pass?}
    C -->|~30%| D[Case Interview Round 1]
    C -->|~70%| E[Rejected]
    D --> F[Case Interview Round 2]
    F --> G[Final Decision]

Parameter	Detail
Format	Digital, game-based (replaces the written PST)
Structure	2 mini-games per session
Core modules	Ecosystem Building + Red Rock Study
Duration	~60–81 minutes total
Scoring	Algorithmic / process-based (decision path + timing telemetry)
Guessing	Penalized — reasoned choices only
Elimination rate	~70% of candidates

For a full overview of the assessment and how to prepare across formats, start with our McKinsey Solve preparation hub.

The Two Modules at a Glance

Each module tests a different mode of reasoning. Ecosystem Building is a constrained-optimization and systems-thinking task: you assemble a working system under hard rules. Red Rock Study is a hypothesis-driven data investigation: you navigate a multi-phase case, pull the right numbers, and defend accurate answers under the clock. Preparing for Solve means practicing both modes deliberately, because they reward almost opposite instincts — patient rule-mapping in one, decisive data triage in the other.

flowchart TD
    A[Solve Session] --> B[Ecosystem Building]
    A --> C[Red Rock Study]
    B --> B1[Read the rules & constraints]
    B --> B2[Select species / build the food chain]
    B --> B3[Satisfy calories, chain length, terrain]
    C --> C1[Navigate the case phases]
    C --> C2[Extract the right data]
    C --> C3[Analyze & answer accurately]

Module 1 — Ecosystem Building

You are given an environment (for example, a reef, a mountain, or another terrain) and asked to build a self-sustaining food chain by choosing a set of species that survive together under the rules. It looks like a nature game; it is really a constrained-optimization problem. Success is not about picking the “coolest” animals — it is about choosing a combination that simultaneously satisfies every constraint the puzzle imposes.

How to approach it, phase by phase:

1. Read the rules before you touch anything. Ecosystem Building punishes candidates who start placing species before they understand the constraints. Typical constraints include a calorie requirement (each species needs enough energy from what it eats), a food-chain length (the chain must reach a required number of levels), and terrain/depth rules (a species can only live where its conditions are met). Write these down or hold them explicitly before selecting anything.

2. Work backward from the constraints, not forward from the species. Instead of asking “do I like this animal,” ask “which combination of species can satisfy all rules at once.” Treat it as a system: every producer must feed a consumer, every consumer must have enough calories, and the whole chain has to reach the required length within the terrain’s limits. This systems view is the skill McKinsey is actually measuring.

3. Check each species against the calorie and terrain conditions individually, then as a set. A choice that works in isolation can break the system — for example, a predator whose only food source doesn’t produce enough calories, or a species that can’t survive at the chosen depth. Validate both the individual fit and the whole-chain fit.

4. Avoid dead-ends by building in slack. The most common failure is committing to species early, then discovering late that no combination completes the chain, with no time to rebuild. Sketch a viable full chain in your head before locking in choices, and prefer species that keep more options open.

5. Manage the clock as a hard constraint of its own. The rule-reading and validation are time-intensive, so budget time for them deliberately and leave a buffer to correct a chain that isn’t balancing. Do not let a single stubborn slot consume the entire window.

The mindset that wins Ecosystem Building is the same disciplined, constraint-first structuring you use to scope a case: define the rules of the game, then engineer a solution that satisfies all of them at once rather than optimizing one variable and hoping the rest fall into place.

Module 2 — Red Rock Study

Red Rock Study is a multi-phase data investigation. You move through a case in stages, and at each stage you decide what information to gather, interpret exhibits, run the analysis, and commit to answers — all under time pressure. This is the closest module to a classic case interview, and it rewards hypothesis-driven analysis: forming a view early, then testing it against the data rather than reading everything indiscriminately.

How to approach it, phase by phase:

1. Navigate with intent. Early phases ask you to gather data or explore the scenario. Do not open everything at random. Form a hypothesis about what the case is really asking, and let it guide which pieces of information you pull first. Because scoring reads your decision path, a targeted investigation reads better than a scattershot one.

2. Extract the right data, not all the data. Each exhibit contains more than you need. Before you dig into a chart or table, know the specific question you are answering — a trend, a comparison, a driver — and pull exactly that. This mirrors the “read the question before the exhibit” discipline that makes analytical work fast and accurate; our PST/Solve data interpretation guide drills this skill in depth.

3. Analyze with a framework, not intuition. When a metric moves, decompose it before you conclude. If profit changed, separate revenue and cost; if revenue changed, separate price and volume. This is the same profitability logic used in case interviews, and it keeps your reasoning path clean and defensible — exactly what the scoring engine rewards.

4. Answer accurately, and only what the data proves. The trap is confusing “plausible” with “supported.” Commit to the conclusion the numbers actually establish, not the one that feels right. If a claim needs an assumption the data doesn’t provide, it isn’t proven — treat these decisions like logic checks.

5. Pace yourself across phases. Because Red Rock is multi-phase, running out of time in an early phase starves the later ones. Set an internal budget per phase, make the confident calls quickly, and don’t over-invest in a single ambiguous exhibit at the expense of the rest of the case.

Red Rock rewards the candidate who investigates like a consultant: hypothesis first, targeted data second, structured analysis third, and a conclusion that is fully backed by evidence. For a deeper treatment of the data-reading mechanics specifically, see the data interpretation deep-dive.

Managing the Clock Across Both Modules

With two modules in roughly 60–81 minutes, time is a shared resource — and because guessing is penalized, “just fill something in at the end” is no longer a valid safety net. Treat pacing as part of the scored process:

flowchart TD
    A[Enter a module] --> B[Read rules / frame the case first]
    B --> C{Time-intensive decision?}
    C -->|Yes| D[Budget time, build a buffer]
    C -->|No| E[Make the confident call, move on]
    D --> F{Path still coherent?}
    E --> F
    F -->|Yes| G[Proceed to next phase]
    F -->|No| H[Correct now, before locking in]

• Front-load understanding. Both modules reward time spent up front — mapping constraints in Ecosystem Building, framing the case in Red Rock. Rushing the setup is the most expensive mistake.
• Protect a correction buffer. Leave room to rebalance a food chain or revisit an analysis. A coherent path that you fixed beats a broken path you ran out of time to repair.
• Never fill answers blindly. Since the engine reads reasoned choices, a deliberate but incomplete decision is better than a random one. Detailed pacing tactics live in our PST/Solve time management guide.

A Preparation Plan for Solve

You cannot cram Solve by memorizing answers — the modules are procedurally varied and the scoring reads process. Build the two reasoning modes instead.

Days	Focus Area	Daily Practice
1–2	Orientation	Read the Solve prep hub. Understand both modules and that scoring is process-based. Try one practice run of each module.
3–4	Ecosystem Building — constraints	Practice constrained-optimization puzzles. Drill reading rules first, working backward from constraints, and validating a full chain before committing.
5–6	Red Rock Study — data	Practice hypothesis-driven exhibit reading. Decompose metrics before concluding; distinguish “proven” from “plausible.” Use the data interpretation guide.
7	Speed & telemetry	Run both modules under a strict clock. Focus on a clean, deliberate decision path — no blind clicking.
8–9	Full simulation	Complete a timed two-module session. Review not just outcomes but the order and reasoning of your decisions.
10	Light review + rest	Consolidate the two mindsets. Rest before assessment day.

Supplement with 10 minutes of mental math daily — percentages, division shortcuts, and estimation — since Red Rock analysis moves faster when the arithmetic is automatic. Reinforce it with our mental math guide.

How Solve Skills Transfer to Case Interviews

Solve is not an isolated hurdle. Each module builds a skill you will use in McKinsey case interviews:

Solve Module	Case Interview Application
Ecosystem Building — constraint mapping	Scoping a case and structuring an issue tree under real limits
Ecosystem Building — systems thinking	Seeing how levers interact in operations and strategy cases
Red Rock — targeted data extraction	Interpreting exhibits in interviewer-led cases
Red Rock — metric decomposition	Structuring profitability and market sizing analysis
Red Rock — evidence-based conclusions	Delivering a recommendation the data actually supports

Candidates who treat Solve as the first phase of case preparation — rather than a separate test to survive — consistently perform better in the interview rounds that follow.

Assessment Day Checklist

• Read every rule or case frame in full before taking any action — setup time is scored process, not wasted time
• In Ecosystem Building, work backward from constraints (calories, chain length, terrain); validate the whole chain before locking choices
• In Red Rock, form a hypothesis first, then pull only the data that tests it
• Decompose any metric that moves before concluding; demand evidence, not plausibility
• Budget time per module and per phase; protect a buffer to correct a broken path
• Never click blindly to fill an answer — guessing is penalized and your decision path is read
• Keep the reasoning path coherent from start to finish; the engine scores how you got there

Key Takeaways

• The written PST is retired; Solve is McKinsey’s global default digital assessment (a few offices may still run PST)
• A session is two mini-games in ~60–81 minutes, most often Ecosystem Building and Red Rock Study
• Scoring is algorithmic and process-based — it reads your decision path and timing, so guessing is penalized and ~70% of candidates are cut
• Ecosystem Building is constrained optimization: read the rules, work backward from constraints, validate the full chain, avoid dead-ends
• Red Rock Study is hypothesis-driven data investigation: navigate with intent, extract the right data, decompose metrics, answer only what is proven
• These skills transfer directly to case interviews, making Solve preparation doubly valuable

Start Practicing Now

The two modules reward the same thing case interviews do: structured, hypothesis-driven reasoning under time pressure. CasesCoach AI practice builds exactly that muscle — you work real cases, get pushed to justify each step, and learn to keep a clean decision path when the clock is running. Start with McKinsey-style cases and hypothesis-driven problem solving, then put it under pressure with our AI Mock Interview. A free account includes 3 practice cases plus AI Mock; Pro unlocks 835+ cases and multiple AI Mock sessions so you can rehearse the reasoning both Solve modules demand.