How Can I Get Better at Structuring McKinsey Case Interviews?

Hi there,

I would be happy to share my thoughts on your questions:

• First of all, considering that the structuring question at McKinsey is actually just a simple brainstorming question (since you also always need to group/cluster the ideas/risks your brainstorm), contrary to what other coaches have said, there is no defined number of top- and/or second-level factors. The same applies to the length of presentation - as long as you add value to your presentation, it is ok - but this is something you can only find out with practice and an experienced coach like me.
• Moreover, the only real way to get better at this specific McKinsey question is practice - there's unfortunately no shortcut to it.
• Lastly, since you seem to have rather fundamental issues with this type of question, I would strongly advise you to consider working with an experienced coach like me on your structuring skills. I developed the "Case Structuring Program" to help exactly such candidates like you who struggle with case study structures.

If you would like a more detailed discussion on how to best prepare for your upcoming McKinsey pre-interview assessment and/or interviews, please don't hesitate to contact me directly.

Best,

Hagen

Hi,

Very good questions and something many candidates struggle with. My recommendation:

On level of detail and length: give the interviewer the top level first, then go one layer down. Say the main areas you want to look at, then take each one and explain its sub-points and, briefly, why it matters. The test is whether the interviewer could follow your logic without seeing your notes.

On number of buckets: three to four main ones, each with two or three sub-points. Something like: "I'd look at three things: A, B and C. Starting with A, I'd break it into A1, A2 and A3", and so on for B and C. Fewer than three looks thin, more than four gets hard to hold in your head and to walk through cleanly.

On how to practise: drill structuring on its own, not full cases. Take one prompt after another, give yourself two minutes to build only the structure out loud, then stop. When you do it, make sure you build your branches from the specific objective in the case, not from a template in your head. That is what stops them coming out generic.

Hope it helps and feel free to DM me if you want to run through a few structures together!

Federico

Hi,

This is the single most common sticking point I see with my candidates. My 2 cents:

On level of detail and length: aim for 60–90 seconds. Give the top level first ("I'd look at three areas"), then take each one and go one layer down, adding a few words on why it matters. 

On numbers: three to four main buckets (usually 3 is the magic number for any consulting company!), two or three sub-points each.

On generating sub-buckets: the problem is almost never logic, it's that you're building from a template rather than from the case. Two things fix it. First, pick a top level that generates depth for you, e.g. a math tree, a value chain, or the client's actual decision criteria, rather than defaulting to profitability. Second, apply a "so what" filter: if the answer to a sub-point wouldn't change the recommendation, cut it. That alone removes most of the generic stuff.

On practice: drill structuring on its own, not full cases. Collect 30–40 prompts, give yourself two minutes to build and 90 seconds to deliver out loud, then stop and move on. And close every structure by saying where you'd start and why.

One last thing, given the Middle East office, you may want to invest an hour each to develop some basic knowledge on the main industries covered there: oil & gas, giga-projects, sovereign funds, banking and public sector, and get comfortable with objectives that aren't profit, e.g. job creation, localisation, diversification. That will do more for you than another twenty cases.

Happy to run through a few structures together if useful.

Franco

This is probably the most common challenge I see with McKinsey candidates.

The good news is that you're likely overthinking it. Interviewers are not expecting an exhaustive list of highly creative sub-buckets. They're looking for a logical way of breaking down the problem.

A few tips that have helped many of my candidates:

• Start with 3–4 high-level buckets that directly answer the question. Don't try to force a generic framework.
• Only go one level deeper where it adds value. You don't need three levels of decomposition.
• Focus on why something could happen, not on listing everything you know about the industry.
• When presenting, spend around 1–2 minutes. Briefly introduce your overall logic, then walk through each bucket and one or two key sub-points. Keep it conversational rather than reading your notes.

To improve, I'd recommend doing structure drills rather than full cases. Take 20–30 random prompts and give yourself exactly two minutes to build a structure. Then compare it with a model answer or discuss it with a partner. You'll improve much faster than by only doing complete cases.

Finally, don't judge your structure by how "original" it is. A simple, tailored, and easy-to-follow structure will score much better than a complicated one that's difficult to communicate. That's especially true at McKinsey.

hey there :)

this is one of the most common challenges, and it mainly comes down to practice. At McKinsey, don't think in terms of memorizing frameworks. Instead, ask yourself, "What would have to be true for this hypothesis to hold?" The answers to that question naturally become your sub buckets.

Aim for 3 to 4 main buckets with 2 to 3 tailored sub buckets each. You don't need to explain every sub bucket in detail. A concise 30 to 60 second walkthrough is usually ideal: state your logic, briefly explain each bucket, and then move into the analysis.

The best way to improve is to take random case prompts and spend just two minutes building a structure. Do this repeatedly without solving the full case. Over time, you'll recognize patterns and become much faster at generating relevant, issue specific ideas.

Good luck, and feel free to reach out if you'd like to practice McKinsey style cases together. Best, Alessa :)

Hello ! I am a former EM and interviewer for the McKinsey Middle East office. 

Correct, cases are interviewee led. The first question focuses on drivers of a problem / solution. You should draw your answer as a tree and present it in a very top down way (i.e., start with the first levels of the tree, then deep dive into each one). The presentation should last 1min - 1min 30 and the interviewer is likely to interrupt to ask questions

Happy to chat more

You're already thinking about it the right way. The mistake many candidates make is believing there's a perfect framework.

In reality, interviewers are looking for clear, logical thinking. Start with three or four main buckets that directly answer the question, then add a couple of tailored sub points where they genuinely help. Don't worry about creating lots of detail.

The best way to improve is to practise structuring on its own. Take a case prompt, give yourself two minutes, explain your structure out loud, and repeat. You'll improve much faster than by only doing full cases.

Keep it simple. A clear structure, explained confidently, will almost always outperform a complicated one.

If you'd like a few tips on McKinsey structuring, feel free to get in touch.

Aim for 3 to 4 main buckets, with 2 to 3 tailored sub-buckets each. Your explanation should take around 90 seconds. Always state your main branches upfront before diving into the detail.

To build tailored sub-buckets quickly, stop thinking in textbook categories like "Marketing" or "Operations." Instead, visualize the exact business model in front of you. Ask yourself what specific actions or metrics drive revenue, costs, or risks for that precise company.

The best way to practice is doing 90-second structure drills. Take 10 different case prompts, draw custom issue trees, and explain them out loud.

Feel free to reach out if you want to discuss your situation further.