DoorDash Entry-Level Embedded Developer Interview Preparation Guide

Approach

• Use volatile pointers to memory-mapped registers.
• Use bit masks for pin 3 (bit 3).
• Do a read-modify-write for DIR and PULLUP to avoid altering other pins.
• Return logical 0/1 from GPIO_IN masked and shifted.

#include <stdint.h>

#define GPIO_DIR_ADDR     ((volatile uint32_t *)0x40000000)
#define GPIO_PULLUP_ADDR  ((volatile uint32_t *)0x40000004)
#define GPIO_IN_ADDR      ((volatile uint32_t *)0x40000008)

#define PIN3_MASK         (1U << 3)

/* Configure pin 3 as input with pull-up enabled and return its value (0 or 1) */
static inline int read_pin3_with_pullup(void)
{
    /* Set as input: clear bit in DIR (1 = output, 0 = input) */
    uint32_t dir = *GPIO_DIR_ADDR;
    dir &= ~PIN3_MASK;
    *GPIO_DIR_ADDR = dir;

    /* Enable pull-up: set bit in PULLUP register */
    uint32_t pu = *GPIO_PULLUP_ADDR;
    pu |= PIN3_MASK;
    *GPIO_PULLUP_ADDR = pu;

    /* Read pin value, return 0 or 1 */
    return ( ( *GPIO_IN_ADDR & PIN3_MASK ) ? 1 : 0 );
}

Why volatile and RMW

• volatile prevents compiler optimizations that could cache register values or reorder accesses; required for hardware registers.
• Read-modify-write preserves other pins' configuration.
• Using explicit masks keeps code clear and safe for concurrent peripheral usage.

Situation & goal
Design a robust RTOS watchdog strategy that detects stuck/livelocked tasks, minimizes false positives for legitimate blocking (I/O, network), and supports graded recovery (task restart, log capture, system reset).

Per-task heartbeat design

• Each critical task obtains a small heartbeat structure:
  • task_id, last_beat_timestamp, allowed_block_ms, state_mask (RUNNING/WAIT_IO/SUSPENDED).
• Task calls heartbeat_kick(task_id) at safe checkpoints (loop iteration, state transition).
• For blocking waits, tasks set state_mask = WAIT_IO and call heartbeat_pause(task_id, expected_block_ms) before blocking; on wake, call heartbeat_resume(task_id).

Central watchdog petting policy

• A supervisory Watchdog Manager task runs at interval T_check (e.g., 100 ms).
• It scans heartbeats and computes:
  • if state == RUNNING and now - last_beat > run_threshold → mark unhealthy
  • if state == WAIT_IO and now - last_beat > allowed_block_ms + hysteresis → mark unhealthy
• Only if no tasks unhealthy for a short quiescent window and system health overall ok does the manager pet the hardware watchdog.

Allowed blocking periods

• Per-task allowed_block_ms set per task class (e.g., sensor read 50 ms, network 5s).
• Use conservative defaults + dynamic extension: tasks can request heartbeat_extend(extra_ms) with quota tracking to avoid abuse.

Recovery actions (graded)

• First detection → capture context: task backtrace, CPU registers, minimal ring log (use lockless single-writer buffer), increment fault counter.
• Attempt soft recovery: signal task to restart via RTOS API (vTaskDelete + vTaskCreate / safe restart function). If task restart succeeds → resume.
• If repeated failures or multiple critical tasks fail → escalate: stop petting watchdog to force system reset, or call platform-appropriate system_reset().
• Always persist minimal fault summary to nonvolatile storage when possible before reset.

Implementation notes (practical)

• Use RTOS hooks (task notify, idle hook) and low-overhead atomic operations for heartbeat updates.
• Keep heartbeat update cheap (single atomic store of timestamp).
• Protect manager scan with priority above typical tasks but below interrupts.
• Example heartbeat API (C):

// lightweight API
void heartbeat_kick(uint8_t task_id);            // update timestamp, state RUNNING
void heartbeat_pause(uint8_t task_id, uint32_t ms); // set WAIT_IO and allowed_block_ms
void heartbeat_resume(uint8_t task_id);          // set RUNNING

