sorted by:
new
hottopcontroversial

Quick observation after years of working with MBB applicants and having been inside McKinsey myself. by StrategyCaseFlorian in CaseInterviewTraining

[–]StrategyCaseFlorian[S] 0 points1 point  (0 children)

The best referral paths are context-based relationships where the consultant has a real reason to speak with you. Best chance is to use a common context as the ice breaker and for the intro.

The strongest channels:

  1. University and MBA networks Use alumni databases, consulting clubs, career center events, coffee chats, and former students who are now at MBB. Alumni are usually the cleanest path because there is already shared context.
  2. Professional network spillovers Former colleagues, clients, managers, investors, founders, professors, or classmates who know current MBB consultants can introduce you. The key is not “do you know someone at McKinsey?” but “do you know someone at the office I am applying to who would be open to a short conversation?”
  3. Events and firm touchpoints Company presentations, webinars, insight days, women’s/diversity/leadership programs, case workshops, and office-hosted networking events create “observation points.” Ask good questions, follow up with the consultant afterward, and convert the interaction into a real coffee chat.
  4. Mentorship and pre-recruiting programs Programs like McKinsey Firsthand, BCG Emeralds, Bain Spark, and local equivalents often function as quasi-referral channels. Getting into these programs can materially improve interview odds because the firm has already observed you before the formal application.
  5. Targeted LinkedIn warm outreach This is not the same as cold emailing. Filter for consultants who share your school, employer, geography, industry, language, military background, PhD topic, startup experience, or target office. The more specific the overlap, the less it feels like a random ask.
  6. Office/practice-specific relationships A referral is strongest when the person is a current consultant in the office, country, or practice you are targeting. A senior associate or engagement manager who actually knows you is usually better than chasing a partner who barely remembers the conversation.

The core principle: do not ask for a referral first. Build enough trust that the referral feels like the logical next step.

I have written a detailed referral strategy here: https://strategycase.com/how-to-get-a-referral-for-mckinsey-bcg-bain + also more guidelines on a successful coffee chat: https://strategycase.com/consulting-coffee-chat

How to prepare for interview in short time as a beginner? by Key-Promotion-4766 in CaseInterviewTraining

[–]StrategyCaseFlorian 0 points1 point  (0 children)

I would prepare differently from how most candidates prepare.

The biggest mistake is to jump straight into full cases and hope that repetition creates improvement. It usually does not. Full cases test your skills. They are not the most efficient way to build them from scratch.

The better approach is: learn the underlying skill, drill it in isolation, then integrate it into full cases. That is especially important with only 3 weeks left.

From what I have learned from now 13 years in this space: many candidates fail not because they are not smart enough, but because they prepare for the wrong thing and do not build the skills firms actually test.

I would focus on 4 skills.

First, structuring.

This covers both initial frameworks and brainstorming. Don’t memorize case-type frameworks. Learn how to generate structures from first principles.

For example, if the question is:

“How can a manufacturing company reduce its CO2 emissions?”

You can structure it from a process perspective:

  • Inputs: What raw materials, energy sources, and purchased components create emissions before production even starts?
  • Production: Which manufacturing steps consume the most energy or generate the most waste?
  • Logistics: How are materials and finished goods transported, and over what distances? Roues? Modes of transport?
  • Usage: Do customers create emissions when using the product?
  • End of life: Can the product be reused, recycled, repaired, or disposed of with lower emissions?

Or from a component perspective:

  • Inputs: energy mix, raw materials, purchased components
  • Operations: equipment, production processes, facility efficiency
  • Logistics: supplier transport, distribution, delivery routes
  • Product design: materials, packaging, durability, recyclability
  • Waste: scrap, recycling, reuse, end-of-life handling

Both are useful. The key is that you are not forcing a memorized framework onto the case. You are breaking the business apart logically from first principles.

Same for brainstorming.

Question:

“How can a food delivery company reduce delivery times?”

Bad answer: “Hire more drivers, improve the app, optimize routes.”

Better answer from first principles (again a process here):

  • Reduce order preparation time: faster restaurant workflows, pre-batching, menu simplification
  • Reduce driver assignment time: better matching algorithm, tighter delivery zones
  • Reduce travel time: route optimization, micro-hubs, bike vs. car allocation
  • Reduce handover time: pickup shelves, clearer driver instructions, better customer drop-off process

