30 Product Analyst Interview Questions

Lacking confidence for the product analyst interviews? 30 questions, 7 topic categories, numerous interview tips, and practice opportunities will fix that.

A product analyst is an interesting job: technical but also business- and user-oriented. Interviews reflect that mix, making them harder than they look. 

This guide cuts through that. You’ll find info on what the interviews look like, with 30 interview questions across seven topic categories to illustrate that. No fluff, no nonsense. Just what you need to be prepared.

What Product Analyst Interviews Actually Test

The answer lies in the position name: it’s about product, and it’s about analysis. In other words, interviewers want to test how you make decisions about a product using data. 

So, yes, SQL coding is tested. However, interviewers are not looking to be impressed by speedy, clean SQL coding. No, SQL is there to test your metric judgement, the skill interviewers focus on.

Product analyst interviews essentially test “only” two things. 

1. Metric Judgement: Business First, SQL Second

The main focus is on choosing the right metric for the problem before you. That’s what product analysts do. SQL is there only to perform calculations. 

Below, I have listed the most important metrics that product analysts need to understand and calculate. While it covers most typical problems, it’s not an exhaustive list. It’s impossible to cover everything here. If you feel your interview could be more niche and industry-specific, you should explore more metrics, just in case.

The interviewers expect you to:

• pick one or two metrics that match the problem
• explain why you chose those metrics
• translate the calculation into SQL 

It’s not rare to see candidates immediately jump into calculation. But what’s the point in the correct calculation, when you calculated the wrong thing? Interviewers will mark that down instantly. 

2. SQL Under Ambiguity: Real Job Conditions

The product analyst interview questions are intentionally ambiguous. As already mentioned, it’s up to you to come up with metrics to define and calculate. The interviewers want to test whether you understand what you’re doing (from the business point of view), not just syntax. 

They expect you to notice the ambiguity and ask clarifying questions or come up with reasoning yourself. For example:

• What is the definition of an active user?
• Is the metric event-based or session-based?
• Do we measure the metric by first action or first purchase?
• What about the users accessing from multiple devices?

Only after clarifying that, and only then, can you deal with actual data and SQL coding.

Product Analyst Interview Format

Product analyst interviews don’t follow a unified script, and the actual process (organizational and in terms of the number of interviews) differs from company to company. 

Still, there are not unlimited ways to assess candidates. In most cases, interviews will include one or more of the approaches illustrated below. 

1. Live SQL or Analytics Exercise

This format means solving analytics problems in real time, often with incomplete or vague requirements. You expect questions along these lines:

• “Calculate Day 7 retention.”
• “Find where users drop in this funnel.”
• “Compare feature usage before and after the app launch.”

The idea behind this is to see if you can translate a vague business requirement into an exact SQL code. 

Here’s an overview of what this format is testing and what you’re expected to do. 

2. Scenario-Based Analytics Case

This is when you get a simulated product problem where something changed. Your task is to find out what and why. Typical questions sound like:

• “Retention dropped last week. Why?”
• “Checkout conversion declined, but traffic remained flat. Why?”
• “Engagement increased after a feature launch. Is that good or bad?” 

By asking these questions, interviewers want to see if you can fix a real product issue using data.

Here’s what’s being tested and how to approach answering these questions.

3. Pre-Written Query or Output Interpretation

These types of questions give an already written SQL query, table, or chart. You have to explain and critique it. Expect something along these lines:

• “What does this query calculate?”
• “Is this the right way to measure retention?”
• “What’s wrong with this metric definition?”

This is just another, reversed way of testing whether you understand the metrics behind the SQL. 

4. Product Metrics Discussion

These are conceptual discussions about what should be measured. Typically, you’ll be asked:

• “How would you measure success for this feature?”
• “What metrics matter most for this product?”
• “What would you track weekly as a PM?”

The interviewers want to see whether you understand what actually matters in the product analysis, even before looking at the data. 

Here are more details on what's being tested and what you’re supposed to do.