Trade-offs & safeguards

• Hysteresis and multiple-sample confirmation reduce false positives.
• Quotas for extensions prevent misbehaving tasks from disabling watchdog.
• Keep hardware watchdog petting decision centralized to avoid tasks accidentally starving reset.

This approach balances detection sensitivity with flexibility for legitimate blocking, provides graded recovery, and keeps runtime overhead minimal for embedded constraints.

Brief comparison

• DVFS (Dynamic Voltage and Frequency Scaling): adjusts core voltage and clock frequency at runtime to trade performance for lower dynamic power (P ∝ V^2·f). Good for fine-grained, active-mode power control.
• Traditional sleep/idle modes: stop clocks, disable peripherals, or power domains; reduce both dynamic and static power. Often called idle, standby, deep-sleep, or power-down with increasing wake latencies.

When each is preferable

• DVFS:
  • CPU-bound tasks with variable load (sensor processing, ML inference with bursty load).
  • When you need responsiveness but can slow down execution to save energy.
  • Constrained wake latency — changes take microseconds–milliseconds.
• Sleep/idle modes:
  • Long idle periods (radio-off between periodic reports, event-driven sensors).
  • When leakage dominates or peripherals can be gated.
  • Deep sleep wakeup can be milliseconds to seconds (depends on oscillator/RTC).

Latency & overhead

• DVFS: low to moderate overhead — changing frequency/voltage requires clock and regulator transitions; latency typically tens of microseconds to a few milliseconds; energy cost for transition small relative to short active periods.
• Sleep modes: entry/exit overhead varies widely; light sleep: microseconds–ms; deep sleep: ms–100s ms; energy saved is large but only worth it if idle duration exceeds break-even time (consider state restore cost).

Combining strategies for IoT

• Tiered policy:
  • Use DVFS during active processing to run slower at lower voltage when deadlines allow.
  • Enter light sleep between short gaps (use fast wake sources).
  • Enter deep sleep for long inactivity; save full context to minimize restore time.
• Practical considerations:
  • Calculate break-even time for each mode (include state save/restore energy).
  • Keep critical peripherals on separate power domains (radio wake retention).
  • Use predictive workload scheduling or token-bucket to batch work and maximize deep-sleep opportunities.

This approach balances responsiveness and energy for constrained embedded IoT devices.

Approach (one-line)
Goal: minimal memory, deterministic CPU use — stream pixels using line buffers, compute kernel with integer/fixed-point, exploit separability if possible, and use SIMD/DSP when available.

Design details

• Fixed-point: represent coefficients as signed Q15 or Q8 depending on dynamic range; pre-scale kernel so multiply-adds become int32 accumulates then shift back. Use saturating arithmetic to avoid overflow.
• Line buffers: store two previous rows (3 rows total) as uint8 arrays to stream; process output per pixel as soon as the 3x3 window is ready — reduces frame buffer to ~2 * width bytes.
• Separable kernels: if kernel is separable (e.g., Sobel ~ [1 0 -1] x [1 2 1]), do two passes: horizontal then vertical with one-line buffer for intermediate — cuts operations from 9 to 6 per pixel and improves cache.
• Loop tiling & unrolling: tile by blocks of columns (e.g., 16 or 32) to keep working set in registers; fully unroll inner loop for small tiles to remove index overhead. Use restrict pointers and manual prefetching where supported.
• SIMD / DSP: if MCU has 8/16-bit SIMD (e.g., ARM Cortex-M4 DSP extensions), implement multiply-accumulate with SIMD intrinsics for 4 or 8 pixels in parallel — yields large speedups. If small standalone DSP is available, offload convolution; ensure DMA can stream lines to DSP to avoid CPU stalls.
• Trade-offs: separable pass needs extra memory for intermediate row (width bytes) and two passes over frame — but arithmetic reduced. Unrolling increases code size; balance with flash constraints.

