DoorDash Embedded Developer (Junior Level) Interview Preparation Guide

Static (compile/link-time) allocation

• Predictability: Very high — sizes and addresses known at build time, no runtime allocation jitter. Good for deterministic timing budgets.
• Memory fragmentation: None — fixed-layout avoids heap fragmentation; memory usage is constant.
• Testability: High — easier to unit-test and simulate; fault scenarios reproducible since state is deterministic.
• Real-time suitability: Excellent for hard real-time and safety-critical systems. Suitable for ISRs and low-latency paths.
• Cons: Less flexible, can waste RAM if buffers are oversized; harder to adapt to runtime variability.

Dynamic (heap/allocator or pool) allocation

• Predictability: Lower — allocation/deallocation incur variable latency unless using designed pools; general heap operations can introduce unbounded delays.
• Memory fragmentation: Risky — standard heaps fragment over time; fragmentation can cause allocation failures even with free total space.
• Testability: Moderate — need tests for allocation failure modes, concurrent allocations, and timing; harder to reproduce non-deterministic bugs.
• Real-time suitability: Poor for hard real-time unless constrained (fixed-size block pools, region allocators, or real-time aware allocators). Use with care in RT paths.
• Pros: Flexible, memory-efficient for variable workloads; supports dynamic data structures.

Recommendations:

• Prefer static allocation for critical, low-level, and deterministic components.
• If dynamic behavior is required, use bounded allocators (fixed pools, slab allocators) and instrument worst-case execution time (WCET) tests and stress tests to ensure real-time constraints.

Explaination (what & why)
Endianness is the byte order used to represent multi-byte values in memory. Little-endian stores the least-significant byte at the lowest address; big-endian stores the most-significant byte first. On embedded systems this matters because peripherals, DMA and network protocols may use a different order than the CPU, causing corrupted values when reading/writing registers or buffers.

Practical bugs (concrete examples)

• Sensor over SPI that sends 16-bit samples MSB-first while the MCU is little-endian: reading two bytes and casting to uint16_t without swapping yields swapped magnitude/sign.
• DMA transfers shared with a peripheral that expects big-endian words: the DMA writes native-order words and the peripheral interprets wrong channels/addresses.
• Packed bitfields used for register maps: compiler-dependent layout + endianness leads to incorrect bit positions across architectures.

Strategies for C drivers (practical)

• Always document peripheral byte order in the driver.
• Use explicit byte-swap helpers, not casts:

// portable swap for 32-bit
static inline uint32_t bswap32(uint32_t x) { return __builtin_bswap32(x); }

• Provide serialization helpers for buffers: read_be16(), read_le16(), write_be32(), etc.
• Avoid packed bitfields for HW registers; use masks/shifts on integer types:

uint32_t reg = mmio_read32(addr);
uint32_t field = (reg >> FIELD_SHIFT) & FIELD_MASK;

• Use compiler/OS helpers when available (htons/ntohs) and assert sizeof types.
• When using DMA, ensure the DMA controller endianness/byte-permutation settings match peripheral, or perform swapping in software after transfer.
• Add unit tests with known patterns (0x11223344) and CI on both endian targets if possible.

Following these practices prevents subtle data corruption and makes drivers portable and maintainable.

I would frame the discussion around user impact, risk, and reversibility. A workaround is a temporary fix that reduces pain now, while the root issue is the underlying cause we still need to solve. I would ask: how many users are affected, how severe is the problem, and how risky is the workaround itself?

If the workaround is low risk and reversible, I would lean toward shipping it now and scheduling the root fix immediately after. For example, if users are blocked by a broken validation rule and we can safely relax it, I would ship the workaround, monitor errors, and commit to the deeper fix in the next cycle. If the workaround could corrupt data or create a bigger support burden, I would slow down and fix the root issue first.

I would make the decision explicit, document the trade-off, and assign an owner for the follow-up fix. That way the team is not pretending the workaround is the final answer, and users get relief as soon as it is safe to do so.

Clarify requirements & constraints

• Constrained MCU (KB–MB flash, limited RAM), intermittent power, limited bandwidth, need auth, anti-rollback, integrity, resume, delta support. Secure boot/root key in immutable ROM.

High-level design

