Question:
Greetings from Croatia,
I am very happy to say that by following advices and materials from your site, I have been able to secure a McKinsey interview with the Zagreb Office.
I’ve been preparing for this for the last four months now, and your site has been the central point of resources and information I needed.
Following your advice, I took a lot of effort in polishing my solid (but far from stellar) CV and consulting cover letter, and used networking extensively to get in touch with their former employees that gave me the green light to apply.
McKinsey accepted my application and I am officially to interview with them in two weeks.
LOMS has been, by far, the most valuable resource I used so far, and I believe will give me the necessary edge in the days to come.
Thinking about the interview process getting closer, I would like to pose a question regarding changing the issue tree (structure) of the case during the interview.
Namely, what happens when I open the case, structure my issue tree, start the analysis, but during the process realize that my issue tree is bad and will make it very difficult to crack the case (for example, we segment the revenues in a non-optimal way).
Is it viable to say, halfway through the analysis, that I wish to change my approach for this part of the analysis or the entire case?
Would this be seen as a big error, and what to do if that happens?
Thank you for your time, and I hope next time I write it will be for your “success story” section.
My Reply:
It is perfectly acceptable to revise your issue tree or framework in the middle of a case.
In fact, in a real life client engagement, this is actually quite common.
Often, the engagement manager will restructure the issue tree every two weeks (typically lower level branches, sometimes by a little, sometimes by a lot).
The key is why you switch the issue tree mid-stream.
If you made a mistake and simply forgot something you should have included originally, that’s not ideal. But, it is better to self-correct your own error than to pretend you did not make it… somehow hoping the interviewer did not notice.
This might even rescue the case in that the interviewer might decide to pass you to the next round, but with some slight hesitation.
As opposed to not passing you to the next round at all — which would be more common if you left something important out of the issue tree and if it was a glaring omission.
Now if you change the issue tree because you have:
1) discovered new information about the case that was not known to you when you created the original issue tree, and
2) you’ve revised your hypothesis given this new information, then revising the issue tree would be considered normal…
In fact, if you did not revise the issue tree in face of this new information and it clearly warranted a change, then failing to revise the issue tree is grounds for being graded a poor performer.
This is one of the top complaints of interviewers about candidates who start with a framework and keep sticking with a framework after there is sufficient information about the case to show it is the wrong framework.
I describe this candidate as overly framework-driven, rather than hypothesis-driven (the latter being preferred even if at the start, both types of approaches might start off exactly the same way).
So it would not be unusual to start a case with a profit framework, and then as you discover more, move to another framework or a custom issue tree.
Sometimes the initial framework or issue tree is wrong, but it is impossible to know this in advance. You have to use the framework and discover it is wrong, and then switch.
When I interview a candidate and I know they choose the wrong framework to start (but had a reasonable starting hypothesis), at this point I would not consider the performance poor.
Rather, I would consider the candidate’s performance interesting — interesting for me as the interviewer because either the candidate will perform in disastrous fashion or in a brilliant one… but probably nothing in between.
Specifically, I will look to see at what point the candidate:
1) realizes their initial hypothesis is wrong.
2) will revise their hypothesis (at the first logical opportunity, or only after several factual “hints”)
3) if/when they revise their hypothesis, will they revise their issue tree to be consistent with the NEW hypothesis or stubbornly (or out of unthinking memorization) stick to the issue tree for the previous hypothesis?
So in many respects, this kind of case is a more useful case for an interviewer to give, because it tests these skills in way that more clearly differentiates a strong vs. weak performer — particularly in comparison to a case where the candidate gets the initial tree right out of either insight or luck.
I will say this, when a strong performer revises the issue tree, they do so immediately after the factual information revealed in the case clearly and logically contradicts the original hypothesis.
For the mid-level performer, it might take two or three factual contradictions to the original hypothesis to prompt the candidate to switch the hypothesis and the underlying issue tree.
This is what an interviewer means when they give the feedback that you are “lacking business acumen…. or business judgment… or lacking insight… or analytically slow”.
These are all code word phrases to indicate that facts were revealed in the case to indicate your hypothesis was wrong, but you did not notice it…. (often because you had some “pet idea” that you were just certain was right, and pretty much ignored all data to the contrary).
That is a big problem… even if you get the case “answer” right.
So in your case interview preparation, it is important to remember that getting the case right is not enough. How you get the case right matters a lot too.
This is why some candidates who feel like they solved the case correctly are frustrated when they do not pass that interview.