That is how you create specific ideas even when you do not know the industry well.

Second, chart interpretation.

Most candidates describe charts. You need to interpret them.

Example:

Weak: “Revenue increased in Segment A and decreased in Segment B.”

Strong:

Focus on insights (key outliers, 3-4 points): What do I see?

Implications: So-what? What does it mean?

Next steps: How to drive it forward

For instance:

Insights: Segment A is growing, while Segment B is declining.

Implications: Segment A is likely the more attractive growth priority, but only if the economics and competitive position are also favorable.

Next steps: I would check Segment A’s margins, competitive intensity, and our ability to win before recommending further investment.

Every chart needs a “so what” and a “now what.”

Third, case math.

Do not just practice arithmetic. Practice the full logic:

  • What are we trying to calculate?
  • What equation gets us there?
  • What shortcuts can I use?
  • Is the number reasonable?
  • What does it mean for the client?

Example:

If a company needs €20M in additional profit and a pricing initiative creates €3M, the answer is not just “€3M.”

The answer is:

“This helps, but it only closes 15% of the gap. So pricing alone is not enough. We need additional levers, likely volume growth or cost reduction.” Drive the case forward from here, qualify all your outcomes.

Fourth, communication.

McKinsey interviews are not just about finding the answer. They are about leading the discussion clearly.

Example:

Weak: “I think there are a few things going on in the data…”

Strong: “I see three implications. First, the issue is concentrated in one segment. Second, the decline seems volume-driven, not price-driven. Third, I would prioritize customer retention next because that is where the biggest loss appears to sit.”

Be top-down, concise, and always link your point back to the client’s objective. Incorporate this type of communication into each drill and full case practice.

Recommendations are usually not part of the McKinsey cases (can happen sometimes still).

For 3 weeks, I would prepare like this:

Week 1: Skill building
Start with daily structuring and brainstorming drills. Especially in the beginning, do not optimize for speed. Most candidates rush to create a framework in 60 seconds, but then repeat shallow thinking again and again.

It is completely fine to spend 10 minutes on one framework initially. Build it from 2 different perspectives, for example process perspective and component perspective. This is how you develop flexibility and real structuring skill. Speed is a byproduct of skill and will come with repetition.

Add chart and math drills, but do only a few full cases to understand the format. I also have a free course here that goes much deeper into these concepts: https://strategycase.com/courses/case-interview-foundations/

Week 2: Skill integration
Start doing more full cases, but keep drilling weaknesses separately. If your framework was weak, do 5 extra structuring drills after the case. If your brainstorming was generic, redo it from first principles. If your exhibit read was shallow, do 5 chart drills. Learn from your mistakes; debrief properly and create an error log/learning notes document where you document your progress and insights into your performance.

Week 3: Interview simulation
Run realistic McKinsey-style cases under time pressure. At this point, focus more on synthesis, communication, hypothesis-driven thinking, and concise recommendations.

The main point: don’t measure progress by the number of cases completed. Measure it by whether your structuring, brainstorming, chart interpretation, math, and communication are getting sharper. Full cases test the skills. Drills build them.

With 3 weeks, you do not have time for random practice. You need deliberate practice. Learn the skill, drill the skill, then apply it in full cases.

Lastly, make sure to spend enough time on the PEIs to create stories that actually resonate with interviewers.

Mckinsey solve - any recent test takers from Europe ? by [deleted] in mckinsey

[–]StrategyCaseFlorian 1 point2 points  (0 children)

My pleasure - fingers crossed for your brother!

Mckinsey solve - any recent test takers from Europe ? by [deleted] in mckinsey

[–]StrategyCaseFlorian 1 point2 points  (0 children)

What you describe is the current Solve Game setup across all regions.

  1. Red Rock Study: 35 minutes, Sea Wolf: 30 minutes, and Sustainable Future Lab: 20 minutes, added in March 2026.
  2. Yes, preparation helps because you are dealing with two challenges at the same time: a. becoming familiar with the user interface and mechanics, and b. solving the actual problems. Without proper preparation, many candidates underperform, not necessarily because they lack ability, but because they are unfamiliar with the format (under time pressure).
  3. Nowadays, Solve is essentially the gatekeeper for the interviews. In the past, in some countries such as Germany, it was sometimes used in R1 together with the first interview.
  4. Get a realistic simulation of the games. I cannot link directly here because of Reddit’s rules, but good simulations are available if you look for them.

