DoorDash Staff Embedded Developer Interview Preparation Guide

Approach summary
I would break the 500 µs budget into components, analyze each with worst-case assumptions, then verify with measurement and stress testing.

1) Budgeting / decomposition

• ISR execution time (T_isr): minimal work—ack, read minimal regs, copy header to ring buffer. Bound with static WCET analysis + cycle counter measurements. Target < 50–100 µs.
• Deferred worker scheduling (T_defer): time until worker runs (scheduler latency) + worker execution. On RTOS, measure max scheduling latency at ISR -> thread priority boundaries. Target < 200 µs.
• Interrupt priorities & nesting (T_prio): worst-case blocking by higher-priority ISRs and interrupt tail-chaining. Account for maximum higher-priority ISR durations that can preempt codec ISR.
• Cache effects (T_cache): cold-cache penalties on ISR/worker code and data (I/D cache refills, TLB). Model number of cache lines touched and typical refill times; include worst-case L1 miss + L2 miss penalties.
• DMA contention (T_dma): bus arbitration delays and shared DMA engine contention; include worst-case waiting time for DMA descriptor processing or bus bandwidth saturation.

Make a safety margin (e.g., 10–20 %) and sum:
T_total = T_isr + T_defer + T_prio + T_cache + T_dma + margin ≤ 500 µs

2) Bounding techniques

• Keep ISR minimal; defer processing to high-priority realtime thread pinned to a core if SMP.
• Use priority inheritance / ceiling for locks; avoid blocking in ISR.
• Assign codec ISR highest real-time priority possible; ensure other ISRs are analyzed.
• Use lock-free ring buffers and single-producer single-consumer DMA descriptors to avoid mutex latency.
• Cache-warm critical code/data at init or use I-cache locking if supported; align buffers to cache lines.
• Configure DMA with dedicated channels, increase arbitration weight or use guaranteed bandwidth features.
• Use static scheduling analysis / response-time analysis for RTOS tasks (RTA formulas).

3) Measurement & verification

• Use cycle counters (ARM DWT_CYCCNT) for microbench ISR timings and trace timestamps.
• Use SoC trace: ETM/ITM/PTM or SWO to capture ISR enter/exit and scheduler events with cycle accuracy.
• External measurement: toggle a GPIO at ISR entry/exit and capture with high-speed oscilloscope or logic analyzer to measure end-to-end latency (interrupt to sample handling).
• Use DMA-visible markers (toggle when DMA descriptor ready) to measure contention impact.
• System trace tools: ftrace, LTTng, perf, Tracealyzer, FreeRTOS+Trace to record scheduling latencies and context switches.
• Introduce synthetic worst-case interference: enable other ISRs, DMA heavy traffic, cache-flush patterns, and run sustained stress tests to capture the true WCET.
• Repeatability: run long-duration randomized tests and record worst observed latencies; compare to analytic upper bound.

4) Validation

• Combine static WCET analysis and measured worst-case from hardware traces; if measured > bound, iterate: reduce ISR work, raise priorities, reserve DMA bandwidth, or tighten cache control.
• Document assumptions (max higher-priority ISR durations, bus arbitration policies) and include test rigs/scripts to reproduce worst-case scenarios.

This methodology yields a defensible worst-case bound and concrete verification evidence for meeting 500 µs.

Answer (approach)

Use a single-producer (ISR)/single-consumer ring where only the ISR writes tail and only the main thread writes head. Make head/tail volatile uint16_t so compiler won’t optimize accesses. Require buffer size power-of-two and mask = size-1. Use compiler and CPU memory barriers around ownership handoff to ensure sample stores are visible before index publish.

Function signatures & implementation

#include <stdint.h>
#include <stdatomic.h>

#define RB_SIZE  256               // power of two
#define RB_MASK  (RB_SIZE - 1)

typedef struct {
    volatile uint16_t head;        // read by consumer, written by consumer
    volatile uint16_t tail;        // written by ISR, read by consumer
    uint16_t buf[RB_SIZE];         // sample type (change as needed)
} ringbuf_t;

/* Called from ISR: enqueue one sample, return 1 on success, 0 if full */
int rb_isr_enqueue(ringbuf_t *rb, uint16_t sample);

/* Called from main thread: dequeue one sample, return 1 on success, 0 if empty */
int rb_dequeue(ringbuf_t *rb, uint16_t *out);

// lightweight compiler barrier
static inline void comp_barrier(void) { atomic_signal_fence(memory_order_release); }

