This guide covers what a Data Scientist at Linktree is expected to do and how to prepare for the interview.
Recruiter Screen
reportedA screening call is a matching exercise run by someone who will not evaluate your statistics. They are checking that the work described on your resume is work you personally did, and that its scope matches the level the role is written for. Logistics get settled in the same half hour so nobody spends an interviewer's afternoon on a mismatch. The answer that fails is the one narrated in the plural. If every sentence is 'we built' and 'the team decided', there is nothing specific to write down about you. Name the piece that was yours, the decision you made inside it, and what changed after.
What to demonstrate
- Whether the ownership implied by your resume survives one round of follow-up about who actually did which part
- Whether your described scope (data size, stakeholders, what shipped) matches the seniority the role is written at
- Whether timeline, location and compensation expectations make the rest of the loop worth scheduling
How to prepare
- Rewrite your top three resume bullets in the first person singular, each with the decision you made and what moved afterwards, then say them out loud once so the 'we' does not return under pressure
- Attach one number to each project: the baseline, the change, and the window it was measured over. Where impact was never measured, say that plainly rather than inventing a figure
- Settle your compensation range before the call and give it as a range with a reason behind it, such as current total comp or a competing timeline, instead of deflecting the question twice
Product Manager Interview
reportedUnderneath the questions about your past work sits a resourcing question. Given four things worth doing and one of you, which gets done and what happens to the rest? Managers ask because that is the daily texture of the job, and because the answer shows whether you rank work by effort or by what it changes. The weak version sorts by personal interest or by whoever asked most insistently. The strong version ties each candidate piece of work to a decision somebody downstream is waiting on, and then names the one you would drop and who you would tell.
What to demonstrate
- Whether you rank work by the decision it unblocks or by how interesting the method is
- How you describe a request you declined, and whether you can say who you said it to
- Whether your sense of how long something takes survives one follow-up question about the messy part
- How you decide something is good enough to hand over unfinished
How to prepare
- Write out your current queue and, next to each item, the decision that stays stalled until it lands. Anything with no waiting decision becomes your example of work you would cut
- Rehearse turning down a plausible stakeholder request out loud, including the smaller alternative you offered instead
- Have one case where you shipped a rough answer early and one where you refused to, with the reason that separated them
Technical Round
reportedThis round decides whether someone can hand you a schema and a question and trust the number that comes back. Correctness under a clock is the bar, not clever syntax. The habit that separates strong from weak answers is checking the grain: after every join, know how many rows you expect and whether the count moved. Most wrong answers in this format are not wrong logic, they are a fan-out from a key that turned out not to be unique, or a filter applied before an aggregate when it belonged after. Say what you expect before you run it.
What to demonstrate
- Whether your row counts survive each join, and whether you notice on your own when they do not
- Deliberate handling of rows that fail to match, including whether the question needs an inner join or a left join with the non-matches kept and counted
- Whether NULLs are treated on purpose, given that a NULL compares equal to nothing and that COUNT of a column skips it
- Reaching a defensible answer inside the window instead of a refined one after it
How to prepare
- Take a two-table schema, write a join that fans out on purpose, then fix it by collapsing the many-side to one row per key before joining. Repeat until the fix is reflex rather than recall.
- Write a funnel as one query and print the distinct user count at each stage, then confirm each stage is a subset of the one above it rather than assuming it
- Do a few timed runs in a plain text box with no autocomplete and no formatter, since assessment editors often have neither
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.
Reading an observational correlation as a causal effect
Name the confounder you are most worried about and the design that would remove it: an experiment, a difference-in-differences with a checked pre-period trend, an instrument, or a regression discontinuity. When none is available, state which direction the bias likely runs and bound the claim accordingly.
Crediting a treatment for regression to the mean
Selecting a group because it is extreme (lowest-engagement users, accounts having their worst month, the bottom decile of a score) moves that group's expected next-period value back toward the average even under no treatment, by exactly as much as the selecting measure is imperfectly correlated with its own later value. Compare against units that met the same selection rule and went untreated, or use two pre-periods so the bounce-back is visible before the intervention starts. A pre-post number on a group chosen for being extreme measures the selection rule, not the treatment.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Roll a daily negative feedback rate up to a week
You have two DataFrames. impressions: impression_id, event_date (date), surface. engagements: event_id, event_date, surface, impression_id (nullable), is_negative_feedback (bool). Compute negative feedback per 1,000 impressions: 1000 times the count of engagement rows with is_negative_feedback True and impression_id not null, over the count of impressions in the same date and surface. Return a daily table by surface, then a weekly table built by re-summing numerator and denominator. Also return the unweighted mean of the seven daily rates for the same weeks, and say which number you would publish.
Approach
- Aggregate the two frames separately to (event_date, surface) grain: a numerator count from engagements filtered on is_negative_feedback and impression_id.notna(), a denominator count from impressions. Keep them as two columns, not a pre-divided rate, because everything downstream needs the parts.
- Outer-join numerator onto denominator so that a day with impressions and zero negative feedback becomes a 0 rather than disappearing. A dropped zero-numerator day silently raises every rolled-up rate.
- Attach a week key to the daily frame, then compute the weekly rate as 1000 * sum(numerator) / sum(denominator) grouped by (week, surface). This is a ratio of sums.
- Compute the second, wrong number for comparison: groupby(week, surface).rate.mean(). Show the two side by side with the daily impression counts so the divergence has a visible cause.
- State the rule: the weighted version is the volume-weighted average of the daily rates, so the unweighted mean over-weights low-traffic days. The two agree only when every daily denominator is identical.
- Report numerator, denominator and rate in the output, never the rate alone, so a reader can tell a denominator move from a numerator move.
Follow-up
- The hide control moved from a submenu to the card on Tuesday. What happens to this metric, and is it a quality regression?
- How would you report this rate split by hide, report, not-interested and unfollow without publishing four charts nobody reads?
- An engagement row has impression_id NULL. Should it be in this numerator, and what is it measuring if you include it?
Trailing seven-day distinct actives without a rolling window
activity has member_id (int64) and local_date (date), one row per member per active local day, about 60 million distinct pairs spanning 400 dates. For every date d in the range, compute the number of distinct members active on at least one day in the closed window [d minus 6, d]. You may not use rolling, and you may not loop over dates recomputing a distinct count across the full frame. Return a DataFrame of date and wau, and state the time and memory cost of the method you chose.
Approach
- Say why the obvious answers fail. Summing seven daily active counts double-counts anyone active on more than one day, which is most of the active base. Looping over 400 dates with a nunique over 60 million rows is 400 full passes. Neither is a rolling-window problem in the pandas sense, because the aggregate is a distinct count and distinct counts do not decompose additively.
- Reframe it geometrically. A member contributes to wau(d) exactly when d lies in [t, t+6] for one of their active dates t. So the answer is the size of the union of those intervals, counted across members, evaluated at each date.
- Merge each member's intervals before counting, which is the step that removes the double counting. After sorting by (member_id, local_date), a new interval starts wherever the gap to the previous active date exceeds 7 days; otherwise the interval extends. The run's interval is [first t of the run, last t of the run + 6].
- Turn merged intervals into a difference array: plus one at each interval start, minus one at end plus one day, then a cumulative sum over the full date index. That is O(number of runs) memory and one sort overall.
- Offer the simpler alternative and price it: explode each (member, date) into the seven dates it covers, drop duplicates on (member, target_date), then count per target_date. Correct and easy to defend, but it materialises seven times the rows before the dedupe, so it is a memory decision rather than a correctness one.
- Handle the edges: dates in the first six days of the range have a truncated window and should be reported as such or dropped, not silently published as a lower wau.
Worked solution 35 min
- a = activity.drop_duplicates().sort_values(['member_id','local_date'])
- gap = a.groupby('member_id').local_date.diff().dt.days; run_start = gap.isna() | (gap > 7); run_id = run_start.groupby(a.member_id).cumsum()
- runs = a.groupby([a.member_id, run_id]).local_date.agg(['min','max']); runs['end'] = runs['max'] + pd.Timedelta(days=6)
- deltas = pd.concat([runs['min'].value_counts(), -(runs['end'] + pd.Timedelta(days=1)).value_counts()]).groupby(level=0).sum()
- wau = deltas.reindex(full_date_index, fill_value=0).cumsum().rename('wau').to_frame()
- Mark the first six dates as truncated and either drop them or carry a flag column
Follow-up
- Now report wau by country. What breaks in the interval approach and what do you change?
- The definition changes to distinct members with at least two active days in the window. Does either method survive?
- How would you compute the same number incrementally each day without recomputing the whole history?
Cluster bootstrap a ratio metric under graph randomisation
units has cluster_id, arm ('control' or 'treatment'), neg_feedback_events (int) and impressions (int), one row per member; members are nested in about 900 ego-network clusters, which were the randomisation unit. The metric is negative feedback per 1,000 impressions, a ratio of sums. Write a cluster bootstrap from scratch: resample clusters with replacement within arm, keeping the number of clusters per arm fixed, recompute each arm's ratio and the relative difference, 2,000 replicates, percentile interval. Also compute a cluster-level delta-method interval and a naive member-level bootstrap. Report all three widths.
Approach
- Collapse to the randomisation unit before resampling anything. Sum neg_feedback_events and impressions to one row per (cluster_id, arm). Resampling has to happen over the units that were independently assigned, and members inside a cluster were not.
- Resample cluster rows with replacement within arm, holding the per-arm cluster count fixed, then recompute R = 1000 * sum(numerator) / sum(denominator) per arm from the resampled clusters. Recomputing the ratio of sums inside each replicate is what propagates the correlation between numerator and denominator; averaging per-cluster ratios instead answers a different question and will not match the point estimate.
- Take the relative lift R_t / R_c minus 1 per replicate and read the 2.5th and 97.5th percentiles off the 2,000 values. Percentile is adequate here; mention BCa as the refinement if the bootstrap distribution is visibly skewed.
- Derive the delta-method interval at the cluster level as the analytic check. With n clusters contributing numerator y_i and denominator x_i, R = ybar / xbar and Var(R) is approximately (1 / (n * xbar^2)) * (var(y) - 2Rcov(y,x) + R^2*var(x)). Arms are independent, so variances add for the difference.
- Run the naive member-level bootstrap only to show what it costs. Resampling members destroys the within-cluster correlation, so its interval is narrower by roughly the square root of the design effect 1 + (m - 1) * ICC, where m is the average cluster size. Quote that number as the price of the design.
- Close with the decision: report the cluster interval, state the number of clusters rather than the number of members as the effective sample size, and say what minimum detectable effect that leaves.
Follow-up
- The cluster sizes are extremely uneven, with the largest cluster holding 4 percent of impressions. What does that do to the bootstrap and what would you change?
- Derive the delta-method variance for the relative lift rather than the difference, and say when the two disagree.
- You have 900 clusters and need to detect a 3 percent relative change. Is this test powered, and what would you trade to get there?
Write a query using window functions to calculate the 7-day rolling av…
Write a query using window functions to calculate the 7-day rolling average of active users per day.
Approach
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- What breaks if events arrive late or out of order?
- How would you verify this result without re-running the same query?
Given a table of user events, how would you calculate the time between…
Given a table of user events, how would you calculate the time between the first and second interaction?
Approach
- Compute rates by summing numerator and denominator separately, never by averaging rates.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which table is the grain you start from, and join outward from it.
Follow-up
- How does the query change if the join becomes one-to-many?
- What breaks if events arrive late or out of order?
Count creators reaching fifty distinct viewers in a week
Using fct_feed_impression(event_date, viewer_member_id, content_id, author_member_id) and fct_content_item(content_id, author_member_id, item_kind), count members who published an original item that reached at least 50 distinct viewers during one calendar week. A re-delivery of the same item to the same viewer is a separate impression row. Reach is measured per item, not pooled across an author's items. Return one row per qualifying author with the distinct-viewer count of their best item. Replies, reposts and quotes are excluded.
Approach
- Filter fct_content_item to item_kind = 'original' first. The join then does double duty as a filter and keeps reply and repost deliveries out of the impression scan entirely.
- Aggregate impressions with COUNT(DISTINCT viewer_member_id) per content_id. COUNT(*) answers a different question — deliveries, not people — and the two diverge by however aggressively the ranker re-serves an item.
- Filter the per-item counts at 50, then group up to author_member_id taking MAX of the per-item reach. The definition is one item reaching 50 viewers, not 50 viewers accumulated across several items, and pooling would let three items of 20 viewers qualify a creator who never reached anyone.
- Use fct_feed_impression.author_member_id wherever the author is needed. It is denormalised precisely so reach and concentration queries avoid joining the largest fact in the warehouse; the join to fct_content_item is only for item_kind.
- Filter the week on event_date, which is already viewer-local. Mixing it with a UTC timestamp predicate on served_at_utc would include or drop a sliver of the boundary days depending on the viewer's offset.
Worked solution 15 min
- CTE orig: SELECT content_id, author_member_id FROM fct_content_item WHERE item_kind = 'original'.
- CTE reach: SELECT i.content_id, i.author_member_id, COUNT(DISTINCT i.viewer_member_id) AS viewers FROM fct_feed_impression i JOIN orig o ON o.content_id = i.content_id WHERE i.event_date BETWEEN the Monday and the Sunday GROUP BY 1, 2.
- Filter reach to viewers >= 50, GROUP BY author_member_id, and select MAX(viewers) as the author's best item.
- Cross-check the delivery multiple: COUNT() over the same impressions divided by SUM(viewers) is the average re-delivery factor, and a value far above 1 tells you how wrong the COUNT() version would have been.
Follow-up
- Extend this to retained reaching creators: qualified in week w and again in week w+1, divided by those qualified in week w.
- Why might this count rise in a week when the total number of publishes fell?
- An item was removed by moderation on day 6 of the week. Should the impressions it earned on days 1 through 5 still count toward its reach?
How would you measure the success of a new feature designed to help cr…
How would you measure the success of a new feature designed to help creators customize their link appearance?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
- 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 identify "churned" users from a raw clickstream dataset?
How would you identify "churned" users from a raw clickstream dataset?
Approach
- Name one primary metric, then the guardrail that stops it being gamed.
- 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
- What would you do if the primary metric and the guardrail moved in opposite directions?
- How would you detect that the metric is being gamed rather than genuinely improving?
How do you balance trade-offs between short-term engagement and long-t…
How do you balance trade-offs between short-term engagement and long-term user retention?
Approach
- Fix the population and the time window before naming any metric.
- 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
- How would you detect that the metric is being gamed rather than genuinely improving?
- Which segment would you cut first, and what would that rule out?
If we notice a 5% drop in click-through rates on creator profiles, how…
If we notice a 5% drop in click-through rates on creator profiles, how would you go about diagnosing the root cause?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Decompose the metric into the rates that drive it, and say which one you would check first.
- Fix the population and the time window before naming any metric.
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 a test shows a positive impact on conversion but a negative impact …
If a test shows a positive impact on conversion but a negative impact on user latency, how would you advise the product team?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- Decide the analysis before seeing data, including how long it runs and when you look.
- Say whether units interfere with each other, and switch design if they do.
Follow-up
- How would you handle interference between treated and control units?
- What would you conclude if the result is positive but the test is underpowered?
What are the most common experimentation pitfalls you have encountered…
What are the most common experimentation pitfalls you have encountered when testing new UI elements?
Approach
- Name the guardrails that would stop a launch even on a positive primary result.
- State the primary metric and the minimum effect worth shipping, then size the test.
- Name the randomisation unit first; it decides the variance and what the test can detect.
Follow-up
- What would you conclude if the result is positive but the test is underpowered?
- How would you handle interference between treated and control units?
Ad load raises revenue per thousand and costs sessions
A proposal raises paid impressions on the home feed from 12 to 16 percent of slots. Revenue per thousand impressions on monetisable surfaces is the team primary metric; weekly members with a qualified session is the company north-star. The two will move in opposite directions, the revenue gain lands immediately, and the session cost lands over weeks. Using fct_feed_impression (surface, rank_position, dwell_ms, event_date, session_id) and the qualified-session definition, design the read: what you measure, over what window, and what exchange rate would make you launch. Deliverable: the design and a decision rule.
Approach
- State the conflict instead of hunting for a framing where both metrics win. Raising ad load moves the primary partly by construction, since paid impressions enter numerator and denominator together at a higher price per slot, so a lift on its own is not evidence that anything improved.
- Fix the window to the slower quantity: at least four weeks with effect-by-week reporting. Organic-impression displacement surfaces through session length and return rate, not through same-day clicks, and a one-week read prices only the gain.
- Choose guardrails on the same exposure base: qualified sessions per member, impressions per engaged session, and 28-day return rate, each reported by week rather than pooled so a decaying or accumulating effect is visible.
- Convert both sides to one currency before the meeting: incremental weekly revenue against incremental qualified-session loss valued at the platform revenue per qualified member per week, and name the assumption that this conversion holds, because it need not.
- Pre-register the decision rule with a stop condition, for example launch only if the four-week qualified-session effect stays inside a stated non-inferiority bound, and record that a flat week-one read does not satisfy it.
Worked solution 35 min
- Write both metrics with numerator, denominator and window, and require ad load (paid impressions over total impressions on the same surface and window) to be reported beside revenue per thousand so the mechanical component of the lift is visible.
- Specify the design: member-level randomisation is defensible here because ad load does not propagate along the follow graph, but say so explicitly rather than assuming it.
- Lay out the empty effect-by-week table you intend to fill: weeks 1 to 4 by revenue per thousand, ad load, qualified sessions per member, impressions per engaged session, 28-day return rate.
- Write the decision rule as one sentence containing a number, plus the exchange-rate calculation with its value-transfer assumption named.
Follow-up
- Revenue is plus 5.2 percent and qualified sessions are minus 0.4 percent, not significant at four weeks. What do you recommend, and what evidence would change it?
- The revenue lift concentrates in two countries and the session loss in a third. How does that change the decision?
A creator metric that changes when you re-run it
Retained reaching creators (published an original reaching 50 or more distinct viewers in week w and again in week w+1, over those who did so in w) has fallen from 0.62 to 0.54 over six weeks. Re-running the query for week w-6 today returns a different number than the dashboard recorded at the time. fct_content_item.enforcement_state, enforcement_at_utc and deleted_by_author_at_utc all mutate after impressions have been served. Determine how much of the decline is restatement and how much is real supply loss.
Approach
- Quantify the restatement directly. Re-run every historical week today and compare to the stored dashboard values. The gap is restatement by construction, and whatever remains after removing it is the real trajectory. Do this before forming any hypothesis about creators.
- Find the mutating inputs and neutralise them. If the query filters enforcement_state = 'none' or excludes items with deleted_by_author_at_utc set, it applies today's state to last quarter's distribution, silently deleting content that genuinely reached viewers then. Rebuild the metric as-of the week end: treat an item as enforced only when enforcement_at_utc is on or before the week end, and as deleted only when deleted_by_author_at_utc is on or before the week end.
- Split the metric into its three moving parts, because they demand different responses: creators publishing an original in the week, the share of those crossing 50 distinct viewers, and week-over-week persistence among the ones who crossed. A publisher decline is a supply problem, a crossing-share decline is a distribution problem.
- Verify the reach count is deduplicated. The threshold is 50 distinct viewer_member_id values, not 50 impression rows. Any change in re-delivery behaviour moves an undeduplicated count without changing reach at all, and would show up as a fake threshold effect.
- Test the distribution hypothesis. Plot the density of creators by weekly distinct viewers around the cut, and track creator reach concentration (top 1 percent of authors' share of weekly impressions) across the six weeks. A thresholded rate is extremely sensitive to a small shift in mass near 50, so a modest concentration increase can produce this decline with no creator changing behaviour.
- Report three numbers: the restated component, the real component, and which of publishers, crossing share or persistence carries the real part. Recommend pinning as-of state in the dashboard and reporting the continuous reach distribution alongside the thresholded rate.
Follow-up
- The table keeps no history. How do you pin as-of state going forward, and what do you do about the six weeks already lost?
- How much of the six-week move survives if the threshold is 40 or 60 rather than 50, and what does the answer tell you?
- If the decline is real and concentrated in creators just under the threshold, what change would you propose and which guardrail would you put on it?
Four days spend equal time on query work, statistics, modelling and product judgement at deliberately shallow depth, which produces a scored map of where you actually stand. The last three days spend everything on the two areas the role weights most, and close by re-running day one to measure movement.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Breadth pass: query fluency
- Solve six prompts spanning aggregation, joins, window functions and date arithmetic in 60 minutes total, stopping at 10 minutes each whether or not it works, and mark every prompt as solved, solved slowly, or stuck.
- For each unsolved prompt write the single blocking sentence (I lost the grain, I did not know the frame clause, I could not express the date boundary) instead of reading the solution.
- Translate one pandas transformation you know well into SQL and one SQL query into pandas, checking that both return the same row count and the same totals.
Deliverable: A scored six-row table, one line per prompt, saved for the day-seven re-run.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Breadth pass: statistics and inference
- Answer ten short questions in writing with nothing open: what a p-value is conditional on, what a 95 percent interval covers across repeated samples, when a paired test is the right one, what the bootstrap estimates, why multiple comparisons inflate false positives, how controlling the family-wise error rate differs from controlling the false discovery rate, what power depends on, what a missed real effect costs a product, the three situations where the central limit theorem does not rescue you (small n, very heavy tails, dependent observations), and what a standard error is the standard deviation of.
- Grade yourself against a reference and count only the answers that were exactly right, not the ones that were nearly right.
- Rewrite the two weakest answers the following morning from memory in full sentences.
Deliverable: Ten graded answers with an honest count of exact hits.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Breadth pass: modelling
- Take one tabular dataset end to end in 90 minutes: a leakage-safe split, a baseline that is not a model (majority class or historical mean), one regularized linear model, one gradient-boosted tree, and a single evaluation metric chosen before you look at any result.
- Write why that metric fits the cost structure: precision at a fixed recall for alerting, calibration for anything feeding a price or a threshold, ranking metrics for retrieval, and note that area under the ROC curve is insensitive to class balance in a way that can flatter a rare-positive problem.
- Name the leak you were most likely to introduce (an encoding fit on all rows before splitting, or a feature computed after the label's timestamp) and write the check that would have caught it.
Deliverable: A notebook whose first cell states the metric and the baseline, plus two lines on what beat what and by how much.
Practice prompt ↗Practice prompt ↗Practice prompt ↗04Breadth pass: product judgement
- Answer three case prompts aloud at 15 minutes each, timing how long passes before you state a success metric.
- For one case write the first segmentation you would run and the row counts you expect per segment, so that a tiny segment cannot quietly drive the conclusion.
- Take a metric definition you did not write, from a public dashboard, a textbook, or documentation you already have open, and list every place two analysts implementing it would diverge: which rows the denominator admits, whether the unit is an account or a person, what the time window is anchored to, and what happens to data that arrives late. Then write the one question that would close the largest of those gaps.
Deliverable: Three recorded case answers plus an ambiguity list for a metric someone else defined, ending in the single question you would ask about it.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Depth, first area
- Rank the four areas by how many bullet points in the role description each one covers, pick the top one, and spend the entire day inside it.
- Work the six hardest problems you can find in that area and for each write the generalizable move you should have reached for first, rather than the answer.
- Re-solve the two you failed the same evening with notes closed.
Deliverable: Six generalizable moves written as instructions to yourself, not as solutions.
Practice prompt ↗Practice prompt ↗06Depth, second area, and the seam between them
- Repeat the depth protocol on the second-ranked area with the same six-problem structure.
- Construct one problem that requires both areas at once, for example a metric redefinition whose effect you must validate with a test whose readout you then have to query.
- Solve your own combined problem end to end and note where the handoff between the two areas cost you time.
Deliverable: One combined problem, solved end to end, with the handoff failure written down.
Practice prompt ↗Practice prompt ↗07Integration and re-measurement
- Re-run the six prompts from day one under the same clock and compare both correctness and time.
- Run a 60-minute mixed mock that moves between areas without warning, since switching cost is what breadth passes do not train.
- Write the two areas you would still fail on, and the sentence you will use in the interview when you hit one of them.
Deliverable: A before-and-after score table plus a written plan for the two remaining gaps.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Data people depend on systems owned by other teams, and much of the job is negotiating for instrumentation, access, or a fix to a broken pipeline. Prepare an example of getting something changed upstream that you did not control. Describe what you asked for, what you traded, and how you worked while you waited.
Describe a situation where you disagreed with a Product Manager regard…
Describe a situation where you disagreed with a Product Manager regarding an experiment's design. How did you resolve it?
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Quantify the outcome, including what you would not claim credit for.
- Name the disagreement or constraint, and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that project again?
Recommend holding a ranker that lifts engagement and hides
A ranking change finished a four-week cluster-randomised test on the home feed. Impressions per engaged session rose 3.1 percent and authored interactions per weekly active member rose 0.4 percent. Negative feedback per 1,000 impressions rose 6 percent, concentrated in hide and not_interested; unfollow was flat. Creator reach concentration rose 1.4 points. The product owner has already briefed the launch upward. In ten minutes give your recommendation, the exchange rate you are applying between engagement and quality, and the specific result that would change your mind. You may request two extra cuts of the data.
Approach
- Put both movements on the same base before arguing about them. Negative feedback is denominated per impression, and impressions per engaged session rose 3.1 percent, so absolute negative actions per engaged session rose about 9.3 percent (1.06 times 1.031), not 6 percent. Say that number out loud; it is usually the first thing nobody has computed.
- Ask whether the negative feedback rise is broad or concentrated: report distinct actors per 1,000 impressions beside the event rate. A rise driven by more members hiding is a distribution problem that affects the median viewer; a rise driven by the same members hiding more is a targeting problem in a segment that may be separable.
- Connect the 1.4 point concentration move to the supply-side guardrail rather than treating it as a curiosity. Pull retained reaching creators by arm and the median viewer's negative feedback on impressions from sub-threshold creators. Concentration is the plausible mechanism that pays for the engagement, and it is paid in creator churn that a four-week window barely registers.
- Read the effect by week with the burn-in excluded, not pooled. A 0.4 percent authored-interaction effect that is 1.1 percent in week 1 and 0.1 percent by week 4 is novelty decay, not a lift. State whether the ranking model was frozen for the test; if it retrained on experiment data, the arms are not independent and a pooled estimate is not interpretable either way.
- Deliver the recommendation as an exchange rate the owner can argue with: this buys roughly N additional hides per additional authored interaction at current volume. Then name the falsifier, for example the week-4 authored-interaction effect holding above 0.3 percent with flat concentration and the negative feedback rise confined to a removable segment.
Follow-up
- The owner launches anyway. What do you instrument on day one, and what is your stop rule?
- Negative feedback rate depends on how reachable the hide control is. Did the treatment change any surface affordance, and how would you know?
- If concentration rose, does the cluster randomisation still hold? Whose feeds leaked into whose?
Defend a qualified-session definition against two motivated objections
The north star is weekly members with at least one qualified session: 30 or more foreground seconds plus at least one non-negative engagement or authored item. A utility surface team argues the 30-second floor penalises fast successful visits. A video team argues requiring an explicit action undercounts passive watching. Both teams are reviewed on this metric. In fifteen minutes, defend or revise the definition, state what each proposed change does to gameability, and name the evidence that would justify a revision.
Approach
- Split the two objections, because they attack different clauses and fail differently. The utility objection is about a threshold (30 seconds); the video objection is about the qualifying condition (an explicit action). Answering both with the same argument is the common tell that the definition was never understood.
- Test each proposed change for gameability before discussing its merit. Dropping the action requirement makes the metric movable by autoplay, by longer video, and by any change that keeps an item in the viewport, which is precisely the failure the clause exists to prevent. A per-surface floor lets one team obtain a definitional lift without changing member outcomes, and makes the platform total a sum of incomparable parts.
- Answer the video objection with evidence rather than principle, and say what evidence would move you: compare week-1 retention among members whose only qualifying signal was long dwell on video_short impressions against members whose qualifying signal was an explicit action. If a fitted dwell threshold predicts return at the same rate as a like, a dwell-based qualifier is defensible, fitted per media_type and re-fitted per period rather than inherited.
- Answer the utility objection by separating the metric from the review. One definition platform-wide, with surface-level diagnostics beside it, and a review conversation that credits the utility surface on its own funnel rather than on a whole-platform north star it structurally cannot move. Forking the definition solves the review problem by destroying the metric.
- Fix the change process in advance so revisions cannot be mistaken for wins: any new definition is dual-reported beside the old one for at least four weeks, the size of the definitional jump is published, and the team proposing the change does not own the analysis that evaluates it.
Follow-up
- The utility team says they are graded on a number they cannot move. What do you actually offer them?
- What evidence would make you drop the 30-second floor entirely, rather than adjust it?
- Enforcement state changes after impressions are served. Does a session stay qualified when its only engagement was on content later removed?
- 01
Describe a situation where you disagreed with a Product Manager regarding an experiment's design. How did you resolve it?
- 02
A ranking change finished a four-week cluster-randomised test on the home feed. Impressions per engaged session rose 3.1 percent and authored interactions per weekly active member rose 0.4 percent. Negative feedback per 1,000 impressions rose 6 percent, concentrated in hide and not_interested; unfollow was flat. Creator reach concentration rose 1.4 points. The product owner has already briefed the launch upward. In ten minutes give your recommendation, the exchange rate you are applying between engagement and quality, and the specific result that would change your mind. You may request two extra cuts of the data.
- 03
The north star is weekly members with at least one qualified session: 30 or more foreground seconds plus at least one non-negative engagement or authored item. A utility surface team argues the 30-second floor penalises fast successful visits. A video team argues requiring an explicit action undercounts passive watching. Both teams are reviewed on this metric. In fifteen minutes, defend or revise the definition, state what each proposed change does to gameability, and name the evidence that would justify a revision.
Is this an official Linktree interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at Linktree. Rounds and questions reflect what candidates have reported, not a process Linktree has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How much preparation time should I dedicate?
Most successful candidates spend 2–3 weeks of focused practice. Prioritize SQL practice and reviewing your past projects through the lens of A/B testing and product metrics.
PracHub interview research ↗What is the company culture like?
Linktree is highly product-focused and fast-moving. Candidates report that the interviews favor people who are curious, collaborative, and biased toward action.
PracHub interview research ↗Is the technical interview very difficult?
It is designed to be rigorous but fair. The goal is to see how you think in real-time, especially when you are asked to pair-code or debug a query.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Data Scientist practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22