A good page to learn about Case Interview McKinsey
Candidate-led cases are interesting but also very difficult especially for beginners. I personally really like these cases because it represents very well how an actual consulting project works and the role of the engagement team in it.
So rather than talking specifically about how a candidate-led case works, let me introduce you to the LOGIC behind management consulting “Problem Solving Test”. It’s ironic that many experienced candidates, having practiced 20 30 cases, actually don’t grasp this very well. That’s why even with that much practice, they can still struggle in certain cases and still feel like they need even more practice.
Well, practice is good, but only when you have mastered the basics. So here we go: the core logical foundation of how management consultants solve problems. We talked a little bit about this in the Case Interview 101 video but here is the much more in-depth explanation. To make this as easy to follow as possible, I divided the whole concept into bite-size elements with numbers.
Element No.1: The problem has to be defined
Element No.2: To solve a big problem, we – management consultants don’t look for solutions right away. Instead, we try to find the ROOT-CAUSE. This ensures us to completely eradicate the problem and to have a long-lasting impact.
Element No.3: There can be millions of possible root-causes. To effectively and efficiently find the right one, we use a top-down and MECE approach. This is called an “issue tree”. See our MECE and Framework video for more details.
Element No.4: In order for each branch to exist in the issue tree, there HAS to be a chance that the Root-cause is in it. Or in other words, for every branch, there must be at least one hypothesis associated with it.
Element No.5: Now assume we have a structured, MECE, and hypothesis-based issue tree. Pick the best hypothesis, or, in other words, choose a big branch to begin with. Then test if the root-cause is in there.
Element No.6: Depending on each case, different methods are used to test hypotheses. But generally a powerful tool is to use benchmarks. Two main types of benchmarks are historical and competitors’ data.
Element No.7: If data suggests that the root-cause is indeed IN the testing branch, go down one level deeper and repeat the same process: breaking down the branches into sub branches in a MECE, hypothesis-driven way and test each sub-branch using data. See case interview examples and answers
Element No.8: At any point where the data suggests that the root-cause is NOT in the testing branch or sub-branch, move to a parallel branch or sub-branch on the same level.
Element No.9: Keep doing this until the whole issue tree has been covered or until the interviewer would like you to switch gears.
Element No.10: Lastly, once you have identified one or many root-causes, think of solutions to fix them!
In theory, the above approach always works. But the following two conditions must be met.
Condition No.1: each and every single part of the issue tree must be perfectly MECE.
Condition No.2: the issue tree, or in other words, the breakdown must somewhat properly isolate the root-cause.
A few tips to meet those conditions:
(1): Make sure you understand the concept of MECE really well. Please refer to our MECE video for more detail.
(2): Try to improve your business intuition in order to be able to pick good frameworks or correctly draw spot-on issue trees. We devoted a whole eBook in our End-to-end program for this.
(3): Most importantly, develop the habit of aligning with the interviewer. No matter how good you are with the two tips above, there will always be cases that are hard to be MECE inside out and hard to draw frameworks that are spot on. The interviewer is actually a great resource you can use.
You should use Case Interview End-to-End Secrets Program for exclusive practice cases and insightful tips!