5. Take-Home or Short Case Study 

This is an assignment completed outside the interview, hence the name. It’s a more elaborate analytics assignment than the single questions you get in the interview. You’re given a dataset, a problem statement, constraints, and are asked to provide a certain type of deliverable, e.g., SQL, slides, write-up, notebook, etc.

Typically, you’d be asked to:

• “Analyze this dataset and share insights.”
• “Evaluate the impact of this feature.”
• “Recommend what the team should do next.”

The idea behind this is to see if you can own a comprehensive analysis and turn it into a business decision. 

All those interview formats and question types are typically spread across a few interview stages, usually at least those three:

1. recruiter or HR screen
2. hiring manager interview
3. technical or analytics interview

However, this is largely irrelevant to your preparation for the product analyst interview; the same skills appear across all interview stages.

Product Analyst Interview Questions by Topic

The five interview question formats we presented above deal with how your knowledge is assessed. We’ll now focus on the “what” – topics tested and questions appearing in real product analyst interviews.

Core Product Metrics Questions

As their name suggests, these questions focus on product metrics. Typically, these are not coding questions. 

Evaluation Criteria

When asking core product metrics questions, interviewers are not much interested in hearing a textbook definition of a specific metric. 

Your answers to these interview questions should score highly on:

• Clarifying assumptions
• Matching metric to product goal
• Showing awareness of metric limitations
• Explaining why, not just what

Here are several examples of such questions. 

Question #1: Returning User

How Should You Frame the Question?

On the surface, this question sounds like the interviewer is interested in a definition. Nope. There’s no textbook-prescribed metric that determines whether a user is returning or not. 

The interviewer tests whether you understand that “returning” depends on product type, time horizon, and the definition of meaningful activity. 

The framing of the question: “It depends on what we mean by returning and what the product is optimizing for.” 

Trade-Offs & Decision Rules

Framing shows that you understand you could use different metrics depending on the returning user. Here are some examples. 

This part shows your understanding of which metric is suitable for what, and you state that explicitly in your answer:

• Use retention rate for product health
• Use repeat core action for value creation
• Use returning user counts for scale and growth tracking

Consider Edge Cases & Assumptions

A strong answer should consider edge cases and state assumptions. 

For this particular case, you could call out edge cases such as:

• Cross-device users (identity resolution)
• Notification-drive opens
• Feed auto-refresh and preload
• Event-driven spikes (election, sports, crises)
• Passive consumption without interaction

Finally: Interview-Ready Answer

Following our own advice, a solid answer could read along these lines:

“I’d define a returning user as someone who comes back within a defined time window and performs a meaningful interaction, not just opens the app.

To measure this, I’d primarily use cohort-based retention tied to a core action, and pair it with the repeat core action rate to confirm users are returning with intent.

Cohort retention tells me whether users come back after the first value.

Repeat core action helps validate that the return reflects real engagement rather than notification-driven opens.”

Typical Follow-Ups

A strong answer would take into consideration the possible follow-ups, and cover most of the basic ones, such as: 

• “Returning within what time window?”
• “Does opening the app count as returning?”
• “Which particular metric would you actually use?”

As you’ve already covered that, you’d probably get the more probing questions, such as:

• “What’s the core action here?”

Pro tip: Commenting/sharing on Facebook, saving/replying on Instagram, sending messages on WhatsApp

• “What retention window would you choose?”

Pro tip: Start with Day-7 or Week-1 retention for high-frequency Meta products; captures habitual return without over-counting noise

• “Why cohort retention instead of DAU/WAU?”

Pro tip: Cohort retention isolates true return behavior, DAU/WAU mixes acquisition and engagement

• “How would you validate that notification-driven opens aren’t inflating this?”

Pro tip: Compare interaction depth and downstream actions for notification-driven return vs. organic return that confirms intent.

• “Would this definition change across Meta products?”

Pro tip: The core action changes, the logic stays the same, i.e., the value-creating interaction. 

