In case interviews, some candidates always seem to get “stuck” in a case — unsure how to proceed.
Other candidates “ace the case” and never seem to get stuck at all.
Why does this happen?
The short answer is this:
You only get stuck in a case if you skip steps. If you never skip steps, you never get stuck!
While today’s question of the day is from CIB who wanted clarification on using creativity in case interviews, as you’ll see in my reply, today’s topic is really about how to avoid getting stuck in a case.
Read on for details.
*** Should I Use Intuition in my Case Interviews? ***
Email:
Victor,
I just had a quick opinion question. I spoke to a friend of mine, ex-Mckinsey consultant and interviewer.
He said, when I asked him about casework and interviews, that there is a key that many people who employ solely the framework miss out on. It seems a bit different from some of the advice given in your lectures and information.
He stated that when given a case to work, any kind of problem the first thing you should do is intuitively solve the problem as quickly and accurately as possible, not waiting til the end of a case interview to describe a solution backed by data.
Then during the rest of the interview utilize frameworks to check the completeness of your solution and to give data driven support to a conclusion.
What do you think about that, it suggests a different style of approach and ideas, and in his mind is the difference between someone feeling around for the right answer, and someone intelligent and reasonable enough to have the right answer. AKA the difference between receiving an offer and almost receiving an offer.
My Reply:
At first glance, it would seem your friend’s perspective differs from the advice I’ve given previously. But, it really is not very different at all — though your friend and I are using different terms to describe the same thing.
When your friend says you should try to “intuitively solve the problem as quickly as possible…,” I would simply use the word “hypothesis” instead of that entire phrase.
So to rephrase using the terminology I’ve been using, your friend’s advice is to avoid relying only on a framework and producing a solution at the end, and is instead suggesting that you state a hypothesis immediately or very early in the case and use a framework to validate/test your hypothesis.
So intuition, business acumen, or common sense is very useful in formulating a hypothesis.
The same intuition is much less useful when you’re trying to logically prove/disprove the hypothesis — where logical and structured analytics are more useful.
The problem your friend sees in many candidates (and I see as well), is some candidates only use a framework without a hypothesis.
This is a big mistake.
When approaching a case problem, you should be stating a hypothesis within the first six minutes of the case.
Sometimes you can state a hypothesis immediately at the start of the case. Other times, you can ask a few questions, get some general information first, and then state a hypothesis.
I personally prefer the latter approach of asking a few general questions first, before stating a hypothesis.
But either approach is acceptable, provided you do the other aspects of the case well.
What isn’t acceptable is to start off asking some general questions intending to state a hypothesis but getting so absorbed in the case that you forget to state a hypothesis.
When you only use a framework (without a hypothesis), then you are not really problem solving. You’re just memorizing a list of questions (associated with the framework) and reciting them to the interviewer.
This is not the skill they are looking for.
Now let’s take this line of reasoning one step further.
When you use intuition to formulate a hypothesis, it is very important that your hypothesis is your educated guess about defining the (underlying) problem the client faces.
Many intuitive problem solvers will use intuition to come up with a solution for the client before they’ve determined what the problem is.
This is a big mistake.
For example, the interviewer will say, “The client’s sales are down, and the client wants your help to figure out how to get sales growing again.”
An intuitive problem solver might immediately say, “The client should create a more generous sales compensation plan to boost sales.”
This is a solution.
The problem with a solution is it is analytically difficult to prove whether or not the solution is the correct decision.
It is far easier to test a hypothesis about the problem.
For example, let’s say intuitively, you think it is a sales compensation issue.
What you should say is, “My hypothesis is that the client recently made their compensation plan less generous, which resulted in a decrease in sales.”
While the phrasing is only subtly different, this latter phrase can be tested.
A single piece of data can disprove this hypothesis. All you need to know is “Did the client change the compensation plan recently?”
If the answer is “No,” then the hypothesis has been disproved and would need to be revised.
It is worth re-reading the past few paragraphs several times until you grasp the nuanced difference between the two approaches.
Both approaches involve a degree to intuition, but if you use the first approach, 95% of the time that results in a rejection.
Even though it might be only the first 20 seconds of a case!
The reason is when you start with a hypothesis that cannot be proven or disproved, then your framework or issue tree is going to be compromised.
You will never be able to make a definitive conclusion on any branch of your analysis and thus will never be able to reach a definitive conclusion for the case overall.
This is what a sub-par candidate does… they end up getting stuck because they structured the case into an unsolvable problem.
So long story short, always make sure your hypothesis includes an explicit definition of the problem and you will be fine.
In cases and in client work, 80% of the difficulty is in isolating the underlying problem causing the “symptoms” the client does not like.
Once you figure out the problem, the solution is often very obvious. In a 40-minute case, it’s not at all unusual for me to spend 39 minutes isolating and defining the problem and spend one minute recommending a solution.
Here’s another way of making this point.
If you are getting stuck in your practice cases, it is because you skipped a step — usually without realizing it.
If you never skip steps, you never get stuck!
So in your hypothesis statements, define the problem explicitly… don’t skip this step!