Junior Mobile Developer Interview Preparation Guide (FAANG Standard)

Overview & goals
Create a lightweight, prioritized onboarding bundle that gets new mobile devs building, running, and shipping a tiny change within 1–2 days, then expand to durable knowledge artifacts.

Priority 1 — Must-have docs & scripts (first 1–3 days)

• Quickstart README (2–3 steps): checkout, install SDKs, run emulator/simulator, start app, run tests, open dev menu.
• Build matrix & environment setup: Xcode / Android Studio versions, JDK, CocoaPods/Gradle, Flutter/React Native CLI, env vars.
• Shortcut scripts: bootstrap.sh / bootstrap.ps1 to install deps, sync certs, run postinstall; run-ios/run-android to launch app on simulator.
• Minimal troubleshooting: common build errors and fixes (code signing, Pod/Gradle caches).

Priority 2 — Developer workflows (days 3–7)

• Local testing guide: device lab access, test accounts, mocking tips, network proxy setup (Charles/Fiddler).
• Code review checklist and branch/release process.
• Feature-flag & config toggles doc.

Who to interview for tribal knowledge

• Lead mobile engineer (architecture, release cadence, historical hacks).
• DevOps/CI owner (signing, keystores, pipelines).
• QA/test lead (flaky tests, device coverage).
• Product/PM for critical flows and analytics events.
• Recent hire (pain points during ramp).

Automated checks & CI tasks

• Fast pre-merge: lint, typecheck, unit tests, static analyzer (Lint/SwiftLint/Detekt).
• Integration: instrumentation/e2e on device farm or emulator snapshots.
• Security/signing: validate keystore presence, check secrets not committed.
• Release pipeline: automated build artifacts, upload to TestFlight/Firebase App Distribution, smoke tests.
• Flaky-test detection and test timeouts.

Converting discoveries into durable resources

• Maintain a living onboarding repo with versioned docs and the bootstrap scripts; include a “first-day checklist” PR template.
• Record short screencasts for heavy tasks (code signing, running on device) and link transcripts.
• Add an “I learned” section to sprint retro or a rotating doc owner to keep docs current.
• Tag docs with labels: stable / needs-review / experimental and track updates in PRs.
• Pair a new hire with the knowledge owner for 2 days and require a 30‑minute doc update session after ramping.

Metrics & cadence

• Target: new hire completes first PR in <48 hours.
• Review doc usefulness monthly; fix top 3 friction points each sprint.

Investigative plan (profiling tools & steps)

• Start reproducible test: reproduce on a representative device, record a screen capture while scrolling.
• Android Studio Profiler (CPU, Memory, Energy): identify CPU spikes, GC events, allocation hotpaths.
• System tracing (Perfetto/Systrace): inspect main thread, render thread, and GPU slices; find long frames >16ms.
• Layout Inspector & View Hierarchy: detect deep/nested layouts and invisible overdraw.
• GPU Profiler / Profile GPU rendering: measure GPU frame times and overdraw.
• StrictMode / Allocation tracker / Traceview: find blocking I/O or expensive allocations during bind/onDraw.

Concrete fixes (code/architecture)

• RecyclerView optimizations:
  • Ensure proper ViewHolder reuse and implement DiffUtil to minimize binds.
  • setHasStableIds(true) when possible and implement getItemId.
  • Use viewType wisely to avoid unnecessary inflation.
• Reduce work on main thread:
  • Move image decoding, JSON parsing, layout measurement computations to background threads (Coroutines/Executors). Bind results on main thread.
  • Example: use Glide/Picasso with .override() to avoid decoding full-size bitmaps.
• Simplify views:
  • Flatten layouts (ConstraintLayout) and replace expensive nested LinearLayouts.
  • Replace custom onDraw heavy work with pre-rendered Bitmaps or cached Drawables when static.
  • Avoid allocating objects in onBindViewHolder/onDraw; reuse Paint, Path, Rects.
