Two candidates walk into the same McKinsey final round. Same case: a regional airline seeing profits drop 30% year-over-year. Both candidates are smart—3.8 GPAs from target schools, similar internships, equally polished.
Candidate A structures a beautiful issue tree. Lists out revenue drivers: passenger volume, ticket prices, ancillary revenue. Cost drivers: fuel, labor, maintenance, overhead. Spends 15 minutes methodically analyzing each branch. The interviewer looks increasingly bored.
Candidate B asks three clarifying questions, draws a simple profit tree, then says: "Given the competitive routes you mentioned and fuel prices staying flat, I'd hypothesize this is a volume problem, specifically load factor dropping on our core routes. Can we look at the passenger data by route first?"
One candidate got the offer. Can you guess which one?
The Most Important Case Type You'll Face
If you prep for only one case type, make it profitability. Here's why:
The numbers don't lie: 40-50% of all case interviews at MBB firms involve profitability analysis. At some firms (looking at you, Bain), it's closer to 60%. You're not just likely to see this—you're almost guaranteed to face it.
It's a gateway skill: Profitability cases test everything else. MECE thinking? You'll need it to structure your profit tree. Business acumen? Required to know what revenue and cost drivers actually matter. Hypothesis-driven thinking? Essential to avoid analysis paralysis. Quantitative skills? You'll be calculating margins constantly.
Real consulting projects: Unlike some academic case types, profitability work is what consultants actually do. McKinsey's bread and butter is helping clients improve margins. BCG built its reputation on cost optimization. Bain? Profit improvement is literally in their tagline. Master this case type, and you're showing firms you understand what the job actually is.
Reality check: Most candidates fail profitability cases not because they don't know the formula (Profit = Revenue - Cost), but because they don't know where to look first. They analyze everything. Top candidates isolate the problem in 90 seconds.
What Makes Profitability Different
You might think: "It's just math, right? Revenue minus cost?"
Yes. And no.
The math is simple. A fourth-grader could calculate profit. But here's what separates good candidates from great ones:
Good candidates: Build comprehensive frameworks. List every possible revenue and cost driver. Ask for data on all of them.
Great candidates: Form hypotheses based on the situation. Know which drivers matter most. Ask for specific data to test their theory.
Example: A retail chain's profits dropped 25%.
- Good candidate: "Let's look at revenue—that's traffic and conversion and average transaction value. And costs—that's COGS, rent, labor, marketing..."
- Great candidate: "A 25% profit drop in retail typically means either traffic collapsed or gross margins got crushed. Given you mentioned new competition opened nearby, I'd hypothesize it's a traffic problem. Can we see store visit data first?"
See the difference? One is mechanical. The other is diagnostic.
What Interviewers Are Actually Testing
When an interviewer gives you a profitability case, they're not testing if you can subtract costs from revenue. They're evaluating:
1. Business judgment — Do you know what metrics matter in different industries? That SaaS companies care about CAC payback and retail cares about same-store sales?
2. Structured thinking — Can you break down profit systematically without missing major drivers or double-counting?
3. Hypothesis formation — Can you make educated guesses about where the problem likely is before diving into analysis?
4. Prioritization — When you have limited time, do you chase the high-impact issues or get lost in minutiae?
5. Quantitative comfort — Can you quickly calculate margins, growth rates, and impact sizing while talking through your logic?
6. Practical recommendations — Do your solutions actually make business sense, or are they theoretical nonsense?
What top candidates know: Profitability cases have a rhythm. Clarify the situation → Form hypothesis → Build focused structure → Test with data → Recommend. If you're spending more than 2 minutes on your initial structure, you're doing it wrong.