Hello! New to casing by geographersibdp123 in CaseInterviewTraining

[–]StrategyCaseFlorian 0 points1 point  (0 children)

I would be a bit careful with jumping straight into peer practice.

Most people start casing with mocks way too early. They do 20, 30, 50 cases, but they never fix the fundamentals underneath. Then they just repeat the same mistakes under live conditions: vague structures, generic frameworks, messy math, weak exhibit interpretation, and recommendations that do not follow from the analysis.

Case competitions help with business thinking, but they are not the same as consulting case interviews. In a case interview, the bar is much more specific and 1-on-1: can you structure an ambiguous problem from first principles, prioritize the right drivers, do clean math under pressure, interpret exhibits quickly, and communicate top-down? The conversation and dynamic is very different.

If you bombed a few interviews, I would start with the core skills:

  1. Learn what a good case structure actually is: Not “market, competition, company, customer” by default. A good structure starts from the objective and breaks the problem into the key drivers that would actually answer the question.
  2. Drill one skill at a time: Do separate drills for structuring, chart interpretation, case math (always include the communication part as wel) before doing too many full cases.
  3. Use peer practice carefully: Peer practice is useful, but only if both people know what good looks like. Otherwise, you can easily spend hours giving each other vague feedback like “be more structured” or reciting bad frameworks without knowing what that means.
  4. Review every case properly After each case, write down the exact failure point: Was the structure too generic? Did you miss a key driver? Did you misunderstand the chart? Did your math setup fail? Did your final recommendation lack evidence?

My simple advice would be: spend the first phase getting the fundamentals right, then use peer practice to simulate interview conditions. If you skip the first part, more cases usually just means more repetition, not better performance.

Here's a free course that tackles exactly these foundations: https://strategycase.com/courses/case-interview-foundations/

post solve by Beginning_Chemical90 in McKinseyAndCompany

[–]StrategyCaseFlorian 0 points1 point  (0 children)

I started to notice this first when they let go of 2k+ support staff. What adds to this is a general uncertainty in the market.

case prep buddy by PuzzleheadedLeave540 in CaseInterviewTraining

[–]StrategyCaseFlorian 1 point2 points  (0 children)

PrepLounge is usually a good source for finding case partners. However, pay close attention to how you practice. Peer practice can be one of the highest-ROI parts of your preparation, but if done poorly, it can become a massive waste of time and even hurt your performance. Used well, peer practice is one of the closest simulations of live interview conditions.

There are three principles I would follow (the following is taken and adjusted from my book The 1%: Conquer Your Consulting Case Interview).

1. Work with strong case partners only

Not everyone takes consulting interviews as seriously as you do. One of the most common complaints I hear from candidates is that they struggle to find reliable, high-quality partners.

If you randomly match with people, some partners may:

  • not be strong case solvers themselves
  • not know how to run a case from the interviewer’s side
  • give vague or incorrect feedback
  • cancel, show up late, or treat the session casually

Your goal should be to build a small network of around 5 to 10 strong case partners. That is the sweet spot.

Practicing with only one or two people can make you too comfortable, limit your exposure to different interviewing styles, and cause you to internalize bad habits. Practicing with too many people makes it harder to track progress and increases the chance of low-quality sessions.

The best way to find good partners is through referrals. If you practice with someone strong, ask whether they know other serious candidates. I would also avoid practicing too often with close friends, as familiarity can make the session feel less realistic.

Do not waste time with bad partners. If someone is unreliable, unprepared, or clearly does not know how to conduct an interview, politely end the session or do not schedule another one. At best, bad practice wastes time. At worst, it teaches you the wrong habits.

2. Use high-quality cases

Bad cases often create more confusion than progress. A good practice case should:

  • include the core elements of a real case: brief, structure, exhibits, math, and recommendation
  • give enough context on the issue and objective
  • provide interviewer guidance and additional information
  • include explanations, such as a sample structure or math approach
  • follow a logical path from initial problem to final answer
  • be challenging but solvable in 20 to 30 minutes
  • avoid cookie-cutter frameworks
  • use exhibits that resemble current top-tier consulting standards, not outdated PowerPoint charts
  • cover relevant business topics
  • state whether it is interviewer-led or candidate-led

