Apple Data Scientist Interview Experience (2026) - Two-Round Stats, SQL, Python, Business Case, Offer

First, if I want to shrink the width of a 95 percent confidence interval to one-tenth of what it currently is, by what factor do I need to grow the sample size. The standard error scales with one over the square root of n , so to cut the width by a factor of ten, n has to grow by a factor of one hundred. This one is a reflex test.

Second, I have before-and-after test scores for a group of students, and I want to know whether a tutoring intervention had an effect. What test do I run and what is the null hypothesis. Paired t-test, because the same students appear on both sides of the comparison, and the null is that the mean of the per-student differences equals zero. If you use an unpaired t-test on this data, you lose power because you are throwing away the pairing structure.

Third, a product question. Apple Music is considering a new "favorites" feature that lets users flag songs they like. How would I evaluate whether this feature is working. My answer walked through a hierarchy: primary success metric (feature engagement rate), secondary metrics (session length, skip rate, return rate in the next 7 days), and counter-metrics (does flagging a song reduce exploration of new music, which would be bad for long-term retention). I emphasized that counter-metrics are the hard part; anyone can list success metrics.

Round 2: Technical (60 min)

Shared code editor, narrated out loud the whole way. Three parts.

Part A: SQL

Problem: Given a users table with a device type column (iPhone, iPad, or both) and a sessions table keyed by user, compute the share of unique users who use only iPhone, only iPad, or both devices.

I wrote a CTE that aggregated device usage per user (grouping by user, then taking an array or a bitmask of distinct device types), then categorized each user into one of the three buckets, then divided by the total count of distinct users.

The trap is the denominator. First instinct is "sum the three buckets and divide each by that sum." But the buckets partition the user base already; you want the denominator to be the total count of distinct users across the whole table, which may not equal the sum of the buckets if some users have no sessions and do not appear in any bucket. Flag this out loud.

Second SQL question: highest earner per department. Classic window function. ROW NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) , filter to rank 1. The follow-up was the difference between ROW NUMBER , RANK , and DENSE RANK in the presence of ties. ROW NUMBER never ties, RANK leaves gaps after ties, DENSE RANK does not. I gave the one-line summary and we moved on.

Part B: Python Coding

Problem 1: Multiply two matrices represented as 2D Python lists. Return the product, or the empty list if the shapes are incompatible.

Triple nested loop. Check len(B) == len(A[0]) first; if not, return [] . The interviewer's follow-up was about sparse matrices: if the input matrices are mostly zeros, how do I improve the time complexity. I described a dictionary-of-keys representation that stores only non-zero entries and walks the intersection of non-zero rows and columns. Average-case complexity drops roughly to O(nnz A avg nnz per row of B), which can be orders of magnitude faster than O(m n p) on sparse data.

Practice it: [[problem/603?company=4|Sparse Vector Operations]]

Problem 2: Reverse the word order in a sentence while collapsing any run of whitespace to a single space.

One-liner in Python: " ".join(reversed(s.strip().split())) . The interviewer asked for the in-place version without using split . The two-pass approach is: reverse the whole string in place, then walk through and reverse each word in place, collapsing adjacent spaces as you go. This takes about seven or eight minutes to get right and is the real test here; the one-liner is just a warmup.

Part C: Business Case and Modeling

Problem: Apple News ran a free-trial promotion. How do I evaluate the campaign, and how do I model the conversion of trial users to paid subscribers.

On evaluation, I explicitly pushed past the obvious surface metric (trial-to-paid conversion rate). Short-term conversion is easy to spike with a strong promotion and says little about whether the feature actually retains users. I talked about 90-day retention, average revenue per user over the 12-month horizon, and LTV versus CAC. I also called out a potential counter-metric: if the trial spiked paid conversions but the paid cohort churned within 60 days, the campaign hurt long-term revenue.

On modeling, I proposed logistic regression as a baseline for interpretability and a gradient-boosted tree ensemble (XGBoost or LightGBM) as the production model for performance. Features: reading frequency, session length, content category preferences, early-trial behavior deltas (day-1 vs day-7 behavior change), and demographic where consented. I flagged label leakage as a risk and explicitly excluded any post-decision features from training.

The interviewer asked me to walk through the gradient of the logistic regression loss. I wrote out the log-likelihood and took derivatives. This was a reflex test and I passed because I had brushed up on the math the week before. If you have not derived this in a while, drill it once before the loop.

Result

Offer came five business days after round 2. Senior DS, Apple Services, with a comp package that was higher on base than my then-current offer but lower on sign-on. I negotiated the sign-on up by about 15 percent and accepted.

Tips

1. Rehearse one project at project-deep-dive depth. Twenty minutes is a lot of time to spend on one bullet. If you cannot defend your method selection, your confounder handling, and the decisions you would reverse today, pick a different project. Apple's round one filter is almost entirely about this.
2. The paired t-test question is a gate. If you get the pairing logic wrong, you are almost certainly out of the loop regardless of how well you did on the product case. Know the three canonical hypothesis tests (one-sample t, independent t, paired t) and which to use in which scenario.
3. For Apple's product questions, always propose a counter-metric. Engagement rate, conversion rate, DAU: these are table stakes. The signal Apple is looking for is whether you can name a metric whose improvement would actually indicate the experiment failed.
4. The in-place reversal problem is the real Python test, not matrix multiplication. Matrix multiplication is a warmup. If you solve it in 90 seconds, you signal that you are not going to struggle with the next problem. Do not spend 15 minutes on it.
5. Derive the logistic regression gradient before the loop. I was asked for it. Two of my friends who interviewed for Apple DS roles in the last six months were also asked for it. Practice writing out the log-likelihood and taking the derivative on paper in under two minutes.
6. Negotiate the sign-on, not the base. Apple is inflexible on base relative to the level band but has historically accepted reasonable sign-on bumps for senior candidates who can justify them with a competing offer or a lost bonus. My recruiter said this out loud to me; it was not secret.

Happy to share more detail with anyone prepping for an Apple DS loop. The interview is short but honest.