Meta Staff Mobile Developer Interview Preparation Guide

Direct answer

The bug is [unowned self] in a repeating timer's closure: unowned asserts the captured object will always outlive the closure, but here the timer keeps firing (and keeps calling self.doWork()) after the view controller has been deallocated, so the closure accesses memory that no longer holds a valid Widget/UIViewController instance, producing EXC_BAD_ACCESS. Fix by capturing [weak self] and guarding against nil, or by explicitly invalidating the timer when the view controller is dismissed so it never outlives its owner in the first place.

Structured elaboration

A repeating Timer is retained by the run loop it's scheduled on, not by the object that created it, so the timer can easily outlive its "owner" unless something explicitly invalidates it. [unowned self] tells the compiler "don't bother with the overhead of an optional weak reference, I guarantee this object is still alive whenever the closure runs"; when that guarantee is false, accessing self doesn't return nil gracefully the way a weak reference would, it directly dereferences freed memory, which is exactly the EXC_BAD_ACCESS signature.

Two independent, complementary fixes:

1. Code-level fix: [weak self] with a guard. This makes the closure defensively check whether self still exists each time it fires, silently doing nothing once the object is gone, at the cost of an optional unwrap on every invocation.
2. Lifecycle-handling fix: invalidate the timer in deinit or viewWillDisappear. This addresses the root cause (the timer outliving its intended owner) rather than just defending against it, and also stops the wasted work of a timer firing for an object nobody cares about anymore. The two fixes are not mutually exclusive: invalidating the timer on teardown is the correct primary fix, and weak self is good defensive practice regardless, in case invalidation is ever missed on some code path.

Worked example

import Foundation

class Widget {
  var timer: Timer?
  init() {
    timer = Timer.scheduledTimer(withTimeInterval: 0.05, repeats: true) { [unowned self] _ in
      self.doWork()
    }
  }
  func doWork() { print("tick") }
  deinit { print("Widget deinit") }
}

var w: Widget? = Widget()
// let a couple of ticks happen, then drop the only strong reference
// while the timer (held by the run loop) is still scheduled
RunLoop.current.run(until: Date().addingTimeInterval(0.12))
w = nil
print("w set to nil")
RunLoop.current.run(until: Date().addingTimeInterval(0.3))
print("done")

Run with swift widget_buggy.swift:

tick
tick
Widget deinit
w set to nil
Fatal error: Attempted to read an unowned reference but object 0x... was already destroyed

The process traps inside the timer's fire callback after w is set to nil: exactly the EXC_BAD_ACCESS-class crash the question describes, confirming the mechanism (a dangling unowned reference accessed after deallocation, not a logic bug in doWork() itself).

Replacing the capture with [weak self] plus a guard, and adding explicit invalidation on teardown:

import Foundation

class Widget {
  var timer: Timer?
  var tickCount = 0
  init() {
    timer = Timer.scheduledTimer(withTimeInterval: 0.05, repeats: true) { [weak self] _ in
      guard let self = self else { return }
      self.doWork()
    }
  }
  func doWork() {
    tickCount += 1
    print("tick \(tickCount) (weak)")
  }
  func stop() {
    timer?.invalidate()
    timer = nil
  }
  deinit { print("Widget deinit") }
}

var w: Widget? = Widget()
RunLoop.current.run(until: Date().addingTimeInterval(0.12))
w?.stop()
w = nil
print("w set to nil (timer invalidated before release)")
RunLoop.current.run(until: Date().addingTimeInterval(0.3))
print("done: no crash with weak self")

Run with swift widget_fixed.swift:

tick 1 (weak)
tick 2 (weak)
Widget deinit
w set to nil (timer invalidated before release)
done: no crash with weak self

No crash: invalidating the timer before releasing the object stops it from ever outliving its owner, and the weak self guard is defense-in-depth in case invalidation is ever missed on some other code path.

Trade-offs and pitfalls

unowned exists because it avoids the small overhead of optional-checking on every access, and is a legitimate choice ONLY when the captured object's lifetime is provably tied to the closure's lifetime (for example, a parent capturing a reference to itself in a closure owned by a child it fully controls and always outlives). A repeating timer scheduled on the run loop is precisely the pattern where that assumption is the LEAST safe, since the timer's lifetime is controlled by the run loop, not by the object doing the capturing, which is why [weak self] (or eager invalidation) should be the default choice for any timer-based callback.