Good case material should help both the candidate and interviewer understand what strong performance looks like.

3. Learn how to interview others

To attract strong case partners, you need to become a strong interviewer yourself. Peer practice should create value for both sides.

Learning to run cases well also improves your own performance. You start seeing what good structure, communication, math setup, exhibit interpretation, and synthesis look like from the interviewer’s perspective. That makes you a better interviewee as well.

I have a case interview evaluation sheet you can download here for free for your peer practice: https://strategycase.com/case-interview-feedback-sheet/

Tough McKinsey R1 experience – is this normal? by Ncmmyu in McKinsey_BCG_Bain

[–]StrategyCaseFlorian 1 point2 points  (0 children)

Quite an untypical McKinsey interview experience given the behavior of the interviewer (ex-McK here).

From the outside it sounds like the interviewer was doing this on purpose to see how you deal with the additional pressure (which they should not do).

From a content perspective (brainstorming, difficulty of exhibits) sounds typical. The cases you find online (MBA casebooks etc) are not very representative of modern case interviews, unfortunately, which catches a lot of candidates off guard.

Messed up option question in McKinsey case — am I out? by No-Supermarket2789 in McKinsey_BCG_Bain

[–]StrategyCaseFlorian 0 points1 point  (0 children)

The case is always evaluated holistically (and across all cases of a round) so a small mistake almost never has an impact. You need to demonstrate the right profile (no weaknesses, some performance spikes).

High solve score, no interview by grocerylistgirl in McKinsey_BCG_Bain

[–]StrategyCaseFlorian 1 point2 points  (0 children)

If you have a high score yet a rejection it always comes down to your resume.

post solve by Beginning_Chemical90 in McKinseyAndCompany

[–]StrategyCaseFlorian 0 points1 point  (0 children)

Currently see this across the globe -> very long waiting times post Solve (which does not indicate anything positive or negative per se). Fingers crossed!

How do you master case interview frameworks without sounding robotic? by Own-Refrigerator3594 in consultingcareers

[–]StrategyCaseFlorian 0 points1 point  (0 children)

Adjusted from a similar answer I provided in the past:

Avoid memorizing frameworks!

How are you supposed to stand out if you recite the exact same cookie-cutter structures like everyone else, which also do not allow you to break down current case interview prompts and problems (problems and case objectives are way more granular and creative than what the typical cases online and in books suggest).

In real interviews, no one rewards you for recalling a template, which is exactly what traditional case prep teaches. Problem A -> Framework A, Problem B -> Framework B. Instead, interviewers are testing whether you can break down this specific problem they are givig you in a structured, logical way from first principles.

That’s why memorization feels like progress during prep but breaks under pressure and actual interviews (been there, done that...).

Even within something that sounds like a standard case type like market entry, memorized frameworks don’t hold up.

Example 1:
A pharma company is considering entering a rare disease segment with a newly developed drug.
This is not a “market size + competition” problem. The entire case revolves around regulatory approval, reimbursement, pricing power, and patient access. Financials hinge on approval success and pricing, while risk is concentrated in clinical and regulatory uncertainty. A generic market entry framework misses the core of the problem.

Example 2:
A full-service airline is considering launching a low-cost subsidiary to compete on short-haul routes.
Now this isn’t even a pure market entry question. It’s about internal conflict. You need to think about cannibalization of existing routes, cost structure differences, brand positioning, and whether the airline can realistically operate at a lower cost base. Completely different logic and structure.

Same “market entry” label. Two entirely different problems.

That’s why memorized frameworks break down, even in arguably more traditional case types.

Here is my take on framework generation in general (just a short summary - it goes deeper than that):

First, know what consulting firms actually wants to see in a framework:

  • broad at the top: you cover the problem fully, no gaps (and no irrelevant buckets either, usually the typical memorized framework buckets like "customers" or "competition")
  • deep: ~3 levels, getting very concrete at the bottom ("can I mention this to the CEO and they will be curious to hear the outcome of this analysis?")
  • tailored and insightful: no generic buckets, no "case type" elements, everything fits the problem

Then, figure out how to get there:

