How to Crack Any Case Interview: Think Like a Consultant, Not a Candidate

There is one question behind almost everything a case interviewer is testing: could I put this person in a room with a client and trust them to handle it well?

That is the mindset I would use when preparing for any case interview. Your interviewer is not looking for someone who has memorized the most frameworks or can perform every calculation perfectly. They want to see whether you can understand an unfamiliar problem, bring structure to it, focus on what matters, communicate clearly and keep moving when things do not go exactly to plan.

I spent five years at Bain, and the biggest mistake I see candidates make is approaching a case as something they need to "solve" rather than a conversation they need to manage well. Once you start thinking like the consultant in the room rather than the candidate being tested, many of the things that make a strong case performance start to make sense.

Case interviews are often presented as tests of problem solving. That is true, but it is incomplete. A good consultant obviously needs to be able to break down difficult problems, interpret data and work with numbers. But doing good analysis is only part of the job. You also need to understand what the client is asking, decide what deserves your attention, explain what you are doing, respond to new information and communicate a recommendation someone can actually act on.

That is why the best mental model for a case interview is not:

"How do I get the right answer?"

It is:

"If this interviewer were my client, how would I handle this conversation?"

Imagine a CEO tells you that profits have fallen by 30% and asks what the company should do. You probably would not immediately draw a memorized profitability framework on a whiteboard and start listing every possible revenue and cost driver you can remember. You would first make sure you understand the problem, clarify what changed and what the CEO cares about, and explain how you plan to investigate it. You would then focus on the things most likely to explain the decline, keep the CEO updated as you work through the analysis, and once you had enough evidence, tell them what you think they should do.

That is also a very good description of a strong case interview. Official recruiting guidance from firms such as McKinsey and BCG reflects this: they describe case interviews as realistic client or business problems designed to understand how candidates structure ambiguous problems, identify important issues, work with data and communicate their reasoning.

There is not always one perfect answer. What matters is whether someone would trust the way you got there.

One of the easiest ways to make a bad start to a case is to hear a few familiar words and immediately begin solving the problem you think you have been given. Slow down and make sure you understand the actual objective first.

If a client tells you:

"Our restaurant chain has become less profitable over the last two years. What should we do?"

there are still several things you do not know. How much has profitability fallen? Is the problem across the entire company or concentrated in particular restaurants? Did something change two years ago? Does the client want to restore historical profitability, hit a specific target or simply understand what happened? Are there constraints you need to know about?

Good candidates clarify the objective before they build their structure. That does not mean asking ten questions before doing any work. It means making sure you understand the things that could materially change how you approach the problem.

A strong opening could sound like:

"Just to make sure I understand the objective correctly: our client operates a chain of restaurants and has seen profitability decline over the last two years. We want to understand what is driving that decline and identify what they can do to restore profitability. Is that right?"

Then, if necessary:

"Do we have a specific profitability target or time horizon we are working toward?"

This reduces the chance that you spend the next 20 minutes solving the wrong problem, but it also shows the interviewer that you listen. That sounds basic, but it matters. Clients want to feel understood before they want to hear your solution.

Do not treat the opening prompt as information you need to get through before showing your structure. Treat it as the beginning of the problem-solving process.

Frameworks can be useful when you are learning case interviews. The problem starts when candidates become dependent on them. You hear "market entry" and automatically write market, competition, company and customers. You hear "profitability" and immediately split the problem into revenue and costs.

Those concepts are not wrong. They are often useful starting points. But a generic framework does not show much judgment because your job is to structure this specific problem.

Suppose the case is:

A premium coffee chain with 12 locations has seen operating profit fall from €2.4 million to €1.3 million in one year. Revenue is roughly stable. The CEO wants to understand what happened.

A generic profitability tree would technically work. But the prompt already tells you something important: if revenue is roughly stable while profit has fallen sharply, costs immediately deserve attention.

A more tailored structure might be:

"Because revenue has remained roughly stable, my first hypothesis is that the decline is primarily cost-driven. I would therefore start by separating costs into those that changed with the number of transactions, such as ingredients and labor, and fixed or semi-fixed costs such as rent and central overhead. If costs do not explain the decline, I would then return to the revenue side and test whether the sales mix has shifted toward lower-margin products or locations."

Now you are doing more than organizing information. You are showing a point of view and using information from the prompt to decide where to start.

Strong structures generally have three characteristics: they are specific to the problem, they cover the major plausible explanations without trying to cover everything imaginable, and they help you prioritize what to investigate first. Think of a structure as a plan for solving the problem, not a checklist for demonstrating case interview knowledge.

This is also one of the skills that improves fastest through repetition. If you want to practise building case-specific structures rather than relying on memorized frameworks, you can work through consulting cases and targeted drills on GradGuide.