Summary / recommendation
For a memory‑critical Android app, prefer redesign (process isolation + careful memory pools) over relying on android:largeHeap. largeHeap is a stopgap that hides problems and worsens OS-level memory pressure; use it only when impossible to refactor.

android:largeHeap — Pros / Cons

• Pros: Quick to enable; reduces immediate OOMs for large images.
• Cons: Encourages memory bloat; Android treats it per-process but overall system memory pressure increases; poorer multitasking (other apps get killed); no battery benefit — larger heaps increase GC pauses and CPU for GC, increasing energy use; hard to reason about across OEM variants.

Separate process / process isolation — Pros / Cons

• Pros: Limits blast radius (e.g., heavy image pipeline in a dedicated process); Android can kill/restart it independently; improves UI responsiveness and reduces main process OOMs. Good for background syncs or batch work.
• Cons: IPC overhead (Binder) and serialization costs; increased APK complexity, lifecycle coordination, and testing; two processes double baseline memory footprint (code and native libs), affecting overall memory and battery.

Native memory pools (NDK) — Pros / Cons

• Pros: Predictable, manual allocation (e.g., pooled bitmaps, native allocators) reduces Java heap pressure and frequent GC; can use mmap/ashmem to share buffers across processes; often lower CPU/GPU copy cost -> battery savings.
• Cons: Unsafe (leaks crash process), platform differences, debugging harder; asset lifetime must be carefully managed; increases code complexity.

Trade-offs & practical guidance

• Start by profiling (Android Studio Memory Profiler, dumpsys meminfo).
• If large allocations are transient, use pooled native buffers + Bitmap pooling (inSampleSize, BitmapFactory options, Bitmap re-use).
• Use a separate process for non-UI heavy work (e.g., worker process for transforms/sync) when isolation and restartability matter; mitigate IPC cost with shared ashmem or file descriptors.
• Reserve android:largeHeap as last resort with clear monitoring and timeboxed mitigation plan.

Maintainability / testing

• Prefer patterns that keep behavior deterministic: pool + clear contracts, small IPC surface, thorough integration tests. Document ownership of native memory and lifecycle to avoid hidden leaks.

High-level tradeoffs

• Monorepo: single source for iOS/Android + core library — easier refactors, single dependency graph, atomic changes. Downsides: larger CI surface, tooling complexity.
• Multi-repo: clear ownership, smaller checkouts, simpler per-repo pipelines. Downsides: cross-repo coordination, harder refactors, version drift.

CI design goals

• Fast feedback per team
• Run only affected builds/tests
• Safe promotion of shared artifacts
• Manage breaking API changes without blocking clients

Detect affected projects

• Use path-based change detection plus dependency graph.
• Example (PR pipeline):

git fetch origin main
git diff --name-only origin/main...HEAD > changed.txt

• Map paths to modules (core/, android/app/, ios/) and traverse module deps (Gradle / CocoaPods / SPM manifests or a precomputed graph).

Minimal builds/tests

• For each affected module run:
  • Static checks + unit tests
  • For mobile: run JVM unit tests and iOS Swift unit tests
  • Only run instrumented/emulator/real-device tests for apps or when platform-specific code changed
• Use build caching (Gradle remote cache, Bazel) and incremental compilation.

Promote shared artifacts safely

• Publish core library artifacts to internal registries (Maven for Android, binary SPM/CocoaPods for iOS) with semantic versions and metadata about source commit.
• CI flow:
  • On core-only PR: run build + full test matrix, then publish to a "canary" channel (e.g., 0.x-canary) and create a release candidate.
  • App pipelines can opt-in to canary or pin stable semver.
• Automate artifact signing and provenance.

Manage breaking API changes

• Enforce semver and require major-version bump for breaking changes.
• Provide CI compatibility job that checks downstream repos/apps by running consumer build/test against the PR branch (lightweight: unit-tests + smoke app build). Use feature flags or dual-api shims so core can keep backward compatibility for one major.
• Add linter/generator that flags incompatible changes (missing symbols, changed method signatures).
• Communicate via automated migration notes and codemods in PR.

Tooling recommendations

