Hi Anonymous!

You touch on an important point here. Many candidates don't understand what distinguishes the clarifying questions at the start from later analysis-related questions (asking for market data. financials, etc.) In general, asking such analysis-related questions at the start is bad! It comes across completely arbitrary, and the interviewer will ask himself why you are asking analysis-questions before even having layed out an analysis approach (the structure)! It just makes no sense to ask for data before laying out your structure, because this information will have ZERO impact on this structure (--> the logic according to which you should address the question).  

The clarifying questions you ask at the beginning have the following objectives:

1. Completely understanding the context/situation (including, unclear terminology, but also, for example, the business model of the client if unclear!)
2. Understanding/narrowing down the actual question(s) of the client (very often the question is poorly/vaguely stated in the prompt, and it is your duty as the candidate to make it precise!)
3. Understanding (and quantifying if applicable) the underlying objective(s) of the client

These questions are aiming at understanding the initial setting, hence forming a precondition to outline your structure towards answering the core question (the issue tree)!

The later analysis-related questions that you ask while navigating through the case are then aiming to verify the actual relevance of each sub-branch in your tree. So if you have defined and disaggregated the criterion to answer the client's core question in a clean way, all these leater questions follow a this precise "roadmap" as layed out by your tree. These questions then oftentimes also comprise enquiries on current performance metrics (revenues, costs, growth rates etc.), which normally never make sense to be asked in the clarifying questions (before making explicit your structure).

Cheers, Sidi

_______________________

Dr. Sidi Koné 

(🚀 Ex BCG & McKinsey Sr. Project Manager, now helping high potential individuals join the world's top Strategy Consulting firms (McKinsey | BCG | Bain))

I understand the importance of striking the right balance when it comes to asking clarifying questions during case interviews. While it is crucial to gather the necessary information to understand the case, it is equally important to demonstrate efficiency and focus in your approach.

While there is no hard and fast rule about the exact number of clarifying questions to ask, it is generally recommended to keep it concise and focused. Spending too much time on clarifying questions can potentially eat into the time you have for analysis and problem-solving.

The key is to ask relevant and insightful questions that help you gain a clear understanding of the case context and objectives. These questions should be aimed at narrowing down the scope of the case and identifying the key areas to focus on. It is important to strike a balance between gathering the necessary information and not getting lost in excessive details.

Asking too many questions can be perceived as a lack of clarity or an inability to prioritize information effectively. It may also indicate a lack of structure in your approach. Therefore, it is important to be mindful of the time and prioritize the most critical questions that will provide you with the information needed to develop a strong framework and analysis.

Remember, the goal is to demonstrate your ability to think critically, analyze complex problems, and provide actionable insights. While asking clarifying questions is important, it should not overshadow your ability to structure and solve the case.

I hope this helps you find the right balance in asking clarifying questions during your case interviews. If you have any further questions or need additional guidance, feel free to ask. Best of luck with your preparation, and I'm confident that with practice and a focused approach, you will excel in your interviews.

Ah, spot on. This is one of my pet peeves. 

Interviewers can't stand when candidates go through the motions. And this is one of the points in the case when it happens. 

The moment I hear a candidate ask ‘do we have any specific target?’ as an interviewer I already have an idea of how they'll perform in the case.

In short, you should always be asking questions if you actually need to. Not by default. 

There's no specific number. Use your common sense. 2-4 are ok. 20-40 are a bit of a stretch. 

Basically, you should be asking questions for 3 reasons:

1. Clarify - you want to understand wherther what you hear was right. As in ‘was that 15 million or 50 million?’

2. Understand - you want to understand what is the business model of the client. So ‘how do these guys make money?'

3. Pre-Validate hypothesis - you have an idea already of where the problem is and can ask a question to help strengthen that hypothesis e.g., ‘do we know whether this is a market wide problem’?

Lastly, you should always proactively explain why you're asking a certain question just so it doesn't seem like you're doing it for no reason.

Great question btw!
Best,
Cristian

———————————————

Practicing for interviews? Check out my latest case based on a first-round MBB interview >>> SoyTechnologies  

Hi there,

Yes, you can waste time by asking the wrong/too many questions. 

Generally speaking, it's something like this:

CLARIFYING Qs → Framework → PROBING Qs

Let's examine in more detail:

• CLARIFYING Qs: They're meant to help you fully grasp the problem at a conceptual level so that you feel comfortable to make it yours. If we don't fully understand a problem conceptually, how are we meant to solve it? These questions are encouraged, and you can spend 1-2 minutes here, easily. For example: If a case prompt lays out a growth issue with a waste processing company but doesn't go into the detail for the business model, you could clarify on what kind of waste they typically process and how they're generating revenue. By knowing the answer to those questions, you may still not understand everything 100% but it's enough to take a stab at an approach i.e. framework (unless you're interviewing with McKinsey, in which case you're not frameworking in the ‘traditional’ sense). 
• PROBING Qs: Let's assume you understand conceptually the ins and outs of the case and you want some hard facts. At this point, you're asking probing questions going into greater detail and often related to quant. It is discouraged to ask these questions after the prompt. Instead, save them for later as you're working along your framework, which is your analytical blueprint for solving the case (again, if it's a non-McKinsey case). For example: If for the waste processing case (see above) you came up with a framework that includes long-term contracts, save all your questions for when you actually enter this area. It may be a dead end, or it may be the path to solving the case. So long as you explore all those areas with all your questions after the framework, you will be fine.