• Dual-bank A/B layout with bootloader in ROM/immutable flash. Bootloader enforces verification and atomic switch.
• Root key: Ed25519 public key stored in ROM (or fused). Use signatures for authenticity; use HKDF + AES-GCM for optional encrypted payloads.

Cryptographic primitives

• Signature: Ed25519 (small, fast, safe against misuse).
• Integrity/MAC for streamed ops: SHA-256 for hashes; AES-128-GCM for authenticated encryption (if confidentiality needed).
• KDF: HKDF-SHA256 for deriving ephemeral keys for delta patches.

Image metadata

• image_length
• image_version (monotonic increment)
• rollback_counter (monotonic)
• base_hash (SHA-256 of base image if delta)
• image_hash (SHA-256 of full image or post-patch)
• signature (Ed25519 over metadata || image_hash)
• flags: delta/applied/compressed
• compression type, patch algorithm id

Verification & update flow

1. Transfer image (or delta) to temporary staging region with progress checkpointing.
2. Verify signature: compute image_hash (for delta, verify base_hash matches running image) then verify Ed25519(signature, metadata || image_hash) using ROM public key.
3. Check rollback: require image_version > stored_monotonic_version (stored in secure monotonic flash or anti-rollback counter area). Only accept greater.
4. Integrity: verify SHA-256 matches.
5. Apply update:
   • For full image: atomically write to inactive bank; verify write by re-hashing.
   • For delta: verify base_hash equals active bank hash; apply patch to inactive bank while streaming and computing SHA-256; if patch fails, abort.
6. Commit: update monotonic_version atomically (use small atomic write or hardware monotonic counter), set boot flag to boot new bank, trigger watchdog reset.
7. Bootloader validates new bank at next boot; if validation fails or boot doesn't complete within watchdog timeout, auto-rollback to previous bank.

Rollback protection

• Monotonic counter stored in write-once / monotonic storage if available, or in redundant, wear-leveled flash with anti-tamper logic; require image_version > stored value before commit. Only increment after successful full verification to avoid fork.

Interrupted updates & recovery

• Chunked transfer with checkpointed offsets; keep both banks intact until new bank verified.
• If interruption, resume transfer using checkpoint; if patching interrupted, discard incomplete inactive bank and resume from last validated chunk.
• Watchdog + bootloader timeout ensures failed boots revert to known-good bank.

Delta updates safety

• Use content-addressed deltas: patch signed server-side producing patch_blob plus base_hash and resulting image_hash.
• Before applying, verify active image hash == base_hash. Reject if mismatch.
• Apply patch in streaming manner to inactive bank, computing hash on the fly. Use checksums per chunk to detect mid-patch corruption.
• Optionally use Merkle-tree or chunked hashes to allow partial verification and resume of patching, minimizing retransfer.

Bandwidth minimization

• Compress payload (zstd/DEFLATE), send binary delta (bsdiff or custom block-diff), use chunked transfers with HTTP range or CoAP block-wise transfers.

Practical considerations

• Keep bootloader minimal and well-audited.
• Test failure modes, power-loss during write, and ensure flash wear leveling.
• Log update attempts and failures to a persistent slot for diagnostics.

This design balances security (Ed25519, SHA-256, monotonic version), reliability (A/B + watchdog), and bandwidth (signed deltas + compression) suitable for constrained embedded devices.

Brief approach / goals
As an embedded developer I’d design a hybrid allocator that guarantees bounded (real‑time) alloc/free latency, minimizes fragmentation for long‑lived systems, supports variable sizes, and offers reclamation strategies without heavy CPU or RAM cost.

Candidate algorithms

• TLSF (Two-Level Segregated Fit)
  • O(1) alloc/free, good fragmentation control for variable sizes.
  • Small metadata, predictable timing → ideal for hard/soft real‑time.
• Slab allocator / object pools
  • Best for fixed‑size, long‑lived objects (drivers, buffers). Zero fragmentation within slab, deterministic.
• Segregated free lists / power-of-two pools
  • Simple, bounded time, trade memory for internal fragmentation.
• Hybrid
  • Use slabs/pools for common long‑lived types + TLSF for miscellaneous allocations.

Metadata layout (compact, suitable for C)

• Per-block header (placed at block start):
  • 32-bit fields on 32-bit MCUs: [ size : 24 bits | flags : 8 bits ]
  • Flags: used/free, prev_free, slab_id/pool_id (if applicable)
