Showing Analytical Ability During Interviews
In my experience, “analytical ability” is the most nebulous trait to be tested for in interviews. Some companies (mistakenly) equate it with “analytics”, asking you to set success metrics. I think of analytical as the “thinking” portion of your interview — how did you get to your answer, and how robust was your path?
In other ways, how good are you at evaluating information and making a decision?
Let’s dive in.
Don’t Lose Sight Of Your Goal
The rest of this article describes how to make good decisions, but it’s critical that your decisions are made in service of something. The worst thing you can do is spend your time solving a problem that doesn’t matter. If you do, it doesn’t matter how well you solved the problem; the solution was useless.
Product manager interviews are a series of progressive steps, each building on the one before it. Before taking any action, consider this litmus test:
What will I use the outcome of this for?
If you don’t have a clear answer, reconsider what you’re doing.
In fact, this question can be used for more than just a litmus test. It can be the driving force of your entire interview. The forward version of this question is:
What do I need to know to make a decision?
The answer to this often branches. Write down all the thoughts that come to mind and communicate them to the interviewer. If nothing else, it shows the breadth of your thinking, even if you don’t get to everything on the list (more on that later).
Set a Goal
Implicit in “don’t lose sight of your goal” is that you need to have a goal. Ill-defined problems never get solved, and jumping into your answer without knowing how you’ll know when you’ve answered the question is a sure way to spend 45 minutes wandering around.
You should be setting multiple goals as you progress through your answer, with increasing fidelity at each step. Your primary, overarching goal might be given in the prompt: “Build an X for Y.” Other times, you’ll get a shell but have to set your own specifics: “Improve [product].” At these levels, broad, ambitious goals work — they’re really just motivation to jumpstart your creativity.
As you get into personas and painpoints, your goals should start to look like behaviors or effects you want to achieve. For example, “To build a better alarm clock for college students, the clock should disincentivize hitting snooze.” These sub-goals, when taken in aggregate, should achieve your primary goal.
As you get into solutions, your goals should start to sound like acceptance criteria: “It should take at least 3 minutes to snooze the alarm.”
By having a cascading set of goals, each of which serves to achieve the goal before it, you provide a clear and obvious path for the interviewer to follow. They may disagree with how you build each feature (this falls into product sense), but they should understand how you decided on what needed to be built in the first place. Framing your approach with your goals also makes it clear to the interviewer that you’re taking a problem-focused approach, rather than falling in love with a solution too early.
Prioritize Your Decisions
If you’ve structured your interview as a series of goals and repeatedly ask yourself what decisions you need to make to achieve each goal, you’ll inevitably run into the problem of having more paths to explore than you have time for. This is where your interviewer gets to see your prioritization skills.
Understanding why prioritization is an important skill for product managers — and thus why an interviewer would be interested — will reveal how we should prioritize within an interview.
- It shows that you can establish what is truly needed, versus what is nice to have. A saying goes “Anyone can build a bridge that stands. It takes an engineer to build a bridge that barely stands.” Teams don’t have unlimited resources. They need a leader who can maximize results while using resources as efficiently as possible.
- It shows you can accept tradeoffs. Schools produce students who can solve “crisply-defined puzzles”. Unfortunately, companies are not solving crisply-defined puzzles. Maybe the best solution is a 60% solution (an “F” grade) and product managers need to be okay with that.
- It shows you are decisive. Product managers live in ambiguity. At some point, after all your thinking and considering is done, you have to take a step. Take that forward step with confidence.
We can repurpose our guiding principle to apply to prioritization.
“What do I need to know to make a decision?”
becomes
What does my product need to achieve my goals?
Embrace Shortcomings
Chances are you’re not going to be an expert in the domain of your interview question. This is fine. The interviewer isn’t judging how well you know the domain. They’re looking at how you explore, interpret, and react to new problems.
This includes realizing where your solution may have come up short, accepting feedback and advice from the interviewer themselves, or acknowledging when you simply have no idea what the appropriate decision is. In these situations, think about what your ultimate goal as a product manager is.
A product manager’s role is not to single-handedly build the best product. It’s to make sure the best product gets built. If you realize that your solution won’t work, or your interviewer points out a critical flaw, take that information and use it to the greater good of the problem at hand. It can be tempting to take it personally and respond by digging in and defending your original position (especially in an interview setting, I get it). But doing so doesn’t show that you can make the most of information at hand. Imagine what you’d think if a coworker reacted that way in real life.
Work with the interviewer on the problem. If you’re struggling with a decision, explain where you’re getting caught up and see if they have any pointers. If you realize something won’t work, switch lenses, self-critique, and adjust your approach. Ultimately, the ability to digest a stream of new information, respond in real time, and navigate a constantly-updating problem is more valuable than having perfect knowledge on the first try.
Programming-curious?
I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.