• “What would make you distrust this metric?”

Pro tip: For example, if retention increases without a corresponding increase in meaningful interactions or downstream engagement. 

Using a similar approach, try answering the following questions. 

Question #2: New Users Engagement

Question #3: Customer Engagement and Disengagement

Question #4: Health of Groups

Question #5: Ad Success Metrics

Retention & Churn SQL Interview Questions

These questions focus on testing how well you reason about retention and churn metrics, and whether you can calculate them in SQL.

Question #6: Churn Rate Of Lyft Drivers

Here’s the dataset preview. 

What This Question Really Asks?

On the surface, the problem looks like a simple aggregation. If you think that, you’ve fallen for a trick. Interviewers like to ask deceptively simple questions, but what they’re actually testing here is:

• Translating a business definition of churn into SQL
• Choosing the correct denominator for a rate
• Numeric precision

Metric Decision Rule

Global churn is explicitly defined in the question as “the percentage of drivers who have stopped driving for Lyft, as indicated by a recorded end_date in the lyft_drivers table.”

The decision you need to make is what data you must use to calculate it:

• Numerator – count of churned drivers, i.e., whose end_date is non-NULL
• Denominator – count of all drivers

Solution Walkthrough

The code below does the following:

1. Identifies churned drivers: end_date IS NOT NULL
2. Counts churned drivers: COUNT() with CASE WHEN Statement
3. Divide by total drivers: COUNT(*)
4. Cast to decimal: prevents integer division

The output shows the churn rate of 0.5.

We chose this approach because:

• It makes the churn calculation logic obvious
• Usually more efficient (or at least no worse) than the WHERE + subquery approach (Alternative solution 1)
• More generalizable if the question evolves into churn by country/acquisition channel/cohort/month; just add the grouping column in SELECT and GROUP BY

Alternative solution 1: WHERE + subquery

Aside from lacking all the pros of the official approach, this solution is, in addition, easier to break if someone edits the query. For example, by removing WHERE end_date IS NOT NULL. 

Alternative solution 2: COUNT(end_date)

This is the simplest solution, simpler even than our official solution. COUNT(end_date) counts only non-NULL values, so the conditional logic is not needed.

Use this when churn is exactly “non-NULL end_date”. Use conditional aggregation (the official solution) when you want the most robust pattern that survives potential changes. 

How Do You Know Your Solution is Correct?

You don’t, but there are some sanity checks you could perform to be 99% sure. 

• Does COUNT(*) equal the number of drivers?
• Confirm end_date is populated only for churned drivers
• Is the ratio between 0 and 1?

Common Mistakes & Avoiding Them

Here are several mistakes this question tries to force you into making. 

Mistake 1: Dividing without casting

This mistake results in integer division, which silently truncates the result. In other words, even though your calculation is nominally correct, you’ll get incorrect output.

See for yourself by running the code without casting. 

Keep in mind you must cast/convert to decimal either the numerator or the denominator. 

Mistake 2: Grouping by year

Some of you think this code calculates what the interviewer wants. 

Be careful, because the question asks for overall churn across all years, not time-based churn. 

Assumptions & Edge Cases

The edge cases to consider when writing the solution could be: 

• Drivers who leave can return later
• Multiple rows per driver
• Soft churn without an end_date

No need to write the solution to take this into account. The important thing is to know that these edge cases could break your code, so be prepared to extend your solution if the interviewer asks you to. 

Now that you’re familiar with the return and churn questions, solve some other similar examples. 

Question #7: Monthly Churn Rate

Use this dataset. 

Write and check your solution in the code editor.

Question #8: First Day Retention Rate

Use this dataset. 

Write and check your solution in the code editor.

Question #9: Retention Rate

Use this dataset. 

Write and check your solution in the code editor.

Cohort Analysis Interview Questions (Multi-Step SQL)

These questions focus on tracking behavior over time relative to an anchor event, such as a signup or first purchase. They are typically multi-step SQL questions, so they also test whether you can break a complex problem into sequential steps and keep the correct grain in each step when tracking behavior over time relative to an anchor event. 

