Google Embedded Developer (Senior Level) - Comprehensive Interview Preparation Guide

Approach
Use a volatile 32-bit pointer for the register, provide simple read/write, and provide two safe RMW helpers: one for foreground code that disables interrupts briefly, and an IRQ-safe variant that uses ARM exclusive access (LDREX/STREX via CMSIS). This avoids undefined behavior and race conditions between ISRs and main code.

Code

#include <stdint.h>
#include "cmsis_gcc.h" // or core_cmFunc.h for __LDREXW/__STREXW/__disable_irq etc.

#define PERIPH_REG_ADDR  ((uintptr_t)0x40021000)
#define PERIPH_REG       (*(volatile uint32_t *)PERIPH_REG_ADDR)

/* Basic access */
static inline uint32_t reg_read(void) { return PERIPH_REG; }
static inline void reg_write(uint32_t v) { PERIPH_REG = v; }

/* Foreground-safe: disable interrupts around RMW */
static inline void reg_set_bits_fg(uint32_t mask) {
    uint32_t prim = __get_PRIMASK();    /* save PRIMASK */
    __disable_irq();
    PERIPH_REG |= mask;
    if (!prim) __enable_irq();          /* restore only if interrupts were enabled */
}
static inline void reg_clear_bits_fg(uint32_t mask) {
    uint32_t prim = __get_PRIMASK();
    __disable_irq();
    PERIPH_REG &= ~mask;
    if (!prim) __enable_irq();
}

/* IRQ-safe using exclusive access (ARM Cortex-M) */
static inline void reg_set_bits_irqsafe(uint32_t mask) {
    uint32_t old, newv;
    do {
        old = __LDREXW(&PERIPH_REG);
        newv = old | mask;
    } while (__STREXW(newv, &PERIPH_REG));
    __DMB(); /* optional memory barrier */
}
static inline void reg_clear_bits_irqsafe(uint32_t mask) {
    uint32_t old, newv;
    do {
        old = __LDREXW(&PERIPH_REG);
        newv = old & ~mask;
    } while (__STREXW(newv, &PERIPH_REG));
    __DMB();
}

Notes / reasoning

• Use volatile to prevent compiler reordering/optimizations.
• Foreground helpers disable interrupts briefly to make RMW atomic w.r.t ISRs.
• IRQ-safe helpers use LDREX/STREX so they can be called from ISRs and tasks safely on ARM Cortex-M.
• Use memory barriers (DMB) if peripheral ordering matters.
• If targeting non-ARM cores, replace exclusive access with appropriate atomic primitives or use critical sections.

Definition & primitives (brief)

Atomic operations in C11 live in <stdatomic.h>. They provide lock-free read-modify-write and load/store operations plus explicit memory orderings:

• atomic_load_explicit / atomic_store_explicit
• atomic_fetch_add/ sub / and/or / exchange / compare_exchange_{weak,strong}_explicit
  Memory order enums: memory_order_relaxed, acquire, release, acq_rel, seq_cst.

Example — atomic increment with acquire-release

#include <stdatomic.h>

atomic_uint counter;

void atomic_increment_acqrel(void) {
    // RMW with acquire-release semantics: ensures prior releases from other threads
    // are visible after this operation, and this release is visible to following acquires.
    atomic_fetch_add_explicit(&counter, 1u, memory_order_acq_rel);
}

Explanation: fetch_add is an atomic read-modify-write. Using memory_order_acq_rel guarantees this operation acts as a release on the write side and an acquire on the read side, suitable when the increment synchronizes both sides (e.g., producer updates state and increments a shared counter).

When to use weaker or stronger orderings (embedded focus)

• memory_order_relaxed: use for performance-critical counters/metrics where only atomicity is needed, not ordering (e.g., IRQ incrementing an event count read later without depending on other memory).
• acquire/release or acq_rel: use when you need to order metadata and payload (e.g., producer writes buffer then releases counter; consumer acquires counter then reads buffer).
• memory_order_seq_cst: use when global total ordering is required or for correctness when reasoning about complex interactions across CPUs; costly on some MCUs or when hardware lacks strong fences.
• In constrained embedded systems prefer the weakest ordering that provides correctness to save cycles/power; use stronger orders or explicit fences when interacting with DMA, peripherals, or interrupt handlers that need strict visibility.

