FAANG mobile mock interview: a full loop to practise in 2026

A FAANG mobile mock interview is only useful if it feels like the real thing: a timer, a stranger’s questions, no IDE autocomplete to hide behind, and a written score at the end. Most people “practise” by reading answers. That trains recognition, and the loop tests production. You need to hear yourself answer out loud, get pushed, and see the score.

This page gives you a complete mock loop for a senior or staff mobile engineer, built to be run with a partner in about four hours of calendar time. First, what the large companies publish about their interviews, with links, so you know which parts of the format are documented and which are folklore. Then four rounds, seven practice prompts with follow-ups, and the rubric I use when I write up a candidate.

One rule before anything else. The prompts below are practice prompts I wrote. They are generic mobile engineering problems of the kind that come up in large-company loops. None of them is a question any company has asked, and I do not attribute questions to companies. Loops change, teams differ, and a list of “real questions from X” is almost always a guess.

What the companies publish, and what they do not

I read the public careers and interview prep pages for Google, Meta, Amazon and Apple before writing this. Here is what each one says, in summary, as described on each company’s careers pages. None of the four publishes a mobile-specific loop on those pages.

So the honest starting point is this: the public material describes general software engineering interviews, and the mobile part is decided by the team. Your recruiter is the only reliable source for your specific loop. Ask them how many rounds, which are coding, whether system design is mobile or backend flavored, and whether you code in a shared doc or an IDE. Google and Amazon both say the format depends on the role or level, Meta points you to its downloadable guides, and Apple publishes no process at all.

What that means for a mobile candidate

If the public format is general, why prepare mobile at all? Because the interviewer on a mobile team brings their own world into the room. A coding prompt stays a coding prompt, but the follow-up becomes “and what happens when this runs on the main thread?” A system design round becomes “design the client” rather than “design the data centre.” Behavioural questions get answered with release trains, crash spikes and app store reviews.

In my experience the mobile candidates who struggle in a large-company loop fall into two groups. The first prepared only algorithms and freezes when the design round asks about offline sync, process death or rollout. The second prepared only mobile and writes slow, untested code in a plain document without autocomplete. The mock below covers both, on purpose.

The mock loop at a glance

The table below is a practice shape I use, not any company’s published loop; real loops differ by company, team and level. Run it as four separate sessions, ideally on two days, with a different partner for at least one round if you can. Fatigue is part of the real loop, so do not split it into twenty-minute chunks.

The interviewer role matters as much as the candidate role. Your partner should read the prompt, answer clarifying questions briefly, push at least twice per round using the follow-ups below, and take notes on what you said, not on what they think you meant. Scoring happens after the round, never during it.

Round 1: coding in a plain document

The first round is the one mobile engineers underrate. Google’s prep page says you will not have an IDE or compiler, and Amazon’s asks for syntactically correct code, not pseudocode, so practise that way: a blank document, no syntax highlighting, no running the code. Write it as if it has to compile.

Prompt 1: merge overlapping download ranges

You are given a list of byte ranges an app has already downloaded for a large file, as pairs of start and end offsets, unsorted and possibly overlapping. Return the merged list, then write a function that returns the missing ranges for a file of a given length.

Follow-ups: What is the complexity, and can you avoid the sort if ranges arrive in order? What if the list has a million entries and this runs on app launch? How would you test the boundary where one range ends exactly where the next begins?

What a strong answer shows: clarifying whether ends are inclusive before writing code, a sort then a single pass, and at least three test cases said out loud, including empty input and touching ranges. The launch-time follow-up should pull the work off the main thread without being asked twice.

Prompt 2: a least recently used cache with a size budget

Implement a cache for decoded images keyed by URL, with a limit on total bytes rather than on count. Getting an item makes it most recently used. Adding an item that pushes the total over budget evicts from the least recently used end until it fits.

Follow-ups: What happens if a single item is larger than the budget? How would you make it safe to call from several threads? What does the system do for you on memory pressure, and how does your cache respond?

What a strong answer shows: a hash map plus a doubly linked list, or a clear statement of why an ordered map is good enough here, an explicit decision on the oversize item, and a concurrency answer that names the tool for the platform: an actor or a lock on iOS, a mutex or a single-threaded dispatcher on Android.

Across both prompts, the thing I score first is whether the candidate talks while typing. A correct solution written in silence scores lower than a slightly slower one where I heard every decision, because I can only write down what I heard.

Round 2: mobile-flavored coding

This round keeps the coding format but adds platform reality. The interviewer is checking whether you know where your code runs and what happens to it when the user leaves.

Prompt 3: a search box that does not spam the network

Write the logic behind a search field: when the user types, wait for a short pause before sending a request, cancel any request still in flight when a new one starts, and never show results for an older query after a newer one has been sent.

Follow-ups: Where is the cancellation, exactly? What happens if the response for query “ca” arrives after the response for “cat”? How would you unit test the timing without real sleeps?

What a strong answer shows: structured cancellation (a stored task cancelled on each keystroke in Swift, or a collect-latest style operator in Kotlin), a guard on the response that checks it still matches the current query, and an injected clock or test dispatcher for the tests.