Question #10: Finding User Purchases

Here’s the dataset preview. 

The Grain Interviewers Are Checking

In this question, there are four grains interviewers want to see you control:

1. Raw data grain (user_id + created_at (timestamp)): There are multiple rows per user, possibly multiple purchases per day. This grain is not suitable for finding first and second purchases. 
2. Normalized activity grain (user_id + purchase_date): This grain creates a stable unit for sequencing, as it collapses multiple same-day purchases.
3. User-sequence grain (user_id + ordered purchase index): This grain uses the ROW_NUMBER() window function to add order without changing row count, and makes the first and second orders explicit
4. Output grain (user_id): Here, each user appears at most once. 

Solution Walkthrough

We’ll use CTEs to write clean code, with the sequential steps easy to understand. 

1. CTE daily: Sets the event grain that ignores same-day purchases
2. CTE ranked: Defines first vs second order per user
3. CTE first_two: Collapse to one row per user with the first two dates
4. Final SELECT: Apply the business rule window (second purchase is 1-7 days after the first)

Here’s the code.

Why This Solution Approach?

Alternative approach #1: The question that’s probably surfacing is: “Can I use RANK() or DENSE_RANK() instead of ROW_NUMBER()?”

The short answer is: Yes. 

The long(er) answer is: Using RANK(), or DENSE_RANK() doesn’t achieve anything. Those functions are designed to handle ties. However, we already removed ties in the daily CTE. So, you could use RANK() or DENSE_RANK(), but it’s unnecessary.

Alternative approach #2: Giving the official solution we’ve shown above should satisfy your interviewer. Why shouldn’t it? The answer makes the first vs second order explicit, it’s robust and portable, and all the grains are in check.

However, you might get asked to optimize that code. Of course, it’s possible to do it. The idea is to use LEAD(), and you’ll end up with only two CTEs instead of three. 

The first CTE is identical. The second CTE is slightly tweaked by adding LEAD() to get the second purchase date. The third CTE you don’t need anymore. 

Final SELECT also stays the same.  

Common Mistakes

This question, like all the questions, wants to force you into making mistakes. Here’s what to look out for:

• Using COUNT(*) >= 2 instead of identifying the first and second purchase
• Applying the 1-7 day filter before determining the purchase order
• Forgetting to deduplicate same-day purchases
• Returning multiple rows per user instead of a user-level result

Now, try to solve several more multi-step cohort analysis questions. 

Question #11: User Activity Analysis

Use this dataset. 

Write and check your solution in the code editor.

Question #12: Premium Accounts

Use this dataset. 

Write and check your solution in the code editor.

Question #13: Consecutive Days

Use this dataset. 

Write and check your solution in the code editor.

Question #14: User Streaks

Use this dataset. 

Write and check your solution in the code editor.

Question #15: New And Existing Users

Use this dataset. 

Write and check your solution in the code editor.

Funnel & Activation SQL Interview Questions

These questions test your ability to construct correct metrics from event-level data. You have to define populations consistently, manage intermediate steps without changing the unit of analysis, and, finally, compute the metrics correctly.

Question #16: SMS Confirmations From Users

We’ll work with two tables. The first one is fb_sms_sends.

The second table is fb_confirmers.

Decisions to Make

This question is pretty explicit in its requirements and definitions, so there’s not that much for you to decide. The goal here is for the interviewer to see if you can follow clear instructions and translate them into code.

However, that doesn’t mean that you have no decisions to make. They may be few, but they’re still very important.

1. Define the metric: confirmed messages (those with type = message)/total number of messages sent
2. Type of join: You should use LEFT JOIN from fb_sms_sends to fb_confirmers, which will keep the unconfirmed sends in the denominator. If you use INNER JOIN, the result will always be 100%, as you literally calculate “confirmation share among confirmed records.” 

Solution Walkthrough

