HackTheRounds Interview Experiences

Apple Data Scientist Interview Experience (2026) - SQL Window Functions, Sparse Matrix Multiply, Apple News LTV, Offer

Apple DS loop: stats and project round (paired t test, CI sample size), technical round with SQL device overlap, sparse matrix multiply in Python, and Apple New

By Anonymous ยท 2026-03-26

Background

Apple opened a batch of Data Scientist seats early this cycle on the Services org, and I jumped on one of the postings the week it went live. I am a new grad with a master's in statistics and two DS internships under my belt, one at a mid-size consumer tech company and one at a health startup. The loop was only two rounds but each one was dense, and it covered more ground per minute than anything else I interviewed for.

Timeline

Total: about 5 weeks.

Round 1: Statistics and Project Deep Dive (60 min)

No coding this round. The interviewer spent the first twenty minutes on my resume, picking one of my internship projects at random and drilling into the methods. Why did I pick that model over alternatives. How did I clean the data. What would I do differently if I had to redo it today. The pattern was clear: they are checking whether I actually understood the work or just pasted bullet points.

Then statistics. First question: if I want to shrink a confidence interval to one-tenth of its current width, by what factor must the sample size grow. Standard error scales with the inverse square root of N, so to cut the interval by 10x you need 100x the samples. Second question: I have test scores from the same set of students before and after an intervention, which hypothesis test do I use and what is H0. Paired t-test because the same students appear in both samples, and the null is that the mean of the paired differences equals zero.

Last part was a product question about search. How would I evaluate a new search feature that surfaces more recent results. I walked through CTR, repeat-search rate, time-to-click, and conversion to a downstream action, and emphasized that the counter-metric is increased repeat searching (a bad sign that users could not find what they wanted on the first pass).

Round 2: Technical (60 min)

Shared code editor, three parts back to back, narrated out loud the whole time.

Part A: SQL

Problem: Given a users table with device type (iPhone, iPad, or both) and a sessions log, compute the share of overall unique users who use only iPhone, only iPad, or both.

I wrote a CTE that pulled distinct users per device, then joined on user id to classify each into the three buckets, then divided by the total count of distinct users. The gotcha was the denominator: first instinct is to sum the three buckets, but you actually want COUNT(DISTINCT user id) over the whole users table. Interviewer nodded when I flagged that.

Second SQL problem was the classic "highest earner per department" using ROW NUMBER() OVER(PARTITION BY department ORDER BY salary DESC) and filtering to rank = 1. They asked the tradeoff between ROW NUMBER, RANK, and DENSE RANK when there are ties. I gave the three-sentence answer and we moved on.

Part B: Python Coding

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

Straightforward triple loop. The follow-up was the interesting part: what if the matrices are sparse. I described a dictionary-of-keys representation where you only store non-zero entries and multiply by iterating only the non-zero intersections. That changes complexity from O(m n p) to O(nnz A nnz B / n) in the average sparse case.

[[problem/603?company=4|Sparse Vector Operations]] is the natural follow-up practice problem and the design patterns around sparse structures map directly.

Problem 2: Reverse the word order in a sentence while collapsing runs of whitespace to single spaces.

I used ' '.join(reversed(sentence.strip().split())) which handles both collapsing and reversal in a single line. The interviewer asked for the in-place version without using the split helper, and I walked through the two-pointer approach that reverses the whole string first then re-reverses each word. That one takes a few more minutes to get right.

Part C: Business Case and Modeling

Problem: Apple News ran a free-trial campaign. How do you evaluate its success and how would you predict which trial users will convert to paid.

On evaluation, I pushed past the obvious metrics (trial-to-paid conversion rate) to long-term metrics: 90-day retention, DAU over the lifetime, average revenue per user, and LTV compared against customer acquisition cost. Short-term conversion is easy to spike with a promotion but says little about whether the feature works.

On the model, I proposed logistic regression as a baseline because it is interpretable and fast, then a gradient-boosted tree ensemble (LightGBM or XGBoost) as the production model. Features: reading frequency, session length, content category preferences, trial-day behavior deltas, and demographic signals where available. I explicitly brought up label leakage as a risk because anything measured after the conversion decision cannot be used.

Brushing up on the logistic regression math before the loop paid off here. [[problem/245?company=4|Logistic Regression Loss Function]] is a useful drill for the derivation in case the interviewer asks you to write the gradient on the spot.

Result

Offer came about a week after the second round. Apple moves slower on comp negotiation than the FAANGs, but the numbers were in the range I wanted. I accepted.

Tips

  1. Apple DS rounds are breadth, not depth. You will not get a single hard algorithm problem. You will get five medium-ish things across stats, SQL, Python, and product, and every one of them has to be correct.
  2. Know the paired-versus-unpaired test distinction cold. Both the 2024 and 2025 Apple DS loops I heard about had at least one hypothesis-testing question that hinged on this.
  3. Practice sparse-data follow-ups. Apple runs on enormous usage datasets and most of it is sparse by default. Expect the sparse question as the natural extension of anything dense.
  4. The product round cares about counter-metrics. Anyone can list the success metrics. The signal Apple is looking for is whether you can articulate how the experiment could fail and what would reveal that failure.
  5. Do not ignore model interpretability. Apple's user-facing data products often have privacy and explainability constraints. When pitching a model, explicitly acknowledge the interpretability tradeoff between linear models and ensembles.
  6. Be ready to defend every bullet on your resume. Round 1 spent twenty minutes on a single internship project. If you cannot narrate the decisions, that is a red flag.

Happy to share more detail if anyone is prepping.