Direct answer

Pick a project that genuinely needed more than one function, and be specific about two things: what YOU owned (not what 'the team' did), and the one concrete mechanism that determined whether the collaboration worked, such as a shared definition of done, a clear handoff point, or clarity on who decided what when opinions differed. Vague answers ('we communicated well') sound rehearsed; specific answers sound lived-in.

What the story needs to show

Your specific contribution. Interviewers are listening for what you personally decided or built, distinct from what your collaborators did. If every sentence is 'we', the interviewer cannot tell what you'd do differently on the next team.

A mechanism-level explanation. Organize the story around one of three lenses:

• Shared goal: did every function agree on what 'done' looked like and how success would be measured, or was each function quietly optimizing for its own definition?
• Interface or handoff: was there a clear point where work crossed from one function to another, and was that point actually defined, or did people guess?
• Decision rights: when functions disagreed, was it clear whose call it was, or did disagreement just stall until someone got tired of arguing?

Honesty if it's a struggle story. The question explicitly allows 'succeed or struggle'. A good struggle story ends on what you changed about the collaboration, not on who was at fault.

Worked example

Situation: [your team] needed to deliver [a feature or initiative] that required real work from [Team A, for example a design or research function] and [Team B, for example a data or infra function], against a fixed external date.
Task: your role was the one connecting the three groups, for example owning the shape of the interface between design and engineering, or owning how data requirements got translated into a schema.
Action: early on, each function had a different idea of what 'done' meant for their piece, which caused rework when the pieces met. You wrote a short one-page agreement naming the shared definition of done and who would sign off on each handoff, and used it to resolve the next two disagreements without a meeting.
Result: the project shipped on the revised date, and the agreement itself became something the group reused on the next cross-functional piece of work, which is the real marker of a story about redesigning the collaboration rather than just pushing through it.

To make that skeleton concrete rather than a fill-in-the-blank: picture a checkout redesign that needed real work from the design function and the payments engineering function, against a fixed external date tied to a promotional campaign launch. The specific disagreement was about what 'done' meant for the new payment-method selector: design considered the screen done once every state (loading, error, empty) matched the approved mockups pixel-for-pixel, while payments engineering considered it done once the integration correctly handled every payment-provider response code, even ones with no mockup drawn yet. That mismatch caused two rounds of rework when a payment-provider error state shipped without a design pass. The one-page agreement that resolved it included this line: 'A screen is done when it matches an approved mockup for every state the payments API can return, and any new state discovered after mockups are drawn triggers a joint 15-minute review before either side builds it.' That single sentence is what let the two functions stop re-litigating 'done' every time a new edge case appeared, and both sides signed off on it before the next round of work began.

Trade-offs and pitfalls

• A generic 'we all communicated well' answer with no mechanism is the single most common weak version of this story, avoid it.
• Over-crediting the team at the expense of your own specific contribution leaves the interviewer unable to evaluate you.
• If you pick a struggle story, resist framing it as the other function's fault. The senior version of this answer explains what you changed about how the groups worked together, not who dropped the ball.
• The strongest answers show you redesigning a structure (a handoff, a shared definition, a decision rule), not just working harder inside a broken one.

Approach (constraints)
Two 4KB sectors (A and B), records ≤256 B. Goal: atomic append-only journal of config records with crash recovery and wear-level safe erase.

Record format (per entry, 16 B header + payload up to 256 B)

• CRC32 (4 B) — covers header+payload
• SeqNum (4 B) — monotonically increasing 32-bit
• Len (2 B) — payload length
• Flags (1 B) — 0x01 = valid, 0x02 = start-of-commit marker
• Reserved/Padding (5 B)
• Payload (Len bytes)
  Entries are written aligned; unused space filled with 0xFF.

Write/erase sequence

• Always append to active sector until near-full. To write a record:

  1. Program header with Flags=0 (invalid), SeqNum, Len, CRC computed with Flags=0.
  2. Program payload. (Either before or after header depending on flash constraints; choose payload-first if partial-program causes no false-valid header.)
  3. Program header final byte: set Flags=0x01 (valid) with one targeted program operation (finalize). This single-byte transition makes entry appear atomically valid.

