Meta Mid-Level Mobile Developer Interview Preparation Guide

Approach
Use recursion with backtracking. A path sum is the sum of values from the root to a leaf. Because node values can be negative, I would not prune when the running sum gets too large, since later negative values could bring it back down.

def has_path_sum(root, target_sum):
    def dfs(node, remaining):
        if node is None:
            return False

        remaining -= node.val
        if node.left is None and node.right is None:
            return remaining == 0

        return dfs(node.left, remaining) or dfs(node.right, remaining)

    return dfs(root, target_sum)

Worked example
For the path 5 -> 4 -> 11 and target 20, the recursion checks 20 - 5 = 15, then 15 - 4 = 11, then 11 - 11 = 0, so it returns True.

Why backtracking is enough
Each recursive call gets its own remaining value, so there is no shared state to clean up. The function explores one root-to-leaf path at a time and stops as soon as it finds a match.

Complexity
Time is O(n) in the worst case, and space is O(h) for the recursion stack, where h is tree height.

Approach summary
I’d attack memory pressure with a mixture of reuse, smaller footprints, device-aware limits, and heavier disk use. Each technique trades latency, complexity, or compatibility for lower RAM usage.

Bitmap pooling (inBitmap / reuse)

• What: Reuse existing mutable bitmaps via BitmapFactory.Options.inBitmap or Glide’s bitmap pool.
• Benefits: Fewer allocations, fewer GC spikes on heap; reduces churn.
• Trade-offs: Only works when sizes/configs match (or supported on newer APIs with flexible byte reuse). Requires careful lifecycle management to avoid accidental mutation/visual bugs. Slight complexity integrating with libraries and different Android versions.

Hardware bitmaps

• What: Use Bitmap.Config.HARDWARE (API 26+), GPU-backed immutable bitmaps.
• Benefits: Offloads memory from Dalvik/ART heap into GPU/native memory; near-zero GC pressure.
• Trade-offs: Immutable (no inBitmap reuse), can't be read/write on CPU, higher native memory usage can still lead to OOM on devices with limited native memory. Only for API 26+, and may increase upload latency for frequent draw-to-bitmap operations.

Downsampling / resizing

• What: Decode at target display size (inSampleSize, inTargetDensity) or downscale images server-side.
• Benefits: Biggest ROI — reduces bytes per image, lowers both heap and native usage.
• Trade-offs: Lower visual quality if over-downsampled; extra work to choose correct size per density/view; possible CPU cost for runtime scaling, but negligible compared to memory savings.

Limit memory cache by device class

• What: Detect device RAM/class (ActivityManager.getMemoryClass / largeMemory) and throttle cache size (e.g., Glide’s LruResourceCache).
• Benefits: Prevents a one-size-fits-all cache from OOMing low-end devices.
• Trade-offs: Smaller cache = more network/disk IO and potential jank when reloading images. Needs tuning and device profiling.

Use disk cache more aggressively

• What: Keep lower-res thumbnails or evict rarely-used bitmaps to disk cache; prioritize in-memory for visible items only.
• Benefits: Lowers memory footprint; disk reads are slower but avoid OOMs.
• Trade-offs: Increased IO, possible user-visible latency; requires good async loading and progressive placeholders.

Practical combination (example)

• Resize to view size on decode, use inBitmap pool for same-size mutable configs on API <26, prefer hardware bitmaps for static, large images on API >=26, cap memory cache based on memoryClass, and store originals/alternates on disk. Profile with Android Profiler and test on low-end devices.

This balanced strategy minimizes GC and OOM risk while keeping UX acceptable; tuning depends on image patterns and device fleet.

Overview
I would build a deterministic, programmable fuzz harness that drives both the client-side sync engine and a mock server, injecting mutated operations and network faults to exercise concurrent local edits and partitions. The harness runs on CI with device/emulator targets and records full traces for repro.

Mutation strategies

• Operation-level:
  • Randomized create/update/delete/text-char-insert/replace/merge for objects and CRDT ops.
  • Parameter mutations: timestamp skew, out-of-order sequence numbers, truncated payloads, malformed fields.
  • Composite bursts: rapid local edits to same object with small pauses.
• Heuristics:
  • Weighted sampling of real production edit traces.
  • Guided mutations to target rare code paths (coverage feedback).

Network fault injection

