How to Work Through Case Interview Frameworks

twitter Facebookgoogle_pluslinkedinmail

Question:

I have a question about working through case interview frameworks. In the Signs example case from the Look Over My Shoulder® recordings, I noticed that the first two candidates did not look at the cost side of the profit tree.

When starting with a profit tree, should we examine both branches before moving to the business situation (or what ever direction the information leads) or is it okay to come back to it later?

Will you get dinged if you solve the case and never look at the other side of the tree (even if it is a dead end)?

My Reply:

The short answer is YES, YES, YES... if you get the right "answer" to the case, but you do it the wrong way, you will absolutely get dinged.

It's also the kind of ding (U.S. idiomatic expression for getting rejected) that frustrates candidates because in their view they got the "answer."

When using any framework, it is important to acknowledge all the branches in the framework. It is recommended to focus on the branch of the framework most likely to be most useful first.

It is not okay to completely ignore the other branches.

The way to say this is, "My hypothesis is the profitability problem is driven by a revenue issue, not a cost one. But, let me draw out this issue tree (see Look Over My Shoulder® program for example issue trees) to show both sides. I'd like to start first with the revenue side, and if necessary circle back at a later time to the cost side."

This shows you have considered both (or all) branches of the framework, you are picking one to start first (as opposed to ignoring all the other branches).

Let me explain why you want to do this.

As an interviewer, I can't tell if you chose to start with Branch 1 first, or if you just completely didn't notice or flat out ignored all the other branches.

As an interviewer, my tendency is to assume you ignored / didn't notice the other branches. This is an offense quite worthy of rejecting a candidate.

Notice the sample issue trees in Look Over My Shoulder® and you will see that if you take notes using the issue tree approach, it is nearly impossible to ignore or forget about other branches of a framework.

So let's say in a profit framework, you guess it's a revenue problem. You analyze revenues, but never look at costs, and you end up being right  -- it's a revenue problem. There's a good chance you'd still get dinged.

Especially in a mathematically complete framework like profitability (as opposed to a conceptual framework like business situation), it is better if you gather enough data on a branch to eliminate it as a possible cause of the problem.

Or quite commonly, it can be a compound problem... so maybe most of the financial impact is on the revenue side, and the cost side has some impact.

It's useful to "size" the contribution of each side (e.g., revenue decline is causing 80% of the profit issue, escalating costs is only contributing 20% of the profit decline issue) and FOCUS on the branch that's the PRIMARY DRIVER (you will hear that term "driver" a lot amongst consultants)... while ACKNOWLEDGING there are secondary drivers/causes that you PLAN TO ANALYZE... time permitting.

(This gives you full credit for seeing all the causes... as opposed to not verbally saying anything I've written in ALL CAPS and the interviewer assuming you didn't notice any of the secondary drivers.)

Incidentally, when a candidate is given the feedback that they are not quantitative enough, very often it means that in the scenario above they will not mathematically "size" the impact of each branch to figure out quantitatively which branch to focus on. Instead, such a candidate will say, "it seems like this is probably more of a revenue problem (but they didn't do the math to quantify the impact), so let me look at the revenue branch."

No, No, No!

As a consultant, you need to use data to justify your next steps. If quantitative data is available and you don't use it, that reflects poorly of you.

There are times when the quantitative data is inconclusive, in those times you use qualitative data.  Generally liberal arts type background candidates make the former error. Those with PhDs in math and hard sciences make the latter error.

(Incidentally, people who are not quantitative enough do not ask enough what questions -- what % of the profit decline came from a drop in sales.

Those who are not qualitative enough - don't ask enough how and why questions... as in transportation costs have gone up for the client, but not for the rest of the industry.)

How does the transportation process work for our client compared to the industry? Why do such differences exist? Notice the answers to these questions are conceptual and not numerical. People with PhDs in technical fields make this mistake all the time.

There are numerous examples of both types of error (not quantitative enough vs. not qualitative enough) in my Look Over My Shoulder® Program, and I discuss this topic in excruciating detail in my commentaries on the interview recordings in that program.

So circling back to your original question, on a quantitative framework like profitability, it is useful to use process of elimination to eliminate branches that are irrelevant before drilling deeper in your primary hypothesis error -- but only if it can be done quickly.

And often in numerically driven (as opposed to conceptually driven) frameworks or issue trees, this can often be done by asking one or two key questions.

In a conceptual framework like the business situation framework, you do not want to cover all the branches before drilling deeper in your primary hypothesis area. This is because it will take too long to do so. You will run out of time.

This is the complaint that many interviewers have when a candidate is "overly framework-driven." As in - they uncover some interesting insight, they could have developed a hypothesis and used it to guide the rest of their case... but instead, they just jumped to the next branch of the framework asking their list of 101 standard questions.

The right balance is to use the framework to start and to keep using the framework until you discover some interesting piece of qualitative or quantitative data that allows you to form a hypothesis.  Then you state that hypothesis out loud (interviewers can not read your mind, and they can not read your handwriting upside down).

Then use the hypothesis to drive what information you need next to test this hypothesis.

It is quite possible to go through the business situation framework, do a customer analysis, discover enough information in your customer analysis to form a hypothesis.

Instead of just moving on to competitor analysis, it would be much better to form a hypothesis and let that drive the rest of the case. In all likelihood you will have to ask competitor questions, but it would be better if the competitor questions were restricted to only those questions needed to prove / disprove the hypothesis.

In practice, the questions asked in a hypothesis driven phase of a case is a subset of the questions that are included as part of the standard framework when you don't yet know enough to form a hypothesis.

Please re-read that last sentence. Many offers were lost on not fully appreciating that last point.

For more case interview preparation resources, review my free video series on Case Interview Secrets .

Additional Resources

If you found this post useful, I suggest becoming a registered member (it's free) to get access to the materials I used to pass 60 out of 61 case interviews, land 7 job offers, and end up working at McKinsey.

Members get access to 6 hours of video tutorials on case interviews, the actual frameworks I used to pass my interviews, and over 500 articles on case interviews.

To get access to these free resources, just fill out the form below:

First Name *
Email *

Note: All registrations require you to confirm your email address.
Please type your email address carefully, entering your email also subscribes you to my Case Secrets Email Newsletter.

Facebookgoogle_pluslinkedinmail twitter
0 comments… add one

Leave a Comment