// Platform-specific full barrier (optional for strong ordering, e.g., ARM)
#ifndef PLATFORM_DMB
#define PLATFORM_DMB() do { /* insert CPU DMB if needed, e.g., __DMB(); */ } while(0)
#endif

int rb_isr_enqueue(ringbuf_t *rb, uint16_t sample) {
    uint16_t tail = rb->tail;
    uint16_t head = rb->head;            // read consumer head (volatile)
    if (((tail + 1) & RB_MASK) == (head & RB_MASK)) return 0; // full
    rb->buf[tail & RB_MASK] = sample;    // store data
    comp_barrier();                       // ensure data written before publish
    PLATFORM_DMB();
    rb->tail = (uint16_t)(tail + 1);     // publish to consumer
    return 1;
}

int rb_dequeue(ringbuf_t *rb, uint16_t *out) {
    uint16_t head = rb->head;
    uint16_t tail = rb->tail;            // read producer tail (volatile)
    if ((head & RB_MASK) == (tail & RB_MASK)) return 0; // empty
    *out = rb->buf[head & RB_MASK];      // read data
    comp_barrier();                       // ensure read before advancing head
    PLATFORM_DMB();
    rb->head = (uint16_t)(head + 1);     // consume
    return 1;
}

Explanation of barriers / volatile

• volatile prevents the compiler from caching head/tail in registers across ISR/main boundaries.
• atomic_signal_fence(memory_order_release) ensures compiler reorders around publish points are prevented.
• On weakly-ordered CPUs (ARMv7-M, etc.) add a CPU data memory barrier (DMB) before publishing to guarantee stores are globally visible to the consumer/ISR.
• No mutexes needed because ownership of indexes is partitioned: ISR only writes tail, main only writes head; both may read the other's index.

Edge cases & notes

• Use power-of-two RB_SIZE; mask simplifies modulo.
• Ensure head/tail are wide enough for wrap-around semantics (16-bit required).
• If sample write/reads are larger than atomic machine width consider additional synchronization.

Overview — goal
Measure instantaneous current during runs, correlate peaks with firmware code paths so you can compute energy per function and per peripheral (Wi‑Fi bursts, sensor reads).

Hardware tools & setup

• Monsoon Power Monitor or battery emulator for accurate current vs time at high sample rates.
• High‑side current sense + low‑noise amplifer into a digitizing scope or data‑logger (e.g., Tek/Keysight oscilloscope, NI DAQ) for µs resolution.
• Current sense ICs (INA219/INA226) for long‑term logging (lower bandwidth).
• Optional: shunt + differential probe when measuring on actual battery.
• Decouple test board to inject test power and keep measurement wiring short.

Measurement procedure

1. Supply device from Monsoon or battery emulator, set sample rate ≥ expected event bandwidth (e.g., 1 MS/s for Wi‑Fi bursts).
2. Calibrate offset and measure idle baseline.
3. Trigger captures on GPIO toggle generated by firmware at function entry/exit, or use scope serial decode.
4. Run targeted scenarios (connect, TX burst, sensor read). Capture multiple iterations.

Software techniques to correlate

• Toggle a free GPIO at function entry/exit (fast, low overhead) to create markers in current trace.
• Use cycle counters / timestamps (ARM DWT) and log events over serial or RTT; align logs with capture by timestamp or by asserting a sync pulse.
• Instrument code selectively (start/stop sampling window) to limit overhead.
• Use RTOS trace (Segger SystemView, FreeRTOS+Trace) to map task activity to energy.

Energy calculation & analysis

• Compute energy with:

E = ∫ V(t) * I(t) dt

Intuition: multiply instantaneous voltage and current, integrate over event window. For constant V:

E ≈ V * Σ I[n] * Δt

• Average many samples to reduce noise; subtract baseline idle energy to get incremental cost.

Practical notes & tradeoffs

• GPIO marking is cheapest and precise; serial logging adds jitter.
• High sample rate instruments capture spikes but produce large data; use triggered captures.
• Watch measurement burden: shunt resistance and probes can change device behavior.
• For battery-life estimates, combine per‑event energy with event frequency and sleep current.

This approach gives per-function and per-peripheral energy numbers you can use to prioritize optimizations (reduce TX time, coalesce work, lower clock, tune peripheral power states).

I would diagnose this in four layers: alignment, execution, incentives, and measurement.

First, alignment. I would check whether everyone still agrees on the problem statement and the target outcome. If different leaders define success differently, teams can stay busy without moving the business.

Second, execution. I would review what actually shipped, what was adopted, and where the process slowed down. Busy meetings and shipped deliverables do not prove value if the critical users never changed behavior.