• Use view layering strategically:
  • Use setLayerType(LAYER_TYPE_HARDWARE) for complex static content; remove for animated content to avoid GPU stalls.
• Defer non-critical work:
  • Use placeholders and progressive rendering; prefetch data and images (RecyclerView Preloader).
• Minimize overdraw:
  • Remove unnecessary backgrounds; enable “Show GPU overdraw” and fix.

Metrics to track

• Frame time distribution: 95th / 99th percentile frame time <=16ms target.
• Jank count / dropped frames per scrolling session.
• Main thread busy time during scroll (ms).
• GC frequency and heap allocations per scroll.
• GPU usage and overdraw count.

Validation & iteration

• After each change, run automated scroll trace (adb shell input swipe / Espresso macros) and compare Perfetto traces and profiler metrics.
• Prioritize fixes that reduce main-thread time and allocations first — those usually yield largest jank reduction.

Compare CRDTs vs OT (brief, mobile-focused)

• CRDTs

  • Convergence via mathematically commutative/associative/ idempotent ops or state merges; works well with unreliable mobile networks and offline-first apps because merges are safe after partitions.
  • Simpler client logic: local updates always allowed; sync uses merge/replicate; good for per-device state (counters, sets, maps).
  • Trade-offs: some semantics harder (list/position-aware editing), metadata overhead (per-replica state).

• Operational Transformation (OT)

  • Transforms concurrent operations against each other to preserve intention (used in collaborative text editors).
  • Requires operation history, central ordering or agreement protocol; more complex to implement on mobile (synchronization, transformation functions, undo/redo).
  • Trade-offs: better at preserving user intent for linear structures (text), but harder under mobile churn and partitions.

For mobile apps I prefer CRDTs for offline-first sync and simpler client code; use OT when exact edit intentions for shared rich text matter and you can maintain reliable coordination.

G-Counter (state-based) — Kotlin implementation

// G-Counter: grow-only counter per-replica; merge = pointwise max
data class GCounter(private val counts: MutableMap<String, Long> = mutableMapOf()) {

    // increment local replica by 1 (or delta)
    fun increment(replicaId: String, delta: Long = 1L) {
        require(delta >= 0)
        counts[replicaId] = (counts[replicaId] ?: 0L) + delta
    }

    // merge another replica's state into this one (in-place)
    fun merge(other: GCounter) {
        for ((id, value) in other.counts) {
            val local = counts[id] ?: 0L
            counts[id] = maxOf(local, value)
        }
    }

    // total value across replicas
    fun value(): Long = counts.values.sum()
    
    // snapshot/copy for sending over network
    fun snapshot(): Map<String, Long> = counts.toMap()
}

Explanation, complexity, edge cases

• Why merge works: each replica keeps monotonically increasing per-replica counters; taking max ensures no double-counting and commutativity/associativity/idempotence.
• Time: increment O(1); merge O(n) where n = number of replicas present in states; space O(r).
• Edge cases: replica id collisions (use UUIDs), clock resets (avoid by only incrementing local counter), deletions not supported (G-Counter is grow-only). For mobile, compress maps, garbage-collect stale replica entries, and sign/verify replica ids for security.

Direct answer

Say the gap out loud early and plainly to the team, rather than quietly trying to fake competence, then take a few fast, targeted steps to get just enough working knowledge to be useful, not to become an expert, and before relying on that understanding for anything consequential, check it against someone who actually knows the area or against a small, low-stakes test.

Structured elaboration

