Apple Backend Developer Interview Questions
Apple's devices lean on services behind them: files and photos that follow a person across their phone, tablet and computer, app downloads, music streaming and messages. Backend work there means very large numbers of devices, users who expect their data to stay private and launch days when everyone updates at once. Prepare to discuss sync, notifications, encrypted data and release-day load. What to show here: services that respect privacy and hold up on launch day. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Apple hires, in its own words, and its questions for every job →
1. Tell me about a time protecting users' privacy made the engineering harder, and you chose the harder path anyway.
- Describe the feature and the easy path.
- Explain what the easy path would have exposed.
- Describe the harder design you chose.
- Share the result and what it cost.
“I worked on a feature that suggested people to share a document with. The quick way was to upload each user's contacts to our servers and match them there. That would have given us every user's whole address book, which nobody had agreed to. I proposed matching on the device instead, with the server only answering yes or no for hashed values in small batches. It took longer to build and the first version was slower. We improved it over two releases. The feature shipped with your result, and we never stored a contact list.”
Weak answers see privacy as a legal checkbox, or cannot name a design they changed because of it.
2. Describe a time you prepared a service for a spike you knew was coming, such as a launch day. What did you get right and what surprised you?
- Describe the event and your estimate of the load.
- Explain how you tested and what you changed beforehand.
- Describe what surprised you on the day.
- Share what you did afterward.
“Before a major release of our app, we expected many times the normal traffic on the update check service in the first hours. I estimated the peak from the previous release and tested at twice that. We added capacity and made the response cacheable at the edge. On the day, the service held, but the surprise came from a small logging service that every request also called. It fell behind and slowed everything. We switched logging to sample mode and recovered. Afterward, I mapped every dependency of the hot path, not just the main one. The result was your result.”
Weak answers scale only the front service and never look at what it depends on.
3. Design the sync for a notes app where a person edits the same note on their phone while offline and on their laptop at the same time. What happens when both come back online?
- Store changes as versioned operations per device.
- Sync only what the server has not seen.
- Merge automatically where safe, such as different paragraphs.
- Keep both versions when a merge is unsafe, and never lose anything.
“Each device would keep a local copy of the note and a log of its changes, each with a version and the device id. When a device reconnects, it sends its changes since the last version the server confirmed, and receives changes from others. If the two devices changed different parts of the note, the server merges them and both devices end up equal. If they changed the same sentence, I would not silently pick one. The note keeps both versions and marks the conflict so the person can choose. The rule I would hold above all: a user's words are never lost.”
Weak answers let the last writer win and overwrite hours of work on the other device.
4. Design a service that delivers push notifications to a very large number of phones, many of which are off or out of coverage at any moment.
- Keep a registry of devices and their current connection.
- Queue messages per device with a time to live.
- Deliver when the device connects and confirm receipt.
- Collapse repeated messages and drop expired ones.
“Each phone keeps one long-lived connection to a gateway, and a registry records which gateway holds each device. When an app server sends a notification, the service looks up the device. If it is connected, the gateway pushes it and waits for a receipt. If not, the message waits in a per-device queue with a time to live, because a notification about a message from an hour ago is still useful, but one from last week is not. When the phone reconnects, queued messages are delivered in order. Repeated messages with the same key are collapsed, so a phone that was off does not get twenty copies.”
Weak answers try to push to an offline phone repeatedly, or keep every message forever.
5. A new version of the system software is released and a very large number of devices want it in the same hour. How would you serve the download without collapsing?
- Serve files from edge caches close to users.
- Offer smaller update files for devices already on a recent version.
- Roll out in stages so not every device asks at once.
- Protect the origin with rate limits and retry backoff.
“The file itself should almost never come from the origin. It is copied to edge caches around the world before release, so most devices download from a server near them. Devices on a recent version get a much smaller file that contains only the differences. The rollout goes in stages: devices are told about the update over hours, with a random delay, so demand is spread and problems appear on a small group first. If demand still spikes, the origin refuses politely and devices retry later with growing waits. The download also resumes from where it stopped.”
Weak answers add more origin servers and serve the full file to every device at once.
6. Some user data is encrypted so that the server cannot read it. What does that change for how you store it, remove duplicates, search it and debug problems?
- Store encrypted blobs with only the metadata the service needs.
- Move search and indexing to the device.
- Give up on server-side dedupe of content, or use keys the client derives.
- Debug with structured metadata and client logs, never with content.
“The server sees only encrypted blobs, so it stores them by id with the minimum metadata: size, version, owner. It cannot search the content, so search happens on the device, which keeps its own index. Removing duplicate files by content is no longer possible on the server, since the same file encrypted twice looks different. If dedupe matters, the client can derive a key from the content itself, though that has trade-offs to discuss. For debugging, I lean on metadata and error codes, and on logs the user chooses to send. It is harder, but it is the point of the design.”
Weak answers assume the server can decrypt for a moment when convenient, which defeats the whole purpose.
7. After a system update, a small share of devices fail to restore their backup from the cloud. You cannot see the content of the backups. How do you find the cause?
- Gather what the failures have in common: device model, version, backup size, error code.
- Compare failing and succeeding restores on the same version.
- Reproduce on a test device with a matching backup.
- Fix, verify on affected devices and add a check to the release process.
“I would start with what I can see: the error codes, device models, software versions and backup sizes for the failures, compared with restores that worked. Often a pattern appears, such as backups made by a much older version, or those above a certain size. With that clue I would build a backup of the same shape on a test device and try to restore it. If it fails, I have a reproduction and can trace it. Once fixed, I would confirm with a few affected users who agreed to help, and add that backup shape to the tests we run before every release.”
Weak answers ask users to reset their devices without finding the cause, or want to look inside the backups.
8. Why do you want to build backend services at Apple, where the servers exist to serve devices and must know as little as possible about the people using them?
- Say what draws you to services behind devices.
- Speak to privacy as a design constraint you welcome.
- Give an example from your work.
- Say what you want to learn.
“Most backend work I have done treated the server as the centre and the client as a thin screen. Apple makes the devices, so the services exist to make a phone or laptop feel complete: files that follow you, notifications that arrive, updates that just work. I like that the server is the quiet part. I also welcome the constraint of knowing as little as possible about the person, because it forces better design, as I found when I moved contact matching onto the device. I want to learn how sync and distribution are done at that scale.”
Weak answers are mostly about the brand, or see the privacy constraint as an obstacle rather than a goal.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.