Practical snippet (conceptual C using Q15 and line buffers)

// process 1 pixel using int accumulators (conceptual)
int16_t k[3] = { -1, 0, 1 }; // Q0 for Sobel-h
int32_t acc = (int32_t)k[0]*row0[x-1] + (int32_t)k[1]*row0[x] + (int32_t)k[2]*row0[x+1];
acc += (int32_t)k[0]*row1[x-1] + ...; // for full 3x3 or do separable pass
out[x] = saturate_u8((acc + ROUND) >> SHIFT);

When to offload

• Use SIMD/DSP if available and DMA can feed line buffers; otherwise optimized fixed-point C with careful tiling/unrolling and line buffers will meet 320x240@30fps on most M-class MCUs.

Clarify goal & constraints

• Sensor amplitude = 10 mV. Target effective 16‑bit resolution referenced to a 2.048 V FS gives LSB ≈ 2.048 V / 2^16 = 31.25 µV. So input-referred RMS noise must be significantly below ~30 µV (target ~10–15 µV RMS to allow margin).

High-level choice: ADC

• Prefer delta‑sigma ADC for best input noise and integrated digital filtering (e.g., ADS1220 family for low-rate, AD7768/AD712 for higher throughput). SAR can work if front-end settles and you implement high-performance filters; SARs typically need more analog anti-alias filtering and precision PGA.
• Recommendation: delta‑sigma with internal PGA (gain selectable to avoid saturating) and >18–24 bit nominal resolution, ENOB at target sample rate ≥16 bits.

Analog front-end

• Gain: amplify 10 mV to near FS. For 2.048 V FS, use gain ≈ 205. Implement as two stages: low-noise instrumentation preamp (CMRR for differential sensor) then precision buffer/PGA.
• Op-amps: select low input‑noise (en < 1 nV/√Hz), low offset, low bias (examples: AD8610/ADA4528/OPA188 family depending on frequency). Use chopper/opamp only if offset drift is an issue.
• Filtering: anti‑alias RC or active low-pass. For delta‑sigma less aggressive, but include input RC and second‑order filter to limit bandwidth to reduce integrated noise. Target bandwidth so that noise integrated < ~10–15 µV RMS.
• Input impedance: high relative to sensor; ensure source drive can handle input bias currents. Use input buffer if sensor source impedance is high.
• Layout: keep gain stage as close as possible to sensor, short traces, guarding for high-impedance nodes.

Reference & buffering

• Use low-noise, low‑drift reference (ADR4525/REF5030 or similar) with PSRR. Buffer reference with low-noise op amp if ADC requires it or use internal ref if high-quality.
• Place reference decoupling and backup caps close to ADC ref pins.

PCB layout & grounding

• Separate analog and digital domains with single star point near ADC/reference return.
• Short, direct analog traces; avoid digital signals crossing analog areas.
• Stitch grounds with vias; use plane splits only if necessary and return digital currents on digital plane.
• Place analog components (op amps, ADC, ref) close together; route sensitive traces away from clock lines.
• Use guard rings around high‑impedance inputs and thermally stable placement for precision resistors.

Supply decoupling & power

• Local decoupling: 0.1 µF + 10 µF near pins; add 100 nF + 1 µF for LDOs. Use low-noise LDOs for analog rails.
• Sequencing: ensure ADC/reference stable before sampling.

Firmware techniques

• Oversampling and decimation: increase SNR by OSR; e.g., 4× oversampling improves SNR by 6 dB (1 bit). Use digital filter taps from ADC or implement custom CIC+FIR if needed.
• Averaging with care (avoid correlated noise): use power-spectral analysis to set sample windows and filters.
• Calibration: two-point calibration (offset & gain) at start-up and periodic. Store coefficients and apply in fixed-point math. Temperature compensation: measure local temp and apply polynomial correction.
• Offset/gain correction: collect known reference measurements (short to ground, apply known voltage) and compute linear correction: V_corrected = (V_raw - offset) * gain_scale.
• Monitor ADC status, CRC, and perform self-test sequences; use synchronous sampling if multiple channels.

