Basics Approach to Design Case Interviews

This article is for Product Case newbies. Often candidates new to the process don’t understand what companies are looking for in a case interivew and they don’t understand why. If you look at what recruiters tell candidates across tech companies the following themes repeat themselves even outside FAANG (MAANG) companies.

The Design Prompt

To start, you will be given a prompt with a hypothetical problem or opportunity in the technology industry (or random topic). You will work through how to approach it with your interviewers.

Typically, the interview starts with breaking down the prompt, identifying users and pain points and continues all the way through selecting a solution and wireframing it out.

Notes:

• Non-FAANG companies will often give you a topic somewhat related to their industry, but not always.

• Show what you would actually build and how - don't just stay on the surface level.

• Many newbies start with an overview of how they would approach the problem. That doesn’t work. You need to ‘play along’ and assume you are solving the problem in real-time.

What companies are looking for:

• How do you identify users and understand their needs

• How you measure impact and prioritize solutions

• How you construct user flows and make design choices

How they evaluate candidates

The evaluation for the interview is focused on the process you use and your ability to implement it. You don't need to study any particular area ahead of time and no prior knowledge is expected, but some familiarity with the restaurant industry is helpful.

To be honest, you get caught in a ‘Catch 22’ they don’t want you to sound ‘frameworky’ yet they judge you if you don’t foll the basic process: Define the customer > Identify painpoints > Prioritize Pain Points > Establish Goal > Walk through Wireframe of MVP > Metrics (optional)

Key tips:

• Don't just stay on the surface level.

• Don't jump right to features!

• Start with breaking down the problems you're solving (why, users, etc.)

• Start with customer problems before jumping into features.

• Ask questions to get clarity

• But don’t sound like you are fishing.

• It's ok to make assumptions to move forward. Call out your assumptions

• Manage your time to make sure you get to wireframes at the end 

What they are looking for:

• Can you look broadly but then scope an MVP and show the steps?

• Are you a 0-1 strategist and builder

• Can you tie features to problems and workflows.