McKinsey Solve: What the Game Actually Scores

McKinsey Solve, built originally with Imbellus and now run in house, screens a large share of candidates before anyone reads a CV. Most preparation for it is guesswork, and the guesswork usually focuses on the wrong half.

Solve assesses you on two independent tracks. Knowing which is which changes what you should practise.

The two scores

Track	What it captures	How to improve it
Product	Whether your final submission was correct	Understand the rules precisely, verify constraints before submitting
Process	How you got there	Gather relevant data before acting, avoid random clicking, revise deliberately when evidence changes

Product score is the obvious one. Process score is the one candidates neglect, and it is genuinely measured: the interface records the sequence of what you inspected, what you selected, and what you changed your mind about.

That has a practical consequence. Two candidates can submit the identical ecosystem and score differently, because one investigated systematically and the other clicked around until something worked.

Deliberate beats fast

Solve is not primarily a speed test. There is a clock, and it matters, but flailing quickly is worse than moving steadily.

The behaviour that scores well looks like this. Inspect the options you need in an order you could justify. Narrow deliberately. Commit. Revise when the evidence changes, not when you get restless.

The behaviour that scores badly is scattergun exploration: opening everything, selecting things to see what happens, and reversing repeatedly without new information.

Read the rules twice, literally

Both main tasks hinge on constraints stated once in the briefing. Candidates lose most of their product score to a rule they skimmed, not to a difficult judgement.

Budget the first two minutes for rules. Then re-read them partway through. Re-reading is not a sign of weakness in this format; it is the highest-yield habit available to you.

Ecosystem Building, as a procedure

The task looks like biology. It is really a constraint-satisfaction problem with a calorie budget. Reduce it to a procedure and it stops being intimidating.

1. Pick the location by its terrain specs, not by preference. Each location has ranges for depth, temperature and salinity. Species carry required ranges of their own. Choose the location where the most species overlap. This is a counting exercise.
2. Filter species on every terrain rule. Discard anything whose requirements fall outside the location's specs, exhaustively, before you think about the food chain. A single violation invalidates the ecosystem.
3. Build from the producers up. Start at the base, then each consumer tier. Every non-producer needs a food source that is itself present and supported.
4. Check the calorie arithmetic. Each species provides calories and consumes calories. A predator needs its food source to supply at least what it eats.
5. Verify every species before submitting. Walk the list once more: terrain legal, food source present, calories sufficient. This final pass separates a full product score from a near miss.

The most common failure

The orphan predator. Candidates include an attractive high-calorie species whose prey did not survive the terrain filter. Every predator needs a supported food source, not merely a theoretically edible one.

Red Rock Study, as a procedure

Red Rock is closer to a timed written case than to a game. A research scenario, a pile of mostly irrelevant data, and scored sub-questions.

The skill being measured is extraction discipline.

• Read the research objective before opening any data. Most of what you are given is deliberately irrelevant.
• For each sub-question, name the variable you need before you go looking. This stops you collecting interesting but useless facts.
• Keep units and time periods straight. Per-year versus per-season errors are the most common scored mistake.
• When asked to choose an analysis, prefer the one that isolates the variable in question over the one with the most data behind it.
• Leave two minutes to re-check any calculation feeding a conclusion you already committed to.

Note that selecting everything is penalised. You are scored on what you leave out as much as what you take, which is exactly the judgement a consultant needs when a client hands over a data room.

What to practise

Practise the method, not the scenario. The specific ecosystem and the specific conservation study change between sittings; the capability does not.

Drill three things:

1. Reading a constraint set and eliminating options systematically against it.
2. Pulling the two or three relevant numbers out of a wall of text and ignoring the rest.
3. Verifying a submission against every stated rule before committing.

Those transfer. Memorising a particular species list does not.