Staff-Level Mobile Developer Interview Preparation Guide (FAANG Standards)

Brief overview

• Fixed-window: counts requests per fixed interval (e.g., per minute). Simple but allows bursts at window boundaries.
• Sliding-window: smooths counts across time, preventing boundary bursts.
• Token-bucket (leaky bucket): tokens refill at a rate; client can burst up to bucket size then must wait.

How a mobile client should adapt (backoff strategies)

• Fixed-window
  • If near limit, slow or queue requests until X-RateLimit-Reset.
  • Use exponential backoff + full jitter for retries to avoid synchronized retries.
• Sliding-window
  • Respect Remaining and Reset; moderate backoff rather than large bursts—linear backoff often sufficient.
• Token-bucket
  • Track local token usage estimate; when empty, pause requests until tokens refill. Use token-aware pacing instead of retries.
• General mobile considerations
  • Honor Retry-After when provided.
  • Use exponential backoff with jitter (e.g., base 500ms, *2, randomize) to save battery and network.
  • Batch and coalesce network calls, defer non-urgent syncs to background/when on Wi‑Fi or on reconnect.

Helpful server-side headers for clients

• X-RateLimit-Limit — total allowed in window
• X-RateLimit-Remaining — requests left
• X-RateLimit-Reset — epoch seconds or delta when quota resets
• Retry-After — seconds (or HTTP-date) when next request may succeed
• Optional: X-RateLimit-Policy or X-RateLimit-Bucket to indicate algorithm/type

Why these help

• Remaining + Reset let client pace requests deterministically.
• Retry-After avoids wasted retries and reduces battery/network churn.
• Explicit policy hints let clients choose pacing strategy (burst-friendly vs smooth).

Direct answer
Autonomy should track demonstrated judgment in a specific domain, not tenure or title, and it should be granted and withdrawn through visible, structural mechanisms, not just a private mental model of how much you trust someone. As someone grows from junior to senior, both the default level of guidance and the criteria for changing it should become more explicit, not less.

What determines the level, not just the person's level

• Domain-specific, not global: someone can have earned full autonomy in one area (their core service) and need more guidance in an adjacent one (security-sensitive changes) they haven't touched before. Treating autonomy as a single dial per person rather than per domain misjudges both directions.
• Base it on evidence: track record of decisions in that specific domain, not just general seniority or how long they've been on the team.

The conversation isn't enough, structure it

• Guidance and autonomy shouldn't live only in how much you check in; they should be encoded in the system itself. Concretely: mandatory review gates on certain categories of change, feature flags that let risky work ship dark before it's fully trusted, and automated checks (tests, linting, policy gates) that catch the class of mistake a specific person is prone to, rather than relying on a human remembering to look for it.
• This matters especially early: a junior engineer with a mandatory review gate on production-config changes isn't being distrusted personally, the system is compensating for a domain they haven't yet built judgment in, and that's a much less fraught conversation than "I don't trust your judgment yet."

Moving the dial, in both directions

• Define, in advance, what "graduating" out of a guardrail looks like: a number of changes in that domain reviewed without a significant issue, or a specific type of decision made correctly under supervision. Vague criteria ("when I feel comfortable") makes the process feel arbitrary to the person on the other side of it.
• The dial also needs to move backward cleanly. If someone senior makes a judgment error in a domain, temporarily reintroducing a guardrail (an extra review, a smaller blast radius) shouldn't read as a permanent demotion; it should be scoped to the specific domain and have the same kind of explicit, objective path back out.

How this shifts junior to senior

• Junior: guidance is broad and mostly structural (required reviews, smaller scoped tasks, pairing), because there isn't yet enough track record to know where the real gaps are.
• Mid-level: guidance narrows to the specific domains where judgment hasn't been tested yet, while proven domains get real autonomy.
• Senior: guidance becomes mostly about the highest-blast-radius decisions (irreversible changes, cross-team commitments) rather than day-to-day execution, and the structural safeguards that remain exist because the stakes are higher, not because trust is lower.

Worked example
A mid-level engineer had strong judgment in their core service but hadn't touched the deployment pipeline before. Rather than a blanket "you need approval on everything" or "you're trusted, go ahead," the guidance was scoped to that specific gap: full autonomy on their usual work, a mandatory review plus a feature flag for anything touching the deploy pipeline, with an explicit criterion stated up front (three pipeline changes reviewed cleanly, then the mandatory review comes off for that category specifically). That made the guardrail feel like a scoped, temporary compensation for an actual gap rather than a general judgment about their competence, and removing it was a specific, visible moment rather than something that just quietly happened.