Consulting problems can become almost infinitely complicated. You could analyze every customer segment, competitor, product, geography, channel, cost line and market trend. Real consultants rarely have the luxury of doing that, and neither do you in a case interview.

A good candidate constantly asks: "What is most likely to matter?" Suppose you discover that a retailer's profit has fallen by €20 million. You then learn that marketing costs increased by €1 million, head office rent increased by €500,000, and gross margin declined by €18 million.

You could investigate all three, but they clearly do not deserve equal attention. The gross margin decline explains nearly the entire problem, so go there first.

This sounds obvious when the numbers are written down. During an interview, candidates frequently do the opposite. They become attached to the structure they created at the beginning and methodically work through every branch. That is not structured problem solving. It is structured box-ticking.

Use your structure as a map, but let the evidence determine where you go. The same principle applies within an analysis. If a chart shows revenue across five product categories and four are almost unchanged while one has fallen by 40%, do not spend equal time describing all five bars.

Start with the answer:

"The main thing I notice is that almost the entire decline comes from Product C, where revenue is down around 40%. The other four categories are broadly stable, so I would focus our investigation there."

That is 80/20 thinking. You looked at the whole picture, identified what matters and moved the conversation toward the answer. The strongest case candidates usually feel fast without appearing rushed. They are not necessarily calculating or speaking faster; they simply waste less time on things that are unlikely to change the conclusion.

Imagine sitting in a client meeting while a consultant silently looks at a spreadsheet for two minutes and then suddenly says: "Twenty-four million." Even if the number is correct, that is not a great client experience. Case interviews are similar because your interviewer cannot evaluate reasoning they cannot see.

That does not mean narrating every thought that enters your head. It means communicating enough for the other person to understand what you are doing, why you are doing it and what you have learned.

This matters particularly during calculations. Instead of silently writing:

120,000 x €200 = €24 million

say:

"I want to estimate annual revenue. We have 120,000 customers paying €200 per year, so I will multiply those together. That gives us €24 million in annual revenue."

Then interpret it:

"That means the new product would need to generate several million euros before it becomes material at company level."

The same applies to charts. Do not simply read numbers from the page. Take a few seconds to understand what you are looking at, then orient the interviewer. For example:

"This chart shows revenue by customer segment between 2024 and 2026. Total revenue has fallen by roughly 10%. The biggest change is in enterprise customers, where revenue is down about €15 million, while the other segments are broadly stable. That suggests I would focus on what changed in enterprise."

A useful sequence is simple: explain what you are looking at, identify the most important observation, then explain what it means for the case. That is how you turn analysis into communication.

It also gives the interviewer opportunities to help you. If your logic is heading in the wrong direction but you are communicating clearly, they can redirect you. If you work silently for three minutes, they cannot.

You will get stuck during case interviews. You may not know why customers are leaving, understand the economics of an unfamiliar industry or immediately see what matters in an exhibit. That is normal. The mistake is thinking you need to hide that uncertainty.

Consultants ask questions constantly. What matters is the quality of the question. Compare these two responses.

Candidate A

"I am not sure why revenue declined. Do we have any more information?"

Candidate B

"Given that the number of customers has fallen while average spend appears stable, my first hypothesis would be that the problem is customer retention or acquisition rather than pricing. Do we know whether the decline is coming from fewer new customers or existing customers leaving?"

Both candidates asked for information, but only one demonstrated thinking before asking. That pattern is useful throughout a case: explain what you would expect, state your first hypothesis, identify one or two plausible explanations, then ask for the information that would help you distinguish between them.

You do not have to be right. A hypothesis is not a commitment. It is a starting point that helps you decide what information would be useful next.

This becomes especially important when you encounter an industry you know little about. Suppose the case is about industrial gas distribution and you have no idea how that business works. Instead of panicking, you could reason from first principles:

"I am not familiar with this industry, but I would expect distribution economics to depend heavily on delivery density, transport distance and utilization of the distribution network. Are those important cost drivers in this business?"

Now your lack of industry knowledge is not the main story. You have shown that you can make a reasonable inference and test it, which is much closer to real consulting work.

At some point in your preparation, you will make a calculation error, misread a chart, investigate something that turns out to be irrelevant or give an answer that the interviewer challenges. None of those things automatically ruins a case. The important question is what happens next.

Imagine you calculate a market size as €20 million and then notice that you accidentally used 100,000 customers instead of 120,000.

A poor response is:

"Sorry, sorry. I completely messed that up. Let me start again."

You have turned a small calculation mistake into a crisis.

A stronger response is:

