Guides

The four-part structure

Every strong case interview answer follows the same shape, regardless of firm or case type:

1. Restate the objective — confirm what you're actually solving for, in one sentence.
2. Lay out a framework — 2-4 areas you'll investigate, stated before you analyze anything.
3. Work the framework out loud — ask for data, do the math, and narrate your logic as you go.
4. Close with a recommendation and its trade-offs — a clear answer, not a summary of what you found.

Interviewers are scoring the structure as much as the answer. A candidate who reaches a mediocre recommendation through a clean, visible structure usually scores higher than one who reaches the "right" answer through a scattered process — because the structure is what an interviewer can actually evaluate as you're talking.

How to start a case on Tech Case Hub

Every case in the case library opens the same way: a briefing screen with the objective, the constraints, and what the interviewer is trained to push on for that specific firm.

1. Pick a firm from the case library — each one runs its own interviewer register (McKinsey's pyramid-principle pushback is a genuinely different experience from Bain's plain-speech pushback).
2. Read the brief fully before clicking Begin case. It's short by design — everything in it is a real constraint, not filler, and you'll be expected to have used it once the case starts.
3. Click Begin case. The interviewer opens with a real, specific question tied to the brief — not a generic "walk me through your approach."
4. Answer in the input box using the four-part structure below. The interviewer responds in real time, pushes back on hand-waving, and asks for the data behind any number you state.
5. When you're done — or if you want to see how you did on a partial run — click End & Score for a scored evaluation.

Step 1: Restate the objective

Before anything else, say the objective back in your own words. Case prompts are often deliberately underspecified — "should this company enter a new market" could mean revenue growth, competitive defense, or shareholder pressure, and each framing changes what you'd investigate first. Restating it does two things: it catches a misread objective in the first 15 seconds instead of the last 15 minutes, and it signals to the interviewer that you think before you calculate.

Step 2: Build a hypothesis-driven framework

This is where most candidates lose points, usually by reaching for a memorized framework (4 Ps, Porter's Five Forces, a generic profitability tree) that doesn't actually fit the case in front of them. Build the structure from the case facts instead:

• What are the 2-4 things that would actually change the answer here?
• State them as parallel, non-overlapping branches — this is the "MECE" idea (mutually exclusive, collectively exhaustive) that shows up constantly in case prep material, and it matters because overlapping branches mean you'll double-count or miss something.
• Where possible, state a working hypothesis for each branch before you have the data — "I'd expect the churn increase to be concentrated in the postpaid segment, because..." — not because you need to be right, but because a stated hypothesis is falsifiable, and falsifiable is what makes an answer sound like reasoning instead of guessing.

Step 3: Work the framework out loud

Once the structure is on the table, work through it branch by branch. Ask for exactly the data you need for the branch you're on — not everything at once. Do the math visibly, round numbers sensibly, and sanity-check anything that comes out surprising ("that's a 40% margin, which seems high for this industry — let me double check that calculation"). Interviewers are listening for whether your logic holds together in real time, not just whether the final number is correct.

Step 4: Close with a recommendation, not a summary

The single most common way candidates lose points at the very end is restating what they found instead of answering the question that was asked. "We found that Segment A has higher churn and Segment B has higher margin" is a summary. "I'd recommend the company prioritize retention spend in Segment A, because a 5-point churn reduction there is worth more than the margin gain in Segment B — the main risk is that retention spend doesn't move churn as much as modeled, so I'd pilot it in one region first" is a recommendation: a clear answer, the reasoning behind it, and the biggest risk or trade-off named up front.

What earns a high score

Every case has a written rubric behind it: the "strong signals" a good answer demonstrates and the "red flags" that sink one. The interviewer scores your transcript against that specific rubric, not a generic impression, and returns:

• A score from 0-100 and a verdict — Strong hire, Lean hire, Borderline, or No hire.
• 2-3 specific strengths, citing what you actually did in the transcript — not generic praise.
• 2-3 specific improvements, citing what was missing or weak.
• Any strong signals you missed, and any red flags you triggered.

A Strong hire verdict requires demonstrating most of the case's strong signals and triggering none of its red flags — which in practice means the four-part structure above, done consistently, not just once at the start. The most common way candidates land at "Borderline" instead of "Strong hire" isn't a wrong final number — it's a strong opening framework that quietly drops the structure once the math gets involved, going back to hand-waving exactly where step 3 matters most.

How structure expectations differ by firm

The four-step shape holds everywhere, but what "good" looks like inside it varies by firm, because each firm's real interviewers are trained to push on different things:

• McKinsey interviewers are trained to reject a framework with more than three top-level branches — top-down, pyramid-principle thinking, where you're expected to state a hypothesis before requesting any data at all.
• BCG interviewers push hardest on branch 3 — every number you state needs to trace back to a source or a clearly labeled assumption. Vague, unsupported claims get challenged immediately.
• Bain interviewers care most about branch 4 — a recommendation that doesn't translate into "what does the CEO actually do on Monday morning" reads as incomplete, even if the analysis was sound.

None of this changes the underlying structure — it changes where in that structure a given firm's interviewer will apply the most pressure, so it's worth knowing before you walk in.

Common mistakes that break structure

• Skipping the framework and going straight to analysis. The single fastest way to lose an interviewer's trust — they can no longer tell if a correct answer came from reasoning or luck.
• Reciting a memorized framework that doesn't fit. Interviewers have seen the 4 Ps applied to a case where it makes no sense many times before; it reads as a script, not thinking.
• More than four top-level branches. Past four, you're not structuring anymore, you're listing — pick the branches that would actually change the recommendation and cut the rest.
• Overlapping branches. If two branches could explain the same piece of evidence, the structure isn't MECE, and you'll end up double-counting or contradicting yourself later in the case.
• Restating findings instead of recommending. Covered above, but worth repeating: the case ends with a decision, not a recap.

The fastest way to get comfortable with this shape is to run it against real cases with something that pushes back the way a real interviewer would — that's the whole premise behind the case library on this site: pick a firm, work a live case with an AI interviewer trained on that firm's actual style, and get scored on exactly the structure this guide walks through.