Trade-offs and pitfalls

• Treating autonomy as all-or-nothing per person, rather than per domain, either over-restricts someone who's earned trust in most areas or over-extends them into an area they haven't proven yet.
• Relying purely on personal judgment about who to trust, without structural backstops (review gates, flags, automated checks), doesn't scale past a small team and creates inconsistency that reads as favoritism.
• Leaving the criteria for regaining autonomy vague turns a guardrail into something that feels indefinite and punitive, even when it was scoped and reasonable at the start.

Read-through (Cache-aside)

• What: App checks cache first; on miss fetches from network and writes into cache.
• Mobile use-case: Caching API responses for feeds or product lists using SQLite/Room or Realm.
• Trade-offs:
  • Consistency: Eventually consistent; stale data until next fetch.
  • Latency: Fast for cache hits; misses incur network delay.
  • Network: Efficient—only misses hit network.
  • Crash resilience: High if persisted; cache rebuild possible after crash.

Write-through

• What: Every write updates cache and synchronously writes to server (or through local persistence that immediately syncs).
• Mobile use-case: Settings or user profile updates that must be reflected server-side immediately.
• Trade-offs:
  • Consistency: Stronger—server and cache kept in sync.
  • Latency: Higher write latency (blocks until network or background reliable upload).
  • Network: More network usage (every write sent).
  • Crash resilience: Good if writes persisted locally until ack; requires retry logic.

Write-back (write-behind)

• What: App writes only to cache/local store; sync to server deferred/queued (background sync).
• Mobile use-case: Offline edits, queued form submissions, or composing posts while offline using WorkManager/BackgroundTasks.
• Trade-offs:
  • Consistency: Weaker—server lags, potential conflicts.
  • Latency: Fast local response for user; perceived snappy UX.
  • Network: Batched network usage—efficient when connectivity is limited.
  • Crash resilience: Risk of data loss unless writes are persisted to durable queue; requires conflict resolution and retry/backoff.

Practical mobile tips: persist caches/queues to durable storage, show offline status, use optimistic UI and conflict-resolution strategies, and choose pattern per feature: read-through for reads, write-through for critical writes, write-back for offline-first UX.

Direct answer

Keep a single, easy-to-find decision log tied directly to the work it affects: what was decided, the options considered, the reasoning, and who owns it, updated by whoever is making the decision at the moment it is made, not reconstructed later from memory.

Structured elaboration

What belongs in an entry

A short, consistent structure works better than a long one, because people will actually fill it out: a title, the date, who owns it, the context in one or two sentences, the options considered with their trade-offs, the decision itself, and the reasoning behind it in a few bullet points.

Where it lives

The log needs to be one discoverable place, linked from the tickets, docs, or roadmap items it affects, not scattered across meeting notes and chat threads. A shared doc or wiki page with a simple table works; the tool matters less than the discipline of always linking to it.

Who keeps it current

The person who owns the decision, not a rotating scribe with no stake in it, writes or finalizes the entry, ideally right after the decision is made, while the reasoning is still fresh and easy to state accurately.

How it gets used afterward

In retrospectives, revisit decisions that affected the outcome and check whether the original assumptions held. For onboarding, a short list of the most consequential recent decisions gives a new team member the context that would otherwise take weeks of osmosis to pick up.

Worked example

A team is deciding between two ways to notify users of an event: a push notification versus an in-app banner. The entry, once decided, looks like this: title, "Notification channel for event alerts"; date and owner, the decision owner's name and the date; context, users were missing time-sensitive alerts under the current in-app-only approach; options considered, push notification (faster delivery, requires a new permission prompt), in-app banner only (no new permission needed, slower to be seen), and both channels (best coverage, more engineering and support surface); decision, push notification with an in-app banner as a fallback for users who decline the permission; reasoning, the delay in the in-app-only approach was the specific problem being solved, and the fallback covers users who opt out.

Anyone who later asks why the team does not just use an in-app banner, since it is simpler, can read this entry and see the trade-off was already considered, rather than re-litigating it from scratch.

Trade-offs and pitfalls

A log nobody updates is worse than no log: it creates false confidence that the reasoning is captured somewhere, while actually going stale. The fix is keeping entries short enough that updating one takes minutes, rather than requiring a formal write-up every time.

A log can also be used as a weapon later, such as insisting a past decision still holds in a situation where circumstances genuinely changed and revisiting was the right call. The log should record reasoning, not lock in a decision forever; a review date or a note on when to re-evaluate keeps it a living reference instead of a trap.

