HackTheRounds Interview Experiences

TikTok Data Science Intern Interview Experience (2026) - SQL, Experimentation, Offer

Two TikTok data science internship rounds covering product metrics, Spark, SQL, statistics, A/B testing, and creator engagement analysis.

By HackTheRounds Team · 2026-05-01

Background

I applied for a TikTok data science internship on March 14, 2026 and received an interview invitation two days later. The first interview took place on March 21, the second was in mid-April, and I received an offer in May.

Both interviews were conducted by video in English. The process was less focused on algorithm puzzles than on whether I could connect analytics, experimentation, SQL, and data engineering choices to product decisions.

Round 1: Project Deep Dive, Metrics, and SQL

The first round began with a project involving a dashboard and text classification. The interviewer asked how I selected metrics such as daily active users, engagement, and conversion, then moved into precision, recall, and F1. The important follow-up was not the formula. It was how the cost of false positives and false negatives changes the metric that should guide the model.

I explained that an imbalanced classification problem can make accuracy misleading. If a false negative hides a high-risk event, recall may matter more. If false positives trigger an expensive review, precision becomes important. F1 provides a compact balance, but the final threshold should be selected from product cost and capacity rather than a generic score.

The data-engineering discussion covered ETL, duplicate records, and skew. For joining a very small reference table to a large event table in Spark, I proposed a broadcast join to avoid a large shuffle. If exact distinct counting became too expensive at scale, I would consider HyperLogLog and clearly communicate that its answer is approximate. Date partitioning would reduce scans for time-bounded analysis, although too many tiny partitions can create its own operational cost.

The SQL task asked for daily active users and average online time. I used common table expressions to make the stages explicit, joined the relevant user and session data, grouped by date, and used distinct user counts for DAU. Average online time required careful treatment of sessions that crossed a day boundary. I clarified whether a session should be attributed to its start date or split across calendar dates, because the two definitions produce different business metrics.

Round 2: Statistics, Experimentation, and Product Analysis

The second round returned to resume details, including preprocessing choices, then tested bias and variance. I described high bias as systematic underfitting and high variance as sensitivity to the training sample. The useful answer connected diagnosis to evidence such as training-versus-validation performance and then to interventions such as feature changes, regularization, model capacity, or additional representative data.

The main case was how to evaluate a product launch. I structured the response around the decision:

  1. Define the user problem and a falsifiable hypothesis.
  2. Select a primary metric, guardrail metrics, and the minimum meaningful effect.
  3. Choose randomization unit and eligibility rules while checking for interference.
  4. Estimate sample size before launch.
  5. Run an A/B test with a staged rollout and monitor data quality.
  6. Interpret confidence intervals alongside practical impact.
  7. Roll back if guardrails deteriorate, then investigate heterogeneous effects.

The scenario used half of eligible traffic for roughly two weeks, but I emphasized that traffic share and duration should follow power, seasonality, novelty effects, and operational risk. A calendar duration alone does not guarantee a useful experiment.

The SQL question asked for users who registered and posted on the same day. I joined registrations to posts on user ID, compared normalized dates, and counted distinct users so multiple posts did not inflate the result. I also mentioned time zones: “same day” must be defined consistently before truncating timestamps.

The final product case asked how to increase creator engagement. I divided creators by lifecycle stage, identified friction in onboarding and recommendation, and proposed measuring time to first post, creation frequency, and retained creator activity. A short-term rise in uploads would not be sufficient if creator retention or viewer-quality guardrails fell.

Analytical Checks I Would Add

Before trusting the experiment, I would verify sample-ratio balance, metric logging, pre-experiment similarity, and whether one user can appear in both variants through multiple devices. I would inspect novelty and day-of-week patterns rather than reading the final aggregate alone. For the creator case, I would separate new, occasional, and established creators because the same intervention can help one group and hurt another. I would also guard against optimizing raw post count with low-quality uploads by tracking viewer satisfaction, policy violations, and downstream retention.

Result

I received the internship offer in May 2026. The strongest preparation was practicing complete analytical decisions rather than isolated SQL syntax or statistics definitions.

Preparation Takeaways

  1. Tie classification metrics to the real cost of each error type.
  2. Review joins, partitioning, skew, deduplication, and approximate distinct counting.
  3. Clarify time-zone and session-boundary rules before calculating product metrics.
  4. Structure experiments from hypothesis through rollout and rollback.
  5. Use `COUNT(DISTINCT ...)` deliberately when joins can multiply rows.
  6. Segment marketplace participants by lifecycle and protect both sides with guardrails.
  7. Practice explaining what business decision an analysis will change.