The analytical interview is where PMs prove they can work with data—or reveal that they can't.
The format varies. Sometimes it's a metric diagnosis: "Conversion dropped 15% last week. How would you investigate?" Sometimes it's experiment design: "How would you test whether this feature is working?" Sometimes it's pure math: "How many gas stations are in the US?"
What they're all testing is the same: can you think quantitatively about product problems?
Let me walk through the main types and how to approach them.
Type 1: The Metric Diagnosis
This is the most common format. Something changed, and you need to figure out why.
Classic prompt: "Our daily active users dropped 10% month-over-month. How would you investigate?"
The Investigation Framework
First: Clarify the context
"A few questions before I dive in. Is this a sudden drop or a gradual decline? Did anything notable happen—releases, marketing changes, seasonality? Is it global or concentrated in certain segments?"
This isn't stalling—it's showing that you know context matters.
Second: Segment before diagnosing
The biggest mistake is jumping straight to hypotheses. Before you diagnose, break down the metric:
- •By platform: Is it iOS, Android, or web?
- •By geography: Is it global or specific regions?
- •By user type: New users or existing? Paying or free?
- •By acquisition source: Organic or paid?
- •By time: When did it start? Gradual or sudden?
Often, the segmentation itself reveals the answer. "DAU dropped 10%" becomes "DAU dropped 30% on iOS, unchanged elsewhere." Now you have a much more focused problem.
Third: Generate hypotheses based on segments
Once you've narrowed the scope, hypotheses become more targeted:
- •If it's iOS-only: Recent app update? iOS version issue? App Store changes?
- •If it's new users: Acquisition changed? Onboarding broken? Marketing campaign ended?
- •If it's sudden: Deploy broke something? External event?
- •If it's gradual: Product decay? Competitive pressure? Seasonal?
Fourth: Prioritize investigation
You can't check everything. Prioritize by:
- •Likelihood (based on what you know)
- •Ease of investigation (quick wins first)
- •Impact (focus on the biggest contributors)
"I'd start by checking whether any releases went out last week, since iOS-specific bugs after deploys are common. If that's clean, I'd look at acquisition mix—did the paid campaigns change? Then I'd dig into the funnel to see where specifically users are dropping off."
Fifth: Know what data you'd need
End by specifying what you'd pull:
"To investigate this, I'd need DAU broken down by platform and acquisition source over the last 8 weeks. I'd want the release log to see if anything shipped when the drop started. And I'd want funnel conversion by step to see where in the journey users are falling off."
Sample Metric Questions to Practice
- •Our signup conversion dropped 20%. How would you investigate?
- •Revenue is up but user count is down. What might be happening?
- •Time in app increased but purchases decreased. What would you look at?
- •Free-to-paid conversion dropped in one country but not others. How would you approach this?
Type 2: Experiment Design
These questions test whether you understand how to run valid experiments.
Classic prompt: "You want to test whether a new checkout flow increases conversion. How would you design the experiment?"
The Experiment Framework
Define the hypothesis
Start with what you're trying to learn: "Our hypothesis is that the new checkout flow will increase purchase conversion by reducing friction."
Define success metrics
What will you measure?
- •Primary metric: Checkout conversion rate (started checkout → completed purchase)
- •Secondary metrics: Revenue per user, cart value
- •Guardrail metrics: Return rate, customer support tickets (make sure we're not sacrificing quality)
Design the test
- •Control group: Current checkout experience
- •Treatment group: New checkout flow
- •Randomization: By user, not by session (you want consistent experience)
- •Split: Start with 10% treatment to limit risk, scale up if early signals are positive
Calculate sample size and duration
This is where basic stats matter:
"If our baseline conversion is 3% and we want to detect a 10% relative lift (3% → 3.3%), with 80% power and 95% confidence, I'd estimate we need roughly X users per variant. Given our traffic, that means running for approximately Y days."
You don't need to do exact math in your head, but you should know the factors: baseline rate, minimum detectable effect, traffic volume, confidence level.
Anticipate complications
- •"I'd watch for novelty effects—early results might be inflated"
- •"We'd need to make sure the test doesn't coincide with major shopping events"
- •"If we see segment differences, we might want to extend the test to confirm"
Common Experiment Mistakes to Avoid
- •No hypothesis: "Let's just test it and see" isn't experiment design
- •Too many variants: You rarely have traffic for 5-way tests
- •Wrong randomization: Session-level randomization creates inconsistent experiences
- •Stopping early: Looking at results daily and stopping when you see significance is statistically invalid
- •Ignoring segments: Overall results might mask segment differences
Type 3: Estimation Questions
These are the "how many gas stations are in the US?" type questions. They're less common now but still show up.
The approach is simple:
- •Break the problem into components you can estimate
- •State your assumptions clearly
- •Do the math step by step
- •Sanity check the result
Example: "How many Uber rides happen in NYC per day?"
"Let me break this down:
NYC population is about 8 million. Not everyone uses Uber—maybe 30% have the app, so 2.4 million potential users.
Of those, maybe 10% are active in a given week, so 240,000 weekly active users. If the average active user takes 2 rides per week, that's 480,000 rides per week, or about 70,000 rides per day.
Let me sanity check: Uber has maybe 3-4 million rides per day globally. NYC being 2% of that feels reasonable for one of their biggest markets. So 70,000 feels within range, maybe conservative."
The exact number doesn't matter. What matters:
- •Clear structure
- •Reasonable assumptions (stated out loud)
- •Basic math executed correctly
- •Sanity check at the end
Type 4: SQL and Data Questions
Some companies will ask you to write SQL or interpret data output.
If SQL is required, you need to be able to:
- •Write basic queries (SELECT, JOIN, WHERE, GROUP BY)
- •Aggregate data (COUNT, SUM, AVG)
- •Handle dates and time windows
- •Explain what your query is doing and why
If they show you data output, you need to be able to:
- •Identify patterns and anomalies
- •Ask what's missing
- •Suggest next analyses
These skills are learnable. If you're weak on SQL, spend a few weeks on SQLZoo or Mode's SQL tutorial before interviewing.
How to Practice
For metric diagnosis: Pick a product you know. Imagine a metric dropped. Walk through how you'd investigate out loud. Do this regularly until the structure is automatic.
For experiments: Think about features you'd want to test. How would you design the experiment? What could go wrong?
For estimation: Practice breaking down random questions. How many coffee shops in your city? How many hours of YouTube are watched per day? Get comfortable making assumptions and doing arithmetic.
For SQL: If it's rusty, spend time on interactive exercises. If it's non-existent, this is a gap worth addressing before PM interviews.
The Meta-Skill
The underlying skill being tested is structured thinking under uncertainty.
You don't have all the information. You can't run the actual analysis. What you can do is show that you know how to approach the problem systematically.
State assumptions. Break down complexity. Identify what you'd need to know. Reason through the implications.
That's what analytical interviews are really testing.
Related reading: Product Sense Interviews and Behavioral Interview Questions for the other major PM interview types.