Third, incentives. I would ask whether teams are rewarded for the new outcome or for protecting their own function. If a team is measured on local throughput, it may resist work that helps the overall initiative.

Fourth, measurement. I would compare leading indicators and lagging indicators. For example, if a support automation project shipped six features but ticket volume did not drop, I would look at adoption, usage, and customer behavior before calling it a success.

I would bring leadership a simple readout: what was intended, what changed, where the bottleneck is, and what evidence supports that conclusion. That gives leaders a choice between fixing alignment, adjusting incentives, or changing the plan.

For example, on a two-quarter initiative to reduce customer support ticket volume through a new self-service help center, the four-layer check found: alignment was actually fine, everyone agreed the goal was fewer repeat tickets, not just more help-center pageviews. Execution had shipped six planned articles and a new search widget on time. Incentives were fine too, the support team was measured on ticket deflection and had every reason to want the initiative to work. The real problem was measurement: the team had been reporting help-center pageviews as the success metric, which had gone up 3x, but nobody had checked whether the same customers who viewed an article still opened a ticket afterward. Pulling that number showed 71% of pageviews were followed by a ticket within 24 hours anyway, meaning the articles were being read but weren't actually answering the question. The recommendation to leadership was not to kill the initiative or blame the team, but to replace the pageview metric with a deflection rate (viewed an article and did not open a ticket) and to revise the two articles with the worst deflection rate. Leadership approved continuing the initiative under the corrected metric rather than shutting it down, and deflection rate became the standing measure for the next quarter.

Approach (brief)
I2C register-read with a repeated START writes the target register address to the slave, then without STOP issues a repeated START and reads N bytes. This preserves bus control and avoids other masters intervening.

Pseudo-transaction
START
slave_addr + W (7-bit addr <<1 | 0) ; ACK/NACK
reg_addr_byte(s) ; ACK after each
REPEATED START
slave_addr + R (7-bit addr <<1 | 1) ; ACK/NACK
data0 -> master sends ACK (if more bytes expected)
data1 -> master sends ACK
...
dataN-1 -> master sends NACK (last byte)
STOP

Notes on ACK/NACK

• Master issues ACK after every received byte except the final one, where it sends NACK to signal end-of-read.

Error handling

• If slave NACKs after slave_addr+W or after reg_addr byte: abort, issue STOP, optionally retry with backoff; check wiring, pull-ups, and device power/state.
• If slave NACKs to repeated-start address+R: issue STOP, retry or report device not responding.
• If NACK occurs during data transfer unexpectedly: send STOP, optionally reset bus (clock pulses + STOP), increment error counter, and retry limited times. Log and escalate if persistent.

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.

Approach

• Use initial two-step calibration: coarse (measure offset vs true time) then temperature sweep to characterize frequency vs temperature.
• Store calibration coefficients (ppm offset, temp coefficient, polynomial) in NVM.
• At each wake compute corrected sleep interval to hit target wall-clock time, compensating for predicted RTC drift and temperature-dependent error. Periodically re-calibrate.

Pseudocode (C-style)

// NVM structure
typedef struct { int32_t ppm_offset; int32_t ppm_per_degC; int32_t ref_temp_mC; uint32_t crc; } rtc_cal_t;

// Read/write NVM helpers (platform-specific)
rtc_cal_t read_cal_from_nvm(void);
void write_cal_to_nvm(rtc_cal_t *cal);

// Convert ppm to fractional seconds per day: seconds_error = ppm * 86400 / 1e6
static double ppm_to_seconds_per_day(int32_t ppm){ return (double)ppm * 86400.0 / 1e6; }

// Initial calibration (run during manufacturing / first boot)
void initial_calibration(void){
  // 1) coarse: compare RTC to reference (NTP / GPS) over window
  int64_t ref_start = get_ref_time();
  int64_t rtc_start = rtc_read_seconds();
  sleep_ms(60000); // measure over 60s or longer
  int64_t ref_end = get_ref_time();
  int64_t rtc_end = rtc_read_seconds();
  double error_s = (rtc_end - rtc_start) - (ref_end - ref_start);
  int32_t ppm_offset = (int32_t)(error_s * 1e6 / (ref_end - ref_start));

  // 2) temperature sweep (simple two-point)
  int32_t t1 = read_temp_mC();
  int64_t rtc_measure_start = rtc_read_ticks();
  sleep_ms(300000); // 5 minutes at temp t1
  int64_t rtc_measure_end = rtc_read_ticks();
  double freq_err1_ppm = measure_ppm_from_ticks(rtc_measure_start, rtc_measure_end);
  // change temperature physically or use environment; measure freq_err2_ppm at t2
  int32_t t2 = read_temp_mC();
  double freq_err2_ppm = /* measured */;
  int32_t ppm_per_degC = (int32_t)((freq_err2_ppm - freq_err1_ppm) * 1000 / (t2 - t1)); // ppm per mC scaled

  rtc_cal_t cal = { ppm_offset, ppm_per_degC, /*ref_temp_mC=*/t1, compute_crc(...) };
  write_cal_to_nvm(&cal);
}

