As a Data Scientist at Suno, you are joining a company at the absolute frontier of generative audio. This is not a traditional analytics role; you are tasked with building the recommendation systems that bridge the gap between AI-generated music and human discovery. Your work directly influences how millions of users navigate an infinite library of sound, determining which tracks reach the ears of listeners and which creators find their audience.
You will operate at the intersection of machine learning, behavioral psychology, and music theory. The role demands someone who can build sophisticated models while remaining deeply grounded in the "why" of user engagement. Whether you are defining content strategy or developing frameworks to measure the novelty and diversity of audio, your contributions will be foundational to Suno’s growth. This role is highly impactful, requiring a blend of technical rigor and the creative judgment necessary to define what "compelling" music looks like in an AI-native world.
Given the founding nature of the recommendation team at Suno, you should be prepared to discuss not just how to build models, but how to set up the data infrastructure and evaluation metrics that will define the team's success for years to come.
Initial Screening
reportedMost candidates lose this call inside the first two minutes, during the walkthrough of their own background. The account runs chronologically, sits at the level of tools and titles, and never arrives at a decision anyone could have disagreed with. Anchor on a problem instead of a timeline: what the team could not answer, what you did about it, what happened next. Ninety seconds is enough, and stopping on time leaves room for the half of the call that belongs to you. What you ask about how work gets prioritised signals your level more reliably than the walkthrough does.
What to demonstrate
- Whether your background summary has a shape (problem, decision, consequence) or is a chronological list of tools and employers
- Whether you can account for gaps, short stints and the reason you are looking, unprompted and without hedging
- The substance of the questions you ask back, which an experienced screener reads as a level signal
How to prepare
- Time your opening walkthrough against a clock. If it runs past two minutes, compress the earliest role into a single clause and spend the recovered time on the most recent one
- Write one honest sentence for every gap or short stint visible on your resume and offer it before being asked about it
- Prepare questions about how work arrives and gets prioritised: who writes the request, how often priorities change, and what happens to an analysis after it is delivered
Technical Deep-Dive
reportedMuch of what gets scored here happens out loud while you type. Nobody can see your reasoning inside a half-written query, so five silent minutes read as being stuck even when they are not. State the plan in plain language first: which tables, what grain you are aggregating to, and the one filter that defines the population. Then write it. The narration doubles as insurance, because a wrong plan gets caught early and cheaply while a wrong query gets caught at the end with no time left to redo it. A timed statistics section, where one exists, is a separate test with its own clock.
What to demonstrate
- Whether the query you write matches the plan you just described
- What you do with a hint, meaning whether the correction gets absorbed or the first approach gets defended
- Whether you can debug your own wrong output by reading the result set and naming which part of the query produced the anomaly
How to prepare
- Solve three problems while screen-sharing into a recording, then watch it back and mark every stretch longer than thirty seconds where you said nothing
- Practise compressing the plan into one sentence before typing, then check afterwards whether the finished query actually matched it
- Time yourself on statistics questions that carry a business reading, such as what a confidence interval does and does not claim, rather than re-reading notes without a clock
Behavioral Interviews
reportedMost of the weight in this round sits on the disagreement questions. Data work routinely produces an answer someone senior did not want, and the interviewer is trying to learn what you do in that hour. Both failure modes are common: folding as soon as a director pushes back, and treating the pushback as ignorance to be corrected with a better chart. A strong answer usually contains a specific thing the other person knew that you did not, and describes how you found out whether it changed the conclusion.
What to demonstrate
- Whether you can state the other side's argument accurately before you explain why you disagreed
- What you treated as evidence during the disagreement, such as a rerun under their assumption or a holdout check, rather than persuasion technique
- Whether you distinguish being overruled from being wrong, and can give an example of each
How to prepare
- Write out one disagreement where you turned out to be wrong, and say what in the data misled you. Candidates prepare the story where they were right, and the follow-up asks for the other one.
- For your main disagreement story, be ready to say what result would have made you drop your position. If no such result exists, you were not arguing from the data.
- Practise stating the opposing position out loud in one sentence the stakeholder would accept, then continue the story.
Leadership Rounds
reportedAn added round often puts you in front of someone outside the core hiring team: a partner engineer, a product owner, a domain expert, sometimes a more senior manager. The question they are really asking is not whether you can do the work but whether they would trust a number that came from you. That changes what a good answer looks like. Lead with what the decision cost and what it changed, keep the method available but not central, and be plain about the limits of your evidence. Overstating a result is the fastest way to lose this round.
What to demonstrate
- Whether you can explain a technical choice to someone who will never read your code, without either flattening it into nothing or hiding inside jargon
- Honesty about evidence strength: what the analysis establishes, what it only suggests, and what it cannot say at all
- How you take disagreement, specifically whether you update on a good objection, hold your position with reasons, or fold on contact
How to prepare
- Write the two-sentence version of your most technical project for a non-specialist, then check that neither sentence needs a method name to make sense.
- For one result you are proud of, write the strongest objection someone could raise and a response that concedes the part of it that is correct.
- Prepare one decision that turned out to be wrong: how you found out, what it cost, and what you changed afterwards. A senior cross-functional interviewer asks for this more often than a technical one does.
PracHub editorial advice for the preparation topics above.
Using report volume as a measurement of how much violating content exists
Reporting is a member behaviour, not an observation of the content. Report counts rise when the report control is made easier to reach, when a coordinated campaign targets an account, and when the audience shifts toward people who object; they fall when violating content is shown mainly to members who agree with it. A ranker that gets better at matching bad content to receptive audiences will drive reports down and harm up at the same time. Prevalence must come from a random sample of served impressions with recorded selection probabilities, labelled by humans against the written policy, and reported with an interval. Reports are useful as a detection signal and as a demand-side complaint rate, not as a denominator-anchored measure of harm.
Randomising individual members when the treatment travels along the social graph
If treated members post, comment or share more, their followers see the extra content whether or not those followers are treated, so the control group is partly treated and the measured difference understates the true effect. For features that redistribute a fixed amount of attention, the leakage runs the other way and the effect is overstated. The size of the bias scales with how dense the neighbourhood is, so it is largest exactly among the connected members whose behaviour the feature was built for. The fix is randomising clusters of the graph (ego networks or communities found by balanced partitioning), clustering the variance at that unit, and accepting that effective sample size falls by roughly the average cluster size.
Reporting a mean for a heavy-tailed metric without saying what it hides
For spend, session length or items per order, a small fraction of units carries most of the total, so the mean has a wide standard error and one account can move it. Fix the handling before you see the result: cap or winsorise at a pre-declared percentile, and report the median or the share above a threshold next to the mean. Capping changes the estimand, so say which question the capped number answers, and check how much of any difference comes from the top 0.1 percent of units.
Reporting a p-value with no effect size or interval
Give the estimated difference with a confidence interval in the units the business cares about, then say whether that whole interval is worth acting on. A p-value only addresses whether you can rule out exactly zero; it says nothing about magnitude.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you manage expectations when a sophisticated model fails to pro…
How do you manage expectations when a sophisticated model fails to produce the expected lift in engagement?
Approach
- Set a baseline first, so any model has something honest to beat.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- Where could label leakage enter this setup?
- How would you choose the decision threshold, and who owns that choice?
Describe a scenario where you had to choose between a complex deep lea…
Describe a scenario where you had to choose between a complex deep learning model and a simpler heuristic approach; how did you justify your choice?
Approach
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Describe your approach to working with engineers to implement a model …
Describe your approach to working with engineers to implement a model you’ve prototyped.
Approach
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Check what information would not exist at prediction time, and exclude it.
- Say how the offline result would be validated online before it is trusted.
Follow-up
- Where could label leakage enter this setup?
- What would you monitor after launch to know the model is still valid?
Simulate the false positive rate of a skewed A/A test
Per-member weekly impressions are strongly right-skewed. Simulate a population from Lognormal(mu=2.0, sigma=1.8), draw N members, split them at random into two arms, and run Welch's t-test on the per-member means. This is an A/A, so the null holds by construction and any rejection is a false positive. Report the empirical rejection rate at a nominal 5 percent for N of 4,000 and 100,000, each under a 50/50 and a 90/10 split, with the Monte Carlo standard error. Add a permutation test on the difference in means as a comparison arm. Say which cell is distorted and why.
Approach
- Build the harness so the null is true by construction: draw one population, then assign arms by a random permutation. Nothing differs between arms except the split, so every rejection is an error and there is no effect size to argue about.
- Choose B before running and derive the Monte Carlo standard error from it: sqrt(p(1-p)/B), which at p near 0.05 and B = 10,000 is about 0.22 percentage points. Any claim that 5.4 percent differs from 5.0 percent has to survive plus or minus roughly 0.43 points at 95 percent, so pick B for the difference you intend to resolve, not by habit.
- Run the four cells. Equal-sized arms are close to robust here because the skewness contributions of the two arms largely cancel in the t statistic; the 90/10 split is where the cancellation fails and the test is genuinely off nominal at small N. Report the numbers rather than asserting the direction in advance.
- Validate the harness before trusting the result: swap the lognormal for a Normal population and confirm every cell returns about 5 percent. If the Normal cells are off, the bug is in the code, not in the tail.
- Add the permutation arm: shuffle the arm labels, recompute the difference in means, and take the two-sided p as the share of shuffles at least as extreme. Under a random split exchangeability holds exactly, so this arm should sit at nominal in every cell and acts as the reference.
- Close with the operational consequence: the fix for the distorted cell is either balanced allocation, a permutation or bootstrap reference distribution, or a pre-registered cap, and a cap changes the estimand so it must be declared before the read, not chosen after seeing it.
Worked solution 35 min
- rng = np.random.default_rng(0); draw x = rng.lognormal(2.0, 1.8, size=N) inside each replicate so the population varies too
- Assign arms: idx = rng.permutation(N); treat = idx[:int(Nfrac)], ctrl = idx[int(Nfrac):]
- p = scipy.stats.ttest_ind(x[treat], x[ctrl], equal_var=False).pvalue; accumulate p < 0.05 over B = 10,000 replicates
- Permutation arm: for a subsample of replicates, build the reference by shuffling labels 2,000 times and taking the share of |diff| at least the observed |diff|
- Assemble a 4-row by 2-column table of rejection rate and MC standard error sqrt(p*(1-p)/B), one row per (N, split) cell
- Rerun the whole table with rng.normal as the population to validate the harness
Follow-up
- A pre-registered winsorisation at the 99th percentile fixes the level. What question is the capped metric now answering, and is it still the one the product owner asked?
- Repeat this with the ratio metric impressions per session rather than a per-member mean. What changes in the variance calculation?
- How much power did the 90/10 split cost relative to 50/50 at the same total N, and when is the ramp still worth it?
Measure notification lift against a holdout without inflating denominators
fct_notification_decision(notification_id, recipient_member_id, decided_at_utc, decision, holdout_group, opened_at_utc, resulting_session_id) carries one row per decision, including suppressed and held-out ones. qualified_session(session_id, member_id, started_at_utc) carries one row per qualified session. Over a fixed 28-day window with holdout assignment stable throughout, compute qualified sessions per member in holdout_group = 'send' and in holdout_group = 'holdout_global', their difference, and that difference divided by sends per member in the send arm. Do not use opened_at_utc anywhere.
Approach
- Build a member-level roster first: one row per recipient with their holdout_group and their send count. Also count DISTINCT holdout_group per member — if any member has two, assignment was not stable and the whole estimate is void, so the query should surface that rather than silently pick one.
- Aggregate sessions to one row per member independently of the notification table. Joining decisions to sessions on member_id before aggregating multiplies each session by the member's decision count, and because the send arm has far more decision rows, the inflation is larger in the arm you are trying to show a lift for.
- Take sends per member from the send arm only. Held-out members have zero sends by construction, so pooling the arms would put a denominator of nearly zero under the whole calculation.
- Compute each arm's sessions per member as total sessions over total members in the arm, keeping members with zero sessions in the denominator via a LEFT JOIN. Restricting to members who had a session conditions on the outcome and discards the zeros that carry most of the effect.
- Report arm sizes beside the estimate. This is a ratio of correlated sums at the member level, so its interval needs the delta method or a bootstrap; a binomial interval on sessions would be far too narrow.
- Never restrict either arm to members who opened a notification. Opening is caused by the same intent the notification is supposed to create, so an opener-versus-non-opener comparison estimates selection and makes almost any send look profitable.
Worked solution 30 min
- CTE arm: SELECT recipient_member_id AS member_id, MIN(holdout_group) AS arm, COUNT(DISTINCT holdout_group) AS n_arms, SUM(CASE WHEN decision = 'sent' THEN 1 ELSE 0 END) AS sends FROM fct_notification_decision WHERE decided_at_utc inside the window GROUP BY 1.
- Assert MAX(n_arms) = 1 and stop if it is not; a member in two arms means assignment drifted mid-window.
- CTE sess: SELECT member_id, COUNT(*) AS sessions FROM qualified_session WHERE started_at_utc inside the window GROUP BY 1.
- LEFT JOIN sess onto arm so zero-session members survive with 0, then GROUP BY arm: COUNT() AS members, SUM(COALESCE(sessions, 0)) * 1.0 / COUNT() AS sessions_per_member, SUM(sends) * 1.0 / COUNT(*) AS sends_per_member.
- Pivot the two arms into one row and compute the difference and the difference divided by sends_per_member in the send arm.
Follow-up
- The result says each send buys 0.02 incremental qualified sessions. Does doubling send volume buy twice as much?
- The holdout arm is 1 percent of members. What can and cannot be concluded at that size, and what would you change for the next window?
- Opt-outs in the send arm rose steadily over the 28 days. How does that change the number you report?
Compare engagement on first delivery versus later re-deliveries
fct_feed_impression(impression_id, event_date, viewer_member_id, content_id, served_at_utc, rank_position) records every delivery, and the same item can be served to the same viewer many times. fct_engagement_event(impression_id, action_type, is_negative_feedback, undone_at_utc) links an action back to the impression it came from. For one week, compute positive engagement rate per impression split by delivery ordinal for a fixed viewer-content pair: first delivery, second, third, fourth or later. Return the ordinal bucket, impressions, engaged impressions and rate.
Approach
- Number the deliveries with ROW_NUMBER() OVER (PARTITION BY viewer_member_id, content_id ORDER BY served_at_utc, impression_id). The impression_id tiebreak makes the numbering deterministic when two rows share a timestamp, which matters because re-deliveries in one scroll can land in the same millisecond.
- Bucket the ordinal to 1, 2, 3 and 4-or-later rather than reporting a long tail. The far tail is sparse and its rate swings on a handful of viewers.
- Deduplicate the engagement side to one row per impression_id before joining. A viewer can like and comment on the same impression, and counting both makes engaged impressions exceed impressions in the bucket.
- Aggregate by summing numerator and denominator per bucket and dividing once. Averaging per-viewer rates answers a different question and is dominated by light viewers, who have one impression and a rate of 0 or 1.
- Say plainly that the resulting curve is not a causal read on re-delivery. The ranker decides what to re-serve and re-serves what it predicts will be engaged with, and rank_position also differs systematically across ordinals. Controlling for rank_position narrows the gap without closing it.
Follow-up
- Re-deliveries show a higher rate than first deliveries. Does that mean re-showing content is good?
- Design the exploration slot or experiment that would actually answer the question this query cannot.
- The same query cut by rank_position shows slot 1 at four times slot 20. What is that number measuring?
What metrics would you prioritize to evaluate the quality of a recomme…
What metrics would you prioritize to evaluate the quality of a recommendation engine beyond simple click-through rate?
Approach
- Fix the population and the time window before naming any metric.
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
Follow-up
- Which segment would you cut first, and what would that rule out?
- How would you detect that the metric is being gamed rather than genuinely improving?
If you were tasked with building a "discover weekly" style feature for…
If you were tasked with building a "discover weekly" style feature for Suno, what data features would you prioritize?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- Fix the population and the time window before naming any metric.
- Decompose the metric into the rates that drive it, and say which one you would check first.
Follow-up
- What would you do if the primary metric and the guardrail moved in opposite directions?
- Which segment would you cut first, and what would that rule out?
What are the trade-offs between collaborative filtering and content-ba…
What are the trade-offs between collaborative filtering and content-based filtering in an audio-heavy context?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Restate the decision this analysis has to support, and who acts on the answer.
- Name one primary metric, then the guardrail that stops it being gamed.
Follow-up
- Which segment would you cut first, and what would that rule out?
- What would you do if the primary metric and the guardrail moved in opposite directions?
How would you handle the "cold start" problem for a brand-new user wit…
How would you handle the "cold start" problem for a brand-new user with no listening history?
Approach
- State your assumptions explicitly before working the problem.
- Clarify what is being asked and what a complete answer would contain.
- Say what you would check first and why it is the highest-information step.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Diagnose a sample ratio mismatch before reading the lift
The dashboard for a 50/50 home_feed test reports, over 9 days, 402,913 distinct viewer_member_id in control and 398,412 in treatment, read from fct_feed_impression.experiment_bucket. Impression rows differ between arms by 4 percent. The team is ready to read a +1.4 percent lift on the primary. Deliver the test statistic and your verdict on whether the lift is readable, the three cuts you would run first to localise the cause, and whether the impression-row gap is itself evidence of a problem.
Approach
- Test at the randomisation unit only. Chi-square goodness of fit on distinct assigned members against the designed 50/50 split, 1 degree of freedom, alerting at a strict threshold such as p < 0.001 because the test runs on every experiment every day and a 0.05 alarm fires constantly.
- Rule the impression gap out as evidence: impressions per member is an outcome the treatment is designed to move, so an arm difference there is expected and carries no information about assignment integrity.
- Localise by splitting the chi-square: by event_date to find the onset day, by client_platform and app_version to catch an arm-specific crash or a build that fails to log the bucket, and by tenure or registration date to catch members who enter the experiment through a different code path.
- Interrogate the trigger point. If the bucket is stamped at first impression rather than at assignment, the treatment can change who ever gets stamped, which produces mismatch and differential triggering at once; reconcile the impression-derived counts against the assignment service log.
- Check analysis-side filters applied after assignment: bot exclusion, impression dedupe, dropping suspended or deleted accounts. Any of these applied asymmetrically produces the same signature.
- Fix the cause and restart. Do not reweight the arms to the designed ratio; the missing members are not missing at random with respect to the outcome.
Worked solution 15 min
- Total assigned = 402,913 + 398,412 = 801,325, so each arm is expected to hold 400,662.5.
- Deviation is 2,250.5 per arm; chi-square = 2 x 2,250.5^2 / 400,662.5.
- Convert to a p-value on 1 degree of freedom and compare against the alert threshold.
- State the observed split as a percentage so the size of the problem is legible to non-statisticians.
- List the three cuts and the one reconciliation against the assignment log.
Follow-up
- The imbalance is confined to one app_version. Can you analyse the remaining versions and ship?
- What alert threshold do you set for SRM across hundreds of concurrent tests, and how do you keep the false alarm rate tolerable?
- An SRM appears only after day 6. What single hypothesis does that timing favour?
Every surface improved while the pooled engagement rate fell
Engagement actions per 1,000 impressions fell 3.4 percent week over week platform-wide. Cut by surface (home_feed, following_feed, topic_feed, search, profile, notifications), every surface's rate rose. Both numbers come from the same fct_feed_impression and fct_engagement_event rows over the same two weeks. Explain the arithmetic, attribute the platform move between mix and within-segment rate with the terms quantified, and state which of the two the product owner should act on and why the other one is still worth reporting.
Approach
- First confirm the platform number is a ratio of sums (total engagements over total impressions) and not an unweighted mean of the six surface rates. If the dashboard averaged surface rates, there is no paradox to explain, only a roll-up bug to fix.
- Build the segment table: impressions w_s (as a share of total) and rate r_s per surface, for both weeks, with numerator and denominator printed beside every rate.
- Apply the exact decomposition dR = sum_s (dw_s * r_s0) + sum_s (w_s0 * dr_s) + sum_s (dw_s * dr_s), and report all three terms. The identity is exact, so the three terms must reconstruct the observed platform delta, which is the check that the table is right.
- Identify what moved the weights. Which surface gained impression share, and why: a surface launch, a notification volume change feeding the notifications surface, or a client change that renders more topic_feed slots per session.
- Decide the action. If the mix term dominates and every within-surface rate rose, the ranker improved and the pooled metric is largely measuring surface allocation. Recommend reporting the fixed-weight rate as the quality signal and the pooled rate as the exposure-weighted reality, and say explicitly which decisions each one is allowed to drive.
Follow-up
- Which should be the headline metric, the pooled rate or the fixed-weight rate, and what does each one fail to catch?
- The same arithmetic occurs across country and platform. How do you choose which dimension to standardise on, and what stops this becoming six standardised metrics nobody reads?
- If search impressions grew because search got better, is the pooled decline a real harm to members?
For someone who can already write the query and train the model but stalls when asked what to measure or whether a change is worth making. Metric definition and case structure come first; the technical work is kept as maintenance rather than the centre of the week.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Metric anatomy
- For three products you use daily, write one primary metric, two input metrics that plausibly move it, and one guardrail that would catch a cheap way of moving the primary at the cost of the product.
- For one of them, specify the metric precisely enough that two analysts would return the same number: numerator, denominator, unit of observation, time window, and how returning and deleted accounts are treated.
- Pick a ratio metric and write what happens to it when the denominator shrinks for reasons unrelated to the numerator, with a concrete example of that happening.
Deliverable: A one-page metric tree for one product, with the primary metric written as an unambiguous spec.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Diagnosing a drop without guessing
- Take the prompt "weekly active users fell 8 percent week over week" and write the segmentation plan before proposing any cause: platform, region, tenure cohort, acquisition channel, and whether the movement sits in the numerator or in a changed denominator.
- List the instrumentation failures that manufacture fake drops (a client release that stopped firing an event, a bot filter change, a shifted date boundary or timezone) and write the query that rules out each one.
- Rehearse stating the boring explanations first, seasonality and day-of-week composition, before reaching for a product cause.
Deliverable: A drop-diagnosis checklist short enough to recite from memory in under a minute.
Practice prompt ↗Practice prompt ↗03Should we build it
- Take a feature idea and write it as a bet: what you believe is true, what would have to be true for it to pay off, the metric that would confirm it, and the effect size that would justify the engineering cost.
- Size the opportunity top-down and bottom-up, then reconcile the two numbers in writing instead of quoting whichever is friendlier.
- Write the counter-metric that would make you kill the feature even if it wins on the primary metric.
Deliverable: A one-page product memo ending in a decision rather than a list of considerations.
Practice prompt ↗Practice prompt ↗04The places aggregate numbers lie
- Construct a Simpson's paradox numerically: two segments where the treatment wins within each segment yet loses overall, and identify the shift in segment weights that causes it.
- Take a heavy right-tailed quantity such as revenue per user and write why the mean is the wrong summary, which percentile you would report instead, and what a moving mean with a stable median tells you.
- Write your definition of a session for the product from day one, then name two real behaviours it misclassifies.
Deliverable: One page holding a worked Simpson's paradox table and a session definition with its two known failure cases.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Technical maintenance, aimed at metrics
- Solve four timed SQL prompts that all end in a ratio metric, so the question of grain stays live in every answer.
- Compute a 95 percent confidence interval for a proportion on a small sample, and state why the normal approximation is unreliable when either np or n(1 minus p) falls below roughly 10, along with which interval you would use instead.
- Take one metric from your day-one tree, write the query that computes it correctly, then write the query that computes it wrong in the most plausible way and explain how you would notice.
Deliverable: Four solved prompts plus a matched correct and plausible-wrong query for one metric.
Practice prompt ↗Practice prompt ↗06Turning engineering work into data science stories
- Write three project stories as situation, decision, trade-off, outcome, each carrying one number and one thing you got wrong.
- For the story you will lead with, prepare an answer to "what would you do differently" that names a decision you made, not a constraint you were handed.
- Practise the sentence that reframes a systems project as a question project: the question the work answered, ahead of the pipeline it shipped.
Deliverable: Three written stories with the lead story delivered aloud and timed under four minutes.
Practice prompt ↗Practice prompt ↗07Mock case and gap list
- Run a 40-minute mock case with someone playing a product manager who pushes back on your metric choice, and record it.
- Listen back and mark every moment you proposed a solution before the success metric existed.
- Rewrite those moments as the question you should have asked, and rehearse the first 90 seconds of the case until scoping comes before solving.
Deliverable: A recorded case plus a rewritten opening 90 seconds.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Nearly every data role forces a trade between the analysis you want and the one that fits the decision window. Prepare a case where you deliberately shipped something less rigorous, named the weakness to the person relying on it, and said what would change your answer. The naming is the part interviewers listen for.
How do you stay aligned with the creative vision of the company while …
How do you stay aligned with the creative vision of the company while maintaining data-driven objectivity?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Close with what you would do differently, concretely.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- How did you know the outcome was caused by your change?
- What did you decide not to do, and why?
Tell me about a time you had to influence a product roadmap using data…
Tell me about a time you had to influence a product roadmap using data insights.
Approach
- Name the disagreement or constraint, and how you resolved it with evidence.
- Quantify the outcome, including what you would not claim credit for.
- Close with what you would do differently, concretely.
Follow-up
- What would you do differently if you ran that project again?
- How did you know the outcome was caused by your change?
Walk through an analysis you shipped that was wrong
Prepare a five-minute account of an analysis you delivered that a decision was made on and that later turned out to be wrong. Cover the conclusion you gave, the mechanism of the error stated precisely enough that a peer could reproduce it, how and by whom it was found, how long it stood, what the wrong decision cost, and the specific check now in your workflow. Expect the interviewer to ask which of your current results is most likely wrong for the same reason.
Approach
- Lead with the decision and the error in two sentences, then go back for detail. An account that opens with context loses the interviewer before the mechanism arrives.
- State the mechanism as a data fact, not a mood. 'A repeated delivery of the same item to the same viewer counted as two impressions in the denominator, so the engagement rate was deflated for high-redelivery surfaces' is assessable. 'The data was messy' is not, and it reads as not having understood the bug.
- Say who found it without softening. If a reviewer or a downstream team found it, say what in your process let it through: a rate rolled up by averaging sub-period rates, a filter applied after treatment, a class decomposition never checked against its total.
- Quantify the cost in the currency of the decision rather than in revenue you cannot support: a launch held for six weeks, a team quarter spent on the wrong lever, a metric definition that ten later decisions inherited. Then say how much of the original conclusion survived the correction, because often the direction held and only the magnitude broke.
- Close on a check that either runs or does not: printing row counts at each grain before aggregating, asserting that the four DAU classes sum to DAU, reporting numerator and denominator beside every ratio. Give one instance of that check firing since, which is what separates a process change from an intention.
Follow-up
- What did you tell the people who had already acted on the wrong number, and when?
- Which result you currently stand behind is most likely wrong for the same reason?
- Why was that check not already in the work? What made it feel unnecessary at the time?
- 01
How do you stay aligned with the creative vision of the company while maintaining data-driven objectivity?
- 02
Tell me about a time you had to influence a product roadmap using data insights.
- 03
Prepare a five-minute account of an analysis you delivered that a decision was made on and that later turned out to be wrong. Cover the conclusion you gave, the mechanism of the error stated precisely enough that a peer could reproduce it, how and by whom it was found, how long it stood, what the wrong decision cost, and the specific check now in your workflow. Expect the interviewer to ask which of your current results is most likely wrong for the same reason.
Is this an official Suno interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Suno. Rounds and questions reflect what candidates have reported, not a process Suno has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How technical are the coding interviews at Suno?
The coding interviews are practical and focused on data manipulation and algorithm implementation relevant to recommendation tasks. You should be comfortable writing clean, efficient code that can handle large datasets.
PracHub interview research ↗What is the company culture like?
Suno is a fast-paced, mission-driven startup that values creativity and high-quality output. The environment is collaborative, and there is an expectation that everyone—regardless of seniority—gets their hands dirty with data.
PracHub interview research ↗How much time should I spend preparing?
Given the seniority and the complexity of the role, most successful candidates spend 2–4 weeks of focused preparation. Prioritize reviewing your past projects and practicing how you articulate your design decisions.
PracHub interview research ↗Is this role fully remote?
This position is based in San Francisco, CA, and you should expect to be in-office to collaborate closely with the product and engineering teams.
PracHub interview research ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
TELUS Digital AI Community Data Scientist Interview Questions & Guide 2026
SQL sets for data scientist prep ahead of TELUS Digital AI Community, covering window functions, funnel and retention queries, and the joins that quietly drop the rows you needed.
Strike Social Data Scientist Interview Questions & Guide 2026
Product-sense practice for a Strike Social data scientist interview: define a social and content platforms metric, pick its guardrails, and argue why a tempting alternative would mislead you.
Reddit Data Scientist Interview Questions & Guide 2026
Data-quality drills for Reddit data scientist prep: survivorship and selection bias, leakage through time-ordered features, and extreme values where provenance decides the call. A logging fault or unit slip gets corrected or dropped; a genu
Patreon Data Scientist Interview Questions & Guide 2026
Timed practice for Patreon data scientist candidates who freeze under a clock: short SQL and probability sets run end to end, then reviewed against a written rubric.