• Latency: variable per-packet/persistent delay distributions (normal, heavy-tailed).
• Reorder: shuffle message queue windows.
• Drop: probabilistic drop, conditional drop (specific message types).
• Partition: isolate client subset for configurable durations then heal with queued delivery.
• Loss patterns: packet-loss bursts, channel-specific (sync vs push).

Invariants to assert

• Convergence: final state across clients and server equivalent (allowing permitted conflict-resolution nondeterminism).
• Causality: no forever-missing causal dependencies.
• Durability: acknowledged writes eventually visible after reconnection.
• No data corruption: schema validation, checksum matches.
• Semantic invariants: app-level constraints (e.g., unique IDs).

Reproduction & Minimization

• Deterministic seeds: seed RNGs and record all seed/state.
• Event logging: append-only trace of operations, network events, timing.
• Replay harness: deterministic scheduler replays events on emulator/device.
• Delta-debugging: binary search over event subsequence to find minimal failing trace.
• Snapshots/checkpoints: capture client DB and server state at key points to fast-forward replays.

Implementation notes

• Use a harness written in Kotlin/Swift or Node test runner with ADB/xcuitest orchestration.
• Expose hooks in sync engine for deterministic clocks and injectable transport layer.
• Integrate with CI, coverage, and issue triage: auto-create bug reports with trace, minimized repro and device/emulator config.

This approach surfaces correctness bugs from timing, partitions, and concurrent edits while providing deterministic, minimized repros for debugging.

Situation: I worked closely with a partner who was strong technically but often changed direction late, which was creating churn for the rest of the team.

Task: I needed to give difficult feedback without damaging trust.

Action: I chose a private conversation and used the SBI format, which means Situation, Behavior, Impact. I said, "In yesterday's planning meeting, when the scope changed after we had already aligned with design, it created rework and made the team less confident in the plan." I kept the tone factual, then asked what was driving the change. It turned out they were reacting to pressure from another stakeholder and had not surfaced it earlier. We agreed they would flag uncertainty sooner and bring changes through planning instead of in the middle of execution.

Result: The conversation was uncomfortable, but it improved our working relationship because it was specific and fair. Their behavior became more predictable, and the team trusted them more because expectations were clearer.

Overview
LiveData, Kotlin Flow and RxJava each model async streams but target different needs: LiveData is Android-UI-centric, Flow is Kotlin-coroutine-native, RxJava is feature-rich reactive library.

Lifecycle-awareness

• LiveData: built-in lifecycle-aware — observers auto-start/stop with LifecycleOwner (Activity/Fragment).
• Flow: not lifecycle-aware by default; use lifecycleScope and lifecycle.repeatOnLifecycle to collect safely.
• RxJava: not lifecycle-aware; requires manual disposal or use AutoDispose / Lifecycle-aware extensions.

Hot vs Cold

• LiveData: hot — keeps latest value; observers receive current state.
• Flow: by default cold (Flows start on collect). SharedFlow/StateFlow provide hot behavior (StateFlow ~ LiveData).
• RxJava: supports both; Observable/Flowable can be hot or cold depending on source and Subjects.

Backpressure

• LiveData: no backpressure semantics — suitable for UI events/state.
• Flow: has structured backpressure via suspending emissions and operators (buffer, conflate, collectLatest).
• RxJava: Flowable offers backpressure strategies; Observable lacks built-in backpressure.

ViewModel & UI threading

• LiveData: pairs naturally with ViewModel; postValue/setValue handle main thread concerns.
• Flow: use viewModelScope to emit on Dispatchers.IO and collect on Dispatchers.Main; operators like flowOn, withContext manage threads.
• RxJava: use subscribeOn/observeOn; integrate with ViewModel but manage disposables.

When to prefer

• LiveData: simple UI state, minimal setup, lifecycle safety (small apps).
• Flow/StateFlow: coroutine-native, testable, better for complex async pipelines, prefer when using coroutines.
• RxJava: existing Rx-heavy codebase or need advanced operators, multicasting, backpressure control; otherwise Flow is lighter for new Android projects.

Example: for continuous sensor data with sampling and backpressure -> Flow with buffer/conflate or RxJava Flowable; for UI form state -> LiveData or StateFlow.

Direct answer

A hash table built with open addressing stores every entry directly in one flat array; on a
collision it probes forward (here, linearly) to the next slot, uses a tombstone marker (not a bare
None) for deleted entries so later probes don't stop early, and resizes once the load factor
crosses a threshold.