• Acknowledging the gap. Say it directly and specifically, "I haven't worked with this before, give me a bit to get oriented," or "I don't know this tool, but here's my plan to get up to speed," rather than staying vague or implying more familiarity than you have. Framing it as a plan, not just an admission, keeps the team's confidence that the work will still get done.
• First concrete steps. Start narrow and targeted at what the current task actually needs, not a full deep dive: read the specific documentation or code relevant to the task, find the smallest reproducible example, and if possible find someone on the team who's used it before and ask a focused question rather than starting from zero alone.
• Validating understanding before moving forward. Don't trust the new understanding blindly; test it in a low-stakes way first, a small script, a scoped experiment, a quick review of the plan with someone experienced, before applying it to something that matters. If something is genuinely high-stakes, explicitly ask someone more experienced to sanity-check the plan before executing it, not just the result after.

Worked example

Assigned to add a feature that touches a message queue technology never used before, the first step is telling the team lead directly: "I haven't used this before, I'm going to spend the morning on the docs and a small test, then check in." Concrete steps: read the specific section of documentation relevant to the exact pattern needed, write a small standalone script that publishes and consumes a test message to confirm the basic mechanics work as expected, and ask a teammate who's used it before one specific question about a gotcha they might already know about, such as message ordering guarantees. Before building the actual feature on top of that understanding, the planned approach gets walked past that teammate in five minutes: "here's how I'm planning to use it, does this match how it's used elsewhere in the codebase?" Only after that quick validation does the real feature get built.

Trade-offs and pitfalls

Pretending familiarity to avoid looking behind usually surfaces later as a mistake that's more expensive to catch. Going too deep too early, reading an entire manual before writing anything, delays delivering when a narrower, task-focused ramp-up would have been enough. Never validating the new understanding against anyone else risks discovering a misunderstanding only once it's already built into something bigger. And over-communicating every small uncertainty in a way that makes the team lose confidence rather than build it is also a risk; the acknowledgment should come with a plan, not just an admission.

I’d start by aligning everyone on the outcome, not the function-specific asks.

Step 1: Clarify the shared goal
I’d bring product, design, data, and engineering into one working session and define the business outcome, success metrics, and deadline constraints.

Step 2: Map dependencies and capacity
I’d list the critical dependencies, identify who owns each one, and make capacity visible by function. That exposes where the real bottlenecks are.

Step 3: Sequence the plan
I’d build the plan around the critical path: what must happen first, what can run in parallel, and what can be deferred. If capacity is tight, I’d use a simple trade-off framework: highest business value, lowest risk, and strongest dependency unlocks first.

Step 4: Create commitment
I’d confirm decision rights, document what each team is committing to, and define checkpoints where we can re-plan if assumptions change.

The goal is not to make everyone equally happy; it’s to make the trade-offs explicit so each group can commit to a plan they helped shape.

Worked example
Say the initiative is a checkout redesign that needs a payments-data migration (data team), a new UI (product design and frontend), and an updated fraud-detection model (data science). In the working session, the shared goal turns out to be reducing checkout abandonment by a set amount before the next major sales event, which becomes the deadline constraint. Mapping dependencies shows the new UI can't ship until the data migration completes, and the fraud model needs at least two weeks of production traffic on the new UI before it can be retrained safely, so the data migration is the critical-path item. Applying the trade-off framework, the data migration (highest dependency-unlock value) is sequenced first, the UI ships second, and the fraud-model update is explicitly deferred to just after the sales event rather than rushed; each team commits to that sequence in writing, with a checkpoint two weeks before launch to re-plan if the migration slips.

High-level approach
Design a client that treats GraphQL ops as small stable identifiers (persisted queries) + lightweight runtime variables, uses batching and in-flight deduplication, holds a normalized on-device cache, applies optimistic mutations locally, and minimizes CPU/network by offloading heavy work to background threads and using compact serialization.

Persisted queries

• Server stores full query text indexed by a sha256 hash.
• Client sends { id: "<sha256>", variables } instead of full text. Fallback: if server returns unknown-id, resend full text and register.
• Benefit: reduces bytes on cellular and avoids long URL bodies on low MTU.

Batching & transport