Example numbers

• ADC: AD7768 at 2 kSPS, ENOB ~18 at chosen bandwidth OR ADS1220 (24‑bit, low‑rate) for simpler MCU integration.
• Front-end noise target: keep Input‑referred noise < 10–15 µV RMS. With amplifier en = 1 nV/√Hz and bandwidth 1 kHz, integrated noise ≈ en * sqrt(BW) ≈ 1 nV * sqrt(1000) ≈ 31.6 nV — after gain 205 gives ~6.5 µV — meets target.

Trade-offs

• Delta‑sigma: simpler analog F/E, high resolution, limited high-rate throughput and higher latency.
• SAR: lower latency and power, needs cleaner analog anti‑alias filtering and precision PGA.

Implement incremental validation: measure noise at each node (sensor out, post‑amp, ADC input) with spectrum analyzer, iterate filter bandwidth and gain, then tune firmware oversampling and calibration.

Approach (brief)
Use branchless two's‑complement trick to compute abs: create a sign mask from x >> 31, compute (x + mask) ^ mask. That yields |x| for all values except INT_MIN (where negation overflows and result stays INT_MIN). Detect INT_MIN with an equality against 0x80000000u (unsigned compare), produce a 0 or -1 mask, and XOR to convert INT_MIN (0x80000000) into INT_MAX (0x7FFFFFFF). All operations are arithmetic/bitwise — no conditional branches.

#include <stdint.h>
#include <limits.h>

int32_t abs_saturated_branchless(int32_t x) {
    /* sign: 0 for non-negative, -1 for negative */
    int32_t sign = x >> 31;
    /* branchless absolute (wraps for INT_MIN) */
    int32_t y = (x + sign) ^ sign;
    /* detect INT_MIN without branching: (unsigned)x == 0x80000000u -> 0 or 1 */
    int32_t is_min = -((unsigned int)x == 0x80000000u); /* 0 or -1 */
    /* if is_min == -1, XOR flips 0x80000000 -> 0x7FFFFFFF; otherwise XOR 0 */
    return y ^ is_min;
}

Key points / reasoning

• x >> 31 yields arithmetic sign extension; safe for two's‑complement.
• (x + sign) ^ sign computes absolute value without branches.
• INT_MIN special-case detected via unsigned equality; negating produces 0 or -1 mask.
• XOR with -1 transforms INT_MIN (0x80000000) to INT_MAX (0x7FFFFFFF).

Time/space: O(1) time, O(1) space. No undefined behavior: no signed overflow, no conditional branches, only well-defined bitwise and shifts on two's‑complement targets typical in embedded systems.

Edge cases: works for all int32 values, returns INT_MAX for INT_MIN. Ensure compiler uses arithmetic right shift for signed >> (common on embedded ABIs) — if target uses logical shift, cast to int32_t/ensure implementation-defined behavior or use unsigned arithmetic with ((uint32_t)x >> 31) and adjust accordingly.

Brief approach / steps

• Copy initialized data (.data) from its load address in flash to its run address in RAM.
• Zero the .bss region in RAM.
• Optionally call constructors (C++), init hardware, then jump to main.
• If time-critical functions live in RAM, ensure their flash-load image is copied to RAM before they execute.

Typical linker symbols

• _sidata : start of initialized data in flash (load address)
• _sdata : start of .data in RAM (run address)
• _edata : end of .data in RAM
• _sbss : start of .bss in RAM
• _ebss : end of .bss in RAM

Concise C startup routine

extern uint32_t _sidata; /* in flash */
extern uint32_t _sdata;  /* in RAM */
extern uint32_t _edata;
extern uint32_t _sbss;
extern uint32_t _ebss;

void Reset_Handler(void) {
    uint32_t *src = &_sidata;
    uint32_t *dst = &_sdata;

    /* copy .data from flash to RAM */
    while (dst < &_edata) {
        *dst++ = *src++;
    }

    /* zero .bss */
    dst = &_sbss;
    while (dst < &_ebss) {
        *dst++ = 0;
    }

    /* If functions are executed from RAM, ensure their image is copied here
       before calling them. Then call system init and main(). */
    SystemInit();
    main();
}