• When replacing configuration atomically, write new record with next SeqNum, then write a special commit record (Flags includes start-of-commit) or use the record itself as authoritative.

• Sector rotation: when active sector nearly full, erase the inactive sector, copy latest valid records needed (or only the latest config) into it, then mark it active; finally erase the old sector.

Boot-time recovery algorithm

• Scan both sectors linearly; treat any 0xFF as end-of-data. For each entry: verify CRC and Flags has valid bit. Ignore invalid or CRC-failed entries. Track highest SeqNum; if multiple entries share SeqNum, prefer the one with commit flag or the last-valid. If no valid entries, use factory default. If an active sector contains no valid entries, treat other sector as active.

Rationale & trade-offs

• Single-byte flag flip minimizes window where partial write appears valid. CRC detects torn writes. SeqNum orders records across rotations. Copy-on-erase keeps at most one sector erase per rotation reducing wear. This scheme is simple, small-footprint, and suitable for constrained MCUs.

Requirements & constraints

• Per-core reservations: each core has multiple reservations (budget Q, period P) with bandwidth (U = Q/P).
• Hard-deadline tasks must not be violated; reclaiming only uses unused slack without reducing reserved guarantees.

High-level design

• Kernel extension hook into per-core runqueue and tick/HR timer. Each core runs independent reservation accounting; inter-core migration disabled for hard tasks.

APIs

• Reservation create/destroy:

int res_create(int core, uint64_t Q_ns, uint64_t P_ns, bool sporadic_reclaim, res_id_t *out);
int res_attach_task(res_id_t r, pid_t tid);
int res_detach_task(res_id_t r, pid_t tid);

• Query/runtime:

struct res_stats { uint64_t budget, period, used, deadline; };
int res_get_stats(res_id_t r, struct res_stats *s);

Data structures

typedef struct reservation {
  uint64_t Q;       // budget ns
  uint64_t P;       // period ns
  uint64_t usage;   // consumed in current period
  uint64_t deadline; // current replenishment deadline (absolute ns)
  uint64_t slack;   // available reclaimable slack
  bool sporadic;    // enables reclaim
  spinlock_t lock;
  list_t tasks;
} reservation_t;

Accounting & replenishment

• Use sporadic server: when a task runs, decrement reservation. If usage exhausted, mark server inactive and run only non-hard or lower-priority best-effort tasks.
• Replenishment: on wake/sleep or budget expiration, enqueue replenishment at deadline = now + P_remaining. Maintain per-reservation replenishment queue (FIFO) to recharge Q.
• Bandwidth enforcement: admission control per-core ensures sum(U) <= U_max (<=1.0). Rejection on create if exceeded.

Reclaiming algorithm

• Maintain per-core global slack pool fed by unused budgets after their deadlines pass.
• Two-tier reclaim:
  • Temporal isolation: only reclaim slack from reservations whose deadline > current time and only for best-effort/aperiodic tasks or sporadic servers flagged reclaimable.
  • Priority-aware lending: lend slack with earliest-deadline-first reclaim; track lent amount per-reservation to charge back on next replenishment.
• Implement “bandwidth-preserving reclaim” similar to SCHED_DEADLINE’s bandwidth reclaim — give temporary runtime without updating original reservation’s usage; instead account in slack pool ledger.

Interrupts & aperiodic tasks

• ISRs: run on reserved interrupt context; account interrupt CPU time against a special IRQ reservation per-core. If interrupt servicing threatens a hard reservation, raise kernel flag to throttle aperiodic handlers and defer non-critical work to bottom halves executing on reclaim budget.
• Aperiodic tasks: handled via sporadic server with own reservation or serviced via reclaim pool. Ensure aperiodic execution never borrows past the donor reservation’s deadline window — enforce max-lend = donor.Q_unused_until_deadline.

Handling deadlines

• Scheduler uses EDF within reserved set; hard tasks pinned to their reservation deadlines. When slack used, mark borrowed runtime with expiration = donor.deadline; scheduler prevents borrowed time from being used to extend donor’s hard deadlines.

Edge cases & trade-offs

