Google Embedded Developer (Staff Level) Interview Preparation Guide

Approach (brief)
Use CAS for lock-free push/pop. Mitigate ABA with hazard pointers: each thread publishes the node it is about to access so other threads won't free it. Retired nodes are kept per-thread and freed only after a global scan ensures no hazard pointer references them.

Code (simplified, single-file, GCC atomics)

// hazard lock-free stack (simplified)
#include <stdatomic.h>
#include <stdlib.h>
#include <stdbool.h>

typedef struct Node {
    int value;
    struct Node *next;
} Node;

typedef struct {
    _Atomic(Node*) head;
} LFStack;

#define MAX_THREADS 8
_Atomic(Node*) hazard[MAX_THREADS]; // published hazard pointers
#define RETIRE_THRESHOLD 16

typedef struct RetireList { Node* nodes[RETIRE_THRESHOLD]; int cnt; } RetireList;
RetireList retire_lists[MAX_THREADS];

void publish_hazard(int tid, Node* p){ atomic_store(&hazard[tid], p); }
void clear_hazard(int tid){ atomic_store(&hazard[tid], NULL); }

void scan_and_reclaim(int tid){
    RetireList *r = &retire_lists[tid];
    if(r->cnt==0) return;
    // collect all hazards
    Node* seen[MAX_THREADS];
    for(int i=0;i<MAX_THREADS;i++) seen[i]=atomic_load(&hazard[i]);
    // for each retired node, free if not in seen
    int w=0;
    for(int i=0;i<r->cnt;i++){
        Node* n = r->nodes[i];
        bool inuse=false;
        for(int j=0;j<MAX_THREADS;j++) if(seen[j]==n){ inuse=true; break; }
        if(inuse) r->nodes[w++]=n;
        else free(n);
    }
    r->cnt=w;
}

void retire_node(int tid, Node* n){
    RetireList *r = &retire_lists[tid];
    r->nodes[r->cnt++]=n;
    if(r->cnt>=RETIRE_THRESHOLD) scan_and_reclaim(tid);
}

void push(LFStack *s, Node* n){
    Node* old;
    do {
        old = atomic_load(&s->head);
        n->next = old;
    } while(!atomic_compare_exchange_weak(&s->head, &old, n));
}

Node* pop(LFStack *s, int tid){
    Node *h;
    while(true){
        h = atomic_load(&s->head);
        if(!h) return NULL;
        publish_hazard(tid,h);
        if(atomic_load(&s->head)!=h){ clear_hazard(tid); continue; }
        Node *next = h->next;
        if(atomic_compare_exchange_strong(&s->head, &h, next)){
            clear_hazard(tid);
            retire_node(tid,h);
            return h;
        }
        clear_hazard(tid);
    }
}

Key concepts & reasoning

• Hazard pointers ensure a node a thread will access isn't freed by another thread.
• Retire lists defer free; periodic global scan compares retired nodes against all hazards and reclaims safe ones.
• This avoids ABA (node reused & freed) because a node won't be freed while any thread has it in its hazard.

Complexity & tradeoffs

• Push/pop are O(1) amortized. Memory overhead: hazard pointers + retire buffers. Scanning cost grows with thread count; tune RETIRE_THRESHOLD for embedded memory constraints.

Edge cases / embedded notes

• Limit MAX_THREADS to known system threads to bound memory. Use static allocation, avoid malloc/free spikes if real-time constraints require deterministic behavior.

Direct answer

Build a standing information diet from what the partner function already produces for itself, its goals or planning document, the metrics it is measured on, and its retro or release notes, and pair that with a recurring informal check-in with one counterpart in that function. You are not trying to get invited into their planning meeting; you are trying to read what they optimize for, and occasionally confirm your read against a real person.

Structured elaboration

The habit that ties these together: translate their metric into one sentence you could say back to them and have them agree it is accurate, then test that sentence the next time you talk. If you cannot state their current priority in a sentence they would sign off on, your information diet has a gap.

Worked example

Suppose you regularly partner with a support or customer-success function but are not in their planning. Their quarterly goals page (a document they publish for their own team) states the goal is "reduce median response time." Reading that before proposing a change that would meaningfully increase inbound volume lets you flag the likely trade-off to your counterpart ahead of launch, rather than finding out after the fact that you worked against their stated goal. The artifact told you what they were measured on; the counterpart conversation confirmed it was still current.

Trade-offs & pitfalls