• Batch window (e.g., 10–50ms or until N ops) to combine small ops into one HTTP/2 multiplexed request or a single POST.
• Use HTTP/2 or HTTP/3 for multiplexing to reduce connection overhead.
• Limit batch size and payload to avoid tail latency on low-end devices.

Request deduplication

• Maintain an in-flight map keyed by (operation id + variables hash). If identical request in-flight, return same promise/future.
• Cancelation tokens propagate so UIs can drop interest without aborting shared in-flight network if others still need it.

Normalized cache

• Normalize by __typename + id; store as compact binary (protobuf/MessagePack) or platform-native binary blobs to reduce parsing cost and memory.
• Use LRU eviction, size quotas, and TTL per type. Run GC off main thread.
• Provide fast lookup for queries via selection-set-aware reads to minimize recomputation.
• Persist cache to disk in batches to avoid frequent I/O.

Optimistic mutations & offline

• Apply optimistic update to normalized cache with temporary client-side IDs; enqueue mutation in durable queue.
• Retry/commit in background when network returns; on conflict, reconcile using server response + merge policies.
• Expose rollback hooks and partial success patterns.

Minimizing CPU & network on low-end devices

• Serialize/deserialize on background threads; use streaming parsers (e.g., kotlinx.serialization streaming / Swift Codable with background queue).
• Avoid repeated re-normalization: compute diffs and patch cache.
• Compress transport (gzip/ Brotli) and use binary encodings for cache payloads.
• Use delta-fetch / conditional requests (If-None-Match) where possible.
• Throttle syncs on battery saver / low-memory; prefer Wi-Fi for large payloads and schedule background syncs with OS job schedulers (WorkManager / BGTask).
• Provide adaptive behavior based on connectivity (metered) and device class.

Example pseudocode (dedupe + persisted)

// Kotlin-like pseudocode
val key = sha256(opId + variablesHash)
if (inFlight.contains(key)) return inFlight[key]
val req = buildRequest(persistedId = opId, variables)
val call = httpClient.send(req)
inFlight[key] = call
call.onComplete { inFlight.remove(key) }
return call

Trade-offs

• Persisted queries require server coordination and deployment discipline.
• Batches reduce overhead but can increase tail latency; tune window per app patterns.
• Normalized caching increases complexity but yields huge savings on re-renders and network.

This architecture optimizes for low bandwidth, intermittent connectivity, and resource-constrained devices while preserving correctness and developer ergonomics.

Direct answer
In sixty to ninety seconds, state what the work was and the concrete outcome in the first sentence, then use the remaining time to give just enough context for the outcome to make sense, without narrating the full journey.

Structured elaboration

1. Lead with outcome, not chronology. Start with what changed as a result of the work, not "so first we looked into..."; the listener's attention is highest in the first five seconds, so spend it on the punchline, not the preamble.
2. Give one sentence of context, just enough for a listener unfamiliar with the project to understand why the outcome mattered.
3. Name the concrete result. A number, a capability that now exists, or a problem that's now solved, stated plainly rather than hedged.
4. Leave a natural opening for a follow-up question, rather than trying to cram in every detail; a pitch that answers every possible question leaves nothing for the listener to ask, which can feel like a wall rather than a conversation.
5. Practice against a clock. Sixty seconds is shorter than it feels; a written script read at a natural pace is the fastest way to find out where it actually runs long.

Worked example
"I led the project to move our nightly batch reports to a real-time pipeline. Before this, finance waited until 9am for the previous day's numbers; now they're available within about five minutes of the event happening. It took about six weeks and meant migrating three internal tools onto the new pipeline, which is the part I'm happy to go deeper on if useful."

Outcome and its concrete magnitude come in the first two sentences (roughly 9am wait to about five minutes), then one sentence of scope, then an explicit invitation to go deeper rather than continuing to add detail.

Trade-offs and pitfalls