Structured elaboration

Three distinct slot states, not two. A naive implementation might track only "empty" and
"occupied," but deletion needs a third state: tombstone (previously occupied, now deleted). A
probe sequence must treat a tombstone as "keep looking, something later might still be the key I
want" while treating true emptiness as "stop, the key definitely isn't here." Confusing these two is
the single most common open-addressing bug: without tombstones, deleting an entry mid-probe-sequence
can make a later, still-present key silently unreachable.

Insertion. Probe from hash(key) % capacity, remembering the first tombstone slot seen (so a
successful insert reuses it rather than always walking to a brand-new empty slot); stop at the key
itself (update in place) or at a true empty slot (place there, using the remembered tombstone slot
if one was seen along the way).

Resizing. The load factor check should count tombstones toward the trigger (not just live
entries), since a table full of tombstones is just as slow to probe as one full of live entries, and
a resize is exactly what clears all tombstones out (it rebuilds the table from scratch with only the
live entries, since insertion during a resize never needs to place a tombstone).

Worked example

_TOMBSTONE = object()

class OpenAddressingHashMap:
    def __init__(self, initial_capacity=8):
        self._capacity = initial_capacity
        self._used = 0
        self._keys = [None] * self._capacity
        self._values = [None] * self._capacity

    def _probe(self, key):
        idx = hash(key) % self._capacity
        first_tombstone = None
        for _ in range(self._capacity):
            slot = self._keys[idx]
            if slot is None:
                return (first_tombstone if first_tombstone is not None else idx), False
            if slot is _TOMBSTONE:
                if first_tombstone is None:
                    first_tombstone = idx
            elif slot == key:
                return idx, True
            idx = (idx + 1) % self._capacity
        return first_tombstone, False

    def put(self, key, value):
        if self._used / self._capacity >= 0.7:
            self._resize(self._capacity * 2)
        idx, found = self._probe(key)
        if not found and self._keys[idx] is None:
            self._used += 1
        self._keys[idx] = key
        self._values[idx] = value

    def get(self, key):
        idx, found = self._probe(key)
        return self._values[idx] if found else None

    def delete(self, key):
        idx, found = self._probe(key)
        if not found:
            return False
        self._keys[idx] = _TOMBSTONE
        self._values[idx] = None
        return True

    def _resize(self, new_capacity):
        old_keys, old_values = self._keys, self._values
        self._capacity, self._used = new_capacity, 0
        self._keys, self._values = [None]*new_capacity, [None]*new_capacity
        for k, v in zip(old_keys, old_values):
            if k is not None and k is not _TOMBSTONE:
                self.put(k, v)

t = OpenAddressingHashMap(initial_capacity=4)
t.put("a", 1); t.put("b", 2); t.put("c", 3)
print("capacity after 3 inserts:", t._capacity)
print(t.get("a"), t.get("b"), t.get("c"))
t.delete("b")
print("get('b') after delete:", t.get("b"))
t.put("d", 4)                       # reuses b's tombstone slot
print(t.get("d"), t.get("a"), t.get("c"))
for i in range(20):
    t.put(f"k{i}", i)
print("capacity after 20 more inserts:", t._capacity)
print("k17 ->", t.get("k17"))

Running this prints: capacity after 3 inserts: 4 (2/4 = 0.5 was below the 0.7 threshold when "c" was
inserted, so no resize fired yet), then 1 2 3 (all three retrievable), then
get('b') after delete: None (confirms deletion), then 4 1 3 ("d" correctly reused "b"'s freed
slot while "a" and "c" remained untouched), then capacity after 20 more inserts: 32 (several
doublings: 4 -> 8 -> 16 -> 32 as load crossed 0.7 repeatedly), then k17 -> 17 (every key survived
all those resizes correctly).

Trade-offs and pitfalls

The two bugs that actually break this in practice: (1) clearing a deleted slot to None instead of
a tombstone, which silently breaks lookups for any key whose probe sequence passed through that slot;
(2) checking load factor using only live entries (ignoring tombstones), which lets a
delete-heavy workload accumulate tombstones until probing degrades toward O(capacity) even though the
live entry count looks small, exactly why the trigger above uses _used (live entries and
tombstones combined), not a live-only count.

Direct answer