• Free blocks: use first bytes of payload for pointers (prev/next) — no separate heap book-keeping to save RAM
• Boundary tags optional: Enable coalescing; cost = extra footer (omit on tiny systems, instead track neighbors in segregated lists)

Reclamation & long‑lived system strategies

• Avoid full compaction: pointer relocation is expensive and unsafe in C.
• Prefer lifelong pools for long‑lived objects so they never fragment general heap.
• Periodic offline defragmentation:
  • Quiescent window: stop real‑time tasks, move live objects using indirection table (handles) and update pointers — heavy but rare.
• Leak detection & scrub:
  • Use allocation accounting, stack traces in debug builds.
• Coalescing on free + deferred coalescing heuristics to reduce CPU jitter.

Failure modes

• Exhaustion: return NULL; provide graceful degradation (fail-fast, fallback to preallocated pools).
• External fragmentation leading to allocation failures despite free memory: mitigated by pools+TLSF sizing.
• Concurrency: need lock-free or priority-aware locks to avoid priority inversion.
• Corruption: use checksums/canaries in header; implement runtime sanity checks.

Trade-offs (RAM overhead vs fragmentation)

• Slabs/pools: high RAM overhead (preallocation), minimal fragmentation, deterministic latency.
• TLSF: low overhead, low fragmentation, O(1) but some internal fragmentation vs perfectly packed.
• Segregated lists (power‑of‑two): minimal metadata, faster, but higher internal fragmentation.
  Recommendation: allocate a modest set of typed pools for frequent long‑lived objects (sized to telemetry), and a TLSF heap for variable ephemeral allocations. Tune bucket sizes and pool counts from telemetry collected in testing.

Implementation tips

• Use compile-time configuration for pool sizes and enable/disable boundary tags.
• Keep metadata word-aligned, avoid dynamic memory in allocator itself.
• Provide diagnostics: high‑water marks, fragmentation metrics, allocation histograms.

This hybrid yields bounded timing, keeps fragmentation low for long-lived systems, and provides pragmatic reclamation paths appropriate for embedded constraints.

Brief approach
Measure interrupt timing by correlating stimulus (GPIO/timer) with CPU reaction across tools: logic analyzer for digital events, oscilloscope for analog edges and noise, CPU trace (SWV/ETM) for cycle-accurate timestamps, and software instrumentation for context and metrics.

Logic analyzer

• Capture ISR entry/exit GPIO toggles, peripheral lines, or pin-probed interrupts.
• Use > logic-depth and sample rate ≥ 4× signal frequency.
• Useful for multi-channel correlation (IRQ line, DMA, peripheral signals).

Oscilloscope

• Measure precise edge timing, rise/fall, signal integrity, ringing, ground bounce.
• Use single-shot and persistence to visualize jitter; measure time between stimulus edge and ISR GPIO toggle.

Trace (SWV / ETM)

• SWV: lower-overhead timestamped printf-like events and PC sampling for Cortex-M.
• ETM: cycle-accurate instruction trace to reconstruct exact latency and jitter, especially for preemption and context-switches.
• Correlate trace timestamps with external events via a sync GPIO toggle.

Software instrumentation

• High-resolution timers (DWT_CYCCNT on Cortex-M) to timestamp IRQ entry/exit.
• Minimal overhead: disable caching of measurement code, inline assembly reads of cycle counter.
• Add optional sampling histograms, min/max/percentiles, and export over UART/SWO.

Practical tips

• Put a dedicated GPIO toggle at ISR entry/exit for cross-tool correlation.
• Keep probes grounded properly; avoid loading lines.
• Combine tools: oscilloscope for signal quality, logic analyzer for event timing, ETM for code-level causality, and software counters for statistics.

Brief hazard definitions (5‑stage: IF, ID, EX, MEM, WB)

• RAW (Read After Write, true data hazard): later instruction reads a register before earlier instruction writes it — causes stalls unless forwarding handles it.
• WAR (Write After Read, anti‑dependency): later writes a reg before earlier reads — eliminated on classic in‑order 5‑stage because writes occur in WB after reads in ID, but can appear in out‑of‑order pipelines.
• WAW (Write After Write, output dependency): two writes to same reg; in in‑order pipeline ordering preserved so uncommon.
• Control hazards: branch instructions alter PC — cause flushes/stalls on mispredicts.