// Compute corrected sleep seconds to wake at target_wallclock (HH:MM:SS)
uint32_t compute_sleep_seconds(int target_wday, int target_h, int target_m, int target_s){
  rtc_cal_t cal = read_cal_from_nvm();
  int32_t cur_temp_mC = read_temp_mC();
  // predicted ppm = base + coeff * (T - ref)
  int32_t deltaT_mC = cur_temp_mC - cal.ref_temp_mC;
  int32_t predicted_ppm = cal.ppm_offset + (cal.ppm_per_degC * deltaT_mC) / 1000;
  // compute seconds until target wallclock according to RTC wall time
  int64_t now = rtc_read_time(); // seconds since epoch
  int64_t target = compute_next_target_epoch(now, target_h, target_m, target_s);
  double nominal_sleep = (double)(target - now);
  // compensate: actual drift during sleep approx = nominal_sleep * predicted_ppm / 1e6
  double adj_sleep = nominal_sleep - nominal_sleep * (double)predicted_ppm / 1e6;
  // clamp to safe bounds
  if(adj_sleep < 1.0) adj_sleep = 1.0;
  if(adj_sleep > 7*24*3600) adj_sleep = 7*24*3600;
  return (uint32_t)(adj_sleep + 0.5);
}

// Daily wake handler
void daily_wake_handler(void){
  // perform task, maybe sync to reference occasionally
  if(need_resync()){ // e.g., monthly or after large error
    initial_calibration(); // or a lighter re-calibration routine
  }
  uint32_t sleep_s = compute_sleep_seconds(/*daily*/0, 7,0,0); // example target 07:00:00
  rtc_sleep_seconds(sleep_s);
}

Key concepts & reasoning

• Model uses linear ppm + temp coefficient (sufficient for many crystals). Store in NVM for persistence.
• Predict error during sleep and shorten/lengthen sleep to hit wall-clock.
• Periodic re-calibration corrects long-term aging and non-linearities.
• Clamp bounds to avoid extreme sleep times and ensure safety.

Edge cases & improvements

• Use higher-order polynomial if oscillator shows non-linear temp response.
• Fuse-in real reference (NTP/GPS) when available for autonomous correction.
• Add CRC and versioning to NVM; protect against power loss during writes.

Approach overview
I’d methodically detect, localize and reproduce the leak using low-runtime overhead checks, instrumentation, and a deterministic stress harness so debugging is repeatable on bare-metal hardware.

Practical methods

• High‑water mark checks

  • Periodically record heap top / free heap and track the peak (high‑water). Log or expose via UART. If peak steadily rises that confirms leak.
  • Example: read current heap pointer or call to allocator stats and save max.

• Sentinel / canary fill patterns

  • Initialize newly allocated buffers with a pattern (0xDEADBEEF) and check for corruption/partial writes to find overruns that can cause leaks or lost pointers.
  • Use a guard region around allocations if allocator permits.

• Wrap malloc/free for instrumentation

  • Replace allocator calls with wrappers that record caller, size, and a backtrace or return address. Maintain a simple table keyed by ptr to detect forgotten frees.
  • Example wrapper:

// simple malloc/free wrapper
void *tracked_malloc(size_t s, const char *site) {
  void *p = malloc(s);
  if (p) record_alloc(p, s, site);
  return p;
}
void tracked_free(void *p, const char *site) {
  if (p) { record_free(p, site); free(p); }
}

• On embedded, store compact metadata (16–32 bytes) or send to host on demand.

• Build a stress harness

  • Create deterministic test vectors that exercise allocation paths repeatedly (sensors, comms, timers). Run in tight loop while logging heap high‑water and allocation table diffs.
  • Vary timing and inputs to trigger subtle races.

• Static code analysis and code review

  • Scan for common patterns: conditional returns after allocation, missing frees in error paths, mismatched ownership, global pointer overwrites. Use tools like cppcheck or clang static analyzer where possible.