• Monorepo: Bazel or Gradle with composite builds + remote cache
• Multi-repo: small repo + automated cross-repo test runner (CI job that checks downstream)
• Use artifact registry, semantic release, feature flags, and automated migration tooling.

This approach keeps mobile teams independent while enabling safe, auditable shared-library evolution.

Direct answer

This isn't a single rule, it's a judgment call driven by stakes, time pressure, and whether the struggle is actually productive. My default is a graduated ladder: ask an orienting question first, then narrow the search space with a hint, and only hand over the answer if that hasn't worked or the situation doesn't allow more time.

Decision criteria

• Stakes and time pressure. A production incident, a hard external deadline, or anything safety or compliance critical pushes toward giving the answer sooner. A practice task or routine work with slack in the schedule can absorb more struggle.
• Productive vs. unproductive struggle. Productive struggle looks like forming a hypothesis, trying something, narrowing the possibilities, and making incremental progress, even slowly. Unproductive struggle looks like repeating the same failed attempt, or restating the same confusion without new information. The first is worth protecting, the second isn't.
• Type of gap. If the person is missing a concept entirely, guiding questions can circle for a long time without landing. If they have the concept but haven't applied it here, a nudge is usually enough.
• Trust and frustration level. Visible frustration that's starting to tip into disengagement is a signal to step in, even on a low-stakes task, because the cost of pushing further is now higher than the learning value.

Worked example

A mentee was stuck for a while on why a piece of work was producing an unexpected result. First move: an orienting question ("What did you expect to happen here, and where does the actual behavior diverge from that?"). They could describe the divergence but not explain it, so the second move was a narrowing hint pointing at the specific area to look at, without naming the cause. They investigated that area and found it themselves. If that hint hadn't landed, the next step would have been to explain the underlying cause directly, then ask them to restate it in their own words and apply it once more on a related case, so the session still ends with them exercising the skill rather than just receiving an answer.

Trade-offs and pitfalls

Always rescuing produces a mentee who never builds independent judgment and starts routing every decision through you. Always withholding produces frustration, slower delivery, and eventually disengagement, especially under real time pressure. A common junior mistake is judging "stuck" purely by elapsed time rather than by whether new information is being generated. A more senior habit is calibrating a default line per person (some people need more room, others need more scaffolding early on) and deliberately moving that line as the person gains experience, so the same person gets less hand-holding a year in than they did in week one.

Direct answer
I'll use Amazon's "Customer Obsession" as the example: in plain terms it means starting from the customer's actual experience and working backward to the decision, rather than starting from what's easiest or cheapest for the team and working forward to how it will land on the customer. In day-to-day work that shows up as a specific, repeatable habit: before finalizing a decision, explicitly write down what the customer will experience as a result, not just what the team will ship.

Structured elaboration

1. State the value in plain language first, in one or two sentences, before layering on any nuance. A stated value is only useful if you can restate it without jargon; if you can't, you probably don't understand it well enough to apply it.
2. Trace two or three concrete decisions the value would actually change, not just decisions it would be compatible with. The test is not "does this decision fit the value" (almost any reasonable decision can be described as fitting almost any value after the fact); the test is "would I have decided differently without this value in mind."
3. Be specific about the mechanism, not just the outcome. It's not enough to say "I'd focus on the customer"; describe the actual practice (writing the customer-facing consequence down explicitly, reviewing a metric that measures customer impact rather than only internal effort, asking a specific question in a design review) that operationalizes the value day to day.
4. Acknowledge the value has a cost or a trade-off, because a value with no real cost usually is not being taken seriously. A genuinely operative value changes what you'd otherwise have done, which means it sometimes means doing the harder or slower thing.
5. Connect it back to your own role specifically, since the same value plays out differently for different functions; the mechanism for a backend engineer, a designer, and an analyst are all different concrete practices in service of the same underlying value.

Worked example
Say you're building a dashboard intended to help a seller reduce order defects. A team NOT applying customer obsession as a working discipline might ship the dashboard once the underlying data pipeline is stable and the metrics are technically correct, treating "the data is right" as the finish line. Applying the value changes the finish line: before shipping, you'd sit with two or three actual sellers using an early version and ask what decision they're trying to make when they open it, which might surface that they need same-day defect data to catch a bad batch before it ships further, not a metric that's accurate but a day stale. The concrete decision that changes: you invest in a same-day data refresh even though it's more engineering effort than the weekly batch job you'd planned, because the customer's real decision-making need, not the easier technical path, is what determines what "done" means. The cost is real (more pipeline complexity, tighter SLAs to maintain) which is exactly why it's evidence the value is actually operative rather than decorative.