Why place time-critical functions in RAM

• RAM execution removes flash wait states and flash controller contention, reducing latency and improving determinism (critical for ISRs, DMA-sensitive code, or flash-inaccessible modes like during erase/write).
• Impact on startup: you must include an extra copy step in startup to relocate those functions' code from flash to their RAM addresses (with corresponding linker symbols, e.g., _siram_text/_eiram_text and _siram_text_lma). That copy must occur before any code calls those routines (including interrupts). Also ensure vector table points to RAM if ISRs run there.

Clarify goal & constraints

• Reduce generated code across TUs and link time while preserving type safety and low RAM/flash for embedded targets. Keep predictable performance and no RTTI if constrained.

Practical techniques

1. Explicit instantiation / extern template

• Move heavy template impl to one .cpp and instantiate only needed types.

// heavy.h
template<typename T> T heavy_op(T);
// heavy.cpp
#include "heavy.h"
template<typename T> T heavy_op<T>(T x){ /*...*/ }
template double heavy_op<double>(double);
// user.cpp
extern template double heavy_op<double>(double);

• Result: only one copy of code emitted.

2. Pimpl / move implementation to single TU

• Expose thin non-template façade in headers, template internals in .cpp via concrete types or small virtual interface when few types exist.
• Trade-off: small vtable overhead vs code size savings.

3. Type-erasure / runtime-polymorphism for many template combos

• Use small type-erasure wrapper (inlined small-buffer) to hold different concrete instantiations but compile one implementation path.

// simplified: store callable with erased type to avoid templating across TUs
class Erased {
  struct I { virtual void run()=0; };
  template<typename F> struct Impl : I { F f; void run() override{ f(); } };
  std::unique_ptr<I> p;
public:
  template<typename F> Erased(F fn): p(new Impl<F>{fn}){}
  void run(){ p->run(); }
};

• Preserves safety at runtime, reduces template explosion.

4. Reduce template parameter space

• Narrow template axes: prefer traits, enums, tag types, or constexpr parameters grouped into bitfields so compiler sees fewer unique instantiations.
• Example: replace bool template params with runtime flags or a single enum tag.

5. Move heavy templates to single TU (monolithic instantiation)

• If a template truly needs to be generic, provide explicit instantiations for supported types only; reject others with static_assert.

Trade-offs & metrics

• Measure binary size and link time before/after; check stack/heap impact of indirection/vtables.
• Prefer explicit instantiation for deterministic embedded performance; use type-erasure when many combinations impossible to statically enumerate.

Recommendation
Start with extern template/explicit instantiation for top offenders, add Pimpl for large classes, then consider type-erasure or parameter consolidation if instantiation count remains high.

Direct answer
Three boundaries matter most: confidentiality (what's said in a mentoring conversation doesn't automatically become input to a performance review), favoritism (visible time and opportunity should be fair and roughly trackable, not just felt fair), and the evaluator conflict (mentoring someone you also formally evaluate creates a structural incentive problem, since they cannot be fully candid with someone who scores them). The practical fix is not avoiding all overlap, since it is often unavoidable, it is naming the boundary explicitly up front and having a plan for when it blurs.

Structured elaboration

Worked example
Situation: I was mentoring someone I would later be asked to give calibration input on for a promotion cycle.
Task: keep the mentoring relationship honest without compromising the integrity of the eventual evaluation.
Action: I told them directly, early, that promotion calibration might eventually involve my input, so mentoring conversations and evaluation conversations were separate. When something they shared in a mentoring context, a specific technical mistake, later became relevant to an honest performance discussion, I went back to them first rather than using it silently, and asked how they wanted it handled.
Result: the relationship stayed trustworthy because the boundary was named rather than assumed, even though the overlap between mentor and evaluator could not be fully removed.