• Relying only on artifacts risks reading a goal that is stale or aspirational and no longer reflects what the team is actually prioritizing day to day.
• Relying only on a single counterpart's opinion risks mistaking one person's take for the function's actual priority, especially if that person is not close to how the team's metrics are reviewed.
• A common miss: reading the dashboard but never validating the interpretation with anyone in that function, which produces confidently wrong assumptions that only surface when a decision already went the wrong way.
• The senior differentiator on an easy-sounding question like this is treating it as a standing habit built before you need it, rather than something you scramble to learn only after a conflict has already surfaced.

Direct answer

git blame <file> (git annotate is essentially the same underlying operation, presented slightly differently) shows, for every line currently in a file, which commit last touched it, along with that commit's author and date, by walking the file's history backward line by line. It's how you answer "who wrote this and why" without opening the full commit log. Its main limitation is that it attributes a line to whichever commit last touched it, so history-rewriting operations like rebase, squash, or a repo-wide reformat can point blame at a commit that isn't the real, meaningful origin of that line.

Structured elaboration

How blame works: for each line in the current version of a file, git finds the most recent commit that changed it, and reports that commit's hash, author, date, and (with the right flags) the original line content.

Limitations under history rewriting:

• A rebase or squash that folds several small commits into one collapses each small commit's individual reasoning (its own message) into a single combined commit. Blame still points at a real, meaningful commit, but you lose the granular "why" that used to live in each separate step.
• A large mechanical commit, most commonly a repo-wide reformat or a bulk rename, makes blame point at that reformat commit for every line it touched, even though the actual logical author and reasoning is much older. This is the most disruptive case in practice, because it can bury real authorship under an unrelated, uninformative commit.
• Squashing before merge (a common practice for a clean history) means blame after the squash points at the merged commit rather than at whichever of the original WIP commits actually introduced a given line.

Strategies to maintain traceability:

• git blame -w ignores whitespace-only changes when attributing a line.
• git blame --ignore-rev <hash>, or better, a repo-wide .git-blame-ignore-revs file (supported since Git 2.23) listing commit hashes that blame should skip over entirely when walking back, configured once with git config blame.ignoreRevsFile .git-blame-ignore-revs. This is the standard fix for the reformat-commit problem: list the reformat commit's hash, and blame walks straight past it to the real prior change.
• git log --follow <file> tracks a file's history across renames, useful alongside blame since blame alone doesn't always surface a rename boundary clearly.
• At the process level, even if individual "wip"/"fix typo" commits get squashed away, make sure the final squashed commit's message is itself informative (references the ticket/PR, explains the actual reasoning), so that even post-squash, blame at least points at a commit that tells you something real, rather than a generic "fixes."

Worked example

.git-blame-ignore-revs:

# Reformat entire codebase with the new formatter, 2026-03-01
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

git config blame.ignoreRevsFile .git-blame-ignore-revs

After this, git blame on a file that was touched by that reformat commit skips straight past it and attributes each line to whatever commit last meaningfully changed it before the reformat.

Trade-offs and pitfalls

.git-blame-ignore-revs only helps for tools and workflows that respect it (recent git, GitHub, GitLab all do; older tooling might not), so it's not a universal fix, more a convention worth adopting deliberately and documenting for the team. Relying purely on commit-message discipline to preserve traceability through squashes is fragile, it depends on every contributor actually writing a good final message, whereas --ignore-rev is a mechanical fix that works regardless of message quality. Neither technique restores information that was never captured in the first place, if the original small commits genuinely never explained their reasoning, squashing them just makes that gap more visible, it doesn't create the gap.

Approach (brief)
Compute out[i] = popcountll(A[i] ^ B[i]) in a bandwidth- and CPU-efficient loop. Use 64-bit XOR + hardware POPCNT where available, fallback to compiler builtin; apply SIMD/NEON for throughput, blocking to fit caches, and threads or DMA for large transfers on SoC.

Example C implementation (single-threaded, portable with POPCNT):

#include <stdint.h>
#include <stddef.h>
#include <x86intrin.h> // for _mm_popcnt_u64 on x86

void hamming_u64(const uint64_t *A, const uint64_t *B, uint8_t *out, size_t N) {
    size_t i = 0;
    // Process 4-at-a-time to help ILP and prefetching
    for (; i + 3 < N; i += 4) {
        uint64_t x0 = A[i+0] ^ B[i+0];
        uint64_t x1 = A[i+1] ^ B[i+1];
        uint64_t x2 = A[i+2] ^ B[i+2];
        uint64_t x3 = A[i+3] ^ B[i+3];
        out[i+0] = (uint8_t)_mm_popcnt_u64(x0);
        out[i+1] = (uint8_t)_mm_popcnt_u64(x1);
        out[i+2] = (uint8_t)_mm_popcnt_u64(x2);
        out[i+3] = (uint8_t)_mm_popcnt_u64(x3);
    }
    for (; i < N; ++i)
        out[i] = (uint8_t)_mm_popcnt_u64(A[i] ^ B[i]);
}

