HackTheRounds Interview Experiences

Apple Software Engineer Interview Experience (2026) - Sorted Squares, Steps Tracker, HealthKit Sync Design, Offer

Apple iOS SWE loop: two pointer sorted squares phone screen, daily steps tracker, HealthKit multi device sync system design, Apple values behavioral, offer.

By Anonymous · 2026-03-23

Background

Apple's recruiting team reached out cold based on a GitHub project I had open-sourced that did efficient time-series aggregation on low-power devices. The role was a mid-level iOS platform SWE position on one of the Health-adjacent teams. I had been at a health-tech startup for three years before this and had written a lot of Swift and C++ for on-device signal processing, so the domain match was strong. The loop was four rounds, three of them technical and one a values round.

Timeline

Inbound recruiter email: late February
Recruiter screen: 1 week after reply
Phone screen with team engineer: 10 days after recruiter
Virtual onsite (3 rounds): 2 weeks after phone screen
Offer: 4 business days after onsite

Total: about 6 weeks.

Phone Screen (60 min)

One algorithm problem, no system design, no project questions.

Problem: Given a sorted array of integers (including negatives), return a new array containing the squares of the input in non-decreasing order.

My first answer was the obvious one: square every element, then sort. O(n log n) time. Correct but wasteful; the interviewer almost immediately asked for a linear-time solution.

The cleaner approach takes advantage of the input being sorted. Place two pointers at the ends of the array. Compare the absolute values at the two pointers. Whichever has the larger absolute value has the larger square; write that square to the end of the output and advance that pointer inward. Repeat until the pointers cross.

O(n) time, O(n) space. Writing from the end of the output array backwards is the key trick; writing from the front forces you to do extra comparisons.

Practice it: [[problem/579?company=4|Dedupe Array In-Place]]

Onsite Round 1: Coding (60 min)

Problem: Design a component that tracks a user's daily step counts and supports three queries: record(timestamp, steps) to append a new reading, totalSteps(from, to) to return the total steps in a time range, and averageStepsPerDay(from, to) to return the daily average. Assume readings come in in roughly chronological order but may arrive slightly out of order due to cross-device sync.

My data structure was a dict keyed by day (truncated timestamp to midnight) mapping to the day's step count. Recording a reading adds its step count to the corresponding day bucket. Range queries walk the days in the range and sum.

The follow-up was about scale: what if we have ten years of data and want the range queries to be fast for long ranges. I described a Fenwick tree (Binary Indexed Tree) indexed by day ordinal, which gives O(log D) range sums and point updates, where D is the number of days in the history. The interviewer nodded and asked about memory: for ten years of steps per user across a billion users, how do you keep the working set small? My answer: store the tree on disk, keep a small LRU cache of recent days in memory, and cold-load from flash when a user opens the Health app. The backing store can be a key-value store indexed by (user id, day) .

The Apple twist is that the follow-up questions are almost always about on-device memory and battery, not about cloud scale. Candidates who default to "add another Kubernetes cluster" miss the point. The expected answer is "what can we keep out of RAM, what can we batch to reduce wakeups, and when does it ship to the cloud."

Practice it: [[problem/577?company=4|Counter with Time Expiration]]

Onsite Round 2: System Design — Health Data Sync

Problem: Design a system that keeps a user's health data (heart rate, workouts, sleep, activity rings) in sync across multiple Apple devices (iPhone, Apple Watch, iPad) and with iCloud, at millions-of-users scale, while respecting Apple's privacy model and the battery and compute limits of the Watch.

This was the round I had been waiting for, because the constraints Apple cares about are genuinely different from the generic "scale Twitter" system design.

I structured around four pillars.

Privacy and access. All sync traffic is end-to-end encrypted with keys derived from the user's iCloud account credentials. HealthKit gates third-party access per data category, with revocation supported at any time. The sync protocol cannot see plaintext; it just moves opaque encrypted blobs.