Reproducing deterministically

• Reduce variables: run single-threaded or disable interrupts, use fixed seed inputs, and stub external I/O.
• Add checkpoints that dump allocation table and call stacks when growth crosses thresholds.
• Bisect test cases: enable/disable features to find the module causing increases.
• Use hardware breakpoints/watchpoints on allocation metadata or pointer writes to catch the moment memory becomes unreachable.

Why this works

• High‑water and wrappers detect existence and extent. Sentinel regions catch corruption. Stress harness and deterministic inputs let you reproduce and bisect. Static analysis reduces candidate causes so you can localize and fix with minimal live debugging on constrained hardware.

Situation & goal
I would integrate static analysis and formal tools into our CI to find class-A defects early in firmware (memory, undefined behavior, concurrency) while keeping developer flow fast and measurable.

Tool selection & roles

• MISRA (C) — coding-convention and safety ruleset for automotive/medical-style compliance.
• clang-tidy — fast style/bug checks and modernizations; run locally/pre-commit.
• Coverity (or similar commercial) — heavy-weight interprocedural defect detection in CI.
• CBMC — bounded model checking for safety-critical functions (bootloader, crypto, scheduler).

Ruleset choice

• Start with a conservative MISRA subset (mandatory + project-specific high-risk rules).
• Enable clang-tidy checks for performance, lifetime and nullptr issues; disable noisy checks initially.
• Use Coverity default CWE-focused suite; add project-specific patterns (ISR misuse, DMA races).
• For CBMC, target small, well-specified modules with formal specs (asserts, pre/post conditions).

Suppressions & triage

• Only allow suppressions with a ticket: use structured comment: /* SUPPRESS: RULE-ID; JIRA-123; EXPIRES:2025-06 */.
• Triage workflow: triage board in sprint backlog; assign severity (blocker/major/minor), owner, and SLAs.
• Capture false positives in a shared whitelist that expires and is reviewed quarterly.

Pre-commit vs gated checks

• Pre-commit (fast): clang-tidy (subset), style, unit tests; fail locally to reduce churn.
• Gated PR CI: MISRA scan + Coverity incremental analysis; block merge on new HIGH or CRITICAL defects.
• Nightly/integration: full Coverity, complete clang-tidy, CBMC runs (long-running); post results to PRs and dashboards.

Metrics to evaluate impact

• Defect rate: # defects found in QA and field per KLOC before vs after (target 30–60% reduction).
• Developer productivity: mean time to merge, review time, and commits per feature; track pre-commit rejection rate.
• False positive rate and triage backlog age.
• Time-to-fix by severity and % of defects caught pre-merge.
• Code churn around suppressed items.

Rollout plan

• Pilot on one repo: tune rules for 4 sprints, measure metrics, iterate. Enforce gating only after false-positive rate < 20% and dev approval.

This balances fast developer feedback, strong CI enforcement for risky code paths, and formal verification for highest-assurance components.

Brief description
Dual-partition A/B uses two firmware slots (A and B). The device runs from one slot while the other is updated, enabling atomic swaps and rollback if the new image fails.

Typical partition layout

• Bootloader (ROM/primary boot stage)
• Partition table / A/B metadata (flags, active slot, version, checksums)
• Boot partition A (kernel + rootfs / firmware image)
• Boot partition B (same layout as A)
• Data / persistent storage

How bootloader chooses a partition

• Read A/B metadata: active_slot, successful_flag, boot_count, checksum/state
• If active_slot marked successful → boot that slot
• If previous boot failed and boot_count < threshold → mark candidate as untested and try alternate
• Verify checksum/signature before handing control; else fallback

How updates are written

• Write new firmware to the inactive slot (e.g., B if running A)
• Verify integrity (hash/signature) after write
• Update metadata to mark inactive as “pending” with boot_count = 0
• Do not alter active slot until new image is proven

Safe switch / rollback

• Bootloader attempts new slot and increments boot_count
• User-space or init sends a “mark successful” to metadata after health checks (services up, watchdog cleared)
• If successful_flag set within threshold, bootloader marks new slot as active and clears previous
• If boot_count exceeds threshold or integrity/health checks fail, bootloader rolls back to previous known-good slot automatically
• Use hardware watchdog and atomic metadata updates to avoid bricking

Notes / best practices

• Use signed images, atomic writes for metadata, small boot_count window (e.g., 3 boots)
• Keep persistent state separate or use migration logic
• Example implementations: Android A/B, RAUC, SWUpdate patterns commonly used in embedded systems.