• The most common failure is starting with the setup ("so basically what happened was...") instead of the outcome, which spends the highest-attention seconds on the least important part.
• Cramming in every detail to sound thorough usually makes the pitch run long and diluted; a pitch that leaves a natural question is often more effective than one that tries to be exhaustive.
• Precision matters more than the exact wording; if you don't have a hard number, say so honestly ("noticeably faster, though I don't have an exact percentage") rather than inventing a specific-sounding figure you can't back up.

Direct answer

Get both teams in the same room with concrete evidence of the overlap, not each team's assumption about who owns what, agree on a single ownership model for the disputed piece, write it down somewhere both teams will actually find later, and set a lightweight recurring check so the boundary does not quietly drift back into ambiguity.

Structured elaboration

Start with evidence, not opinion

Map the actual overlap: which capability, which parts of the system, which decisions each team has been making independently. A short, concrete inventory, such as "both teams modified this component in the last quarter, for these reasons," turns a "whose job is this" argument into a shared problem to solve.

Choose an ownership model, do not just split the difference

Common options: one team owns it fully and the other is a client of it, ownership is split along a clear seam such as by data domain or by interface, or the piece gets consolidated into a single shared service with one clear owner. Whichever you pick, the test is whether a new engineer joining either team could read the agreement and know who to ask.

Write it down where it will be found

A decision made in a meeting and never documented decays within a sprint. Put the ownership boundary in the same place engineers already look, such as a README, a service catalog, or an API contract doc, not a one-off meeting note.

Set a recurring, lightweight check

A short standing sync between the two teams for boundary-crossing changes, or a simple rule that any change to the shared piece pings both teams, is enough to catch drift early without adding heavy process.

Worked example

Two teams both maintain code that retries failed requests to a downstream service, each having added its own retry and backoff logic independently over time. The overlap surfaces when a production incident review shows both teams' logic firing on the same failure and compounding retry pressure on the downstream service.

The teams map the overlap and find one team's logic lives in a shared client library, while the other's is inline in their own service and duplicates the same behavior. They agree the shared library should be the single source of retry logic, with the other team's inline logic removed and replaced by a call to the library. They write this into the library's README as "owned by Team A, changes to retry behavior require a ping in the shared channel," and add a short section to each team's onboarding doc pointing new engineers at the library first. They also add a lightweight rule: any pull request touching retry or backoff logic in either codebase gets a reviewer from the other team tagged automatically.

Trade-offs and pitfalls

Consolidating too aggressively can overstep a team's actual mandate and create a bottleneck if the new sole owner becomes a blocker for changes the other team needs quickly. Splitting too finely, dividing by an overly granular seam, creates new edge cases at the new boundary instead of removing them.

The common failure mode is not picking the wrong model, it is skipping the documentation and recurring-check steps because the meeting felt like it resolved things. Verbal agreements between the two people in the room do not survive a reorg or a new hire; only a written, discoverable agreement does.

Four things, at minimum: a machine-parsable error CODE (a stable string a client can branch logic on), a human-readable MESSAGE (for logging and debugging, never for client branching logic), a correlation or trace ID (so a developer can find this exact request in server-side logs), and a documented mapping from error codes to HTTP status codes so the status line and the body agree on what actually happened.

Why each field earns its place

Error code, not just a status code. HTTP status codes are coarse (a 400 covers many different validation failures); a specific, stable string like insufficient_inventory lets a client write real logic ("if this specific error, show the user a restock message and offer alternatives") instead of parsing a human-readable sentence, which is fragile and can change wording without warning.

A message meant for humans, not machines. The message field exists for logs, support tickets, and developer debugging; a client should never regex-match against it to decide behavior, because message wording is exactly the kind of thing that changes without being treated as a breaking change.

A correlation ID. When a client reports "I got an error," the correlation ID is what lets an engineer find the exact request in server-side logs in seconds instead of guessing based on approximate timestamps.