Trade-offs & pitfalls
The most common failure is reciting the value's definition fluently and then giving an example so generic it would apply to any company with any stated value ("I always think about the user"), which demonstrates you've read the careers page rather than that you understand the mechanism. A second pitfall is picking an example where the value cost nothing: if every example you give was also simply the obviously correct engineering or business call regardless of the stated value, you haven't actually shown the value did any independent work in your reasoning. A third is over-indexing on one company's specific phrasing so heavily that the answer would sound out of place at any other employer; the goal is to show you can genuinely reason from a stated principle to a concrete decision, a transferable skill, not that you've memorized one company's vocabulary.

Direct answer
Cutting a document in half without losing the point means removing words and sentences that restate, hedge, or elaborate past the level of detail the reader needs, not removing content the reader actually needs. Start by identifying the load-bearing sentences, then cut everything else, then tighten what's left.

Structured elaboration

1. Identify the load-bearing sentences first. For each paragraph, ask: if this sentence disappeared, would the reader miss information they need to act? Mark the ones that survive that test.
2. Cut whole sentences before trimming words. Removing a redundant sentence saves more length, with less risk of losing meaning, than trying to shave words from every sentence.
3. Common categories to cut entirely: sentences that restate a point already made in different words; hedging phrases ("it is worth noting that," "we believe that," "in our opinion") that add no information; background the reader already has; and process narration ("first we looked at X, then we considered Y") when only the conclusion of that process matters.
4. Convert paragraphs to lists where the content is genuinely parallel (a set of options, a set of risks); a list of five short items reads faster than one paragraph saying the same five things in prose.
5. Tighten individual sentences last: replace multi-word phrases with single words ("in order to" to "to", "due to the fact that" to "because"), and cut adjectives and adverbs that don't change the meaning.

Worked example
Before (47 words): "It is worth noting that, due to the fact that the vendor contract renewal date is rapidly approaching, we believe that it would probably be a good idea for us to schedule a review meeting sometime in the next two weeks in order to discuss next steps."

After (17 words): "The vendor contract renews soon. Let's schedule a review meeting within two weeks to decide next steps."

That's a 64% cut (47 words to 17) on this one sentence, achieved by removing three hedges ("it is worth noting," "we believe," "probably") and one restated phrase ("in order to" to "to"), not by removing any fact.

Trade-offs and pitfalls

• The risk in aggressive cutting is losing a caveat or edge case that genuinely mattered; after cutting, reread once specifically asking "did I just delete a risk or exception, not just a restatement?"
• Cutting to a target percentage (half the length) as a goal in itself can tempt you to remove real content once the easy hedges are gone; if you run out of filler before you hit the target, the document may have been genuinely that dense, and the honest move is to say so rather than cut substance to hit a number.
• Lists are faster to scan but can flatten genuine nuance between items; use them for parallel content, not for things that need qualification relative to each other.

Approach summary
I’d treat foldables as first-class layouts: detect hinge geometry, adapt to single- or two-pane UIs, and preserve context during fold/unfold transitions.

Layout strategies

• Two-pane (master-detail) for wide states: use ConstraintLayout/Compose Row with two fragments/composables.
• Hinge-aware padding: query WindowLayoutInfo and inset content around the hinge; treat hinge as non-clickable separator.
• Single-pane fallback: stack navigation on narrow/closed screens.

Continuity

• Listen for WindowLayoutInfo changes via WindowManager to animate state transitions and preserve view model/state across configuration changes. Save scroll/selection in ViewModel to restore seamlessly.

Interactions across hinge

• Disable interactive targets overlapping hinge. For drag/drop, snap or reject drops crossing hinge; use drag shadow and check hit-test against hinge bounds. For gestures, map gesture regions to avoid mid-hinge swipes.

Android APIs & UX patterns

• Use WindowManager.WindowLayoutInfo and WindowManager.registerLayoutChangeCallback (or Jetpack WindowManager). Follow foldable UX: avoid important controls on hinge, keep primary content on one pane.