Battery and compute. The Watch has severe constraints. WatchOS background tasks are limited in both frequency and duration, and they spin down aggressively when the user is not interacting. The design has to batch updates, prefer syncing while the Watch is charging, and avoid waking the Watch radio for every new heart-rate sample. My approach: local buffer on the Watch, flush to the phone over Bluetooth when the user returns home (charging plus Wi-Fi proximity), and upload to iCloud from the phone.

Multi-device reconciliation. Each device maintains a local clock and emits change-sets tagged with a logical timestamp. Conflicts resolve with last-write-wins on most data types, with a "manual review" option for categories where the conflict could matter (workout overlaps, for example). I described a CRDT-style sync protocol for data categories that benefit from it (such as activity rings, where merges are additive).

Offline and lossy. Users go offline for long periods (hiking, international travel). The design has to tolerate multi-day offline periods and upload in bulk when connectivity returns. My answer: ring-buffer local storage on each device with a configurable retention window, plus a deduplication layer on the server that handles duplicate uploads idempotently via content hashing.

The interviewer pushed on two scenarios. What if the user revokes HealthKit access for a third-party app that has already synced data? My answer: the per-app key is invalidated and the app's locally cached copies become unreadable; the server does not need to do anything because access is enforced by encryption at the client, not by server-side ACLs. Second: what if the user switches to a new phone and restores from iCloud backup? The encrypted store restores from the backup, keys are re-derived from the user's iCloud credential, and the Watch re-pairs and re-keys via the iPhone.

Onsite Round 3: Behavioral and Values

Not a generic behavioral. Apple has a specific set of corporate values they interview against (innovation, collaboration, focus, quality, excellence in craft), and the questions are designed to elicit stories that map to them.

Questions I got:

Tell me about a project where you pushed quality higher than the team's initial bar
Tell me about a time you chose a simpler solution over a more technically impressive one
Tell me about a time you disagreed with a designer or PM and how you resolved it
What does "craft" mean to you in the context of writing software

The answer that seemed to land best for me was the "simpler solution" one. I talked about an instance where I had built a fancy streaming aggregation pipeline for health data on the Watch, then replaced it with a flat append-only log and a periodic full-scan aggregation because the log was easier to audit, easier to recover from corruption, and took less battery. The interviewer's follow-up was about how I measured the battery difference. I had actual numbers; I had run both versions on a test device and measured the current draw on the radio. She said "that's the kind of detail we want."

Result

Offer came four business days after the onsite. Mid-level iOS platform SWE, based in Cupertino with a hybrid schedule of four days on-site per week. Compensation was within the levels.fyi median. I accepted.

Tips

For the squares problem on the phone screen, do not settle for O(n log n). The interviewer will ask for linear regardless. Write the two-pointer version from the start and save the five minutes.
For Apple onsite coding, default to the on-device memory and battery framing. If the interviewer's follow-up is "how do we scale this," the expected answer is not more servers. It is about what we keep out of RAM, what we batch to avoid waking the radio, and when we ship to the cloud. Wrong frame is the most common failure mode.
For the health sync design, know HealthKit's privacy model cold. End-to-end encryption from client to iCloud, per-app access control at the HealthKit layer, revocation semantics. These are not advanced topics for Apple; they are the assumed starting point.
CRDTs are a differentiator in multi-device sync design. Even naming them and giving a one-sentence summary signals that you know why last-write-wins is not always the right answer. Several candidates I know who skipped this got asked about it anyway.
For the values round, bring hard numbers. "I made the battery better" is a weak story. "I measured 12 percent less radio current on a TestFlight build over a seven-day rolling window on X devices" is a strong story. Apple's interviewers respond to measurement.
Do not compare Apple to Google or Meta in the loop. Several candidates I know have tanked their values round by casually framing Apple as "slower but more polished than Google." Apple's engineers have a specific self-image and it is better to let the interviewer draw those lines if they come up.