"I used 100,000 customers in that calculation, but the exhibit gives us 120,000. Let me correct that. At €200 per customer, the market is €24 million rather than €20 million. That does not change the overall conclusion, but it makes the opportunity slightly more attractive."

You identified the error, corrected it, explained the implication and continued. That builds trust.

The same principle applies when the mistake is conceptual. Suppose you spend two minutes investigating price and then realize the data shows price has not changed. Say so:

"It looks like my initial pricing hypothesis was wrong. Prices are stable, so I would deprioritize that and focus on the 15% decline in customer volume."

That is not failure. It is updating your view when the evidence changes. Real client work contains incomplete information, wrong hypotheses and calculations that need checking. Good consultants are not people who never make mistakes. They are people who catch problems, deal with them transparently and keep the work moving.

One of the clearest differences between weaker and stronger case candidates is what they do with analysis after completing it. Weak candidates report what they found. Strong candidates explain what it means.

Suppose you have just analyzed a proposed price increase. A descriptive answer might be:

"The company currently charges €10. If we increase prices by 5%, the price would become €10.50. Based on the exhibit, we might lose some customers, although we would receive more revenue from the customers that remain."

Everything in that statement might be true, but the client still does not know what you think. A better answer would start with the conclusion:

"I would implement the 5% price increase. Even after accounting for the expected loss of customers, our analysis suggests revenue would still increase by roughly €1.2 million. The biggest risk is that customer churn is higher than we have assumed, so I would test the increase in a small group of locations before rolling it out nationally."

That answer gives the client a recommendation, the most important evidence, a number, the key risk and a next step.

You should do this throughout the case, not only in the final minute. After a calculation, say: "This gives us a €6 million opportunity, which would cover roughly half the client's profit gap." After a chart: "Customer volume is down 18% while price is almost unchanged, so volume rather than pricing appears to be the main revenue problem." After an analysis: "This rules out labor cost as the primary driver. I would move next to raw material costs."

Quantification is particularly important. "Revenue fell significantly" is weaker than "revenue fell approximately 15%." "The opportunity is large" is weaker than "the opportunity could add around €8 million, or 20% of current revenue."

Consultants frequently need to make decisions without perfect information. Quantifying what you do know makes your reasoning more precise and helps everyone understand the scale of the issue.

You cannot memorize your way to being ready for every case interview. There are too many industries, too many business models and too many ways an interviewer can change the problem. Eventually you will get something you have never seen before, and that is the point.

Practice should therefore do more than expose you to lots of cases. It should make the underlying behaviors automatic. You want to become comfortable clarifying an ambiguous problem before jumping into the answer, creating a structure from scratch, identifying which branch matters most, talking through unfamiliar calculations, interpreting charts quickly, forming hypotheses with incomplete information, changing direction when evidence contradicts you, recovering after a mistake and giving a clear recommendation under time pressure.

That requires repetition, but the quality of the repetition matters. Doing 50 cases badly will not automatically make you good. After each practice case, identify the one or two things that would have most improved your performance.

Maybe your math was fine but your structures were too generic. Maybe you found the right insights but did not communicate them clearly. Maybe your final recommendation contained six observations and no actual recommendation. Once you know the weakness, target it deliberately. If synthesis is weak, practice synthesis. If exhibit reading is weak, do exhibit drills. If you keep getting lost halfway through cases, work on communicating the objective and keeping track of what you have learned.

Full cases are useful because they combine all of these skills. Focused drills are useful because they allow you to isolate one skill and repeat it until it improves. That is also how we designed GradGuide's consulting practice: you can work through complete cases when you want the full interview experience, or focus on individual skills when there is something specific you need to improve.

You also need to practice aloud. Case interviews are conversations, and being able to construct a great framework in your head is not the same as being able to explain one clearly to an interviewer.

Sometimes practice should also feel uncomfortable. You should encounter industries you do not know, calculations where you initially make a mistake, interviewers who challenge your recommendation and moments where you simply get stuck. The goal is not to eliminate those moments. The goal is to become good at what happens next.

Case interviews become easier to understand once you stop treating them as an academic test. Your interviewer does not expect you to know everything, but they do expect you to listen carefully, bring structure to an ambiguous problem, focus on what matters, communicate your reasoning and respond well when new information changes the answer.

When you practice your next case, imagine there is a real client sitting across from you. Make them feel understood, give them a clear plan, focus their attention on the things that matter and tell them what you are doing. If something does not work, be honest about it and adjust. Once you have enough information, tell them what you think they should do.

That is ultimately what the case interview is trying to find out: can you think and communicate like a consultant when the answer is not obvious?

The only reliable way to get comfortable doing that is to practice. If you want to put these principles into practice, you can try a consulting case on GradGuide, including full voice-based cases, exhibits, interviewer pushback and detailed feedback afterwards.