Notice it during normal work rather than a special investigation, scope a fix small enough to do without asking, fix the actual root cause rather than the symptom, and tell the team what changed and why so the fix is visible rather than buried in a commit.

Structured elaboration

1. Discovery usually happens incidentally: while doing assigned work, you hit something off, a flaky test everyone re-runs, a script everyone has a manual workaround for, that is outside your actual ticket.
2. Scope the fix to what you can safely do inside your own access and time without needing approval, because the change is small, contained, and does not touch anyone else's active work.
3. Fix the actual cause: spend the extra time to find why it is happening rather than patching the symptom, re-running until it passes, adding a longer timeout, which just delays the same failure.
4. Keep people informed: a short note in the team channel or pull-request description saying what was broken and what changed, so teammates do not independently rediscover the same thing later.
5. Measurable outcome: something concrete that changed as a result, fewer reruns needed, less time lost per week, even if the number is modest.

Worked example

A shared integration test suite failed intermittently, and the team's habit was to re-run the whole suite until it passed, costing a few extra minutes each time and adding up across a team running it many times a day. Digging in during downtime between tickets uncovered the real cause: two tests shared a test fixture, a piece of setup data, and ran in a nondeterministic order, so one test occasionally read data the other had not finished writing, a race condition, a bug where the outcome depends on timing that is not guaranteed. Isolating the fixture per test so each test owned its own data, the fix went out as a small pull request with the root cause noted in the description, so reviewers understood it was not just a timeout bump. After the fix, the suite's flaky reruns, which had been happening roughly half a dozen times a day across the team before the fix, dropped from that regular daily occurrence to about once every couple of weeks over the following month.

Trade-offs and pitfalls

A common wrong turn is patching the symptom, retry logic, a longer timeout, because it is faster, which hides the same bug until it resurfaces somewhere less convenient. Another is fixing it silently without telling anyone, so the team never learns what was actually wrong and cannot recognize the same pattern next time. Also watch scope: a fix this small does not need permission, but if it had required touching shared infrastructure other teams depended on, the right move would have been to flag it first rather than just changing it.

Direct answer
A lightweight structure needs three ingredients: a small, predictable time commitment (a fixed cadence, not open-ended availability), a place where knowledge accumulates outside people's heads, and two or three signals you actually look at instead of a heavy program. Keep it low-overhead by reusing rituals the team already has, like code review, rather than inventing new meetings.

Structured elaboration: the components

Worked example
For a four-person team, a three-week rotation covers every unique pair exactly once: week one pairs A-B and C-D, week two pairs A-C and B-D, week three pairs A-D and B-C, then the cycle repeats. If each pairing block is 45 minutes, the weekly time cost per person is one session, 45 minutes, or 0.75 hours a week, plus roughly 15 to 20 minutes a month writing up notes. That puts the total time cost under an hour a week per person, small enough that it does not meaningfully compete with deliverable time, and it is a claim that can be checked against the actual calendar rather than taken on faith.

Trade-offs & pitfalls
The temptation is always to add more: formal training modules, a matching algorithm, quarterly surveys. A program with more infrastructure than the team has bandwidth to sustain decays within a few weeks. The senior distinction here is that a junior design assumes more structure is always better, while a senior deliberately underbuilds and only adds structure once a specific signal shows it is needed. A second pitfall is shared docs going stale because nobody owns freshness; assign light rotating ownership (whoever paired last updates the relevant page) rather than creating a separate docs-owner role, which is more overhead, not less. A third pitfall is picking the wrong rotation speed: too fast and no pair builds enough context to go deep; too slow and some people never get exposure to others. Match the cycle length to team size so everyone pairs with everyone within one cycle, as in the rotation above.

Approach (brief)
Use a Dictionary<Key, Node> for O(1) lookups and a doubly-linked list to maintain recency (head = most-recent, tail = least-recent). Each Node stores key, value, cost (e.g., image byte size). Track totalCost and evict from tail until under capacity.

Swift implementation (core logic)

final class LRUCache<Key: Hashable, Value> {
    private class Node {
        let key: Key
        var value: Value
        var cost: Int
        var prev, next: Node?
        init(key: Key, value: Value, cost: Int) {
            self.key = key; self.value = value; self.cost = cost
        }
    }

    private var map = [Key: Node]()
    private var head: Node?
    private var tail: Node?
    private var totalCost = 0
    private let capacityCost: Int

    init(capacityCost: Int) { self.capacityCost = capacityCost }