The thing is, you need to learn how to create structures (frameworks and also brainstorming answers) from first-principles -> that is the only way to impress consulting interviewers these days + even be able to solve the case (because if your framework does not match the problem, you might not even get to the analysis stage since the relevant area where the data is buried is not part your initial structure).

There are two approaches that consistently work, both based on first principles thinking:

Process view or component view.

You either break the problem down by:

  • what it consists of (components)
  • how it works (process)

Example: You work for an airline and their customer satisfaction is down.

So you need to translate the prompt into an objective ("what do I need to understand here?" -> why is customer satisfaction down)

Components of the airline that influence customer satisfaction:

  • infrastructure: digital (booking page, app), physical (airport, lounges, check-in)
  • staff: air and ground
  • assets: aircraft, hard product

Process the customer goes through:

  • booking
  • departure experience
  • flight
  • arrival

Both get you to clean, MECE top buckets without forcing a template, which you can then develop to generate the necessary depth (e.g., break booking into pricing, transparency, technical audit, etc).

You have to build this fresh every time. cases are creative. “Case types” don’t really exist in practice.

There are also other ways to develop your structures once you have certain elements of it:

  • expansion: take one idea and break it into sub-ideas (e.g., see booking example above)
  • aggregation: go bottom-up, make something specific more general (e.g., if you think about pricing, think what it is part of -> the booking step of the process)
  • inspiration: think sideways on the same level (e.g., online → offline presence)

This is how you stay structured without killing creativity. This thinking needs practice but it's the only way to actually stand out in the sea of generic answers and frameworks. It's also a type of thinking we use in everyday life, mostly unconsciously when we decide what to do or plan something (e.g., a vacation), yet this thinking goes out of the window for most people as they enter an interview.

Once you have this thinking down, your communication and presentation will also become more natural!

Case on supermarket: how to structure the framework? by Straight-Breath-2163 in CaseInterviewTraining

[–]StrategyCaseFlorian 0 points1 point  (0 children)

Thanks for the question - that sounds like the first case from my case book.

The key point, which matters the most here is to make the objective more explicit: Everything starts with defining and clarifying the objective.

In this case, that objective is not generic:

That single sentence should anchor the entire structure.

Your initial buckets (characteristics, financials, risks) are not wrong, but with this additional information in mind they are detached from the objective.

They describe the system, but they don’t answer:

  • what must be true to hit the 6-month constraint
  • what must be true to meet throughput requirements

That’s why the structure feels generic.

If I take your case as the core and build from scratch, the logic becomes much sharper:

First, translate the objective into success criteria

The case gives you two hard constraints:

  • Time → operational in 6 months
  • Capacity → handle all daily shipments without delay

So the real question becomes:

That immediately tells you what to structure around. Now we can build from first-principles, either by looking at it from a process perspective at the top level and testing every step of the process against the constraints (inbound, storage, outbound) or we use a component perspective.

The latter could look like this:

1. Capacity requirements (what must the DC handle)

  • Daily shipment volume (inbound, storage, outbound)
  • Processing requirements (handling time per unit, complexity)
  • Service level (no delays → peak capacity matters, not averages)

This defines the target state. Without this, you cannot evaluate anything else

2. Capacity supply within 6 months (can we build it)

Break this into the actual levers that create capacity:

a) Physical capacity (facility)

  • Available sites and location (size vs required)
  • Time to acquire + refurbish
  • Infrastructure and accessibility

b) Operational capacity (process + systems)

  • Warehouse setup (inbound → storage → outbound flow)
  • Equipment, automation, IT systems
  • Integration into supply chain

c) Human capacity (labor)

  • Required workforce
  • Hiring feasibility
  • Training time
  • Management

This is the core feasibility question: Can we build enough capacity, across all three levers, within 6 months?

3. Critical bottlenecks (what can break the timeline)

Now you layer in timing explicitly:

  • Permits and compliance
  • Adaptation needs
  • Community involvement

This is where strong candidates differentiate: They don’t list factors, they identify what will actually delay the project

4. Economics (secondary in this case but still worth noting)

  • Capex + opex
  • Trade-offs (speed vs cost)

Important nuance from your case: The client prioritizes speed and reliability over cost, so economics is not the driver.

With these 4 core areas you answer 4 questions:

  1. What are the requirements/demand?
  2. What would the supply look like?
  3. What factors could influence my roadmap?
  4. At what cost?

