Case Interview Structure

Hi Chanon,

This is a great question!

Cases typically cover the breakdown you have mentioned, although of course some may be more numerical or conceptual focused. Regarding coming up with a hypothesis:

Typically in candidate-led cases (non-McKinsey), my perspective is that you would state your hypothesis after putting together a MECE framework that covers the entire problem space so you do not miss out on any important components that could be relevant for the case.

Including a hypothesis is important because:
 

1. The hypothesis drives your thinking: it allows you to test a particular component of your framework to check if it is the root cause or key lever of the problem presented.
    
2. It directly relates back to the client's ask: any insights uncovered in the case process should be related to the unfolding hypothesis as the answer to the problem becomes clearer.
    
3. It keeps focus and ties the case together: when delivering the recommendation you can reference early hypothesis and what the final answer is based on the findings from the analysis carried out.

I hope this answers your question and I am happy to help any time!

Best,

Yousef

Hi Chanon,

First of all, forget the nonsense about having to generate a hypothesis before drafting your structure. In fact, stating a hypothesis for the overall problem only makes sense if you really have something to ground your hypothesis on! This is very rarely the case, since case prompts tend to be quite vague at the beginning. Just stating a hypothesis for the sake of it serves no purpose! It would just be a shot from the hip - and this is something you should avoid at all cost during an MBB interview!

Secondly, let me share some more insights about the anatomy of a case interview. There are 3 principal “phases” during a case discussion: 

1. Starting into a case
2. Navigate/analyze the case
3. Close the case

Some more details about Phase 1: Starting into a case. 

This consists of 5 steps, as outlined in the exhibit below. Please, check out this exhibit and read the below rough description of the five steps. This should already help, I hope.
 

STEP 1.1: Listen

Listen carefully to the initial outline of the question / problem statement shared by the interviewer.

• Take notes
• Mark unclear/missed information
• Identify the core question!

STEP 1.2: Recap

Briefly repeat the problem statement (“paraphrase”).

• Double check your understanding
• Prevent misinterpretations / allows interviewer to clarify points misunderstood

STEP 1.3: Clarify

Ask clarifying questions.

• Objectives:
  • Understanding context / situation
  • Understanding scope of the question(s)
  • Understanding underlying objective(s) of the client
• NOT meant to start the analysis already! → Do NOT randomly ask for specific data!

STEP 1.4: Structure

Take time and draft your analytical approach (“your structure”).

• Always announce towards the interviewer that you want to take a moment to outline your approach!
• Then draft your structure with pen and paper
• Properly structuring case questions is THE central foundation for delivering consistent excellent performances in case solving!
• Core skill which needs to be learned! You don't learn this in university or business school!

STEP 1.5: Explain

Walk the interviewer through your structure.

• Once done with crafting your logic, you need to explain this logic to the interviewer
• Top-down communication! Start from core question → outline required insights to answer this core question
• Explain the RATIONALE behind your approach! → always justify WHY you’re doing what you’re doing!
• DO NOT just list areas/buckets!
• Prioritize required analyses!
• Align with the interviewer on your approach; adapt your structure, if the interviewer gives you specific guidance!

Cheers, Sidi

___________________

Dr. Sidi S. Koné

Former Senior Engagement Manager & Interviewer at McKinsey | Former Senior Consultant at BCG | Co-Founder of The MBB Offer Machine™

Hi Chanon,

Q: I have recently heard that we should also clearly draw a hypothesis before basing the framework on those hypotheses.

I don’t see reasons to state a hypothesis before presenting the initial structure – it would be like a random guess at that stage.

Instead, I would recommend using hypotheses when there are:

1. Multiple drivers that could be responsible for an outcome (eg there was a decline in profits and this might be due to either revenues or costs)
2. Not enough data to identify the driver responsible for it (eg you don’t have the data on how revenues and costs changed)

Therefore, to start the case, you can first present a structure showing the drivers that you would like to analyze to answer the question. Then, when you don’t have enough data to identify the correct driver, present the hypothesis to make explicit which area you would like to prioritize, out of those you have defined in the structure.

Additionally, I would not recommend just stating a hypothesis but also explaining how you would like to verify it and asking for the relevant data. In this way, you can identify whether the hypothesis is correct right away.

As an example, let's say that during the case the interviewer asks where you want to start a cost analysis. Then, after taking some time, you can:

1. Present a structure
2. State a hypothesis on the main area of analysis
3. Ask for data to verify the hypothesis

Bad example (no structure and the hypothesis is not verified with data):

“My hypothesis is that this could be a fixed cost problem, so I would like to start there.”

Good example (structure is present and the hypothesis is verified with data):

“Costs can be divided into fixed and variable costs. Within fixed costs, we could have [LIST OF COSTS]. Within variable costs, we could have [LIST OF COSTS]. My hypothesis is that this could be a fixed cost problem; to verify this, I would like to know how fixed and variable costs have changed. Do we have any information on that?”

Hope this helps,

Francesco

Hi Chanon, 

That is indeed the basic structure of an interview. Be aware though that sometimes your interviewer might change around components (e.g. brainstorming before quant analysis) and that quant analysis can also contain an exhibit.

Hypotheses should serve as the foundation of your framework, guiding your analysis and shaping the direction of your approach. For example, you might hypothesize about the competitive landscape, market trends, or customer behaviors to structure and prioritize your framework effectively.

The timing of introducing hypotheses can be within your framework. For instance, you could say, "Next, I would like to research the competition to verify that Product X is indeed superior to competitors' products."

Best,

Oliver

1. You missed exhibit interpretation

2. No, you don't need to draw an hypothesis [but your framework must allow to test multiple hypothesis]. For practice purposes, when you are practicing on your own, an just started doing cases, I find the idea of thinking of an hypothesis as something useful, because it forces you to think about SPECIFIC things that you need to look at. A lot of approaches and frameworks are overly generic, and thinking about hypothesis testing can help you in being more detailed. But this is not something I recommend when you are doing “live” cases, nor for real interviews.

In addition to the other answers on here - I would also like to add that following the process is a very small part of showcasing your skills. There are other things that matter equally and perhaps more. Things like your communication skills, your interview personality, your confidence level, and so on. Try not to focus too much on creating rules-based approaches and focus more broadly on performing “well” across all interview evaluation dimensions.

Further to your question on the upfront hypothesis - its neither a yes or a no. Depending on the case, and depending on what you are solving for - the answer will change. There is no rule written in stone. Same goes for all the other components - except probably Clarifying Questions - which is perhaps the only major constant across all cases.

Chanon,

No, it's not true. 

Stating a hypothesis early on is part of an older school of thought that makes absolutely no sense these days. 

You should only state a hypothesis when you feel like you can provide supporting evidence for it. 

This sort of supporting evidence is normally discovered during the case. 

So, in that sense, you should communicate your emerging hypothesis whenever you feel like you would be able to answer the question of ‘why are you suggesting that hypothesis?’

If you don't have an answer to that question, it means you don't have a hypothesis.

Best,
Cristian

Hi Chanon,

The hypotheses are your guiding anchors throughout the case. They should inform

• your structure
• the insights you take out of a chart
• you calculation logic and what you make of the results
• recommendation

That being said, the most elegant way is to come up with a hypothesis at the end of each element of the case.

E.g. You deliver a clear structure with several elements, then dive deeper to conduct your analysis and prioritize (The prioritization is the hypothesis,...).

You forgot data interpretation as part of your case interview structure btw = chart and data analysis.

Cheers,

Florian