• Migration: to ensure isolation, either forbid migration for hard-tasks or transfer reservation state atomically.
• Overhead: per-core timers and replenishment queues cost; coalesce timers using hierarchical timers.
• Simplicity vs. utilization: stricter enforcement simpler; aggressive reclaim higher utilization but more accounting complexity.

Why this works

• Maintains temporal isolation with admission control; sporadic replenishment preserves hard deadlines; reclaiming increases utilization without breaking guarantees by bounding lend periods and precise accounting.

I would treat this as a change-management problem, not just a rollout problem.

First, I would diagnose where adoption is breaking down. I would review usage data, interview a few people from each function, and compare the new process to the old one. I want to know whether people are resisting because the process is too slow, unclear, misaligned with incentives, or simply not useful in their day-to-day work.

Then I would test the rollout design. I would ask: did we train people, give them a reason to care, and remove the old path? For example, if support keeps using the old escalation template, maybe the new process adds friction and does not solve their problem fast enough.

If the issue is execution, I would tighten enablement, add team champions, and publish a clear operating cadence. If the issue is the process itself, I would change it based on the feedback rather than forcing adoption of a bad design.

I would judge success by outcomes, not attendance at meetings. If adoption improves, cycle time drops, and fewer teams revert to the old habit, the rollout is working. If not, I would change the process before asking for more compliance.

For example, when a company rolled out a new cross-functional incident-escalation process across product, engineering, and support, usage data after three weeks showed only 40% of support tickets were being routed through the new template, the rest were still going through the old one. Interviews with five support agents revealed the real problem: the new template required them to fill in a business-impact field that only engineering had the context to answer, so agents defaulted back to the old, faster template rather than get stuck. That pointed to a process-design gap, not a training gap. The fix was to move the business-impact classification to a follow-up step engineering completed after triage, instead of asking support to guess it up front. Within two weeks of that change, template usage rose to 92%, and average escalation cycle time (the time from a ticket being flagged to a fix being assigned) dropped from about 3.5 days to just under 2 days.

Approach (brief)
Provide a safe, minimal blocking full-duplex SPI transfer: assert CS, configure mode/clock if changed, transfer N bytes by writing TXDR then waiting for RXDR, finally deassert CS. Support variable clock by reconfiguring baud register before asserting CS and protect shared peripheral with a mutex/lock.

Code (blocking, polling)

// Example minimal SPI transfer (polling) for MCU with registers SPI->CR, SPI->DR, SPI->SR
#include <stdint.h>
typedef enum { SPI_MODE0=0, SPI_MODE1, SPI_MODE2, SPI_MODE3 } spi_mode_t;
volatile uint32_t LOCK=0;

static inline void lock_acquire(void){ while(__atomic_test_and_set(&LOCK, __ATOMIC_ACQUIRE)); }
static inline void lock_release(void){ __atomic_clear(&LOCK, __ATOMIC_RELEASE); }

int spi_transfer(uint8_t *tx, uint8_t *rx, size_t n, uint32_t baud_div, spi_mode_t mode, void (*cs_assert)(int), void (*cs_deassert)(int), int dev_id){
    lock_acquire();
    // safe reconfigure
    SPI->CR &= ~SPI_CR_ENABLE;
    SPI->BR = baud_div;            // set clock
    SPI->CR = (SPI->CR & ~SPI_CR_MODE_MASK) | (mode << SPI_CR_MODE_SHIFT);
    SPI->CR |= SPI_CR_ENABLE;

    cs_assert(dev_id);
    for(size_t i=0;i<n;i++){
        SPI->DR = tx ? tx[i] : 0xFF;            // write to start transfer
        while(!(SPI->SR & SPI_SR_RXNE));       // poll RX ready
        uint8_t r = (uint8_t)SPI->DR;
        if(rx) rx[i]=r;
    }
    cs_deassert(dev_id);
    lock_release();
    return 0;
}

Interrupt vs Polling (trade-offs)

• Polling: simple, deterministic latency, good for short bursts and bare-metal; wastes CPU if transfers long.
• Interrupt-driven: lower CPU usage, better for multitasking or long transfers; more complex (state machine, circular buffers), higher ISR overhead and latency jitter.
• Choose polling for < few hundred bytes or realtime-critical inner loops; choose interrupts (or DMA) when offloading CPU and handling concurrent tasks.