High-level goal
Validate that creating/editing notes offline, then reconnecting, results in correct sync, robust retry/backoff, predictable conflict resolution, safe app restarts, and clear UX messaging.

Environment & tools

• Devices: iOS and Android (one each), multiple OS versions
• Tools: airplane mode, Charles/Fiddler for network manipulation, adb/idevicesyslog, app build with debug logging

Step-by-step test plan

1. Prepare

• Sign in and ensure baseline notes exist; note server clock and last-sync timestamp.

2. Offline create

• Turn on airplane mode. Create Note A (title, body, attachment). Expected: note saved locally, UI shows “Unsynced” or sync icon; no crashes; local DB entry with temporary client-id and modified timestamp.

3. Offline edit

• Edit Note A and create Note B. Delete Note C (existing). Expected: local changes recorded in operation queue with incremental sequence numbers.

4. Reconnect + happy path

• Disable airplane mode. Observe automatic sync. Verify:
  • Notes appear on server (via backend or another client).
  • Local temporary IDs replaced with server IDs.
  • UI shows success toast and removes “Unsynced” state.
  • Verify timestamps and content match.

5. Retry/backoff handling

• Simulate flaky network: reconnect but throttle or drop requests. Verify exponential backoff occurs (logs), no duplicate ops, retry intervals increase, and eventual success when network stable.

6. Conflict cases

• Setup: On Server/other device, edit Note A while offline on device. Reconnect. Verify conflict resolution policy:
  • If last-write-wins: verify the correct version prevails and user is informed.
  • If merge with user choice: verify conflict UI prompts with clear options (Keep mine / Keep theirs / Merge), and choice applies correctly.

7. App restart during sync

• Start sync, then force-close app or reboot device mid-sync. Reopen app and verify:
  • Sync resumes or restarts safely.
  • No duplicate notes or partial states.
  • Operation queue persists and continues.

8. UX messaging checks

• Ensure messages are actionable and consistent: “Offline — changes saved locally”, “Syncing…”, “Sync failed — Retry”, conflict dialogs show diffs, success toasts non-intrusive.

9. Edge and error cases

• Large attachments offline; ensure upload resumes or fails gracefully.
• Server rejects operation (validation error); verify user sees error and can edit/fix.
• Clock skew: create edits with device time changed; verify server uses server timestamps and promotes consistent ordering.

10. Verification & logs

• Cross-verify server records, client DB, and another signed-in device.
• Capture logs for retries, conflict resolution decisions, ID mappings.

Acceptance criteria

• No data loss or duplication.
• Predictable conflict handling per spec.
• Reliable retry/backoff behavior.
• Clear UX messaging at each state.

Overview / key difference

• ARC (iOS): compile-time reference counting with runtime retain/release; deallocation is deterministic when reference count reaches zero.
• Garbage collection (Android ART): tracing, pause-based collector that runs periodically to find unreachable objects; deallocation is non-deterministic.

Allocation costs

• ARC: allocation is cheap (heap alloc); each strong reference change emits a retain/release which is a small atomic or non-atomic operation — cost paid at reference updates.
• ART: allocation is cheap and often fast-pathed into a thread-local bump allocator; reclamation cost is batched during GC cycles.

Determinism & pause characteristics

• ARC: deterministic deallocation — object deallocated immediately when last strong ref removed; no global stop-the-world pauses.
• ART: deallocation is non-deterministic; modern ART uses concurrent collectors with short pauses but GC can still introduce latency spikes, especially under memory pressure or large heaps.

Common leak types

• ARC (iOS):
  • Retain cycles via strong references (delegate closures, two-way object graphs).
  • Long-lived caches or forgotten observers (NotificationCenter) holding strong refs.
• ART (Android):
  • Logical leaks: objects reachable from GC roots (static collections, singletons, native references).
  • Finalizer/phantom-reference pitfalls and large object graphs kept alive unintentionally.

How this influences allocation patterns

• iOS: prefer value types (structs) where appropriate to avoid retains; minimize long-lived strong references; be careful with closure captures (use weak/unowned).
• Android: prefer short-lived objects, reuse buffers/objects to reduce GC churn; avoid excessive allocation in UI hot paths.

Memory-leak detection strategies

• iOS: use Instruments — Leaks and Allocations, look for retain cycles (weak/unowned fixes), check for unbalanced retain/release in bridging Objective-C, audit NotificationCenter and KVO.
• Android: use Android Studio Profiler / MAT / LeakCanary, inspect GC roots and retained sizes, check for static or native references, and analyze heap dumps to find paths to GC roots.

Practical guidance