A stable status-code mapping. insufficient_inventory should map to the same HTTP status every time (409 Conflict is a reasonable choice here, since it reflects a state conflict rather than malformed input), documented so both server and client code agree on the mapping rather than each side guessing.

Worked example

{
  "error": {
    "code": "insufficient_inventory",
    "message": "Only 3 units of sku_1001 are available.",
    "correlation_id": "req_8f2c9a1e",
    "retryable": false
  }
}

This example is 145 bytes as compact JSON. A client parses this programmatically by checking error.code === "insufficient_inventory" (stable, documented) to decide its own behavior (offer the customer 3 units instead of the requested 5), logs error.correlation_id for later debugging if the customer files a support ticket, and displays a localized version of its OWN copy for that error code to the end user rather than showing error.message directly (which is written for a developer audience, in one language, and not meant for end-user display).

Trade-offs and pitfalls

The most common mistake is putting only a human-readable message in the error body and expecting clients to parse it for meaning; the moment that message's wording changes (even a small rewording meant purely to be clearer for humans), any client parsing it silently breaks. A second common mistake: reusing the SAME error code for conceptually different failures because they happen to produce the same HTTP status, which forces clients back to string-matching the message anyway to tell them apart, defeating the entire purpose of having a code field.

Overview (why this matters)
I build UIs that look crisp and consistent across devices by relying on density‑independent units and proper assets. Below I compare platforms, show conversion math for a 1080×1920 device with devicePixelRatio = 3, and give practical rules for assets and pitfalls.

Platform mappings

• Android: dp (density‑independent pixels) for layout, sp for text (scales with user font-size setting). System maps dp → px by multiplying with device density (scale).
• iOS: points (pt). 1 pt maps to 1× or 2×/3× device pixels depending on scale factor (@1x, @2x, @3x).
• Flutter: uses logical pixels (same idea as dp/pt). Flutter’s devicePixelRatio multiplies logical → physical pixels.
• React Native: layout units are density‑independent (like dp); PixelRatio.get() gives scale to map to physical pixels.

Conversion formulas

px = dp * density
dp = px / density

Plain-intuition: divide physical pixels by DPR to get density‑independent size.

Example for 1080 x 1920, devicePixelRatio = 3:

• width in dp/pt/logical px = 1080 / 3 = 360
• height in dp/pt = 1920 / 3 = 640

Choosing raster vs vector

• Vector (SVG/PDF/ShapeDrawable): use for icons, logos, simple illustrations — scales perfectly, small size for many densities.
• Raster (PNG/JPEG/WebP): use for photos or complex artwork. Provide multiple scaled assets.

Preparing icons & splash screens

• Android densities: provide mdpi (baseline = 1x), hdpi (1.5x), xhdpi (2x), xxhdpi (3x), xxxhdpi (4x). If design icon is 48dp (baseline mdpi = 48px), produce:
  • mdpi: 48px
  • hdpi: 72px
  • xhdpi: 96px
  • xxhdpi: 144px
  • xxxhdpi: 192px
• iOS: provide @1x, @2x, @3x PNGs. For a 44pt icon:
  • @1x: 44px, @2x: 88px, @3x: 132px
• Flutter/React Native: include images for 1x/2x/3x (or use vector). Put correctly named files or specify asset variants.

Bitmap scaling pitfalls & text legibility

• Upscaling bitmaps causes blurring/artifacts; always supply higher-resolution source and downscale (not the reverse).
• Treat text as text (use fonts) instead of baked into images to preserve sharpness and accessibility (scales with accessibility settings).
• Beware of relying on devicePixelRatio alone: different devices may have same DPR but different physical sizes/DPI; test on small high‑DPI phones and large tablets.
• Use fractional dp cautiously—round to pixel boundaries when rendering bitmaps to avoid subpixel blur.

I typically prefer vectors for UI chrome and multiple raster sizes for complex images; always test on 1×, 2×, 3× devices and verify text scaling under accessibility settings.