Compiler/asm techniques to minimize stalls

• Instruction reordering / scheduling
  • Move independent instructions between producer and consumer to cover latency.
  • Example (assembly):

    ADD R1,R2,R3    ; produces R1
    NOP
    LDR R4,[R5]     ; independent work moved to fill latency instead of NOP
    SUB R6,R1,R7    ; consumes R1

• Schedule independent instructions
  • Prefer loads, address computations, previous loop invariant ops; exploit register pressure carefully.
• Loop unrolling
  • Unroll to expose more independent work and amortize branch overhead; reduces branch frequency and increases ILP.
• Branch inversion + fall-through
  • Invert condition so the likely path is fall‑through, minimizing taken‑branch penalties on simple fetch units.
• Replace NOPs with useful work
  • Insert registers saves, prefetches, or independent arithmetic to utilize cycles instead of NOPs.
  • Example:

    LDR R0,[R1]      ; load
    ADD R8,R9,R10    ; independent work while load completes
    STR R0,[R2]      ; dependent on load

Practical tips for embedded

• Respect tight register file on microcontrollers; balance unrolling with code size.
• Measure with cycle-accurate simulator; tune scheduling per target forwarding/bypass behavior.
• Use compiler pragma/asm blocks for critical hot loops; use profile-guided optimization when available.

Direct answer

Detecting whether a + b would overflow a 32-bit signed integer, without widening to 64 bits, means reasoning about the operation BEFORE it happens using only the bounds of int32_t itself: check whether b is positive and a is already close enough to the maximum that adding b would exceed it, and symmetrically for a negative b against the minimum.

Structured elaboration

Why you can't just compute a + b and check the result. Computing the sum first and then checking whether it looks wrong is undefined behavior for signed integer overflow in C++, meaning the compiler is permitted to assume overflow never happens and can optimize the check away entirely, silently producing incorrect results specifically in the case you were trying to detect. The check has to be done using only values that are guaranteed to be representable, before the actual addition occurs.

The two symmetric cases. If b is positive, overflow happens when a is already greater than INT32_MAX - b (equivalently, adding b would push past the maximum); this comparison, a > INT32_MAX - b, is always computable without overflow since INT32_MAX - b cannot itself overflow when b is positive. If b is negative, overflow (underflow past the minimum) happens when a is less than INT32_MIN - b; note INT32_MIN - b is safe to compute here specifically because b is negative, making this subtraction move away from, not toward, the boundary.

The zero and boundary cases. b == 0 never overflows regardless of a, and the two comparisons above naturally handle this correctly without a special case, since a > INT32_MAX - 0 is simply a > INT32_MAX, which is never true for a valid int32_t value of a.

Worked example

bool add_will_overflow(int32_t a, int32_t b) {
    if (b > 0 && a > std::numeric_limits<int32_t>::max() - b) return true;
    if (b < 0 && a < std::numeric_limits<int32_t>::min() - b) return true;
    return false;
}

Executed and verified (g++, -Wall -Wextra): add_will_overflow(INT32_MAX, 0) is false (no overflow); add_will_overflow(INT32_MAX, 1) is true (the classic overflow case); add_will_overflow(INT32_MAX - 1, 1) is false (exactly at the boundary, still valid); add_will_overflow(INT32_MIN, -1) is true (the symmetric underflow case); add_will_overflow(INT32_MIN, 0) is false; add_will_overflow(INT32_MIN + 1, -1) is false (exactly at the boundary on the negative side); ordinary values like add_will_overflow(100, 200) and add_will_overflow(-100, -200) are both false; and add_will_overflow(INT32_MAX/2 + 1, INT32_MAX/2 + 1) is true, confirming the check also catches an overflow that occurs from two moderately-large positive values rather than only from a value already at the exact boundary.

Trade-offs and pitfalls

The single most common mistake is writing the intuitive-looking but broken version, int32_t sum = a + b; if (sum < a) return true; (checking whether the result "wrapped around" to something smaller than one of the inputs): this relies on signed overflow actually wrapping, which is undefined behavior in C++ and not guaranteed to behave that way at all, especially under compiler optimizations that are explicitly permitted to assume signed overflow never occurs and can eliminate the check entirely. A second, more subtle mistake is getting the comparison direction backwards for the negative-b case (checking a < INT32_MIN + b instead of a < INT32_MIN - b), which happens to work correctly by luck for some inputs and silently fails for others; testing both boundary directions explicitly, as in the worked example, is what catches this class of subtle sign error.

