Featured Post: Why the right answer is not enough!
Sarah Chang is a Columbia University graduate who will be joining McKinsey later this year. I came across a recent post of hers, and asked for permission to reproduce, which she has graciously agreed to.
She catches on to a few things that many students overlook. I always teach students the art of assumption-question, to always link numbers back to the original questions, to ask "so what?" and other tips and tricks that help you stand out as a candidate. It's a long list but worth the read. Her one mistake? Not numbering her points, in true consultant fashion!
The recruiting season for summer consulting internships is kicking in, and many friends have been asking me to case cram in preparation for their upcoming slew of interviews. I'm more than happy to share tips from my experiences, as I've found the general advice of "case, case, case until you've practiced at least 50 cases" to be a bit misguided.
Being exposed to so many different scenarios may let you "crack" any case, but often it's not sufficient. I think there are a few things people tend not to do enough, and these also happen to be the things that really impress interviewers. As you ramp up for your big day, I hope you'll find the following helpful to keep in mind.
Aim for specificity and ask for more details during the case setup. Immediately after the case narrative is a perfect time to ask questions for more strategic details that can help you form an attack plan. In some of my interviews, the interviewer surprisingly hinted at the "key" to the case when I probed a bit more about the industry. For instance, if it's a market entry in a particular country, asking "Just curious, why this country?" can give you some clues and motivations behind why there's a problem in the first place. Careful though - strike a balance between asking for contextual background and overly detailed information that belongs later in the case.
Isolate the real crux of the problem. Too often, people try to force-fit canned frameworks without thinking about where the core of the problem hinges, and it completely defeats the point of doing a case. Instead, it's helpful to rephrase the objective. For example, if the question is whether or not to launch a new line of business, say "So what we're really trying to determine here is if the incremental increase in revenue outweighs the incremental increase in costs", not just "I want to look at profitability broken down into Revenues and Costs".
Be conversational and raise interesting points. In general, the interview shouldn't be one-sided. Don't suggest that you're looking for guidance from the interviewer, but it is perfectly acceptable to ask questions and make the the interview seem more like a discussion rather than a quest to find the "key" to the case.
Be mindful of your frameworks in terms of depth vs breadth. Be exhaustive in the minimal amount of information you need to form a firm conclusion, but within this breadth, develop several nested layers of analyses that show your depth of thinking.
Communicate clearly why you're asking every question. The easiest way to lose your interviewer or appear unstructured is if you haphazardly ask questions, even within each section of your framework. Say explicitly why you need this piece of information and what it will allow you to confirm or disprove once you receive an answer. For instance, "Do we have a breakdown of customer segments? I'd like to see which of our customers contribute most to our profits in order to know who we should prioritize in customer retention."
Make sure every question you ask leads you to an actionable answer. This is a followup to the previous point. Try not to ask seemingly related questions that don't actually get you closer to a recommendation. If the case is on cost-cutting strategies, sure Profit is made up Revenues and Costs, but you don't have to analyze revenues just because it's in the Profit equation. This also goes back to an earlier point of isolating the crux of the problem. Otherwise, it seems unfocused and directionless. Essentially, before you ask a question, check to see if it's oriented towards giving you something that helps you get to a conclusion. If not, you probably don't need to ask it.
When you calculate something, see if there's a simple follow-up calculation you can do to put the number into context. It's always good to put any calculation into context. If you've just discovered that you can save 25% by outsourcing to China and know that your total costs right now are $100m, you should apply both these numbers together and conclude that "Outsourcing seems financially viable since we could save $25m in costs, which is significant considering that profits are $90m." The calculation suddenly gives meaning to the data you already have and supports the decision to outsource.
At the end of any calculation, proactively discuss the implications and what they mean. Don't wait to be prompted by the interviewer! Once you reach a number, immediately jump into why this number is important and what it means for the situation. Explain the impact and how it informs the rest of your analysis.
Work your math out loud. Talk through equations you're going to use as well as your calculations. If there's a mistake in the logic, it's possible the interviewer will correct you if you've done well so far. Always double check your final answer before you announce it. For the non-engineer, you should also be able to do simple math calculations in your head and be very familiar with manipulating the zeros in millions and billions. Practice percentages - you should immediately know that 60% of 3 million is 1.8 million, etc.
Incorporate recent real-world trends into the discussion. This helps the case be more conversational and demonstrates applicability of your analysis in the real-world. For instance, if the case is on healthcare or hospitals, find a way to tie in how ObamaCare might impact the situation.
Look for second and third level insights. This is perhaps what people forget to do most. You're not there to crunch through numbers to determine that indeed, a particular market is big enough for a new business to reap a sizable profit. Anyone can do that. The interviewers are testing you to see if you have the business acumen to, for instance, figure out the relationship between adjusting price and how customers/competitors will respond, why they might respond in that way, and what this means for your approach to the problem. Always probe beyond the "no-brainer" surface level observation and show you're considering multiple tiers of the problem.
When asked to brainstorm, create categories before listing ideas. Ask for 15 seconds to think, form some groups such as "Internal" versus "External", and list your creative, brainstormed output within these categories. Then you can report back and say "I believe there are two categories of risks--internal and external. For internal, I'm thinking X, Y, Z." It creates so much more structure and makes it easier to follow your logic.
Summarize before moving onto the next area of analysis. At any given time, the interviewer should know exactly what you have already analyzed and how that relates to what you're currently analyzing.
To find risks, revert back to assumptions. This is something I've found really helpful. If you're being prompted about potential risks for your recommendation, go back to the initial assumptions you made and say why they make your recommendations less reliable. For example: "One risk I see is that we previously assumed the military was X million people. However, if the government decides to downsize the military in the next few years, then our market may not be as big as we projected." It may not give the most insightful risks, but at least you've got somewhere to start.
Give your recommendation first in your summary and then back it up concisely with one quantitative and two qualitative pieces of evidence. Most case interview books suggest this, but it's easy to get jumbled in all the data you've uncovered by the end. Depending on your case, you may have more quantitative evidence, but it's good to give some specific numbers at the end to highlight the most important of what you calculated earlier.
It's okay to give conditional recommendations. It doesn't have to be black or white. You can say "Company A should enter Market B only if they are sure they can capture 20% market share in the first year." It adds complexity to your analysis but still keeps it highly actionable and specific.
Outline risks and next steps at the end. Again, don't be prompted by the interviewer to bring up potential risks for your recommendation. You should be thinking ahead and explaining what your assessment may have missed, or other data that would have been helpful to formulate a more robust analysis.
It takes much more than just getting to a final answer to pass a case interview. Case interviews are 50% content and 50% how you present your content (in a clear, structured way). If you simply barrel through to arrive at a final answer, but miss the nuances and extra considerations that prompt discussion, chances are the interviewer never had a chance to really see how you think. At last, some good general advice I heard was to "bring a high energy version of yourself," as it shows you're genuinely interested and curious about solving problems together. It's a lot to keep in mind, but I think while most of these points are never explicitly covered in any of the popular case interview books, they're equally if not more important than reaching a "right answer".