Also, consider some coaching to see what the dynamic is really like and set yourself up for success.

Hope this helps a bit. Best of luck!

Moritz

~~~~~~~~~~~~~~~
>> Need a senior McKinsey coach? See my profile in a nutshell
>> Need real McKinsey cases? See two real examples with Zero Carbon Mine (hard) & Car Convenience (Intermediate + brand new)

Hi there,

Yes, that happens. I suggest you think (and explain to your interviewer) why you are making the question. That would improve the quality of your questions and narrow down to a number of really useful ones.

A coach can definitely help here. You have plenty of great options to choose in PrepLounge.

Best,

Alberto

—

Check out my latest case based on a real MBB interview: Sierra Springs

Hi there,

Q: Is there such a thing as asking too many questions? At what point does it become excessive?

I would not worry about the exact number of clarifying questions but rather what is asked with the question. That’s because in some cases you might need more questions to clarify a point.

Example: in some cases you may understand the goal of the client with one question. In others, you might need two or three. The same is true for a clarification of the revenue/operating model of the client.

In general, the goal of the clarifying questions should be to:

1. Clarify what is unclear in the prompt.
2. Get the relevant information needed to properly structure and communicate an answer for the question asked.

Based on that, I would recommend clarifying the following if not already presented in the prompt:

1. Objective and constraints of the client. E.g. Why does the client want to complete this acquisition? or How much does the client want to increase revenues, and in what timeline?
2. Operating model of the client - mainly what they sell, to whom and how. E.g. Could you please clarify what product the client is currently selling?
3. Any element mentioned by the interviewer that you don't understand. E.g. You mentioned that our client performs standard activities as an intermediary bank. Could you please clarify which activities this involves? I am not particularly familiar with that sector.

Hope this helps,

Francesco

Hi,

This is a great question. I was just recently asked this at a workshop I conducted for one of the business schools in the region.

Here's my perspective having been an interviewer:

• Clarifying questions are meant to help you get to a better understanding of the problem statement/question you are trying to solve
  • This is very similar to what we actually do on the job with a new client project
• There is no rule or guide in the interviewer form that says you need to ask [x] number of questions, or cannot ask more than [y] number of questions
• That being said - there are definitely questions that are relevant and logical, and questions that are less relevant
  • E.g. if I take the analogy of a real client project, that means asking questions that you would actually ask once the project has started and not before during the scoping phase
  • E.g. asking questions that have answers that you never make use of eventually)
• Lastly, do note that the more questions you ask, the more you are taking away time from actually solving the case and showing your logic/thinking

Hope this helps to clarify!

Oh boy. YES. You should ask no more than 4-5 questions MAX, and the process should not take 5-10 minutes.

You're absolutely right there's a balance in between.

==========================================

At a real client site what would you do?

Would you rattle off a ton of questions and bombard them before even figuring out your project plan? (10 minutes in a case can be metaphorized into 1 week in a real project).

Would you ask only 1 question and not actually get an understanding of the situation before creating your workstreams/allocating work?

Would you rattle off a list of predetermined questions that are identical across every client? 

Of course not!

Same goes for a case. Think critically about the problem.

===============================================

There is not single question you "must" ask. Rather, every case is different. You need to ask questions that help you better understand the situation (objective, business model, etc). AND help you narrow your scope and focus your framework.

If there's no specific timeline there's no specific timeline.

Let me add to this - please don't ask timeline questions just for the sake of asking timeline questions. If, for example, the prompt is "We've seen an increase in demand and need to ramp up production", asking for timelines is silly...we know the answer to be ASAP. If you ask timelines, you both waste a question and show you don't think critically about problems!

I'll repeat: You need to ask questions that help you better understand the situation (objective, business model, etc). AND help you narrow your scope and focus your framework.

=================================================

General Rules for Clarifying Questions

1. They should help you define your box (context/scope)
2. They should help make your box smaller (narrow the scope)
3. They should help you develop your approach to solving the problem…not start solving the problem already

===============================================

I always write BOTMG at the bottom of my framework page to help myself think of things I'm missing in case I'm stuck.

This helps "trigger" you to consider questions around B = Business Model, O = Objective, T = Timing, M = Market, G = Geography.

However, you should never just say "so, what is their business model?" Obviously, ask questions that help you frame your hypothesis, understand the situation, and ultimately drive your case better.

Yes. Depends also on case type. Many Mck cases for instance have longer case intros and don’t require asking questions at all. Warm regards, Frederic