Thanks for your great resources on caseinterview.com!
I got an offer from McKinsey in Europe and I think a huge part of my success is thanks to your videos. They were not only interesting but also very entertaining!
I could implement most of your recommendations. When I got the case I stalled and said a similar phrase like your "Thats an interesting question!“ Two out of 3 cases I really had no idea of how to solve it! Then I repeated the question, verified my understanding and terminology and then I took a pause. I made some hypothesis, drew assumptions from them and then I asked for data using your great business situation framework!
I had practiced to use the framework dozens of times before and like you predicted by the time I got more and more flexible! At the interview, I only picked out a few relevant questions from your framework.
Your best advice however was: “When in doubt – segment!” About two times I felt I was lost and had no idea of how to continue. So I just asked to break the problem into pieces and in both cases the interviewer provided me with data.
I really liked the process: opening the case, structuring the case, closing the case. Although I had some difficulties with closing the case – It was not so easy to apply the pyramid principle and the conclusion –recommendation – data – data – data principle, but I did well. When I started with the case I just imagined that it were a real client situation – immediately I felt comfortable.
I read many books on how to ace the consulting interview but I think your resources have been the best. Not only did they provide the best insight into the case interview and of how to solve the case but they were also fun and entertaining. I got a good idea of consulting!
I offered my private congratulations to the person who got this offer. His email reminded me of a few pointers that I think are worth emphasizing / re-emphasizing.
1) When in doubt SEGMENT.
I do this literally everyday in my client work these days. Aggregate numbers like total sales, total profits, total costs often mask underlying dynamics of what's going on in a business. So when you don't know what to do, just segment the data you've been given.
This act alone will often uncover interesting patterns that will help you generate a more data-suggested hypothesis.
Also in real consulting engagements, this is quite often the first few weeks of a real client project. When we don't know much about a new client, we will often take their baseline numbers and spend a 1 - 3 weeks segmenting them (the term dis-aggregate is often used to describe the same process).
2) The Business Situation Framework is a Framework, not a Checklist
The idea of the framework is to help remind of you of all the key issues that could be relevant. It is a big mistake to mechanically go through each item in the framework. You might start that way prioritizing the key issues in the framework that your intuition and judgment suggest might be most important, and then what usually happens is you stumble upon some key piece of information.
Often this information prompts a new or refined hypothesis, and then you drive the rest of the case trying to test/validate your hypothesis.
In some situations, when time permits, you might chase down that new hypothesis to its logical conclusion, and then go back to the original framework. For example, in a profit = (revenue - cost) framework, you might start with revenue, find some new information about where the revenue is coming from... switch to the business situation framework to better understand the customer and competitor dynamics... close out that analysis, and then it would be perfectly appropriate to cycle back to the cost side of the original framework (assuming you hadn't done any analysis in that area up front).
This is what we would typically do in a real client situation. In a case interview situation, often you simply run out of time and often don't get to explore the rest of the original framework. Or sometimes the interviewer knows that a particular part of your analysis, in this example costs, is a dead end (because the interviewer did the actual analysis in real life) and will push/nudge you to say the revenue side of the framework because they know that's where the interesting data resides.