Skip to main content

How to Answer Case Study Interview Questions

Premium

In this lesson, we’ll walk through a framework to help you succeed in a case study interview question.

When you receive a “guesstimation” or product question, try solving them by following this GASSS framework:

  • Goal: Listen closely, ensure you recorded the facts and numbers, and agree on a goal.
  • Assumption: Ask clarifying questions and make 2-3 assumptions when your questions aren’t explicitly answered.
  • Structure: Decompose the big problem into smaller potential drivers. Present a framework that combines these drivers.
  • Solution: Check for data on each component, make assumptions if not, and get to the root of the issue.
  • Synthesis. State the solution with the bottom-line up-front (BLUF). Propose next steps and caveat any assumptions.

Case Study Interviews Framework

Let’s say you’re asked, “Views of videos at YouTube are falling. What should we do now?” We’ll walk through the GASSS framework to demonstrate how you’d answer this problem.

Step 1: Goal

These interviews can come in different flavors. Sometimes, the interviewer might begin with a lot of facts or numbers. Other times, they might state something with very sparse information. In both settings, the objective is to listen carefully and take notes when possible.

Once you’ve heard them, take the steps listed below, which you can remember as “LEG”:

  1. Listen closely to the prompt presented.
  2. Ensure you have recorded all the facts and numbers correctly. To do this, say them out loud back to the interviewer
  3. Goal: agree on a goal for this problem. Do they want a final number, diagnosis, explanation, or recommendation? For instance, you might be asked for a number by which YouTube video views fell or the cause of this decline or a recommendation for what to do. Even though some practical steps might overlap, these are different goals to solve for.

Step 2: Assumptions

In order to solve the problem, you typically need to make assumptions or ask clarifying questions.

When making assumptions, some suggestions include:

  • Take 1-2 minutes to come up with these.
  • Jot them all down as they come to mind.
  • Before stating them out loud, consider which ones you really want to make.
  • Usually, 2-3 assumptions are needed to make progress on the problem.

It’s best to be explicit about what you’re doing. Say that you’re making assumptions or choose to clarify any of these points further. In both cases, you want to indicate to the interviewer that they should correct you if something isn’t right.

Clarifying questions vs. assumptions:

  • It’s usually best to ask clarifying questions first and then make assumptions if/when your question isn’t explicitly answered.
  • You can also make this a two-stage process, where you go through your questions first and then explicitly come up with assumptions next.
  • This approach is usually best for cases with a lot of facts and figures, while melding assumptions and questions can work for “information-sparse” prompts, where the interviewee is likely to want you to take the lead with very little information.
  • “I’m going to assume video views fell across all YouTube markets” (assumption) vs. “Did views of videos fall across all markets?” (clarifying question)
  • “I’m going to assume video viewing duration also fell as views fell” (assumption) vs. “Did viewing duration also go down?”

Step 3: Structure

A good structure for a problem is almost always the key to succeeding in a case interview.

A good structure takes an amorphous problem and puts reasoning around it, typically by decomposing a big problem into smaller potential drivers or attributes.

For example, video views could be falling because:

  • People are viewing fewer videos (drop in consumption)
  • Fewer people are viewing videos (drop in users)

A good structure also involves MECE components: Mutually Exclusive, Collectively Exhaustive.

For example, the drop in new users could be driven by a drop in

  • New users or old users (exclusive: since a user can only be new or old, and exhaustive: together, old + new users make up the entire user base), or
  • Young users or old users

As you can see from the example above, there are many ways to “structure” a problem, and even more ways to bucket each component into MECE drivers. For example, you can segment into drop-in views by platform (web, mobile, tablet) directly, instead of usage and users (and type of user).

Collaborate with your interviewer on what approach might make sense. Often, they can nudge you in the right direction. Don’t be afraid to try 1-2 approaches and select the one that feels easiest to work with.

Some structuring approaches include:

  • By “person traits”
    • demographics (age, sex),
    • socioeconomics (education, income),
  • By “usage pattern”
    • Platform (iOS, Android OR mobile, web, tablet)
    • Usage amount (power users, modest users, infrequent users)
  • By geography
    • Nations
    • Urban vs. rural