Here’s what the code below does.

1. Defines the metric: COUNT(b.phone_number)::FLOAT/COUNT(a.phone_number) * 100 AS perc 
2. Sets the denominator grain: Rows in fb_sms_sends on 2020-08-04 with type = 'message'; each row corresponds to one SMS sent.
3. Choose the join type: LEFT JOIN to keep the unconfirmed messages in the dataset. 

Here’s what the full code looks like. 

Here’s the output showing the metric is 20%.

Calling Out Edge Cases

The data we’re using is pretty straightforward and clean. You can expect to get a little trickier data, so you should call out edge cases and check with the interviewer if you should account for them.

Possible edge cases are:

• Multiple sends to the same phone number on the same day (denominator is per send, not per user).
• Multiple confirmer rows per phone/date (needs deduping if table isn’t unique).
• Confirmation with no send record (should not count, as you anchor on sends).
• NULL phone number (these should probably be excluded, but you should check). 

Follow-Ups To Expect

After providing the above solution, be ready to give some additional explanations:

• “Why LEFT JOIN, and not INNER JOIN?”
• “What exactly counts as ‘sent’ vs ‘confirmed’?”
• “How do you know ETL junk isn’t inflating/deflating the metric?”
• “What happens if a phone number confirms without a second record?”

Question #17: Same-Day Orders

Use this dataset. 

Write and check your solution in the code editor.

Question #18: Acceptance Rate By Date

Use this dataset. 

Write and check your solution in the code editor.

Question #19: Marketing Campaign Success

Use this dataset. 

Write and check your solution in the code editor.

Feature Impact & Experimentation Questions

These questions are all about reasoning about cause and effect between product changes and outcomes. They probe your understanding of how metrics interact (hypothetically) and how an observed change could (or should) be validated or tested.

Let’s see what feature impact and experimentation questions involve. 

Question #20: Graph of Sales and Revenue

What the Interviewers Want To See

We classified this as an easy question, but it still requires you to think. That’s what the interviewers are most interested in. In a bit more detail, they want to see you:

• Understand that revenue = price x quantity
• Explain opposing trends
• Explain trade-offs in plain language

Interview-Ready Answer

The two graphs show how price impacts demand and revenue. 

“The product prices were probably decreased first. That made the product more affordable, so the units sold increased. However, this had a negative effect on revenue; despite the increased demand, sales generated less revenue due to the price decrease. 

Later on, prices increased. This had an opposite effect: number of units sold decreased, but the higher price more than offset the lower volume, so the revenue went up.” 

Typical Follow-Ups

The answer I gave above would get you high scores on the correct intuition marks. However, some interviewers might be interested – after establishing the base point of you making sense – in your reasoning about causality, evidence, and decision. 

They would probably ask at least one of these questions. (The idea is not to memorize the answers, so the “answers” in brackets are only suggestions that should give you the idea of different directions you could take in answering the additional questions.) 

#1: “How do you know price is the driver?” 

(You’d want to check price history, discounts, and promotions. Probably segment by time, cohort, or campaign. Compare metrics – average selling price, units sold, revenue – pre and post price change. That’s all to confirm whether price is the driver or not.) 

In short, sales volume peaked when prices were low, and revenue peaked when prices rose. 

#2: “What else could cause this pattern?”

(Possibly: mix shifts (enterprise vs retail), bundling or packaging changes, channel effects, external demand shocks.)

#3: “What would you do next?”

(You’d want to suggest A/B pricing tests, price elasticity analysis, holding quality/features constant, monitoring retention and lifetime value, not just revenue.)

#4: “Which metric would you prioritize when deciding what to do next?”

(The metric changes depend on the goal. If you want a decision about prices, you could use revenue per user (RPU), average selling price (ASP), units sold, conversion rate, gross margin. If the goal is a growth vs monetization trade-off, use revenue growth rate or unit growth rate. Prioritizing long-term business health? Use customer lifetime value (LTV), retention, churn, repeat purchase rate, cohort revenue over time.) 

