Apple interview prep

Use the STAR format: describe the context and the decision you disagreed with, the specific concern you raised and how you raised it (data, an experiment, or a clear argument), the outcome, and what you would do differently. Show that you can advocate for your position while remaining constructive, and that you can commit to a decision once it has been made even when you disagree.

What a strong answer covers: The goal is to show technical judgment and professional communication, not to relitigate old grievances. Avoid framing the story as you versus them. A strong answer includes evidence you used to make your case.

Follow-up: What would you do if the team made the same decision again and the outcome was worse than you predicted?

Last reviewed 2026-10-07

Use STAR: explain the project goal, what you built, what happened, and what you did next. Own your share of the failure rather than attributing it entirely to data, compute, or other constraints. Name a specific technical mistake — a leaky split, a flawed evaluation metric, a mislabeled dataset — not a vague sense that the model was wrong. Describe what you learned and how you applied it on a subsequent project.

What a strong answer covers: A strong answer names a specific technical root cause, not bad luck or insufficient time. The retrospective action matters as much as the failure itself.

Follow-up: What would be the first thing you would investigate if you had three days to debug the same project now?

Last reviewed 2026-10-07

Use STAR: describe the decision, what information was missing, what assumptions you made and why, how you documented those assumptions, and what you did to limit downside risk. Show that you can move forward without perfect information while keeping the team informed about your uncertainty and the conditions that would change your decision.

What a strong answer covers: This tests judgment and risk management. A strong answer distinguishes between uncertainty that is worth waiting to resolve and uncertainty you can safely assume away for now.

Follow-up: How did you decide what additional information was worth waiting for versus what you could assume away?

Last reviewed 2026-10-07

Use STAR: set the scene, describe the failure and how you found it, and explain how you communicated it. Lead with the business impact first, then explain the cause at a level the audience can act on. Show that you gave them what they needed to make a decision rather than a full technical post-mortem. Include what you proposed to fix and what the outcome was.

What a strong answer covers: The best answers show empathy for what the stakeholder needs to know, not just what you know. Avoid jargon without explanation and avoid false reassurance about a fix that is not yet validated.

Follow-up: How would you set up a review process to catch similar issues before they reach stakeholders?

Last reviewed 2026-10-07

Use STAR: describe the problem you noticed, why it was not clearly owned, what you chose to do, how you involved or informed the right people, and the outcome. Show judgment about when to escalate versus act, and demonstrate that you understood the constraints and worked within or around them thoughtfully rather than bypassing important processes.

What a strong answer covers: This tests initiative and judgment. Interviewers probe whether you involved the right people at the right time. A strong answer shows you didn't silently take over someone else's work.

Follow-up: How did you decide this was your problem to solve rather than someone else's?

Last reviewed 2026-10-07

Federated learning keeps training data on device, reducing privacy risk and regulatory exposure. The trade-offs are communication cost (many rounds of gradient exchange), statistical heterogeneity (non-IID data across devices), systems heterogeneity (varying compute and availability), and difficulty debugging without access to individual examples. Gradients can still leak information through reconstruction attacks, so combining federated learning with differential privacy or secure aggregation adds protection at the cost of some model accuracy.

What a strong answer covers: Federated learning does not automatically guarantee privacy — it reduces the attack surface but gradient leakage is a real threat. The central tension is between stronger privacy guarantees and model quality.

Follow-up: How would you validate that a federally trained model generalises well across heterogeneous device populations?

Last reviewed 2026-10-07

Primary constraints are model size (flash and RAM), inference latency, battery impact, and thermal limits. Techniques: use smaller architectures, apply quantisation and pruning, use hardware-specific kernels (Core ML on Apple, NNAPI on Android), and avoid dynamic shapes that prevent graph compilation. Test on actual devices at the target battery level and thermal state, not only on simulators. Design the feature pipeline to work without a network request.

What a strong answer covers: Thermal throttling is often overlooked: a device that has been running a demanding app may execute the model significantly slower than benchmarks suggest. Server-side numbers don't translate directly to device performance even for the same architecture.

Follow-up: How would you decide whether to run inference on-device or on a server for a new feature?

Last reviewed 2026-10-07