Optimizations & reasoning

• Hardware POPCNT / intrinsic (_mm_popcnt_u64 or __builtin_popcountll) gives minimal cycles per 64-bit popcount.
• Loop unrolling (4-at-a-time) increases ILP and amortizes memory latency.
• Prefetch/align arrays to 64B to improve cache line utilization; process in blocks sized to L1/L2 cache (e.g., 32KB blocks) to avoid thrashing.
• SIMD: on ARM NEON, load vectors and use vector table or pairwise popcount emulation (NEON lacks scalar 64-bit popcnt on older cores) — newer ARMv8.2 has vcnt for bytes; XOR then vcnt+horizontal sum to get counts for 8 lanes.
• Multithreading: split into contiguous chunks per core to maximize cache locality; avoid false sharing by aligning output chunk boundaries to cache lines.
• Embedded SoC constraints: if DMA available, use DMA to stage A/B into tightly aligned SRAM, then compute in place to reduce external memory bandwidth. For tiny RAM, process in smaller DMA-sized tiles.
• Power/perf trade-offs: use core-specific optimized path (POPCNT vs NEON) via runtime CPU feature detection.
• Edge cases: non-multiple-of-unroll N, unaligned pointers, missing POPCNT instruction — provide fallbacks.

Approach — why constraints matter

• The compiler reorders, allocates registers, and elides stores/loads under optimizations. Inline asm must declare all side effects so the optimizer preserves correctness.
• Declare: inputs/outputs, clobbered registers, "cc" if flags changed, and the special "memory" clobber when asm may read/write or must act as a fence for memory ordering.
• Use "volatile" to prevent removal if the asm has semantic effects not visible to C.

How incorrect constraints break optimized code

• Missing a register clobber: compiler may keep a value in that register across the asm, leading to corruption when asm modifies it.
• Missing "memory" clobber: compiler may reorder adjacent loads/stores across the asm, breaking synchronization or device I/O.
• Wrong constraints for outputs: compiler may reuse the same register for inputs and outputs causing unexpected overwrites.
• Wrong "cc" usage: branch conditions may be miscompiled if flags are changed by asm but not declared.

GCC inline asm example — ARM memory barrier

• Use a DMB (Data Memory Barrier) to ensure ordering of explicit memory accesses on ARMv7/ARMv8.
• "memory" clobber prevents compiler from reordering memory ops across the barrier.
• "volatile" prevents removal when seemingly no C-visible effect.

// ARM: full system scope DMB (ensure memory accesses complete & ordered)
static inline void arch_dmb(void)
{
    __asm__ volatile ("dmb ish" ::: "memory");
}

Notes:

• Use "dmb ish" (inner-shareable) on SMP systems; use "dmb sy" for strongest ordering if needed.
• If asm changes condition flags (e.g., uses CPSR), add "cc".
• For device register accesses, also ensure volatile accessors on pointers or use explicit asm to perform the load/store and declare appropriate clobbers.

Direct answer
A good 30-60-90 plan moves someone from learning the environment, to contributing under supervision, to owning outcomes independently, with the phase boundaries defined by demonstrated behavior (what they can do unsupervised) rather than by the calendar alone. Track it with a small number of concrete, visible outputs per phase so "on track" is something you can point to, not just a feeling.

The three phases, by what changes

• Days 1-30 (learn and observe): environment setup, codebase or domain orientation, shadowing, and one small real contribution rather than a toy task, so the first change is real but low-risk.
• Days 31-60 (contribute under guidance): own a medium-sized piece of work end to end with a mentor available for review and unblocking, not doing it alongside them line by line.
• Days 61-90 (own outcomes): lead something (a project, an on-call rotation, a smaller onboarding task for the next hire) with the mentor as a backstop, not a co-pilot.

How you know they're on track

• Define the signal per phase in advance, not retroactively: for phase 1, did they reproduce the environment and ship one small real change without major help; for phase 2, is their review feedback shrinking in volume and severity over successive changes; for phase 3, can they make a reasonable decision alone and only escalate the genuinely hard calls.
• Check in on cadence (weekly early on, less frequent later) rather than waiting for day 30, 60, or 90 to find out something drifted three weeks ago.

Adjusting the plan for real constraints