A candidate who writes a correct debounce but cannot explain the race between two responses has written a demo, not a feature. That distinction is what the follow-up exists to find.

Round 3: mobile system design

Sixty minutes, one prompt, and the first ten minutes belong to requirements. If you are drawing boxes at minute three, you are designing something the interviewer did not ask for.

Prompt 4: an offline-capable photo sharing feed

Design the client for a feed of photo posts that users can read on a train with no signal, and where posts they create offline are published when the connection returns.

Follow-ups: The app is killed by the system halfway through an upload. What happens? Two devices edit the same caption offline. Who wins, and who decides that rule? You ship this to one percent of users and crash rate rises. How do you get back?

What a strong answer shows: a local store as the source the UI reads from, an outbox of pending writes with idempotency keys so a retried upload does not create a duplicate, background transfer that survives the app being suspended, and a conflict rule that the candidate says is a product decision, not only a technical one. The rollout follow-up is where senior and staff separate: a strong answer names the flag that turns the feature off without an app release and says how they would verify that the switch works before widening exposure.

Prompt 5: move a large app to a modular architecture

Your app is one large module that forty engineers work in. Builds are slow and every release has merge pain. Propose how you would split it, in what order, and how you would know it worked.

Follow-ups: Which team goes first, and why that one? How do you stop the old patterns from creeping back? What do you measure before you start?

What a strong answer shows: a baseline measured before any change (clean and incremental build time, merge conflicts per release), a first module chosen for low risk and high learning, dependency rules enforced by tooling rather than by review comments, and a plan that can stop halfway and still leave the codebase better. This is the prompt I would use for a staff candidate, because the hard part is people and sequencing, not the module graph.

For both design prompts, I want to hear what the candidate would not build. Saying “no real-time sync in version one, polling every few minutes is enough for a feed” is a stronger signal than adding a WebSocket because it sounds advanced.

Round 4: behavioural and ownership

Behavioural rounds at large companies are structured. Amazon’s SDE II page says each interviewer typically asks two or three behavioural questions and recommends the STAR method; Google’s prep page describes a mix of behavioural and hypothetical questions and also suggests STAR. Use stories from mobile work, with numbers where you have them.

Prompt 6: a release that went wrong

Tell me about a release that caused a problem for users. What happened, what did you do in the first hour, and what changed afterwards?

Follow-ups: How did you find out, from users, a dashboard, or someone else? What would you do differently in the first hour? What did the team change in the process, and is it still in place?

Prompt 7: a technical disagreement you lost

Describe a technical decision you argued against, where you made your case and the team went the other way anyway.

Follow-ups: What did you do after the decision? Were you right in the end? What did you learn about how to make the argument?

What a strong answer shows, for both: one specific story, your own actions in the first person, a result that is measured or at least concrete, and a lesson that changed what you do now. For prompt 7, the best answers commit fully to the decision they lost and can show it.

The weak version of every behavioural answer is the same: “we” all the way through, no numbers, and a lesson so general it could come from any job. When I cannot tell what the candidate personally did, I cannot score it.

The rubric

Score each round on the six rows below, from 1 to 4, and write one line of evidence for every score. A score without evidence is a feeling, and feelings are what the debrief throws out.

For a senior bar, I look for mostly 3s with no 1s. For staff, I need 4s on trade-offs and ownership in the design and behavioural rounds; a staff candidate who codes at a 3 is usually fine, a staff candidate who designs at a 3 usually is not.

How to run the mock

• Book the four sessions in advance, and do not reschedule because you “feel unready.”
• Give your partner this page, but ask them not to share the prompts with you beforehand.
• Record the rounds, with permission, and watch the first five minutes of each before reading the scores.
• After each round, pick the single lowest row on the rubric and drill that one thing before the next mock.
• Repeat the loop in two weeks with new prompts of the same shape and compare the scores.

The recording is the most uncomfortable part and the most useful. Almost everyone discovers they go quiet at exactly the moment the interviewer most needs to hear them think, which is when they are stuck.

What changed in 2024 to 2026

• Google’s interview tips page says Google Search and AI are not permitted during its interviews (Google Careers, Interview tips).
• Other companies set their own rules, and those rules change.
• Ask your recruiter what is allowed in each round, and practise the coding rounds without an assistant.

Sources

• Google Careers, How we hire
• Google Careers, Software Engineer (SWE) interview prep guide
• Meta Careers, Preparing for your technical screen
• Meta Careers, Preparing for your full loop interview
• Amazon Jobs, How we hire
• Amazon Jobs, SDE II interview prep
• Amazon Jobs, Leadership Principles
• Apple Careers, Work at Apple
• Google Careers, Interview tips

These pages were read on 24 September 2026. Companies revise them, so check the current version before your own loop, and treat your recruiter’s description as the final word.

What to do next

• Mobile system design interview, the full method for round 3
• Mobile live coding interview, for rounds 1 and 2
• Staff mobile system design interview, if the loop is for Staff
• Practice, to run the prompts under a timer

Company-specific pages for Google, Meta, Amazon and Apple adapt this loop to what each company publishes. Start with this general version, score it honestly, and fix the lowest row first.