• Profile on device with realistic workloads.
• On iOS focus on reference graph correctness; on Android focus on reducing garbage churn and eliminating GC-rooted survivors.

Direct answer
Restate the instruction in your own words as a quick confirmation before acting, framed as checking your own understanding rather than doubting them, so it reads as diligence rather than not having listened.

Structured elaboration

• Frame it as confirming your own plan, not re-asking their request. "Just to make sure I act on the right thing, my plan is to do X, does that match what you meant?" reads very differently from "wait, what did you want again?"
• Be specific in the paraphrase, not generic. A vague paraphrase ("okay, got it, I'll handle it") gives them nothing to correct if you actually misunderstood; a specific one gives them an easy, fast way to say "actually, no" if needed.
• Do it briefly and move on. One sentence of confirmation, not a lengthy negotiation over wording; the goal is a fast check, not a renegotiation of the request.
• If genuinely rushed, confirm asynchronously right after rather than not at all: a one-line follow-up message restating what you understood, sent immediately after the quick instruction, still catches a misunderstanding before you've acted on it.

Worked example
Instruction given quickly in passing: "Can you get that report over to finance today?"

Weak version: "Yep, will do." (No confirmation of which report, which finance contact, or what today means if it's late in the day.)

Better version: "On it, I'll send the Q3 variance report to Priya in finance by end of day, that's the one you mean?"

This surfaces, in one sentence, exactly which report, which recipient, and what "today" means, giving them a fast chance to correct any of the three if you guessed wrong, without making them repeat the whole instruction.

Trade-offs and pitfalls

• Doing this for every trivial instruction can come across as needing excessive hand-holding; reserve the explicit paraphrase for instructions with real ambiguity or real consequences if you get it wrong.
• A paraphrase that's too close to a verbatim repeat of their words doesn't actually test whether you understood the intent, only whether you can repeat words back; try to restate it in language that shows you grasped the underlying goal, not just the surface phrasing.
• If they seem rushed or impatient with the confirmation, a very short version ("Q3 report to Priya today, correct?") gets the same benefit with almost no added time.

Direct answer
I treat a company's published culture and values as a claim to be tested, not a fact to accept, and I look for evidence in three places: how people describe real, specific incidents (not slogans) when I ask about them, whether the org's actual structures and incentives would make the stated behavior easy or hard to practice, and whether the story is consistent across different people I talk to in the process.

Structured elaboration

1. Ask for a specific recent incident, not a description of the value. A question like "tell me about a time the team had to choose between shipping fast and following the documented review process" forces a real story; a question like "how would you describe the engineering culture here" invites a rehearsed, values-page-adjacent answer that tells you little.
2. Check whether the org's structure actually supports the stated value, independent of what anyone says. If a company claims to value psychological safety but every interviewer you meet is visibly guarded about naming any team problem, or if a company claims strong autonomy but every technical decision in the loop turns out to require a director's sign-off, the structural evidence contradicts the claim regardless of the wording used to describe it.
3. Triangulate across multiple people, ideally at different levels and tenures. A single enthusiastic interviewer proves little; a hiring manager, a peer-level engineer, and someone from a different function independently describing the same specific behavior (not the same slogan) is much stronger evidence.
4. Ask what the company would do differently if it stopped believing the value, and watch for a concrete, structural answer versus a vague one. People who work inside a genuinely lived value can usually name a real trade-off it costs them; people describing marketing usually cannot.
5. Treat your own discomfort as data. If a described norm (pace, feedback directness, decision-making style) makes you visibly uneasy during the process itself, that is a more reliable signal about fit than anything printed on the careers page, because it is your own live reaction rather than a claim you are being asked to evaluate secondhand.

Worked example
Suppose a company's careers page says it "empowers engineers with high autonomy." During the loop, ask the hiring manager for a specific recent example: "Tell me about the last time an engineer on this team made a production architecture decision without it going through a review committee first." A genuine, lived-autonomy answer sounds like: "Last quarter one of our engineers decided independently to switch a service from synchronous to async processing after noticing latency complaints; she looped in two people for a sanity check, shipped it, and reported the outcome in the next team sync." A marketing-only answer sounds like: "We really believe in empowering our engineers," repeated with no specific incident when pressed twice. If a peer engineer you speak to separately can also describe a comparable specific incident in their own words, that consistency is strong corroborating evidence; if the hiring manager's story turns out to be the ONLY example anyone can produce company-wide, that is itself informative about how common the behavior actually is.

Trade-offs & pitfalls
The main failure mode is accepting an interviewer's fluent, confident description of the culture as sufficient evidence on its own; confidence and specificity are not the same thing, and a well-rehearsed answer to a values-page question is exactly what a company under-delivering on its stated culture is most likely to have prepared. A second pitfall is over-weighting a single glowing anecdote from one enthusiastic interviewer without checking whether it generalizes; one great story is an anecdote, not a pattern. A third is treating any inconsistency you find as automatically disqualifying: it is normal for a large or growing organization to have real variance across teams, so the useful conclusion is usually about the SPECIFIC team and manager you'd actually join, not the company as a monolithic whole.

Approach
Use DispatchGroup to track three async tasks, collect any errors in a thread-safe structure, and call the completion handler on DispatchQueue.main after group.notify.

Code

import Foundation

enum TaskError: Error {
    case failed(id: Int, reason: String)
}

func runThreeTasks(completion: @escaping ([Int: Error]) -> Void) {
    let group = DispatchGroup()
    var errors: [Int: Error] = [:]
    let errorsQueue = DispatchQueue(label: "errors.queue") // serial for thread-safety

    // Example async task function
    func performTask(id: Int, work: @escaping (@escaping (Error?) -> Void) -> Void) {
        group.enter()
        work { error in
            if let e = error {
                errorsQueue.async {
                    errors[id] = e
                    group.leave()
                }
            } else {
                group.leave()
            }
        }
    }

    // Start three concurrent tasks
    performTask(id: 1) { done in
        DispatchQueue.global().asyncAfter(deadline: .now() + 1.0) {
            done(nil) // success
        }
    }

    performTask(id: 2) { done in
        DispatchQueue.global().asyncAfter(deadline: .now() + 0.5) {
            done(TaskError.failed(id: 2, reason: "Network")) // failure
        }
    }

    performTask(id: 3) { done in
        DispatchQueue.global().asyncAfter(deadline: .now() + 0.8) {
            done(nil) // success
        }
    }

    group.notify(queue: .main) {
        completion(errors) // empty if all succeeded; keys indicate failed task ids
    }
}

Explanation & Notes

• Use a serial queue to mutate shared errors safely.
• group.enter() / group.leave() must balance even on early returns.
• Completion runs on main for UI updates.
• Alternative: use DispatchSemaphore or Combine/async-await for newer codebases.

Direct answer

Decide by diagnosing which constraint is actually binding right now: if it's a visibility or credibility gap, take the shippable path since it buys proof and goodwill; if it's a capability gap that will bottleneck everything after, invest the depth even though it won't show for a while. When genuinely unsure, default toward shipping, since visible momentum is what buys you the room to go deep later.

Structured elaboration

• Diagnose the binding constraint first. Ask directly: do people doubt I can do the harder thing (a visibility problem, solved by shipping), or can I genuinely not yet do it reliably (a capability problem, solved by depth)?
• Weigh the time horizon of the payoff. Depth work compounds, the skill gets reused across many future situations; shipping is mostly a point-in-time signal. The earlier you are in a role or level, the more depth tends to be worth relative to a single visible win.
• Look for a hybrid slice. Can part of the deep work be carved into something small enough to ship and visible enough to protect the time for the rest? This is often available and often missed.
• The same logic applies over a longer horizon. A lateral move offering real ownership but far less visibility is this same trade-off stretched over months instead of a single decision: the test is whether that ownership will eventually surface as something demonstrable, or whether it's ownership of something structurally invisible with no path to ever becoming visible.

Worked example

I was mid-way through work on a system that badly needed a deeper rewrite, work that wouldn't show results for a couple of months, right when a lower-effort, more visible feature request landed that would help my case going into a review cycle. I asked which was actually the binding constraint: I already had credibility for shipping, what I was missing was proof I could handle harder technical problems, so instead of choosing one or the other outright, I carved out the piece of the deep rewrite causing the most visible pain, framed it publicly as phase one of the larger effort, and used the resulting goodwill to protect time for the rest. The same question came up later at a larger scale, when I considered a lateral move into a role with far more ownership but almost no visibility; I only took it once I'd confirmed the ownership would eventually surface as something demonstrable, rather than staying invisible indefinitely.

Trade-offs & pitfalls

• Always choosing visibility produces a track record that looks credible but is shallow exactly when the next level starts expecting real depth.
• Always choosing depth risks being read as someone who goes quiet and doesn't ship, even when the eventual work is excellent.
• A hybrid slice isn't always available, and pretending there's always a clever middle path is itself a tell that you're avoiding an honest either/or call.
• For the lateral-move version specifically, the trap is accepting invisible ownership indefinitely on the promise it will "pay off eventually," with no concrete idea of how or when it becomes visible.