Edge cases / safety

• Ensure CS asserted before transfers and deasserted after last byte (clocking).
• Protect config changes with a lock or run in critical section.
• Handle FIFO/full/overrun flags and timeouts in production code.

Brief approach / goals
Explain how to enable ARM CoreSight ETM/SWO/instruction trace on a real device, capture PC-level trace, map PCs back to source using ELF, keep trace volume manageable, and reduce runtime overhead—using practical tools and embedded-developer considerations.

Steps to enable trace

• Verify SoC CoreSight: ETM, TPIU/ETB, STM/ITM (SWO) present and not fused off; check TRM and debug access permissions (secure/non-secure).
• Hardware connections: connect trace pins to probe (TPIU/ETM over parallel pins or over TPIU->SWO/FTM). For SWO use single-pin UART/SWO via SWD. For full instruction trace you need ETM + TPIU and a probe with enough bandwidth (Lauterbach, SEGGER J-Trace, ARM DS-5).
• Configure clocks and trace port: enable trace clock and set TPIU protocol (NRZ/SPI), set trace frequency so probe can capture (match probe max).
• Enable ETM: program ETM registers to trace PC (select context ID, timestamp settings, address comparators for filtering). Enable ETM via ETM_CR and ETM_SSCSR following TRM.

Capture data

• Use a trace-capable probe and software:
  • Lauterbach/TRACE32: full ETM capture + decoding.
  • SEGGER J-Trace + Ozone: ETM + SWO capture.
  • Open-source: OpenOCD + babeltrace2 for SWO/ETM partial flows (probe support limited).
  • pyOCD supports SWO ITM stream capture for Cortex-M.
• For SWO/ITM: enable ITM stimulus ports in firmware for printf-like events and use host tool to capture ITM/SWO async packets.
• Start capturing: 1) reset and halt CPU, 2) enable trace units, 3) start trace stream, 4) resume CPU.

Correlate PCs to source lines

• Export trace containing PC samples (addresses + timestamps).
• Use ELF symbols to map addresses:
  • Use addr2line or eu-addr2line, e.g.
    bash

    addr2line -e build/firmware.elf -f -C 0x08001234
    

  • For bulk mapping, script with pyelftools or objdump to build address->symbol table, then binary-search map PCs to functions/lines.
• Ensure build includes debug info (-g) and that code not relocated; use .map file to validate address ranges.

Manage large trace volumes

• Prefer filtered ETM: program comparators to only trace functions/regions of interest.
• Use context ID / address comparators to trace tasks or threads only.
• Use trace-to-buffer (ETB) to store locally then download in chunks.
• Downsample: trace PC sampling (periodic PC-sampling) instead of full instruction trace if supported.
• Use SWO/ITM for event markers and coarse profiling; use ETM for short, focused captures.
• Stream compression: some probes compress; use binary trace formats and post-process with babeltrace to decode to higher-level traces.
• Use circular buffers and capture-on-trigger to avoid continuous huge dumps.

Minimize instrumentation overhead

• Rely on hardware ETM rather than software instrumentation (no inserted branches).
• Use short, targeted trace windows triggered by events (GPIO, software trigger via STM).
• Use hardware timestamps so no extra cycles for timekeeping in firmware.
• Use sampling (PC sampling, DWT cycle counter triggers) not full-instruction logging for long runs.
• If software tracing needed, use ITM stimulus or lock-free ring buffers DMA to memory to avoid blocking.

Practical considerations & pitfalls

• SWO bandwidth is limited (e.g., 2 MHz SWO ~2 Mbps); don’t try full instruction trace over SWO.
• ETM requires high probe bandwidth and often parallel pins; ensure probe supports trace clock and port width.
• Watch power and EMI when enabling high-speed trace clocks.
• Trace capture can change timing; minimize impact by short captures and isolating interrupts when needed.
• Ensure symbol addresses match firmware image (watch bootloader relocation, link addresses).
• Use consistent timestamp sources (ETM timestamp or CPU DWT CYCCNT) to merge SWO events and ETM PCs.

Tools summary

