iOS Playbook
The experienced iOS engineer interview study plan
You already ship iOS. You do not need a tutorial — you need to know what to study, what to ignore, and when to stop. This is one curriculum with three routes, depending on how long you have.
It is free and there is nothing to sign up for. The practice problems it links to are the ones already on this site.
Pick your route
These are not three different plans. They are the same curriculum at three levels of compression, so a shorter route tells you exactly what you are giving up instead of quietly giving you less.
30-day route
You have a month and a current job. This is the only route that covers everything.
Time: 60–90 min on weekdays, one longer weekend block
- Days 1–4Arrays & hashing
- Days 5–7Two pointers · Sliding window
- Days 8–9Stack · Binary search
- Days 10–12Linked lists
- Days 13–15Trees
- Days 16–18Graphs
- Days 19–22One-dimensional DP
- Days 23–24Backtracking · Intervals & matrix
- Days 25–27iOS live codingBuild one small app per day from an empty file. Timebox to 45 minutes and keep the code.
- Days 28–29Mobile system design
- Day 30Past-project deep diveOut loud, to a person or a recording. Reading it silently does not count.
What you give up: None. If you have 30 days, there is no reason to run a shorter route.
14-day compressed
Your loop is in two weeks. You have interviewed before and you are rusty, not new.
Time: 90 min, every day, no rest day
- Days 1–2Arrays & hashing
- Day 3Two pointers · Sliding window
- Day 4Binary search · Stack
- Days 5–6Linked lists
- Day 7Trees
- Day 8Graphs
- Days 9–10One-dimensional DP
- Days 11–12iOS live codingNon-negotiable. This is the round you are most likely to fail and least likely to have practiced.
- Day 13Mobile system design
- Day 14Past-project deep dive
What you give up: Backtracking, intervals, and matrix are dropped. They are the least likely to appear in an experienced iOS loop and the most self-contained to pick up later. If you finish early, add them back in that order.
7-day emergency
Your onsite is next week. The goal is not mastery — it is not being surprised.
Time: 2–3 hours, and accept that you will not cover everything
- Day 1Arrays & hashingIf you only do one DSA unit, do this one. It is the most-asked by a wide margin.
- Day 2Two pointers · Sliding window
- Day 3Trees · Linked lists
- Day 4Graphs · One-dimensional DPOne pass each. Understand the shape; do not chase completeness.
- Days 5–6iOS live codingTwo full 45-minute builds. Do not skip this to grind more LeetCode.
- Day 7Mobile system design · Past-project deep dive
What you give up: Binary search, stack, backtracking, intervals, and matrix are dropped, and the units you do cover get one pass instead of three. You are buying familiarity, not fluency. Expect to be able to recognize a problem type and start correctly — not to finish every problem clean.
The curriculum
Every unit names the mistake that most often costs people the round, and an exit criterion you can actually observe. “Feeling ready” is not an exit criterion.
Arrays & hashing
Rebuild the reflex of reaching for a dictionary before reaching for a nested loop.
- Two Sumeasy
- Contains Duplicateeasy
- Valid Anagrameasy
- Group Anagramsmedium
- Telemetry: Top K Frequent Error Codesmedium
- Product of Array Except Selfmedium
More problems in this pattern →
- Most common mistake:
- Jumping to code before saying what the dictionary holds. Say "key is the value, value is the index" out loud first — the bug you avoid is the one you would have written.
- You are done when:
- You can state the key and the value of your map before writing a line, on every problem in this unit.
Two pointers
Recognize sorted-input problems where the second loop is unnecessary.
- Valid Palindromeeasy
- 3Summedium
- Container With Most Watermedium
More problems in this pattern →
- Most common mistake:
- Not saying why the pointer moves. "I move left because the area can only improve if the shorter side changes" is the answer; moving it silently is not.
- You are done when:
- You can justify each pointer move in one sentence without looking at the code.
Sliding window
Handle "longest/shortest substring such that…" without re-scanning the window each step.
- Best Time to Buy and Sell Stockeasy
- Longest Repeating Character Replacementmedium
- Minimum Window Substringhard
More problems in this pattern →
- Most common mistake:
- Shrinking the window with an `if` when the invariant needs a `while`. This is the single most common silent wrong answer in this unit.
- You are done when:
- You can name the window invariant, and say what makes it become invalid, before coding.
Stack
Matching, nesting, and monotonic scans.
- Valid Parentheseseasy
- Min Stackmedium
More problems in this pattern →
- Most common mistake:
- Treating min-stack as a trick to memorize instead of the general idea: store the answer alongside the value so pops stay O(1).
- You are done when:
- You can explain why min-stack is O(1) and not O(n) per pop.
Binary search
Search a sorted or rotated space, and search over an answer range.
More problems in this pattern →
- Most common mistake:
- Off-by-one on the boundary. Pick ONE template — inclusive or exclusive high — and use it every single time. Interviewers do not care which; they care that you are consistent.
- You are done when:
- You write the loop boundary correctly from memory, twice in a row, without a compile-run-fix cycle.
Linked lists
Pointer manipulation without losing the rest of the list — and LRU, which is the one that actually shows up in iOS loops.
- Reverse Linked Listeasy
- Merge Two Sorted Listseasy
- Linked List Cycleeasy
- LRU Cachemedium
More problems in this pattern →
- Most common mistake:
- On LRU, forgetting that the hash map must store the NODE, not the value. Storing the value makes eviction O(n) and quietly fails the follow-up.
- You are done when:
- You can implement LRU with a dict plus a doubly-linked list, and say why both are required.
Trees
Recursion you can explain, plus the BST ordering property.
- Invert Binary Treeeasy
- Maximum Depth of Binary Treeeasy
- Same Treeeasy
- Validate Binary Search Treemedium
More problems in this pattern →
- Most common mistake:
- Validating a BST by comparing each node only to its direct children. It passes the obvious cases and fails the interview. Pass min/max bounds down.
- You are done when:
- You can state the recursive contract — "what this call returns and what it assumes" — before writing the body.
Graphs
BFS/DFS on grids and adjacency, plus cycle detection framed as prerequisites.
- Number of Islandsmedium
- Clone Graphmedium
- Course Schedulemedium
More problems in this pattern →
- Most common mistake:
- Marking a node visited when you dequeue instead of when you enqueue. The result is still correct but the queue blows up, and a good interviewer will ask about it.
- You are done when:
- You can turn a grid into "nodes and edges" out loud, and pick BFS or DFS with a reason.
One-dimensional DP
The recurrence, the base case, and why the greedy version is wrong.
- Climbing Stairseasy
- House Robbermedium
- Coin Changemedium
- Longest Increasing Subsequencemedium
- Word Breakmedium
More problems in this pattern →
- Most common mistake:
- Writing the table before saying what `dp[i]` MEANS. If you cannot finish the sentence "dp[i] is the …", you are not ready to write the loop.
- You are done when:
- You can state the meaning of dp[i], the recurrence, and the base case as three separate sentences.
Backtracking
Enumerate choices without duplicating work or answers.
- Subsetsmedium
- Combination Summedium
- Permutationsmedium
More problems in this pattern →
- Most common mistake:
- Forgetting to undo the choice after the recursive call, or appending the working list by reference so every answer mutates together.
- You are done when:
- You can name the choice, the constraint, and the undo step for any of these.
Intervals & matrix
Sorting-by-start, and the in-place grid manipulations that get asked as warmups.
- Merge Intervalsmedium
- Insert Intervalmedium
- Rotate Imagemedium
- Spiral Matrixmedium
- Set Matrix Zeroesmedium
More problems in this pattern →
- Most common mistake:
- On set-matrix-zeroes, using a marker value that can legitimately appear in the input. Use the first row/column as the marker, or say out loud why your sentinel is safe.
- You are done when:
- You sort by the right endpoint and can say why it is the right one.
iOS live coding
The round that actually separates experienced iOS candidates: build a small thing in Swift, on a real API, while talking.
- Most common mistake:
- Treating it as a DSA round. It is a "can you write shippable code" round — naming, error paths, and concurrency matter more than the optimal big-O.
- You are done when:
- You can build an image loader with a cache, from an empty file, in 45 minutes, narrating as you go.
Mobile system design
Design a client, not a backend: caching, pagination, offline, sync conflicts, and what happens on a bad network.
- Most common mistake:
- Drawing a backend architecture. You are being asked about the client — the interviewer wants the cache invalidation story and the offline queue, not your load balancer.
- You are done when:
- You can take "design an Instagram-like feed" from requirements to a client architecture with a stated caching and pagination policy, in 45 minutes.
Past-project deep dive
The round most experienced candidates under-prepare, and the one where seniority is actually judged.
- Most common mistake:
- Describing what the team shipped instead of what YOU decided. The signal being scored is your specific technical judgment and the tradeoff you personally chose.
- You are done when:
- You have two stories rehearsed out loud, each with a decision you owned, an alternative you rejected, and why.
What to skip
“Study everything” is the advice that makes people quit. If your time is finite, these are the things I would cut first — and these are opinions, not rules.
- Advanced graph algorithms (Dijkstra, union-find, min spanning tree)OpinionRare in mobile loops relative to how long they take to learn. If you have limited days, arrays and the iOS rounds pay back more per hour.
- Segment trees, tries, and advanced heap variantsOpinionAlmost never asked in an iOS interview. If one appears, it is a screening signal you were unlikely to pass with a week of cramming anyway.
- Grinding past ~75 problems before you have done a single mock live-coding roundOpinionThe marginal problem is worth far less than the first rehearsal of the round you have never practiced.
- Memorizing Big-O tablesOpinionYou are asked to derive complexity for YOUR solution, out loud. A table does not help you do that; explaining your own loop does.
- Backend system design (sharding, consensus, load balancers)OpinionMobile system design asks about the client. Time spent on database replication is time not spent on cache invalidation and offline sync.
What each round actually tests
- DSA / codingOpinionWhether you can externalize your reasoning while writing code. The algorithm is table stakes; the narration is the differentiator.
- iOS live codingOpinionWhether your code would survive code review: naming, error paths, and concurrency correctness.
- Mobile system designOpinionClient architecture judgment — caching, pagination, offline behavior, and what happens on a flaky network.
- Past projectsOpinionScope of ownership and the quality of a tradeoff you personally made. This is where level is decided.
- Swift concurrency (async/await, actors, Sendable)PlatformStrict concurrency checking is part of the Swift 6 language mode, so data-race questions are checkable against the compiler rather than a matter of taste.
- Loop structure and round countReportedVaries by company, org, and year. Treat any specific claim about a named company loop as candidate-reported and re-check with your recruiter — they will tell you the format if you ask.
What changes by level
The same answer lands differently depending on the level you are interviewing at. Level names vary by company; the shape does not.Opinion
- Mid (IC3–IC4)
- Solve the problem and explain it. Ownership stories can be feature-sized. Correctness carries most of the weight.
- Senior (IC5)
- Correctness is assumed. You are scored on tradeoffs you name before being asked, and on whether your past-project story shows a decision you owned end to end.
- Staff (IC6+)
- You are scored on scope and influence: problems you chose to take on, work you prevented, and how you reasoned about a system beyond your own commits.
Mistakes I see over and over
- Coding in silence, then narrating afterward. The interviewer cannot score a decision they did not hear you make.
- Asking zero clarifying questions on an intentionally underspecified prompt. The ambiguity is the test.
- Optimizing before a working solution exists. Say "here is the brute force, it is O(n²), let me improve it" — then improve it.
- On past projects, saying "we" for a decision that was yours. It reads as smaller scope than you actually have.
- Preparing only the rounds you are already good at, which for most experienced iOS engineers means grinding DSA and never rehearsing live coding or system design.
Start
Pick the route that matches your actual deadline, then do day one today. The first rep is worth more than another hour of choosing a plan.