Now try to solve a couple more problems.

Question #21: A/B Testing a Campaign

Question #22: Cities with Higher or Lower Demand

Multi-Step SQL Case Questions (Real Interview Prompts)

These are (relatively similar) to multi-step cohort analysis SQL questions in that they, too, test how you decompose business problems into a logical sequence of query steps. However, the problems in this case are more open-ended, simulating the actual requests you’ll get at your job: procedural, not formulaic prompts (you decide what to do in what order), and you have to decompose the actual problem. 

Now, to examples. 

Question #23: Rank Variance Per Country

The question gives you two tables. Here’s the fb_comments_count table. 

Here’s the fb_active_users table.

What Does It Want?

Despite the word “rank” in the question title and the extensive use of DENSE_RANK() in the solution, this question is not about ranking. At least, it’s not only about that. 

The output depends on chaining intermediate results correctly, and that’s what this question is about: the procedure. Specifically, it tests:

• Decomposition skills: how you turn the problem into a sequence of transformations (monthly totals -> ranks -> deltas)
• Grain discipline skills: keeping one row, meaning one thing, as you move from events -> country-month -> country

Decisions & Trade-Offs

There are three main decisions you have to make here.

1. Aggregating before ranking: You can’t rank countries until each country has a single total per month.
2. Using DENSE_RANK(): The question says “Countries with the same total should share the same rank, and the next rank should increase by one (without skipping numbers).”, which means using DENSE_RANK() when ranking, not RANK() (the latter skips ranks).
3. Comparing ranks on aligned grains: The comparison must be at country (one row per country with December & January ranks), not at the comment-event level.

Solution Walkthrough

Here’s what the solution does.

CTE monthly_comments: Joins the tables to get country, limits comments to those from 2019-12-01 inclusive to 2020-02-01 exclusive in WHERE and sums them. The result is one row per country per month with the total number of comments. 

WITH monthly_comments AS
  (SELECT u.country,
          date_trunc('month', c.created_at)::date AS month_start,
          SUM(c.number_of_comments) AS total_comments
   FROM fb_comments_count AS c
   JOIN fb_active_users AS u ON c.user_id = u.user_id
   WHERE c.created_at >= '2019-12-01'
     AND c.created_at < '2020-02-01'
   GROUP BY u.country,
            date_trunc('month', c.created_at)::date),

CTEs december & january: We split two months into two separate datasets showing country and total_comments.

december AS
  (SELECT country,
          total_comments
   FROM monthly_comments
   WHERE month_start = '2019-12-01'),

january AS
  (SELECT country,
          total_comments
   FROM monthly_comments
   WHERE month_start = '2020-01-01'),

CTEs december_rank & january_rank: We rank countries within each month by total_comments DESC using DENSE_RANK().

december_rank AS
  (SELECT country,
          total_comments,
          DENSE_RANK() OVER (ORDER BY total_comments DESC) AS dec_rank
   FROM december),
   
january_rank AS
  (SELECT country,
          total_comments,
          DENSE_RANK() OVER (
                             ORDER BY total_comments DESC) AS jan_rank
   FROM january),

CTE rank_compare: Joins the december_rank and january_rank CTEs, producing one row per country with both December 2019 and January 2020 ranks. 

rank_compare AS
  (SELECT d.country,
          d.dec_rank,
          j.jan_rank,
          d.total_comments AS dec_comments,
          j.total_comments AS jan_comments
   FROM december_rank d
   JOIN january_rank j USING (country))

Final SELECT: Here, we keep countries whose ranking improved (dec_rank > jan_rank) and sort the output from the lowest rank number (highest rank) to the highest rank number (lowest rank). 

rank_compare AS
SELECT country
FROM rank_compare
WHERE dec_rank > jan_rank
ORDER BY dec_rank;

Here’s the whole code.

Avoiding Typical Mistakes

When solving that question, try not to fall into one of its traps. 

