As a Data Scientist at TikTok Shop, you sit at the intersection of high-velocity e-commerce and world-class content recommendation systems. Your work directly influences how millions of users discover products, how creators monetize their content, and how merchants scale their businesses. You are responsible for transforming massive, complex datasets into actionable insights that drive product strategy and business growth.
The role is both highly technical and deeply collaborative. You will build predictive models, design rigorous A/B experiments, and develop metrics that define the success of new features. Because TikTok Shop is a fast-evolving ecosystem, you must be comfortable navigating ambiguity, translating loose business objectives into concrete analytical frameworks, and communicating findings to cross-functional stakeholders, including engineers, product managers, and business leaders.
Recruiter Screen
reportedData Scientist covers at least four different jobs: experimentation, product analytics, causal work on observational data, and applied modelling that ships into a system. A screening call is the cheapest place to find out which of them is being hired for, and doing that diagnosis openly reads as senior rather than fussy. Ask what the last few pieces of work on the team actually were, and roughly how a week splits between querying, modelling and stakeholder time. Then say which parts of that you have done and which you have not. Claiming the whole range is the fastest way to be caught one round later.
What to demonstrate
- Whether you can distinguish the flavours of the role and locate your own experience inside one of them honestly
- Whether you name what you have not done instead of stretching to cover every line of the posting
- Whether your hard constraints (notice period, location, work authorisation, level) surface now rather than at offer stage
How to prepare
- Map the last two years of your time into rough percentages across query writing, experiment design, modelling and stakeholder work, so a question about scope has a real answer
- Mark every responsibility in the posting as done, adjacent or new, and prepare one sentence for each adjacent item naming the closest thing you have actually built
- Decide which logistics are non-negotiable before the call so you can state them in one sentence rather than negotiating live
Technical Assessments
reportedBefore anything else, this round is a reading test. You are given a small schema and a question phrased in business language, and most of the difficulty sits in the gap between them. Who counts as an active user, does a refunded order still count as an order, is that date column an event time or a load time. Weak answers start typing immediately and compute something precise about the wrong population. Strong ones pin the definition in one sentence, name the column that encodes it, then write the query. On a timed assessment with nobody to tell, write the definition in a comment anyway.
What to demonstrate
- Whether an ambiguous term becomes a specific column and filter before any computation happens
- Whether you read the schema for keys and cardinality rather than only for column names
- Whether the result answers the question at the grain it was asked at, per user or per session or per day
How to prepare
- Take three metrics you already use and write down the exact filter and exact grain behind each, then practise stating one of them in a single sentence out loud
- On a schema you have never seen, spend the first minute writing what one row of each table means and which key it is unique on, then predict which joins can duplicate rows
- Rehearse a version where the definition changes halfway through, and edit the query you have instead of starting over
Product Case Study
reportedThis round runs as a working session, so part of what it decides is whether you are useful to think with. The interviewer will interrupt: a hint that the data you assumed does not exist, a challenge to your metric, a nudge toward a branch you skipped. Treating those as interference is the common failure. Reason out loud while your thinking is still provisional so there is something to react to, and when a redirect arrives, take it instead of defending the path you had already started down.
What to demonstrate
- Whether your reasoning is audible while it is still unsettled, or only after you have privately decided
- What you do with a hint: absorb it and adjust, or argue for the original route
- Whether your clarifying questions have answers that would change your approach, as opposed to filling silence
- Whether you can be wrong about something in the middle of the case and keep moving without restarting
How to prepare
- Run practice cases with a partner instructed to interrupt twice: once to remove a data source you assumed existed, once to reject the metric you chose. Practise absorbing both without going back to the start.
- Before each practice case, write down the clarifying questions you plan to ask, then check afterwards whether any answer actually changed what you did. Drop the ones that did not.
- Explain an analysis you already know well to someone outside the field and have them stop you at every point where the reasoning jumped a step.
Project Deep Dive
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.
Year-over-year and week-over-week comparisons on calendar dates
Retail demand is organised around a promotional calendar and a 4-5-4 fiscal calendar, not around the Gregorian one, so aligning on calendar date puts a peak promotional week against an ordinary week whenever the event moves, and the occasional 53-week fiscal year shifts every subsequent week by one. Moving holidays compound this across markets. Compare on fiscal week with the event aligned (week-before-event, event week, week-after), state which alignment you used, and treat any single-week comparison spanning a major event as uninterpretable without that alignment.
Reading revenue or cohort value before the return window closes
Returns arrive days to weeks after delivery and vary enormously by category, so a two-week-old cohort reported on gross revenue is being compared with a mature cohort reported on something close to net. In apparel the gap between the two definitions is routinely twenty to forty percent of gross, more than the effect size of almost any experiment or campaign being evaluated. Attribute refunds back to the parent order's placed date rather than the refund date, hold the reporting lag at the 95th-percentile return-initiation lag for the category, and never let a fresh cohort's gross number sit in the same table as a mature cohort's net number.
Ending an analysis without a recommendation or next step
Close with what you would do and what would change your mind, stated as a condition you can check later. If the evidence is genuinely inconclusive, recommend the specific next measurement and say what it costs in time or exposure.
Reading a dozen metrics with no multiplicity control
Nominate one primary metric before launch and treat the rest as guardrails or exploratory, with Bonferroni or Benjamini-Hochberg applied when you intend to make claims from them. Twenty independent tests at 0.05 under the null produce at least one false positive about 64 percent of the time.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between Cross-Entropy and MSE loss functions an…
Explain the difference between Cross-Entropy and MSE loss functions and when you would choose one over the other.
Approach
- Quantify uncertainty explicitly rather than reporting a point estimate alone.
- Sanity-check the answer against a simple bound or a simulated case.
- Write down the assumption the method needs before you use the method.
Follow-up
- What sample size would you need to detect an effect half this size?
- How would you explain this result to someone who does not know statistics?
How would you design an A/B test for a new ranking model? What metrics…
How would you design an A/B test for a new ranking model? What metrics would you track?
Approach
- Check what information would not exist at prediction time, and exclude it.
- Pick an evaluation metric that matches the cost of each error type, not a default.
- Frame the prediction: the label, the moment of prediction, and the action it triggers.
Follow-up
- What would you monitor after launch to know the model is still valid?
- How would you choose the decision threshold, and who owns that choice?
Cluster bootstrap a confidence interval for revenue per session
sessions has session_id, customer_id, arm in {control, treatment}, net_revenue_cents (zero for non-converting sessions) and converted (bool). A customer contributes several sessions and is assigned to one arm. Estimate the difference between arms in revenue per session, defined as the ratio of summed revenue to session count, and return a 95 percent interval from a bootstrap you write yourself: no scipy.stats.bootstrap, no library CI helper. Resample at the level that respects the dependence in the data, use 2000 replicates, and report the point estimate alongside the interval.
Approach
- State the estimand as a ratio of totals, not a mean of per-customer ratios. Revenue per session is sum(revenue) / count(sessions); averaging each customer's own ratio weights a one-session customer the same as a forty-session customer and estimates a different quantity.
- Collapse to one row per customer with (revenue_sum_i, session_count_i) before resampling. The bootstrap then draws customers with replacement, which is what preserves the within-customer correlation that makes session-level resampling too optimistic.
- Resample within each arm separately, with the same number of customers as that arm has, so the arm sizes are fixed by design and only the sampling variability is resampled.
- For each replicate compute sum(revenue)/sum(sessions) per arm and take the difference; note that the number of sessions per replicate varies, which is correct for a ratio estimator and not a bug to patch.
- Report the percentile interval from the 2.5th and 97.5th quantiles of the replicate differences, and cross-check the width against the Taylor linearisation for a ratio, var(R) = n / ((n-1) * (sum N_i)^2) * sum (Y_i - R * N_i)^2.
Worked solution 35 min
- Aggregate to customer level: revenue_sum, session_count, arm. Assert each customer_id appears in exactly one arm.
- Write the ratio estimator as a two-line function over a customer-level frame so the replicate loop and the point estimate call the identical code.
- Draw 2000 replicates per arm with rng.integers on positional indices, which is faster than df.sample and easier to seed reproducibly.
- Take the 2.5 and 97.5 percentiles of the 2000 differences; report the point estimate from the full data, not the bootstrap mean.
- Recompute the same interval resampling sessions instead of customers and print the ratio of the two widths as evidence for the design choice.
Follow-up
- Revenue per session is right-skewed and a single large basket moves the estimate. What capping rule would you pre-declare, and what estimand does capping change the answer to?
- How would pre-period revenue per customer be used to tighten this interval, and what is the condition for that adjustment to stay unbiased?
- Returns are still open on a third of these orders. What do you report today, and what do you refuse to report?
Given two tables (users and orders), how would you identify the top 5%…
Given two tables (users and orders), how would you identify the top 5% of users by spend using a self-join or window function?
Approach
- State the window function and its partition and ordering out loud before writing it.
- Say which table is the grain you start from, and join outward from it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
How would you handle duplicate records in a large dataset when calcula…
How would you handle duplicate records in a large dataset when calculating daily active users?
Approach
- State the window function and its partition and ordering out loud before writing it.
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- Compute rates by summing numerator and denominator separately, never by averaging rates.
Follow-up
- How would you verify this result without re-running the same query?
- What breaks if events arrive late or out of order?
Write a query to calculate the retention rate of users who made a purc…
Write a query to calculate the retention rate of users who made a purchase in the last 30 days.
Approach
- Handle the rows that do not match: a LEFT JOIN with a NULL check is usually the question.
- 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
- What breaks if events arrive late or out of order?
- How does the query change if the join becomes one-to-many?
Daily net sales on local dates without timezone boundary double counting
A weekend promotion ran from 00:00 to 23:59 local time on Saturday and Sunday. From fct_order_line (order_line_id, order_id, customer_id, placed_at_utc, placed_at_local, quantity, unit_paid_price_cents, line_discount_cents, currency_code, fx_rate_to_usd, line_status) joined to dim_customer (customer_id, billing_country_code), produce net merchandise value in USD per calendar day and billing country for the promotion week, grouped on the local date. Add a second grouping on the UTC date, and report the USD that changes day between the two. Exclude cancelled lines.
Approach
- Group on placed_at_local::date for the business-facing number, and keep placed_at_utc only for ordering and for the comparison column; picking one and stating it is the whole exercise.
- Bound the window with half-open comparisons, >= start AND < end, not BETWEEN. BETWEEN is inclusive at both ends, so BETWEEN d AND d + 1 day puts the instant of midnight into two buckets.
- Convert each line with its own fx_rate_to_usd before any SUM. Summing local cents across currencies and applying a single day rate afterwards produces a number with no unit.
- Compute net merchandise value as quantity * unit_paid_price_cents minus line_discount_cents only if unit_paid_price_cents is gross of the discount; check one row against unit_list_price_cents first rather than assuming, since double-subtracting the discount is a silent 10 to 20 percent error.
- Build the comparison by selecting both date expressions at the line grain, then aggregating twice from the same CTE and joining on order_line_id to sum the value whose assigned date differs.
- Note explicitly that a local day spanning a DST transition has 23 or 25 hours, so a day-over-day rate comparison across that date is not like for like.
Worked solution 25 min
- Verify on a handful of rows whether unit_paid_price_cents is already net of line_discount_cents.
- Build a line-grain CTE with local_date, utc_date, usd_value and billing_country_code, excluding line_status IN ('cancelled_by_customer','cancelled_out_of_stock').
- Aggregate by (local_date, billing_country_code) and separately by (utc_date, billing_country_code).
- Sum usd_value over lines where local_date <> utc_date and report it per country.
- Sanity check the promotion days against the adjacent Friday and Monday under both groupings.
Follow-up
- The promotion ran in six markets at local midnight each. What does a single UTC-bounded filter do to the reported lift per market?
- How would you compare this weekend against the same promotional weekend last year, given the date moves?
- placed_at_local is stored without an offset. What breaks, and what would you add to the table?
How would you measure whether the AI-generated answers in the TikTok a…
How would you measure whether the AI-generated answers in the TikTok app are actually useful to the user?
Approach
- State what result would change your recommendation, so the answer is falsifiable.
- Name one primary metric, then the guardrail that stops it being gamed.
- 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?
- What would you do if the primary metric and the guardrail moved in opposite directions?
If you notice a sudden drop in conversion rate, how would you investig…
If you notice a sudden drop in conversion rate, how would you investigate the root cause?
Approach
- Decompose the metric into the rates that drive it, and say which one you would check first.
- State what result would change your recommendation, so the answer is falsifiable.
- Fix the population and the time window before naming any metric.
Follow-up
- How would you detect that the metric is being gamed rather than genuinely improving?
- What would you do if the primary metric and the guardrail moved in opposite directions?
You are given a product like TikTok Shop; what guardrails would you pu…
You are given a product like TikTok Shop; what guardrails would you put in place, and what is your "target of interest" for optimization?
Approach
- Fix the population and the time window before naming any metric.
- 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.
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?
How do you determine the required sample size for an experiment, and w…
How do you determine the required sample size for an experiment, and what do you do if the results are not statistically significant?
Approach
- Name the randomisation unit first; it decides the variance and what the test can detect.
- State the primary metric and the minimum effect worth shipping, then size the test.
- Name the guardrails that would stop a launch even on a positive primary result.
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?
Estimate a loyalty tier effect at a published spend cutoff
Accounts crossing $500 in trailing-twelve-month net spend are upgraded to dim_customer.loyalty_tier = 'gold', which grants free returns. Leadership wants the causal effect of gold on the 90-day repeat rate and on the net unit return rate from fct_return_line. The threshold is published on the site. No randomised grant exists, but the tier is recomputed monthly for every account and a small number of upgrades are granted manually by support. Specify the design, the estimation choices, every assumption you must test, and what the estimate does and does not license leadership to conclude.
Approach
- Propose regression discontinuity on trailing-twelve-month net spend at the monthly recompute, comparing accounts just above and just below $500, and state the identifying assumption: potential outcomes are continuous in the running variable at the cutoff, so accounts at $498 are a valid counterfactual for accounts at $502.
- Attack your own design before the interviewer does. The threshold is published, so customers can top up to reach it, and that is precise manipulation of the running variable, which breaks identification. Test it with a density discontinuity test (McCrary, or the Cattaneo-Jansson-Ma local polynomial version) and expect a mass point just above $500. If manipulation is present, say so and offer the alternatives with their costs: a donut RDD that drops a window around the cutoff and extrapolates in, which trades bias for a stronger functional-form assumption, or estimating on the pre-publication period when the threshold was not visible.
- Get the estimation details right. Use local linear regression with a triangular kernel and an MSE-optimal bandwidth with robust bias-corrected confidence intervals, and refuse high-order global polynomials, which put extreme weight on observations far from the cutoff and generate spurious discontinuities.
- Handle the manual grants by moving from sharp to fuzzy. Crossing $500 becomes an instrument for actually holding gold: estimate by two-stage least squares, report the first-stage jump in gold probability at the cutoff, and flag a weak-instrument problem if compliance is low. The estimand becomes a local average treatment effect on compliers at the cutoff.
- Run the standard battery and read the return outcome carefully. Check covariate continuity at the cutoff (acquisition_channel mix, tenure, category mix), run placebo cutoffs at $400 and $600, and use outcomes measured before the upgrade as placebo outcomes. Note that free returns raising the return rate is a real causal effect rather than a bias, so the decision-relevant outcome is contribution margin net of return shipping and recovered value, matured for the 90-day return window.
Worked solution 45 min
- Build the running variable as trailing-twelve-month net spend at each monthly recompute date, net of refunds attributed to the parent order, and centre it at $500.
- Run the density discontinuity test at the cutoff; report the estimate and its interval before any outcome regression.
- Estimate the first stage: the jump in P(loyalty_tier = 'gold') at the cutoff, using local linear regression with a triangular kernel and an MSE-optimal bandwidth. If the jump is below 1, proceed fuzzy by 2SLS.
- Estimate the reduced form for the 90-day repeat rate and the net unit return rate on the same bandwidth, with robust bias-corrected intervals, and divide by the first stage for the LATE.
- Run the checks: covariate continuity at the cutoff, placebo cutoffs at $400 and $600, placebo outcomes measured before the recompute date, and sensitivity of the point estimate to halving and doubling the bandwidth.
- Convert the two outcomes into one decision number: contribution margin per delivered order over the following 90 days, matured past the return window.
Follow-up
- Your density test shows a clear spike just above $500. What is the strongest causal statement you can still make, and what would you need to make a stronger one?
- Leadership reads the estimate and proposes lowering the threshold to $300. What is wrong with that inference?
- How would you decide the bandwidth, and what does the estimate do if you halve it?
Return rate spike dated on the wrong event
Net unit return rate for the last four delivery weeks reads six points above the trailing-year average. The dashboard's numerator sums quantity_returned from fct_return_line by received_at_utc week; its denominator sums quantity from fct_order_line by delivered_at_utc week. fct_return_line also carries initiated_at_utc, refunded_at_utc, return_reason, disposition and order_line_id; dim_sku carries supplier_id, style_id, size_code and category_l2. Deliverable: state whether a quality regression occurred, quantify how much of the spike is an artefact, and name the reason class and SKU attribute carrying anything that survives.
Approach
- Re-anchor both sides on the same event before anything else: tie each return line to its parent order line and cohort the numerator on that line's delivered_at_utc week. A numerator dated on receipt against a denominator dated on delivery is two different populations and the ratio is not a rate.
- Separate the two lags. Plot initiated_at_utc minus delivered_at_utc (customer behaviour) and received_at_utc minus initiated_at_utc (warehouse throughput) by week. A processing backlog clearing moves only the second; a genuine behaviour change moves the first.
- Handle maturity honestly. Correctly anchored, recent delivery weeks are incomplete and will read low, not high. Either suppress weeks younger than the 95th-percentile initiation lag, or apply completion factors from the historical lag curve and state the stationarity assumption you are making about that curve.
- Check the denominator for mix. Return rates differ by an order of magnitude across category_l2, so a delivery-volume shift toward a high-return category raises the blended rate with no behaviour change anywhere. Run the same within-versus-mix split used for any other blended rate.
- Only on the residual, split by return_reason class (defect and damage, fit and description, remorse) and then by supplier_id, style_id and size_code. A real regression concentrates; a definitional artefact is spread flat across the catalogue.
Follow-up
- How would you publish this metric so an immature delivery week cannot be misread as an improvement?
- One order line generated two return lines because the customer returned part of the quantity twice. What does that do to your numerator and to a naive count of RMAs?
- Your completion factors are fitted on last year. What would make you refuse to apply them this quarter?
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 ↗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.
Most of the questions in this section reduce to one thing: can you be handed a vague request and come back with something useful? Prepare an example where the ask was underspecified, you chose an interpretation, and you said out loud which interpretation you chose. Describing how you narrowed the question matters more than the technique you eventually used.
Tell me about a time you had to explain a complex technical result to …
Tell me about a time you had to explain a complex technical result to a non-technical stakeholder.
Approach
- State the situation in two sentences and spend the rest on your reasoning.
- Pick a story where you drove the decision, not one where you observed it.
- 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?
Choose between three teams asking for the same week
Three requests land on the same Monday. Merchandising wants a size-curve read before a buy deadline on Thursday. Growth wants a channel attribution rebuild that has been requested twice and dropped twice. Supply chain wants a stockout root-cause on a category that cancelled four thousand units last month. You have one week and no help, and each requester believes theirs is first. State what you do, in what order, and what you tell the two people who do not get the week.
Approach
- Sort by the decision behind each request rather than by who sent it. A buy deadline is an irreversible commitment with a fixed date; an attribution rebuild changes no decision this week.
- Ask each requester two questions: which decision changes, and what happens if the answer lands a week later. Those two separate a real deadline from felt urgency without arguing about either.
- Look for the cheap partial before assuming any request consumes the week. If the size curve already exists at style grain, the merchandising read may be two hours rather than four days.
- Decline explicitly with a start date attached instead of leaving a request in a silent queue. Growth has been dropped twice, so a third silent drop is a relationship cost you are choosing to pay; name it rather than incur it by default.
- Escalate the collision upward once, with the three decisions and their dates side by side, so the tradeoff is resolved where it is owned rather than by whoever follows up hardest.
Follow-up
- Growth escalates to your manager saying analytics never supports them. What did you do before that happened, and what do you do now?
- The buy deadline moves to Tuesday. What do you cut from the size-curve read, and what do you refuse to cut?
Tell a team their test cannot be read before Friday
A checkout test has run eleven days. Conversion is 2.4 percent in control and 2.7 percent in treatment, and the team wants to ship on Friday. Revenue per visitor is higher in treatment, driven by a small number of very large baskets, and the return window on those orders has not closed. The engineering lead has already announced the win internally. You are asked for sign-off. Give your answer, the evidence behind it, and a path that lets them ship without pretending the result is something it is not.
Approach
- Compute rather than assert. State the minimum detectable effect the observed sample supports at a 2.4 percent baseline, then say whether a 0.3 point absolute lift sits inside or outside it. An objection without that number reads as caution and loses to a launch date.
- Separate the two problems, because they have different fixes. Conversion may simply be underpowered. Revenue per visitor is a different failure: the mean is driven by the tail, so it needs a cap declared before the data was seen or a bootstrapped interval, and a cap chosen now is not a cap.
- Run the mechanical checks first because they are cheap and they end arguments: sample ratio mismatch, the triggered-population definition, and whether both arms drew on the same constrained inventory.
- Quantify the return exposure concretely: the share of treatment revenue sitting in orders whose return window is open, and what the category's matured net unit return rate would do to the lift if applied to it.
- Offer a path rather than a veto. If the change is reversible and the downside is bounded, ship it, with the read scheduled at return maturity and the decision rule written down now, before anyone knows which way it goes.
- Handle the premature announcement quietly and separately. It is a fact to correct, not a position to negotiate against, and making it the topic guarantees the measurement argument is lost.
Follow-up
- The team says the large baskets are real revenue and capping throws away the win. What is your answer?
- What decision rule would you write down today so this same conversation does not happen on the next test?
- 01
Tell me about a time you had to explain a complex technical result to a non-technical stakeholder.
- 02
Three requests land on the same Monday. Merchandising wants a size-curve read before a buy deadline on Thursday. Growth wants a channel attribution rebuild that has been requested twice and dropped twice. Supply chain wants a stockout root-cause on a category that cancelled four thousand units last month. You have one week and no help, and each requester believes theirs is first. State what you do, in what order, and what you tell the two people who do not get the week.
- 03
A checkout test has run eleven days. Conversion is 2.4 percent in control and 2.7 percent in treatment, and the team wants to ship on Friday. Revenue per visitor is higher in treatment, driven by a small number of very large baskets, and the return window on those orders has not closed. The engineering lead has already announced the win internally. You are asked for sign-off. Give your answer, the evidence behind it, and a path that lets them ship without pretending the result is something it is not.
Is this an official TikTok Shop interview guide?
No. It is PracHub's own research and practice material for the Data Scientist role at TikTok Shop. Rounds and questions reflect what candidates have reported, not a process TikTok Shop has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long does the entire process usually take?
The process typically moves quickly, often ranging from 3 to 6 weeks. Candidates should be prepared for a fast turnaround between rounds.
PracHub interview research ↗Are the interviews conducted in English?
While English is the primary language for most US-based roles, the global nature of TikTok means you may occasionally interact with international colleagues. Some regions, such as Singapore, have reported interviews in Mandarin.
PracHub interview research ↗How much should I focus on LeetCode-style coding?
While standard algorithmic coding is part of the process, the focus is heavily weighted toward practical, real-world SQL and domain-specific ML questions. Ensure your SQL skills are sharp before focusing on general algorithms.
PracHub interview research ↗What is the most important thing to demonstrate in the case study?
The most important thing is a structured approach. Start by clarifying the objective, identify the key metrics, propose a methodology, and always discuss potential pitfalls or biases.
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
Explore related engineering environments and compare the preparation focus.
Zulily Data Scientist Interview Questions & Guide 2026
Causal-inference exercises for Zulily data scientist prep: difference-in-differences, matching, instrumental variables, and knowing when observational data simply cannot answer the question asked.
Zalando Data Scientist Interview Questions & Guide 2026
Statistics practice aimed at Zalando candidates: conditional probability, sampling distributions, confidence intervals people routinely misread, and saying out loud which assumption a test depends on.
US Foods Data Scientist Interview Questions & Guide 2026
Prepare for the data scientist interview at US Foods with original practice on experiment design, SQL, and metric reasoning, each exercise paired with a worked solution and the reasoning behind it.
Wayfair Data Scientist Interview Questions & Guide 2026
Case practice for the Wayfair data scientist interview, where the prompt is deliberately underspecified and your first move is scoping it into something measurable.