← TikTok Interview Insights

TikTok·Data Scientist·Technical Phone Screen·Intermediate

Intermediate
Jun 2026

Summary

SQL-heavy technical screen for a Data Scientist role at TikTok. The main problem was about aggregating buggy vs non-buggy submission counts per employer using conditional aggregation, with a few follow-up angles thrown in.

Questions Asked (3)

Q1

Write a SQL query that counts buggy and non-buggy submissions for each employer, including employers with zero submissions, ordered by employer_id. Use conditional aggregation in a single query.

Data ModelingTechnical Trade-offs
Author's notes

The LEFT JOIN part I got right away, that's pretty standard.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by identifying the tables and columns: submissions (with employer_id and buggy flag) and employers (with employer_id). Use a LEFT JOIN from employers to submissions to include employers with zero submissions, then apply conditional aggregation with SUM(CASE WHEN buggy = 1 THEN 1 ELSE 0 END) and SUM(CASE WHEN buggy = 0 THEN 1 ELSE 0 END) to count buggy and non-buggy submissions. Group by employer_id and order by employer_id.

Pro tip: Mention that using COUNT(CASE WHEN buggy = 1 THEN 1 END) is more efficient than SUM(CASE WHEN buggy = 1 THEN 1 ELSE 0 END) because it avoids unnecessary additions and handles NULLs automatically. Also, clarify that the buggy flag might be stored as a boolean or integer, so adjust the condition accordingly.

1. Identify tables and columns

Determine the relevant tables (e.g., employers and submissions) and columns (employer_id, buggy flag). Assume a buggy flag column that indicates whether a submission is buggy (e.g., 1 for buggy, 0 for non-buggy).

2. Choose the join type

Use a LEFT JOIN from employers to submissions to ensure all employers are included, even those with no submissions. This is crucial for including employers with zero submissions.

3. Apply conditional aggregation

Use SUM(CASE WHEN buggy = 1 THEN 1 ELSE 0 END) for buggy count and SUM(CASE WHEN buggy = 0 THEN 1 ELSE 0 END) for non-buggy count. Alternatively, use COUNT(CASE WHEN buggy = 1 THEN 1 END) for conciseness.

4. Group and order

Group by employer_id to aggregate per employer, and order by employer_id as requested. Ensure that the grouping includes all employers from the LEFT JOIN.

5. Handle edge cases

Consider if buggy flag can be NULL; if so, decide how to treat NULLs (e.g., as non-buggy or exclude). Also, verify that the query returns 0 for employers with no submissions.

Key Points to Mention

  • LEFT JOIN to include employers with zero submissions
  • Conditional aggregation using CASE WHEN inside SUM or COUNT
  • Grouping by employer_id and ordering by employer_id
  • Handling NULLs in the buggy flag appropriately
  • Efficiency of COUNT(CASE WHEN ... THEN 1 END) over SUM(CASE WHEN ... THEN 1 ELSE 0 END)
  • Assumption about the buggy flag data type (boolean vs integer)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you adapt the query if the submission status column were a string like 'buggy' or 'non_buggy' instead of a boolean?

Data ModelingTechnical Trade-offs
Author's notes

Pretty quick swap, just change the condition to status = 'buggy' inside the CASE.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Acknowledge the change from boolean to string and explain that the query logic must now compare against string literals instead of true/false. Then discuss how to adapt the query while maintaining correctness and performance, and mention any trade-offs such as index usage or case sensitivity.

Pro tip: Mention that string comparisons can be slower than boolean checks, so consider normalizing the column or using an enum type if the dataset is large. Also, be prepared to discuss how this change might affect downstream aggregations or filters.

1. Identify the change

Recognize that the column now contains string values like 'buggy' or 'non_buggy' instead of boolean true/false.

2. Adjust the query condition

Replace boolean expressions (e.g., WHERE is_buggy = TRUE) with string comparisons (e.g., WHERE status = 'buggy').

3. Consider performance implications

Discuss how string comparisons may impact query performance, especially if the column is not indexed or if case sensitivity matters.

4. Handle potential edge cases

Address issues like inconsistent casing, trailing spaces, or unexpected values, and suggest normalization or validation.

5. Evaluate trade-offs

Weigh the pros and cons of keeping the string representation versus converting to a boolean or enum, considering storage, readability, and query efficiency.

Key Points to Mention

  • String comparison syntax (e.g., = 'buggy') vs. boolean logic
  • Index usage and performance impact of string columns
  • Case sensitivity and collation settings
  • Data normalization and consistency (e.g., trimming, lowercasing)
  • Potential need for schema changes or ETL adjustments
  • Impact on downstream queries and aggregations

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

If a new employer is added with no submissions at all, does your query still return a row for them with zero counts?

Data Modeling
Author's notes

Yes, that's exactly what the LEFT JOIN from employers to submissions is for.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify that the answer depends on the join type used in the query. If the query uses a LEFT JOIN from the employers table to the submissions table, then a new employer with no submissions will still appear with zero counts. If it uses an INNER JOIN, the employer will be excluded. Then explain how to ensure zero counts are returned, such as using COALESCE or IFNULL on the aggregated count.

Pro tip: Mention that you would verify the query's behavior with a test case and consider using a LEFT JOIN with COALESCE to handle NULLs, which shows attention to data completeness and edge cases.

1. Identify the join type

Determine whether the query uses an INNER JOIN or LEFT JOIN between the employers and submissions tables. This is the key factor that determines if employers with no submissions are included.

2. Explain the impact of join type

If it's an INNER JOIN, the employer will not appear. If it's a LEFT JOIN, the employer will appear but the count will be NULL unless handled.

3. Describe how to handle NULL counts

Use COALESCE(COUNT(submissions.id), 0) or IFNULL to convert NULL counts to zero. This ensures the output shows 0 instead of NULL.

4. Confirm with a test case

Suggest creating a quick test by inserting a new employer with no submissions and running the query to verify the result.

Key Points to Mention

  • LEFT JOIN vs INNER JOIN behavior
  • COALESCE or IFNULL to handle NULL counts
  • Aggregation with COUNT and grouping by employer
  • Importance of data completeness in reporting
  • Testing edge cases with sample data
  • Potential need for a RIGHT JOIN or FULL OUTER JOIN depending on the query structure

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.