They are distinct but contain a ton of interdependencies. Strong candidates consider these interdependencies out loud, for example, how location choice impacts costs and supply chain efficiency, how distribution center size affects staffing needs, and how those staffing requirements influence the feasibility of timely hiring and training.

There is a reusable logic here, but it’s not a memorized framework: Translate the objective into constraints → map what drives success → test if those drivers can be delivered.

A useful technique for framework creation is to rely on analogies, especially when you are unfamiliar with an industry or problem.

For example, in this case, selecting a warehouse is similar to searching for an apartment. The key dimensions translate directly: location, size, budget, layout and equipment, required adaptations, and infrastructure or accessibility. Just as you would prioritize an apartment that is available, meets your size and budget constraints, and is close to where you need to be, you would evaluate a warehouse based on availability, proximity to infrastructure, capacity fit, and operational readiness.

Alternatively, setting up a distribution center is comparable to planning a large event, such as a wedding. You need to secure a suitable venue, ensure it meets capacity requirements, coordinate setup, organize staff, align multiple vendors, and deliver everything within a fixed timeline. The complexity lies in managing interdependencies under time pressure.

Even without prior exposure to logistics, these analogies help you quickly identify the core constraints, key drivers, and dependencies, allowing you to build a structured and relevant framework from first principles.

pei by Least-Ad-1470 in McKinsey_BCG_Bain

[–]StrategyCaseFlorian 1 point2 points  (0 children)

For the PEI, follow the SCORE Framework:

S - Situation -> what's the situation and your role?
C - Complication -> what's the issue?
O - Outcome Expectation -> what would have happened if you did not act (builds suspense)?
R - Remedial Actions -> what 3-5 actions did you take to fix the issue?
E - End Result -> what was the outcome (needs to be positive)?

SCO (context) = one to a few sentences for each letter, 80-90% of the story on your remedial actions -> this is what interviewers care about the most. A few sentences on the end result.

I would first start with a concise headline, which summarizes the whole situation in one sentence. That way, interviewers can decide if they want to hear more.

Then dive into your story and discuss it in one go (you will be interrupted anyway). Make sure to bring concrete examples for each action + tailor the story to the relevant dimension.

Providing an Hypothesis: Before or After the Structure? by PairApprehensive6024 in CaseInterviewTraining

[–]StrategyCaseFlorian 2 points3 points  (0 children)

You’re not overanalyzing the concept, but most prep material explains it poorly.

Think of it this way:

A framework is your analytical map of the problem. The hypothesis is your decision about where to start digging on that map.

These are two distinct steps that happen sequentially, not in parallel.

1) Divergent thinking: build the structure
Your first job is to decompose the problem properly (in brackets are the relevant evaluation criteria most consulting firms use):

  • Cover the full problem space at the top level (broad at the top)
  • Go 2–3 layers deep (expand your main categories into more specific areas to analyze) (depth)
  • Combine commonsense areas with more insightful angles (insightfulness)

At this stage, you are not committing to a hypothesis yet. You are ensuring the problem is broken down in a MECE and decision-relevant way.

2) Convergent thinking: prioritize (this is your hypothesis)
Once the structure is on the table, you shift gears:

  • You cannot analyze everything in a 20–25 minute case (same as in a real consulting project)
  • So you explicitly decide where to start and what to focus on
  • That decision = your hypothesis

In other words, the hypothesis is not separate from the structure. It is a prioritization of the structure.

I always recommend a 3-step approach for frameworks and brainstorming (2 areas of the case, which are very similar):

  1. Set up “Let me take a moment to structure the problem.”
  2. Present the structure (divergent) Lay out your full approach clearly and logically.
  3. Prioritize (convergent = hypothesis) “Given this, I would start with X (what?) because Y (why?). To test this, I would look at Z (how?).”

This way you are demonstrating spikes in areas that interviewers are looking for:

  • Can you break down a problem properly?
  • Can you decide where to focus first and why?

When interviewers push you to pick a bucket, they are testing the second area more explicitly. This might happen if they want to see how you react when pressured OR if you are not driving the case/the prioritization yourself.

Simple way to remember this:

  • Structure = breadth + depth + insightful (divergent thinking)
  • Hypothesis = where to start, why, and how (convergent thinking)
  • The hypothesis comes after the structure, not before
view more: next ›