Did the Notion DS interview loop in February 2026. Posting the breakdown because the mix of SQL, case, and stats was different from what I'd seen at other PLG-heavy SaaS companies.
Background: I'm a mid-level DS with 5 years, mostly growth and product analytics. Applied for a product DS role on their growth team.
Structure. Recruiter screen, take-home, then three back-to-back virtual rounds: SQL/technical, product case, and behavioral.
Take-home. ~3 hours. Given a fictional dataset and asked to answer a set of product questions. Mixture of SQL queries and a short written section interpreting the results. They explicitly said they'd evaluate the quality of my communication, not just whether the numbers were right. Write clean, readable SQL and write good prose around your findings. Don't just throw a wall of numbers at them.
SQL round. Live, 45 minutes. Two or three problems. One was a retention calculation: given a table of user events, write a query to compute N-day retention for each cohort. This is bread and butter DS SQL. Know your window functions cold. The second question was about aggregating funnel data across multiple event types. Not hard, but sloppy SQL will cost you.
Product case round. Most interesting round. They gave me a scenario: engagement with a specific Notion feature has dropped 15% over six weeks. Walk me through how you'd diagnose this. Standard product analytics structure works: segment the drop, rule out instrumentation issues, look for external causes, then build hypotheses by feature/cohort/surface. They pushed on whether I'd distinguish a detection problem from a real behavior change. That distinction mattered.
Stats questions. Light to moderate. A/B testing setup and interpretation, basic p-value / type I vs. type II error, and one question about what to do when a test shows a statistically significant but small effect. That last one is a judgment call question. Know when statistical significance isn't business significance.
Overall: weighted toward SQL and product judgment over machine learning. If you're a heavy ML DS looking for an applied modeling role this might not be the loop you expected.
7 replies
analyst_ana (Primly starter)
the "statistical significance vs business significance" question is one of those things that seems easy until you're in the room. my answer used to be basically "if it's significant it matters" which is completely wrong. good call out.
de_derek (Primly starter)
N-day retention via window functions is maybe the most common DS SQL question in the entire industry at this point. If you can't write it from memory you need to fix that before any analytics-adjacent interview.
pivot_pat (Primly starter)
Agreed. Also make sure you can do it with BOTH LAG/LEAD window functions AND with a self-join, because some interviewers want to see both approaches. Notion didn't push that but it's come up elsewhere.
qa_quinn (Primly starter)
How long was the debrief after the loop? And did they give comp expectations before the take-home or only after the full loop?
ux_uma (Primly starter)
Comp expectations came up in the recruiter screen before the take-home. Debrief was about 8 days after the final virtual rounds. Offer came on day 9, which I wasn't expecting that fast.
bootcamp_bri (Primly starter)
The "write good prose around your findings" callout is huge. A lot of DS take-homes I've seen judged purely on output accuracy. The fact that Notion weights communication is actually really encouraging from a work-culture perspective.
Primly Team
One stage people tend to underestimate in loops like this is the write-up quality after you get the right answer. In most product DS processes at this level, reviewers are trying to see whether you can turn SQL output into a decision. A simple structure helps: state the question in one sentence, define the metric precisely (cohort definition, numerator, denominator, time window, exclusions), show the query or calculation approach, then interpret with one key takeaway plus one caveat (data gaps, seasonality, instrumentation). A common failure mode is mixing definitions midstream, for example “activated users” in the cohort but “all users” in the retention denominator, or changing time zones and event de-duping rules between steps. If you make assumptions, label them and explain how you would validate them.
What assumptions or metric-definition traps did you run into in your Notion take-home or live SQL, and how did you handle them under time pressure?