• Limited training resources: when there's no dedicated ramp-up bandwidth (no spare mentor hours, no formal training material), lean harder on asynchronous artifacts: written runbooks, recorded walkthroughs, a curated list of the most representative recent changes, and a lighter-touch weekly sync instead of daily pairing. The phases stay the same; what changes is how much is self-serve versus live.
• Cross-skill ramp: if someone hired primarily for one skill set is expected to also ship in an adjacent one by day 90 (for example, a backend-focused hire expected to ship frontend work), that adjacent skill needs its own explicit milestone inside the plan, not an assumption it'll happen by osmosis. Concretely: days 1-30 stays focused on their strong area to build early confidence and trust; days 31-60 introduces the adjacent skill on a small, well-scoped, low-risk piece with close review; days 61-90 has them own something end to end in the new area, even if smaller in scope than their core-skill ownership.

Worked example
For a new hire joining an established codebase with a small team and no dedicated onboarding budget (the limited-resources case), the 30-60-90 looked like: days 1-30, self-serve environment setup using a written runbook plus a single half-day pairing session, culminating in one small, real bug fix; days 31-60, ownership of one medium feature with async review as the main touchpoint, and a short weekly 15-minute sync instead of daily check-ins; days 61-90, the new hire wrote the onboarding runbook update for the next person, which served double duty as both a real deliverable and a check on whether they actually understood the system well enough to explain it. Being on track was tracked by a short checklist per phase (environment reproducible, first fix merged with normal review effort, feature shipped with review comments trending down) rather than a single blanket "how's it going" check-in.

Trade-offs and pitfalls

• Treating the day boundaries as fixed calendar dates rather than behavioral milestones creates false confidence; someone can hit day 60 without actually being ready for phase-3 ownership, and pushing them into it anyway sets them up to fail.
• Under-supporting the adjacent-skill ramp (assuming a backend engineer will "pick up" frontend without an explicit milestone) is a common way cross-skill onboarding quietly fails; it needs the same structure as the primary skill, just smaller in scope.
• Compressing the plan under limited training resources by cutting phase 1 short (rushing into real ownership before the environment and codebase are understood) trades a faster-looking ramp for more review overhead and rework later.

Approach summary
On bare-metal I treat memory-leak detection as two complementary flows: heavy-weight development-time inspection (emulation/harness) and lightweight in-field telemetry via allocator instrumentation and sampling. Development finds root causes; field data narrows suspects.

Allocator instrumentation techniques

• Wrap malloc/free/realloc/new/delete in a thin layer that records: size, timestamp, caller PC (compact backtrace), and an allocation id. Keep metadata in a small slab or hash table.
• Store metadata off-heap or in a reserved RAM region to avoid corrupting app heap.
• Expose APIs to produce heap snapshots or to walk outstanding allocations.

Sampling & lightweight counters for field

• Use probabilistic sampling (e.g., 1/1000 allocations) to capture full backtraces for a subset; maintain aggregate counters per callsite for all allocations.
• Maintain lightweight per-module counters: total bytes allocated, total frees, current outstanding.
• Emit periodic telemetry (compact binary protobuf) over existing telemetry channel when device is idle or on boot/shutdown.
• Use bloom-filter or checksum of allocation stack to detect repeated leak patterns without storing every record.

Development-time strategies

• Run firmware under QEMU or Instruction-Level Simulator with full allocator logging and ASan/Valgrind on host-linked components.
• Build unit/integration harnesses that stress allocation patterns and take snapshots before/after tests to diff outstanding allocations.
• Use fault-injection: force OOM paths, instrument critical paths with guard pages (in emulator), and use malloc wrappers that optionally abort on leak thresholds.
• Automate regression tests by intentional leak injection to ensure detectors catch leaks.

Trade-offs & practical tips

• Metadata size must be bounded; rotate or compact old entries.
• Sampling reduces overhead but may miss rare leaks—use heavier sampling in QA.
• Protect instrumentation code for ISR/real-time contexts (use lockless rings or defer logging).
• Correlate field telemetry with firmware version and usage patterns to prioritize fixes.

Situation: I led a launch that needed Product, Engineering, and Support to deliver the same outcome, which was reducing customer setup time.

Task: Each team had different priorities, so I needed one shared goal and a way to surface trade-offs early.

Action: I started with a single business metric, then broke it into team-level commitments. Product owned the user flow, Engineering owned reliability, and Support owned readiness. I held a weekly cross-functional checkpoint where each team shared risks, not just status. When conflicts came up, I made the trade-off explicit. For example, we chose to delay one nonessential feature so we could simplify onboarding and reduce support tickets.