• Using RANK() instead of DENSE RANK(): This will cause ties to be skipped, hence the result will be incomplete/incorrect.
• Incorrect data filtering: Using created_at <= '2020-01-31' instead of created_at < '2020-02-01' could miss or duplicate edge dates, depending on the data. Not in the case of our data, as the column created_at shows dates. But if it were a timestamp, SQL would treat created_at <= '2020-01-31' as a timestamp at midnight, excluding other events the rest of '2020-01-31'. At interviews, you often don’t control the schema, so it’s safer to use half-open ranges, as in the solution, to capture full months without boundary bugs.
• Ranking across the entire dataset: That’s not going to work. You need a separate ranking for each month, not a single global rank. 

Here are several other questions of the same type. 

Question #24: Player with Longest Streak

Use this dataset. 

Write and check your solution in the code editor.

Question #25: Google Fit User Tracking

Use this dataset. 

Write and check your solution in the code editor.

Question #26: Fans vs Opposition

Use this dataset. 

Write and check your solution in the code editor.

Question #27: Average Time Between Steps

Use this dataset. 

Write and check your solution in the code editor.

ML-Style Analytics Questions (Product Data Focus)

This question category is about models and metrics in a product context rather than how you write code. More precisely, these questions focus on your ability to frame prediction or classification problems, choose appropriate evaluation metrics, reason about bias and trade-offs, and connect model outputs to product decisions.

For example, like in these questions. 

Question #28: Recommendation System

The dataset consists of two tables. The first one is users_friends.

The second is users_pages.

Avoid Falling For These Traps

The question seems deceptively simple: you’re interested in “pages my friends follow”. But have you considered this?

• Should you include pages followed by multiple friends once or multiple times?
• What if friendship is stored one-directionally (e.g., A -> B but not B -> A)
• How would you rank recommendations?
• How do you avoid recommending pages the user already follows?

Typical follow-ups and edge cases revolve around those mistakes. 

How to Approach It?

Your solution should imply this in its logic:

• Candidate generation: user -> friends -> friends’ pages
• Exclusion: removing pages that the user already follows
• Uniqueness: output one row per (user_id, page_id) recommendation

Also, when choosing the approach, the main trade-off is deciding how you perform exclusion. 

• NOT EXISTS is usually the safest exclusion mechanism (avoids NULL pitfalls).
• LEFT JOIN … IS NULL would also work, but it’s easier to break if the join keys aren’t unique or if you accidentally filter the right table in WHERE.

Solution Walkthrough

1. Define output grain: one row per (user_id, page_id) should already exist in users_pages. 
2. Generate candidates: join users_friends with users_pages to get the pages friends follow. 
3. Exclude existing follows: remove pages already followed by the user with a subquery in NOT EXISTS.
4. Deduplicate: keep distinct recommendations
5. Validate: confirm zero overlap with users_pages for the same user-page pairs.

Here’s the code. 

Try solving these two additional problems. 

Question #29: Algorithm Performance

Use this dataset. 

Write and check your solution in the code editor.

Question #30: Naive Forecasting

Use this dataset. 

Write and check your solution in the code editor.

Common Tables Used in Product Analyst SQL Interviews

Product analyst interviews revolve around a certain number of recurring tables that represent how product data is stored in practice. 

Interview tip: Identify table roles early (event vs dimension vs relationship) and adjust joins and aggregation grain accordingly. Don’t treat all tables the same.

SQL Skills Checklist for Product Analysts 

Product analyst interview questions, as we’ve seen, focus on product-related knowledge, even when requiring SQL coding. Still, SQL is the single most important tool you have for showcasing your product knowledge.

Here’s what SQL skills you’d need to be fluent in. 

Conclusion

The 30 questions in this guide reflect actual product analyst interview requirements: problem structuring, choosing the right metric, explaining your reasoning, and writing a workable SQL code. 

Knowing all this doesn’t remove difficulty, but it gives you knowledge and confidence. That’s what’ll make the difference at your interview.