Trade-offs & pitfalls
Pretending you can be a purely neutral mentor when you structurally have some evaluator influence is dishonest and erodes trust once it surfaces. Over-formalizing boundaries, a written contract for every casual pairing, feels bureaucratic when the stakes don't call for it, so match the formality to the actual overlap: an evaluator relationship needs an explicit conversation, a casual peer pairing usually doesn't. The senior distinction is naming the boundary before it's tested, not scrambling to explain it after a mentee feels burned.

Approach (brief)
Set up SPI peripheral as master full-duplex; configure two DMA channels: one memory->peripheral (TX), one peripheral->memory (RX). Start RX DMA first (so peripheral RX is ready), then start TX DMA and enable SPI. Synchronize via DMA-complete interrupts or checking transfer-complete flags. Handle mismatched sizes by transmitting dummy bytes or discarding extra RX bytes. Maintain cache coherency: clean TX buffer before DMA, invalidate RX buffer after DMA.

Pseudocode (C)

// Pseudocode: configure and kick off full-duplex SPI DMA transfer of N bytes
void spi_dma_transfer(uint8_t *tx_buf, size_t tx_len,
                      uint8_t *rx_buf, size_t rx_len, size_t N) {
    size_t tx_count = (tx_len >= N) ? N : N; // we'll send real bytes then dummies
    size_t rx_count = N;

    // 1) Cache maintenance
    if (HAS_DCACHE) {
        if (tx_buf) dcache_clean_region(tx_buf, tx_len);    // ensure memory visible to DMA
        if (rx_buf) dcache_invalidate_region(rx_buf, rx_len); // avoid stale data
    }

    // 2) Configure SPI peripheral for N bytes (master, full-duplex)
    spi_init_master_full_duplex();

    // 3) Configure DMA channels
    dma_config_t dma_tx = {
      .dir = MEM_TO_PERIPH, .src = tx_buf ? tx_buf : &dummy_byte,
      .dst = &SPI->DR, .len = N, .src_inc = !!tx_buf, .dst_inc = 0
    };
    dma_config_t dma_rx = {
      .dir = PERIPH_TO_MEM, .src = &SPI->DR, .dst = rx_buf,
      .len = N, .src_inc = 0, .dst_inc = 1
    };
    dma_setup_channel(DMA_CH_RX, &dma_rx);
    dma_setup_channel(DMA_CH_TX, &dma_tx);

    // 4) Start sequence: enable RX DMA first, then TX DMA, then enable SPI/DMA requests
    dma_enable(DMA_CH_RX);
    dma_enable(DMA_CH_TX);
    spi_enable_dma_rx(); // enable SPI DMA request for RX
    spi_enable_dma_tx(); // enable SPI DMA request for TX
    spi_enable();        // start SPI clocks

    // 5) Wait/synchronize: use DMA interrupts or poll completion
    wait_for_dma_complete(DMA_CH_RX);
    wait_for_dma_complete(DMA_CH_TX);

    // 6) Post-transfer cache maintenance
    if (HAS_DCACHE && rx_buf) dcache_invalidate_region(rx_buf, rx_len);

    // 7) Cleanup: disable SPI DMA requests, clear flags
    spi_disable_dma_rx(); spi_disable_dma_tx(); spi_disable();
    dma_clear_flags(DMA_CH_RX); dma_clear_flags(DMA_CH_TX);
}

Notes & Reasoning

• Start RX DMA first so peripheral RX writes have destination ready; start TX to generate clocks.
• If tx_buf shorter than N, point TX DMA to a single-word dummy byte (non-incrementing) after real bytes; if rx_buf smaller than N, discard extra bytes or limit RX length.
• Use DMA interrupts (highest priority) to minimize CPU wait; on RTOS signal a task.
• Cache: clean TX before DMA (writeback), invalidate RX after DMA (invalidate) to ensure CPU reads updated data.
• Edge cases: SPI overrun if RX not ready, peripheral FIFO sizes, alignment and DMA burst/size configuration, handling errors/timeouts.