Approach (brief)
Use a singly-linked free-list of fixed-size blocks. Initialization is O(1) by treating a contiguous buffer and linking blocks in-place. Allocation and free are O(1). For single-core systems where free may be called from an ISR, make alloc critical by briefly disabling interrupts while popping the head; free runs in ISR and simply pushes the block (no blocking). This is safe because on single-core the allocator's critical section prevents an ISR from preempting alloc while it manipulates the list.

Code (core functions)

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

/* Platform must supply these to disable/enable interrupts */
extern uint32_t enter_critical(void); /* returns previous primask/state */
extern void exit_critical(uint32_t state);

typedef struct Block {
    struct Block *next;
} Block;

typedef struct {
    Block *free_list;
    size_t block_size;
    size_t num_blocks;
    void *buffer;
} MemPool;

/* O(1) init: link blocks in buffer */
void mp_init(MemPool *mp, void *buffer, size_t block_size, size_t num_blocks) {
    mp->buffer = buffer;
    mp->block_size = (block_size < sizeof(Block*)) ? sizeof(Block*) : block_size;
    mp->num_blocks = num_blocks;
    mp->free_list = NULL;

    uint8_t *p = (uint8_t*)buffer;
    for (size_t i = 0; i < num_blocks; ++i) {
        Block *b = (Block*)p;
        b->next = mp->free_list;
        mp->free_list = b;
        p += mp->block_size;
    }
}

/* O(1) alloc: disable interrupts briefly while popping head */
void *mp_alloc(MemPool *mp) {
    uint32_t state = enter_critical();
    Block *b = mp->free_list;
    if (b) {
        mp->free_list = b->next;
    }
    exit_critical(state);
    return (void*)b;
}

/* O(1) free: can be called from ISR; push onto list without blocking */
void mp_free(MemPool *mp, void *ptr) {
    if (!ptr) return;
    Block *b = (Block*)ptr;
    /* Push: safe in ISR because alloc disables interrupts when popping */
    b->next = mp->free_list;
    mp->free_list = b;
}

Concurrency reasoning and trade-offs

• Assumption: single-core. Alloc disables interrupts so it cannot be preempted by ISR while modifying the list; free (called from ISR) pushes without disabling interrupts. This prevents corruption because alloc's critical region is atomic w.r.t ISR.
• Benefits: simple, low overhead, O(1) ops, ISR-safe free.
• Limitations: if free can be called from multiple concurrent contexts (e.g., thread and ISR both call free) this simple push is okay because both may race unless alloc/pop isn't disabled; here alloc disables interrupts so race between two frees (both in normal context) could corrupt list. If frees can be done from thread context too, either always disable interrupts in free or use atomic compare-and-swap (if hardware supports) to implement lock-free push.
• Alternative (more general): use atomic CAS for push/pop to support lock-free multi-context use without disabling interrupts. That increases code complexity and may require 32/64-bit atomic ops.

Situation & Task
In my last embedded role I received recurring feedback in code and design reviews: interrupt-context code wasn't clearly documented, critical sections were inconsistent, and postmortem showed a race in an ISR-driven UART path. I needed to change my practices to reduce bugs and reviewer friction.

Actions

• Created a personal learning plan with clear goals: master ISR-safe patterns, formalize critical-section APIs, and add unit + HIL tests.
• Studied core materials (ARM Cortex-M interrupt model, memory barriers) and applied static-analysis rules (MISRA-like checks, clang-tidy) to my local toolchain.
• Adopted Unity/CMock for unit tests and QEMU + hardware-in-loop for regression tests.
• Added a personal PR checklist (interrupt-safety, stack usage, reentrancy) and annotated functions with ISR/Thread context.

Result & Tracking

• Measured outcomes over 3 months: review comment count on interrupt/safety dropped 70%, postmortem regressions reduced from 3/month to 0, and CI test coverage for low-level modules rose to 85%.
• Tracked progress with a small dashboard (PR metrics, CI pass rate, and a personal learning log with time spent and resources).

This concrete change improved code quality, sped reviews, and gave me a repeatable process for absorbing review feedback.