Live coding · 14 min
Mobile live coding interview: what to say while you type
How a mobile live coding round is scored, a 45-minute plan, what to say at each stage, a worked Swift example, and how to recover when you stall.
Senior and Staff loops · 12 min read
Google mobile mock interview: practise the loop in 2026
A Google mobile mock interview based on what Google's careers pages publish: shared-doc coding, design and behavioural rounds, six practice prompts and a rubric.
A Google mobile mock interview should copy the one part of the format Google is explicit about: you write code in a shared document, in front of an engineer, and you are expected to test it yourself. Everything else about the loop depends on the team and the level, and Google says so.
This page does three things. It summarizes what Google publishes about its software engineering interviews, with links. It turns that into a four-round mock for a senior mobile engineer, with six practice prompts, follow-ups and what a strong answer shows. And it gives you the rubric I use to write up a candidate, so your partner can score you instead of just saying “that felt good.”
The prompts are practice prompts I wrote. They are generic mobile engineering problems, not questions Google has asked, and I never attribute a question to a named company. If a site promises you “real Google questions,” it is guessing.
What Google publishes about its interviews
As described on Google’s careers pages, including How we hire and the software engineer interview prep guide, the technical interviews look roughly like this. I have paraphrased; the links are in the Sources section.
- You code in the language of your choice unless the role needs a specific one, and you are expected to test your code and find corner and edge cases.
- Interviews may cover programming, data structures and algorithms, and designing systems, worked in a shared document with the interviewer. You will not have an IDE or compiler.
- The guide asks you to ask clarifying questions, say when you are making an assumption and why, and avoid pseudocode unless the interviewer asks for it. It suggests being prepared to write around 20 to 30 lines of code in your strongest language.
- Depending on role and level, you may need more depth in coding, data structures and algorithms, systems architecture, or other domain areas. The guide notes that systems architecture interviews are not part of every process and are typically for candidates with years of industry experience.
- Interviewers will likely ask a mix of behavioural and hypothetical questions, and the guide asks candidates to think about collaboration, conflict and leadership, including leading without the title.
Google’s pages do not describe a mobile-specific loop. There is no published list of iOS or Android rounds. So the mobile part of your loop comes from the team: the “other domain areas” line is where it lives, and your recruiter can tell you whether you will get a mobile design round or a general one.
What that means for a mobile candidate
Two consequences follow. First, general coding matters more than many mobile engineers expect, and it happens without an IDE. If you rely on autocomplete for Dictionary initializers or Kotlin collection functions, practise without it now. Second, the domain depth shows up in follow-ups and in design. An interviewer from a mobile team will ask what happens to your solution on a phone: on the main thread, on a slow network, after the process is killed.
When I interview mobile candidates in a shared-document format, the most common failure is not a wrong algorithm. It is a candidate who writes the right algorithm silently, then cannot say what they tested. The guide’s instruction to test your own code is the single most useful sentence on the page.
The mock loop at a glance
This is a typical practice shape, not a loop Google publishes; your recruiter will tell you your actual rounds. Plan four sessions. Use a plain shared document for the coding rounds, with syntax highlighting off if your tool allows it.
| Round | Time | Format | Focus |
|---|---|---|---|
| 1. Coding | 45 min | Shared document | Data structures, algorithms, tests |
| 2. Coding with mobile follow-ups | 45 min | Shared document | Same format, platform-aware follow-ups |
| 3. Mobile system design | 45 to 60 min | Drawing tool or doc | Client architecture and trade-offs |
| 4. Behavioural and hypothetical | 45 min | Conversation | Collaboration, conflict, leadership |
A timing split I suggest for practice, not one Google publishes: five minutes clarifying, five minutes describing the approach, twenty-five writing, ten testing and answering follow-ups. If you are still clarifying at minute ten, your partner should say so.
Round 1: coding in a shared document
Prompt 1: visible time per list item
A list screen reports events as a stream of tuples: a timestamp, an item ID and whether the item became visible or hidden. Write a function that returns total visible time per item. Items that are still visible at the end of the stream count until a given end time.
Follow-ups: What if a “hidden” event arrives for an item that was never shown? What if two “visible” events arrive for the same item in a row? What is the complexity, and what does the memory look like for a very long session?
What a strong answer shows: a map from item to the start time of its current visibility, a second map for totals, explicit handling of the malformed sequences (and a decision stated out loud), then tests for the end-of-stream case. The candidate should explain why this does not need sorting if timestamps are already ordered, and ask whether they are.
Prompt 2: rate-limit analytics events
Write a limiter that allows at most N events per rolling window of W seconds per event name. Calls that exceed the limit are dropped. The clock is injected.
Follow-ups: Fixed window or sliding window, and what does each cost? How much memory for ten thousand event names? How would you test it without waiting real seconds?
What a strong answer shows: a queue of timestamps per name, or a sliding-window counter with the approximation named, an injected clock used in the tests, and awareness that on a phone memory for rarely used names should be released.
A candidate who says “I would test this” and moves on has not tested it. I want to hear the input, the expected output, and the walk through the code, line by line, for at least one case.
Round 2: coding with mobile follow-ups
Prompt 3: an image loader that never shows the wrong picture
In a scrolling list, each row asks a loader for an image by URL. Rows are reused while scrolling. Write the loader and the row binding so that a row never shows an image meant for another item, and duplicate requests for the same URL share one download.
Follow-ups: Where does the decode run? What happens when the row is reused before the download finishes? How do you cap memory?
What a strong answer shows: in-flight request coalescing keyed by URL, a check at bind time that the row still represents the same item (or cancellation of the old request on reuse), decoding off the main thread, and a bounded cache. On iOS that often means an actor holding in-flight tasks; on Android a coroutine scope tied to the row’s lifecycle. Either is fine if the candidate can defend it.
This round rewards candidates who connect a plain coding answer to the platform without being dragged there. If your partner has to ask “and where does this run?” twice, score communication lower.
Round 3: mobile system design
Prompt 4: offline-first notes with sync
Design a notes app that works fully offline, syncs across a phone and a tablet, and never silently loses an edit.
Follow-ups: Two devices edit the same note offline. What does the user see? The sync protocol needs to change next year while old app versions are still installed. How? The process is killed mid-sync. What state is on disk?
What a strong answer shows: a local database that the UI reads from, treated as the truth, an operation log or versioned records rather than “last write wins” by accident, a conflict policy the candidate is willing to name and defend, idempotent sync requests, and a versioned API with a plan for old clients. At senior level, a clear diagram and those decisions are enough. At staff level, I expect the candidate to talk about how the change rolls out and how they would switch it off.
Prompt 5: cut cold start time in half
Cold start on your app has doubled over two years. Design how you would find out why, fix it, and keep it from coming back.
Follow-ups: How do you measure cold start in the field, not just on your own device? Which work can move off the startup path? How do you stop the next team from adding it back?
What a strong answer shows: field measurement split by device class, a trace of what runs before first frame, lazy initialization of anything not needed for the first screen, and a regression budget enforced in CI. The staff-level answer adds ownership: who is paged when the budget is broken.
The design round is where “it depends” either helps or hurts. It helps when followed by the two options and the one you choose. It hurts when it is the whole answer.
Round 4: behavioural and hypothetical
Google’s guide mentions both kinds. A behavioural question asks what you did; a hypothetical asks what you would do. Answer the second with the same structure as the first.
Prompt 6: leading without the title
Tell me about a time you got a group of engineers to change how they worked, when you were not their manager.
Follow-ups: Who disagreed, and how did you handle it? How did you know it worked? Hypothetical version: your team wants to adopt a new UI framework and one senior engineer is strongly against it. What do you do this week?
What a strong answer shows: one real story, the specific objection and how it was addressed, a measurable result, and for the hypothetical, concrete first steps rather than values. “I would listen to everyone” is a value. “I would ask him to write down his two strongest objections and run a one-week spike on the riskiest one” is a step.
Behavioural answers are scored on evidence, just like code. If I cannot tell what you personally did, I have nothing to write.
The rubric
Score every round on these six rows, 1 to 4, with one line of evidence per score.
| Signal | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Clarifying | Starts immediately | Asks, then ignores the answers | Pins down inputs, limits and edge cases | Narrows the problem and states assumptions aloud |
| Approach before code | No plan stated | Plan stated after coding starts | Plan and complexity before code | Compares two approaches and picks one with a reason |
| Code quality | Pseudocode or does not run | Works on the happy path | Clean, named, handles edges | Clean and easy to change for the follow-up |
| Self-testing | None | Asserts it works | Walks through two or more cases | Finds and fixes own bug before the interviewer does |
| Mobile judgement | No platform awareness | Mentions threads when asked | Raises main thread, lifecycle, memory unprompted | Designs for old versions, killed processes, rollback |
| Collaboration and leadership | Vague, “we” throughout | Own tasks only | Own decisions and reasons | Outcomes through other people, with a result |
A senior mock pass is mostly 3s with no 1s. Treat any 1 as the thing to fix before the next mock, even if everything else went well, because in a real debrief a single weak row is what people remember.
How to run it
- Send your partner this page and ask them to keep the prompts from you.
- Turn off autocomplete and highlighting for rounds 1 and 2.
- Record each round and replay the first five minutes: that is where clarifying happens or does not.
- Pick the lowest row, drill it for a week, then run the loop again with new prompts.
Most candidates find the self-testing row is their lowest on the first run. It is also the fastest to fix, because it is a habit, not knowledge.
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
- Google Careers, Interview tips
The first two pages were read on 24 September 2026 and the interview tips page on 21 October 2026. Google updates them and the loop varies by team, so confirm your own format with your recruiter.
What to do next
- Mobile live coding interview, for the shared-document rounds
- Mobile system design interview, for round 3
- FAANG mobile mock interview, the general version of this loop
- Practice, to run prompts under a timer
Run the loop once, score it honestly, and fix the lowest row before you run it again. The second run is where the scores start to move.