Result: The teams stayed aligned, the launch shipped with fewer surprises, and the process made future collaboration easier because everyone knew how decisions would be made.

The key lesson was that shared outcomes work best when the goal is visible, disagreements are discussed early, and trade-offs are decided openly instead of being left to drift.

Approach
Use power-of-two capacity so index wrap is mask = size - 1. Keep head (read index) and tail (write index) as unsigned integers that monotonically increase; buffer index = idx & mask. For ARM Cortex‑M (single core, byte store/read atomic), use volatile for head/tail and memory ordering via compiler barriers (asm volatile("" ::: "memory")) to prevent reordering between producer (ISR) and consumer (main). No interrupt disabling.

#include <stdint.h>
#include <stddef.h>
#include <stdbool.h>

struct rb {
    uint8_t *buf;
    size_t mask;        // size - 1
    volatile uint32_t head; // consumer reads
    volatile uint32_t tail; // producer writes
};

static struct rb rb_inst;

void rb_init(uint8_t *buf, size_t size) {
    // size must be power of two
    rb_inst.buf = buf;
    rb_inst.mask = size - 1;
    rb_inst.head = rb_inst.tail = 0;
}

/* Compiler memory barrier to prevent reordering */
static inline void barrier(void) { asm volatile ("" ::: "memory"); }

bool rb_push(uint8_t b) {
    uint32_t tail = rb_inst.tail;
    uint32_t head = rb_inst.head; /* read consumer index */
    uint32_t next = tail + 1;
    if ((next - head) > (rb_inst.mask + 1)) return false; /* full */
    rb_inst.buf[tail & rb_inst.mask] = b;
    barrier(); /* ensure data written before updating tail */
    rb_inst.tail = next;
    return true;
}

bool rb_pop(uint8_t *out) {
    uint32_t head = rb_inst.head;
    uint32_t tail = rb_inst.tail; /* read producer index */
    if (head == tail) return false; /* empty */
    *out = rb_inst.buf[head & rb_inst.mask];
    barrier(); /* ensure read completes before advancing head */
    rb_inst.head = head + 1;
    return true;
}

Explanation & Assumptions

• SPSC: producer only writes tail and buffer slot; consumer only writes head.
• volatile prevents compiler caching of head/tail. The memory barrier prevents compiler (and on ARM, typical out-of-order) reordering of data access and index update.
• On ARM Cortex‑M (no cache, single core), this is sufficient; if using Cortex‑M with DMA/shared memory or multicore, stronger barriers (DMB) or atomic ops needed.

Complexity & Edge Cases

• O(1) push/pop, uses size power-of-two. Check size validity at init (not shown). Must ensure buffer pointer lifetime > rb usage.

Definition / purpose
A context switch in an RTOS is the act of saving the currently running task’s execution state and restoring another task’s state so the CPU can continue execution on the new task with correct register/memory context. It enables multitasking and preemption for real‑time behavior.

CPU & memory state to save/restore

• CPU registers: program counter (PC / PC/PC-like), stack pointer (SP), status/flags (PSR/CPSR), general purpose registers (R0–Rn).
• Special registers: floating-point / DSP registers (if FPU used), control registers, banked registers (on some architectures).
• Memory-related: TCB pointers (task control block), MMU/TLB context if using memory protection, kernel bookkeeping (ready list pointers).
• Interrupt mask / priority state.

Stack implications (tasks vs ISRs)

• Each task requires its own stack; full CPU and optionally FPU registers are spilled onto the task stack during switch.
• ISRs often run on the current task’s stack or an interrupt stack depending on architecture; nesting increases stack usage—use separate IRQ stack to limit corruption and bound worst‑case stack depth.
• Ensure stack alignment for ABI and FPU context saves.

Performance costs & latency sources

• Time to push/pop register set and FPU state.
• Kernel overhead: scheduler decision, ready list manipulation, TCB updates.
• Cache/TLB misses when resuming different address space.
• Interrupt disable/enable windows and priority handling add latency.
• Typical cost: tens to hundreds of cycles on simple MCUs; microseconds on faster cores when saving FPU + cache effects.

Two ways to reduce overhead

1. Minimize saved state: use lazy FPU context save (save FPU only on first use) and design convention to limit caller-saved vs callee-saved usage so fewer registers are saved on switch.
2. Reduce frequency of switches: increase task coalescing (longer time slices for non‑real tasks), use cooperative scheduling for low-priority work, or use lockless/event-driven design to avoid many short-lived tasks.

This approach balances predictability and resource constraints typical in embedded RTOS design.