• Commercial: Lauterbach TRACE32, SEGGER Ozone/J-Trace, ARM DS (Streamline), Percepio Tracealyzer (for RTOS events)
• Open-source: OpenOCD (limited ETM), babeltrace2, pyOCD, pyelftools, addr2line/objdump

Example workflow (practical)

1. Build with -g and keep .map.
2. Connect J-Trace, enable trace clock, program ETM to trace region A–B and timestamping.
3. Configure trigger (e.g., ITM event) and start streaming to host into a file.
4. Stop after condition, decode with babeltrace or TRACE32, extract PC list.
5. Map PCs to source via addr2line batch script and visualize hot paths or hotspots.

This approach gives cycle-accurate hotspots with minimal runtime overhead by using ETM hardware, selective capture, and symbol-based correlation for actionable optimizations.

I would treat this as a heap-corruption hunt, not a crash hunt. Heap corruption usually happens earlier than the visible failure, so I want the first bad write, not the last symptom.

What I would instrument first:

• A sanitizer build in staging, especially AddressSanitizer, because it reports the exact out-of-bounds write or use-after-free.
• A thin malloc/free/realloc wrapper that logs pointer, size, and call site for the large-request path.
• Guard checks around the suspicious buffers, for example canary bytes before and after a large allocation.

Concrete example: if the service fails after a 64 KB upload, I would log every allocation made while parsing that request and compare a good run to a bad run. If the crash disappears under a sanitizer build, I know the bug is timing-sensitive, and I keep narrowing by request size and code path until one suspicious write shows up.

I would not start with the final crash stack alone, because heap corruption often makes the crash happen far away from the real bug.

High-level summary
Metastability and input jitter require trade-offs between reliability, latency and CPU. Below I list common software-level mitigations, their costs, and a testing plan to estimate MTBF for your target.

Mitigations (what, why, cost)

• Double-flop synchronizer (2-stage FF): simple, industry standard for single-bit crossing. Latency = 2 clock cycles; CPU cost = none (hardware flip-flops). Reduces metastability escape probability by giving extra resolve time.
• Multi-stage synchronizer (3+ FFs): further reduces failure probability exponentially; latency = N cycles; CPU cost = none.
• Oversampling (sample input multiple times per bit using software/GPIO interrupts or ADC): increases robustness to narrow glitches and jitter. Latency = depends on sample window (often tens–hundreds µs); CPU cost = high if polling; moderate if using DMA + timer.
• Majority voting (N samples, take majority): works with oversampling; extra memory/CPU to collect and compute majority; latency = sampling window length + compute (very small).
• Hysteresis / Schmitt-trigger inputs: analog front-end reduces noise-induced transitions; latency = negligible; CPU cost = none if hardware; software equivalent = require stable run-length before accept (debounce) — increases latency and CPU if polled.

Trade-offs summary

• Hardware FFs: minimal CPU, fixed latency (clock cycles).
• Software oversampling/majority: flexible but high CPU and higher latency; good for low-rate signals.
• Hysteresis/debounce: low CPU (if implemented in hardware); increases detection time.

MTBF estimation (design tests + extrapolation)

1. Controlled stress: use FPGA or signal generator to create asynchronous transitions at controlled rates and adjustable timing relative to destination clock; inject worst-case pulses and jitter.
2. Measure failure rate: run long-duration tests counting corrupted captures. Vary synchronizer resolve time (extra wait cycles) or sampling window.
3. Fit exponential model to observed failure rate to extract device/time constant and constant K:

MTBF = e^(T_res / tau) / (f_input * f_clock * K)

Plain-English: increasing resolve time T_res exponentially increases MTBF; f_input and f_clock scale collision opportunities.
4. Extrapolate to field conditions using measured f_input, f_clock and fitted tau, K. Include confidence intervals and run time sufficient to observe >10 failures for statistical validity or use accelerated stressing to get failures faster.
5. Practical checks: use oscilloscope to capture ambiguous transitions, validate with multiple input patterns, and combine hardware (Schmitt) + 2-stage sync + optional software debounce for high-assurance.

Notes: document assumptions (clock domains, measured jitter), include safety margins (design for MTBF >> expected device lifetime).