    private func moveToHead(_ node: Node) {
        guard head !== node else { return }
        // unlink
        node.prev?.next = node.next
        node.next?.prev = node.prev
        if tail === node { tail = node.prev }
        // insert at head
        node.next = head
        node.prev = nil
        head?.prev = node
        head = node
        if tail == nil { tail = head }
    }

    private func insertAtHead(_ node: Node) {
        node.next = head; node.prev = nil
        head?.prev = node; head = node
        if tail == nil { tail = head }
    }

    private func removeTail() -> Node? {
        guard let node = tail else { return nil }
        map[node.key] = nil
        totalCost -= node.cost
        if head === tail {
            head = nil; tail = nil
        } else {
            tail = node.prev
            tail?.next = nil
        }
        return node
    }

    func get(_ key: Key) -> Value? {
        guard let node = map[key] else { return nil }
        moveToHead(node)
        return node.value
    }

    func put(_ key: Key, value: Value, cost: Int = 1) {
        if let node = map[key] {
            totalCost -= node.cost
            node.value = value
            node.cost = cost
            totalCost += cost
            moveToHead(node)
        } else {
            let node = Node(key: key, value: value, cost: cost)
            map[key] = node
            insertAtHead(node)
            totalCost += cost
        }
        // Evict while over capacity
        while totalCost > capacityCost {
            _ = removeTail()
        }
    }
}

Complexity

• get / put: O(1) time; space O(n).

Thread-safety options

• For simple use, wrap public methods with a serial DispatchQueue (DispatchQueue(label:..., attributes: .concurrent) with .barrier for mutations) or use os_unfair_lock/NSLock for low-latency locking.
• Example: use private let queue = DispatchQueue(label: "lru.cache", attributes: .concurrent); read via queue.sync, writes via queue.async(flags: .barrier) to avoid races and keep reads concurrent.

Accounting for item costs (images)

• Provide cost parameter (bytes) per put; maintain totalCost; evict least-recent until totalCost <= capacityCost. For images, use image.pngData()?.count or image.costForCaching API; consider approximate costs to avoid expensive size computations.

Edge cases & notes

• Handle large single-item cost > capacity (optionally reject or allow by evicting all others).
• Consider weak references if values should be released when not strongly held elsewhere (NSCache alternative).

Direct answer
State the decision and the immediate next steps out loud before the meeting ends, then send a short written follow-up within the hour that restates the same thing, so there's both an in-the-room confirmation and a durable record that matches it.

Structured elaboration

1. Confirm verbally before people leave the room (or call). In the last minute or two, say "so to confirm, we've decided X, and the next steps are Y owned by Z by Thursday, does that match everyone's understanding?" This catches a misalignment while everyone who can correct it is still present.
2. Watch for silence versus agreement. Nobody objecting isn't the same as everyone actively agreeing; a direct question ("does that match?") is more reliable than just pausing and moving on if no one immediately speaks up.
3. Send the written follow-up promptly, ideally within the hour, restating the same decision and action items. The verbal confirmation and the written one should say the same thing; if they don't, that's usually a sign the verbal confirmation was rushed or unclear.
4. Keep the written version short and scannable, matching the same content as the verbal confirmation rather than adding new information the room didn't actually agree to.
5. Flag anything genuinely still unresolved, in both the verbal check and the written follow-up, rather than letting an unresolved point quietly look settled just because the meeting ended.

Worked example
Verbal, at the end of the meeting: "So to confirm: we're going with the phased rollout, Sam owns the migration plan by next Friday, and we're holding off on the customer announcement until that's done. Does that match what everyone heard?"

Written follow-up sent the same hour: "Recap from today: decided on the phased rollout. Sam: migration plan due next Friday. Customer announcement is on hold until the migration plan is ready. Shout if this doesn't match what you remember."

The two versions state the identical decision and owner, and the written version explicitly invites correction rather than assuming silence means agreement.

Trade-offs and pitfalls

• Skipping the verbal confirmation and only sending a written recap later means any misunderstanding surfaces after people have already left and possibly acted on their own interpretation.
• Skipping the written follow-up and only confirming verbally means anyone who wasn't in the room, or who forgets, has no record to check against.
• A written recap that silently adds detail beyond what was verbally confirmed can create a new source of disagreement; keep the two consistent, and if you realize something needs adding, flag it explicitly as new rather than folding it in unannounced.