This might not work for every problem. For “brainteaser” style problems, like tennis balls in planes, don’t worry about MECE buckets, just create a reasonable structure (e.g. # of balls = volume of plane/volume of a single ball)**

Create an explicit framework

Once you have selected a structure, present your framework by laying out how the chosen structure returns the main quantity of interest.

Total drop in views = drop in views on mobile + drop in web + drop in tablet

Step 4: Solution

Now that you have your components, your structure (set of components), and a framework (how you combine the components) for how they all tie together, go through them one by one by:

  1. Asking if there’s data on them/behavior of each component
  2. Make assumptions if there are not
  3. Get to the root of the issue (and do any math necessary to get there)

When you ask if there’s data, the interviewer might tell you how much drop each platform saw, and then you can use that data to assess where the problem lies.

If they don’t have data, you could guess that the rise of competition from, say, Instagram Reels or TikTok probably led to a drop in mobile, and (then for step #3), say you’d want to look into that further.

If the math is getting really complicated, you’re probably making a mistake. Take a pause, zoom out and confirm you’re on the right path.

When doing the interview, don’t worry if you spend almost ½ to ⅔ of your time landing on a precise goal, with a clear set of assumptions and a solid framework. This is often the meat of the work, after which “solving” the problem should be fairly quick! If there is actual data to work with (which your interviewer might hint at in the beginning, then it might take a bit longer, but leaving ~33% to 50% of time for these last two sections is usually plenty!)

Step 5: Synthesis

Once you’ve solved the problem by getting to the root of it, state the solution with the bottom-line up-front (BLUF) principle in mind. Your synthesis should:

  1. Repeat the goal
  2. Use the BLUF principle
  3. Repeat the structure
  4. (optional) Mention context/factors
  5. Propose next steps
  6. (optional) Caveat any assumptions or unknowns

"We wanted to determine why views on YouTube videos were falling. We learned that the drop in views was driven by a drop in mobile views). This was because we structured the drop in overall views as being driven by a drop in mobile, web or tablet use, and learned that X% of the overall drop came from mobile. We think this could be because of the rise of competition like TikTok drawing away users. To confirm this, we could run a survey on users who also use TikTok, or we could collect demographic information to assess the ages of users who are viewing fewer videos, since we think primarily young/Gen Z users have adopted TikTok. We assumed that usage drop was universal across markets, but if this is not true, we might want to pursue an alternative approach."

Tips

  • Solve the right question. Confirm you’re solving the right problem (e.g. views vs viewers or viewing hours) and don’t be afraid to revisit what this is as you start getting into the weeds of your solution. At the end, especially, make sure you end up with a synthesis or solution that solves the main problem.
  • Talk out loud and make it conversational. Frequently check-in with your interviewer and communicate with them so they know what you’re thinking. In particular,
    • Explicitly agree on a goal
    • State your assumptions
    • Articulate your structure/framework
  • Use yardsticks from your life or general knowledge. If you’re sizing an airplane, think about the last time you were on one. You know your height, so that could be a good way to estimate the height of an airplane body (e.g. it could probably fit 4-8 of you stacked from base to top, including cargo). You can also reference Exponent’s Quick Reference for Estimation Questions.
  • Frequently summarize. When moving between segments of the case, it can be a good idea to quickly summarize what you just did in 1-2 lines and then say what you’ll do next (e.g. We just broke down views into mobile, web and tablet; next we’ll look into how much each dropped by so we can diagnose the overall issue).
  • Decompose the problem. Don’t chew off the whole problem in one go, and don’t guess the final answer at the outset (e.g. “It’s definitely because of TikTok.” Even if you’re “right”, you’ll miss the actual point of the interview, which is to communicate how you think.)
  • Smart simplification is key. Simple is better; make things linear where possible (i.e. components that can be multiplied and added to get to the final metric of interest), and don’t overcomplicate the buckets (e.g. by getting into nuances that can be avoided, like people watching YouTube on their Tesla screens, which is neither web, mobile or tablet)
  • Don’t be in a rush. Most of the hardest parts are agreeing on a framework (as defined in step 3), which comes first, so don’t rush it. You often have a lot more time than you think. Similarly, don’t be afraid of silence or to ask for time to jot notes down or think to yourself.
Next Lesson