Testing

• Use emulator/device configurations for multi-posture, Android foldable emulator, physical devices when possible, automated UI tests mocking WindowLayoutInfo, and manual exploratory testing for accessibility and edge cases.

Direct answer

Persuading a skeptical stakeholder starts with diagnosing what kind of resistance you're actually facing, since the same "here's more data" response only works on an evidence-based objection. A political objection or a loss-of-control objection needs a different tactic entirely.

Structured elaboration

Objection taxonomy. Naming the type of resistance before choosing a tactic is what separates a senior answer from "I showed them more data":

Worked example

Situation. At a product org, a UX team relied on manual review of every design change against brand guidelines. A design systems lead proposed an automated linting check for a subset of mechanical rules. One senior designer resisted far more strongly than the proposal's scope seemed to warrant.

Stakes. The designer's review was a required approval gate; without their buy-in, adoption could be blocked or slow-walked indefinitely, regardless of how good the tool was.

The influence moves.

• Noticed the resistance didn't track with the evidence: false-positive-rate numbers didn't move the reaction at all, which was the signal something else was going on.
• Asked directly what was underneath the resistance, and learned it wasn't about accuracy: automating the check felt like it removed the designer's voice and shrank their judgment role.
• Reframed the proposal to preserve their say explicitly: the linter would catch only mechanical rule violations (spacing, contrast ratios), routing anything subjective to the designer's review, unchanged.
• Gave the designer a visible role in defining which rules counted as mechanical versus subjective, turning them from a blocker into the rule-owner.

Resolution. The designer became the tool's internal champion once their judgment role was made explicit rather than replaced.

What a senior candidate does differently. Doesn't try to win a trust objection with more data. A mid-level answer keeps citing the false-positive rate; a senior candidate diagnoses the objection type first and matches the tactic to it.

Trade-offs and pitfalls

• Misdiagnosis wastes your strongest tool. Aiming data at a political or trust objection wastes the one resource that can't solve that problem, and can read as tone-deaf to the stakeholder.
• Political objections sometimes can't be fully resolved through the stated concern, because the real driver is unstated. A senior candidate says plainly when they suspect this is happening rather than pretending the objection was purely rational.
• Preserving a role is not the same as granting a veto. The trade is scoping what the stakeholder keeps control over, not surrendering the decision.

Situation & goal
Migrate a core resource schema (rename field + nested object restructure) with zero downtime so existing iOS/Android apps keep working.

Plan overview

1. Clarify change & constraints

   • Example: rename "user_name" → "username" and move "address: { street, city }" into "contact.address": { line1, city }.
   • Support both shapes for 3 release cycles; no forced client update.

2. API versioning + compatibility layer

   • Add new endpoint /v2/resource while keeping /v1/resource.
   • Implement server-side compatibility adapter: v2 canonicalizes new shape; v1 continues returning old shape by mapping fields (username ↔ user_name, contact.address.line1 ↔ address.street).
   • Keep both representations in responses (both keys) for a transitional period to simplify client parsing.

3. Feature flags & rollout

   • Behind a server-side feature flag per client-app-version and for internal traffic.
   • Gradually enable v2 for automation tests, internal apps, then beta users, then percentage rollouts.

4. SDK updates & client-side fallbacks

   • Release SDK update (iOS Swift/Android Kotlin) that:
     • Parses both shapes robustly (check new key then fallback to old key).
     • Exposes a migration flag in SDK to prefer new canonical model.
     • Include minor-version compatible changes, mark breaking model changes behind opt-in.
   • For apps not using SDK, provide parsing snippets and sample code.

   Example parsing (Kotlin):

   kotlin

   // try new, fallback to old
   val username = json.optString("username").ifEmpty { json.optString("user_name") }
   val street = json.optJSONObject("contact")?.optJSONObject("address")?.optString("line1")
                 ?: json.optJSONObject("address")?.optString("street")
   

5. Testing & monitoring

   • Extensive contract tests, CI against both shapes.
   • End-to-end tests for each client version.
   • Instrument metrics: error rates, parsing fallbacks used, API latency, crash logs (native).
   • Rollback plan: flip feature flag, revert to v1 responses.

6. Communication & deprecation timeline

   • Announce change 8 weeks prior: developer docs, migration guide, sample code, SDK release notes.
   • Week 0: launch v2 + SDK with dual-shape parsing; start opt-in rollouts.
   • Weeks 2–6: monitor, push SDK patches, encourage app updates (in-app messaging, Play/App Store release notes).
   • Week 8: mark v1 deprecated; keep functioning.
   • Week 16: final warning and require migration; Week 20: retire v1 (only if <0.1% clients using old shape; otherwise extend).
   • Provide fallback support and extended timeline for enterprise customers.

Why this works

• Server-side adapter + dual-key responses guarantee backward compatibility.
• Feature flags and staged rollout minimize risk.
• SDK-level parsing + clear migration docs reduce app updates friction and allow zero-downtime switch.

Direct answer

With incomplete information, I make the assumptions explicit rather than silent, act on the option that's easiest to reverse if I'm wrong, and treat speed versus caution as a question of what being wrong here actually costs, rather than a fixed personal preference for one or the other. Afterward, I go back and specifically check whether the assumption held, rather than assuming a good outcome means the assumption was right.

Structured elaboration

• Making assumptions explicit: under pressure, it's tempting to act on a gut read without naming it, which makes the assumption invisible even to yourself. Saying out loud, or writing in the incident channel, that you're assuming X and here's what changes if that's wrong, keeps the decision auditable and makes it easy to correct once better information arrives.
• Speed versus caution as a reversibility question: I weigh how easy the action is to undo if the assumption turns out wrong. A fast, easily reversible action, such as turning off a recently added code path, is worth taking on weaker evidence than a slow, hard-to-reverse one, such as deleting data or a database failover with replication risk, which deserves more caution even under time pressure.
• Choosing based on cost of being wrong, not just cost of waiting: the pressure to move fast is constant during an incident, but the right pace depends on what a wrong decision actually costs versus what a few more minutes of confirmation costs. Those aren't always the same, and conflating them leads to either reckless speed or paralysis.
• Validating or reversing afterward: once better information is available, actually go back and check the original assumption against it, rather than treating a good outcome as automatic proof the assumption was correct, since a good outcome can happen for the wrong reason.

Worked example

During an incident, a service was returning elevated error rates, and two plausible causes were in play: a recent minor configuration change, or a spike in traffic from a specific partner integration. I didn't yet have enough log detail to be certain which one it was. I made my assumption explicit in the incident channel: assuming this was the configuration change since the timing lined up closely, rolling it back now since that's fully reversible either way, and continuing to investigate the traffic angle in parallel. Rolling back the configuration change was low-risk even if I was wrong, since it just returned a value to its previous state, so I acted on partial evidence there. I deliberately didn't take the more aggressive, harder-to-reverse action available, throttling that partner's traffic entirely, since that carried real cost to a legitimate integration if my traffic-spike theory turned out wrong, and the evidence for it was weaker than for the configuration theory.

The rollback didn't fully resolve the error rate, which was itself useful information: it meant my assumption had been partially wrong, the configuration change wasn't the whole story. With that confirmed, I went back to the traffic theory with more confidence, pulled the actual request logs rather than acting on the correlation alone, and found the partner integration really was sending a malformed batch that was triggering errors on a specific code path. At that point the evidence was strong enough to justify the more aggressive, less reversible action I'd held off on earlier, so I applied a targeted rate limit to that specific partner's traffic, which resolved the remaining error rate.

Afterward I explicitly checked both original assumptions against what I'd learned rather than just closing the incident once resolved: the configuration theory had been a real contributing factor, just not the complete cause, and the traffic theory turned out to be the dominant one. Writing that down mattered, because if I'd stopped investigating the moment error rates started improving after the rollback, I'd have wrongly concluded the configuration change was the entire story.

Trade-offs and pitfalls

The common mistake is treating speed and caution as a single dial to turn up or down uniformly, when the right answer depends on how reversible each specific action is, not on a general instinct to move fast or slow. The other trap is stopping the investigation the moment things start improving, mistaking partial improvement for full confirmation of the original assumption, which can leave the actual root cause unaddressed and ready to resurface. Being explicit about assumptions also has a real cost, it takes a few extra seconds during a stressful moment, but that cost is small compared to what it saves later when someone needs to understand why a decision was made.