Airbnb Entry-Level Embedded Developer Interview Preparation Guide

Definition — what is an atomic operation
An atomic operation is an indivisible read-modify-write sequence that appears to other threads/ISRs as happening instantaneously: no interleaving can observe a partially-completed update. In embedded C this prevents data races between ISRs, tasks, or multiple cores.

Common atomic primitives

• GCC built-ins
  • __sync_fetch_and_add / __sync_add_and_fetch (legacy)
  • __atomic_load_n, __atomic_store_n, __atomic_fetch_add, __atomic_compare_exchange_n (recommended; fine-grained memory-order control)
• C11 stdatomic
  • _Atomic types: atomic_int, atomic_uint32_t, etc.
  • Operations: atomic_load(), atomic_store(), atomic_fetch_add(), atomic_compare_exchange_strong(), atomic_flag_test_and_set()
  • Memory orders: memory_order_relaxed/acquire/release/acq_rel/seq_cst

Example — removing a race (ISR + main task)
Non-atomic (race possible if ISR interrupts between read and write):

volatile uint32_t counter;

void ISR(void) {
    counter++; // read-modify-write non-atomic on many targets
}

void task(void) {
    // also increments
    counter++;
}

Replace with atomic:

#include <stdatomic.h>
atomic_uint_fast32_t counter = ATOMIC_VAR_INIT(0);

void ISR(void) {
    atomic_fetch_add_explicit(&counter, 1, memory_order_relaxed);
}

void task(void) {
    atomic_fetch_add_explicit(&counter, 1, memory_order_relaxed);
}

Now increments are RMW atomic — no interleaving corrupts the counter.

Limitations on 8- and 32-bit processors

• 8-bit MCUs: many atomic RMW for >8-bit types are not lock-free; compiler may synthesize critical sections (disabling interrupts) or use library locks. 16/32/64-bit atomics often expensive or unavailable.
• 32-bit MCUs: 32-bit atomics are commonly lock-free if aligned; 64-bit atomics often require a software mutex or LL/SC emulation. Memory-order semantics still hold but cost/performance varies.
• General: atomics do not replace higher-level synchronization for composite invariants or multi-variable transactions. Always check atomic_is_lock_free() and generated code for your toolchain/architecture.

Brief answer
For Cortex‑M with data cache disabled: DMA buffers only need to meet the DMA controller’s alignment and size constraints (peripheral DMA burst, word/halfword/byte), no CPU cache concerns. With data cache enabled: buffers must be handled so CPU and DMA see coherent data — align to cache line size, and perform explicit cache maintenance (clean/invalidate) around transfers.

Key requirements

• Alignment: align buffer base and length to DMA and cache line boundaries. Common Cortex‑M7 D‑cache line = 32 bytes (check your SoC).
• Placement: if available, place DMA buffers in non‑cacheable SRAM region (MMU/MPU) or peripheral‑coherent memory.
• Cache maintenance:
  • For DMA TX (CPU -> peripheral): Clean (write back) cache lines covering buffer before starting DMA.
  • For DMA RX (peripheral -> CPU): Invalidate cache lines after DMA completes so CPU loads fresh data from memory.

Practical steps (embedded/CMSIS example)

• Align buffers:

#define CACHE_LINE  32
__attribute__((aligned(CACHE_LINE))) uint8_t dma_buf[1024];

• Before starting TX DMA:

SCB_CleanDCache_by_Addr((uint32_t*)dma_buf, sizeof(dma_buf));
__DSB(); __ISB(); // data + instruction synchronization
start_dma_tx(dma_buf, sizeof(dma_buf));

• After RX DMA completes:

__DSB();
SCB_InvalidateDCache_by_Addr((uint32_t*)dma_buf, len);
__DSB(); __ISB();
process_data(dma_buf);

Notes / tradeoffs

• Use non‑cacheable memory to avoid maintenance cost when performance/power allows.
• Ensure DSB/ISB (or compiler intrinsics) surround cache ops to prevent reordering.
• Some DMA controllers require 32‑bit aligned accesses; check peripheral docs.
• For high throughput, prefer double buffering and minimize cache flush scope to affected addresses.

Direct answer

The mistake was sending a demand forecast to leadership that was off by a meaningful margin because I misunderstood a default filter in a reporting tool I had just started using, not because I was careless. I found out when a stakeholder cross-checked the number against a different report and it didn't match, and what changed afterward wasn't just personal caution, it became an automated check that catches that specific class of error before a report goes out.

What happened and how I found out

I was new to a business intelligence tool the team had recently adopted and built a demand forecast that, unknown to me, was silently excluding a large customer segment because of a default filter left over from a template I had copied. The number went into a deck that leadership used to plan inventory for the following quarter. I found out three days later when a colleague, cross-referencing the number against an older report format, flagged that the totals didn't reconcile. As soon as I confirmed it was a real error and not a discrepancy in his numbers, I told the people who had received the deck that same day, with the corrected figure and a plain explanation of the cause, rather than waiting until I had a full write-up ready.

Recovery and what changed

For the immediate damage, I worked with the planning team to understand what decisions had already been made off the wrong number and flagged which of those needed a second look before anything was locked in. Longer term, I didn't trust myself to just be more careful next time, since the error came from a tool default I didn't know existed, not from rushing. Instead, I built a validation step into the report template itself, a total-reconciliation check against a known-good source that runs automatically before the report is finalized, so the same class of mistake gets caught by the process rather than relying on me remembering to check a filter I didn't know to look for.

Trade-offs and pitfalls

The instinct after a mistake like this is often to promise to be more careful, which sounds responsible but doesn't actually prevent a repeat if the root cause was unfamiliarity rather than carelessness. The fix that actually holds is the one that doesn't depend on me remembering; a habit can lapse under pressure, an automated check in the template can't.

Approach summary
I would design DMA to move large SPI bursts with minimal CPU, while guaranteeing the 1 ms hard interrupt latency by careful priority/arbiter settings, buffer alignment, cache coherency, and double-buffering.

DMA configuration

• Use burst/word-sized transfers (e.g., 32- or 16-bit) matching SPI peripheral data register width to maximize bus efficiency.
• Enable peripheral-driven (handshake) DMA if supported so DMA only services when SPI FIFO/shift register ready.
• Set FIFO threshold and DMA burst length to fill/empty peripheral FIFO efficiently.

Cache / coherency & alignment

• Place DMA buffers in non-cached SRAM or mark as DMA-capable; if using cacheable memory, perform explicit DCache clean before DMA (CPU->DMA) and invalidate after DMA (DMA->CPU).
• Align buffers to bus/burst boundaries (e.g., 4/8/16 bytes) to avoid split transactions and ensure RX/TX descriptors map to cache lines.

Double-buffering / ping-pong

• Use two buffers and alternate: while DMA fills/sends buffer A, CPU/processes buffer B. Use DMA complete interrupts or hardware double-buffer mode to swap with minimal latency.

Interrupt priorities & avoiding starvation

• Assign hard 1 ms ISR highest priority; program DMA and SPI interrupts lower. If DMA engine shares CPU bus, limit DMA maximum bus utilization: use smaller burst sizes or yield periods so DMA doesn't lock bus for long critical sections.
• If MCU DMA has priority arbitration, configure it as lower priority than CPU masters or enable DMA throttling (e.g., pause between bursts).
• In RTOS, ensure ISR uses minimal work and defers processing to a high-priority task that still respects deadlines.

Peripheral FIFO & overflow

• Set SPI FIFO thresholds and DMA watermark so DMA services before FIFO under/overflow. Monitor and handle errors in DMA error callback.

Validation & metrics

• Measure SPI throughput, DMA bus occupancy, and worst-case ISR latency with logic analyzer and cycle-accurate timers. Iterate burst sizes and buffer sizes until throughput is near-max while ISR latency meets 1 ms worst-case.

This combination maximizes throughput while preserving deterministic 1 ms interrupt behavior.

Direct answer
I treat a company's published culture and values as a claim to be tested, not a fact to accept, and I look for evidence in three places: how people describe real, specific incidents (not slogans) when I ask about them, whether the org's actual structures and incentives would make the stated behavior easy or hard to practice, and whether the story is consistent across different people I talk to in the process.

Structured elaboration

1. Ask for a specific recent incident, not a description of the value. A question like "tell me about a time the team had to choose between shipping fast and following the documented review process" forces a real story; a question like "how would you describe the engineering culture here" invites a rehearsed, values-page-adjacent answer that tells you little.
2. Check whether the org's structure actually supports the stated value, independent of what anyone says. If a company claims to value psychological safety but every interviewer you meet is visibly guarded about naming any team problem, or if a company claims strong autonomy but every technical decision in the loop turns out to require a director's sign-off, the structural evidence contradicts the claim regardless of the wording used to describe it.
3. Triangulate across multiple people, ideally at different levels and tenures. A single enthusiastic interviewer proves little; a hiring manager, a peer-level engineer, and someone from a different function independently describing the same specific behavior (not the same slogan) is much stronger evidence.
4. Ask what the company would do differently if it stopped believing the value, and watch for a concrete, structural answer versus a vague one. People who work inside a genuinely lived value can usually name a real trade-off it costs them; people describing marketing usually cannot.
5. Treat your own discomfort as data. If a described norm (pace, feedback directness, decision-making style) makes you visibly uneasy during the process itself, that is a more reliable signal about fit than anything printed on the careers page, because it is your own live reaction rather than a claim you are being asked to evaluate secondhand.

Worked example
Suppose a company's careers page says it "empowers engineers with high autonomy." During the loop, ask the hiring manager for a specific recent example: "Tell me about the last time an engineer on this team made a production architecture decision without it going through a review committee first." A genuine, lived-autonomy answer sounds like: "Last quarter one of our engineers decided independently to switch a service from synchronous to async processing after noticing latency complaints; she looped in two people for a sanity check, shipped it, and reported the outcome in the next team sync." A marketing-only answer sounds like: "We really believe in empowering our engineers," repeated with no specific incident when pressed twice. If a peer engineer you speak to separately can also describe a comparable specific incident in their own words, that consistency is strong corroborating evidence; if the hiring manager's story turns out to be the ONLY example anyone can produce company-wide, that is itself informative about how common the behavior actually is.

Trade-offs & pitfalls
The main failure mode is accepting an interviewer's fluent, confident description of the culture as sufficient evidence on its own; confidence and specificity are not the same thing, and a well-rehearsed answer to a values-page question is exactly what a company under-delivering on its stated culture is most likely to have prepared. A second pitfall is over-weighting a single glowing anecdote from one enthusiastic interviewer without checking whether it generalizes; one great story is an anecdote, not a pattern. A third is treating any inconsistency you find as automatically disqualifying: it is normal for a large or growing organization to have real variance across teams, so the useful conclusion is usually about the SPECIFIC team and manager you'd actually join, not the company as a monolithic whole.

Initialization

• Configure baud, parity, stop bits, data bits in UART registers.
• Enable RX interrupt (and TX-empty interrupt disabled until TX queued).
• Initialize circular buffers for RX and TX and error counters.
• Provide callback registration for errors or data-available notifications.

Buffers / Strategy

• Use small power-of-two circular buffers (head/tail, mask) for RX and TX.
• RX: ISR pushes received bytes; if buffer full, increment overrun counter and drop oldest/newest per policy.
• TX: Application enqueues bytes; enable TX-empty interrupt. ISR sends bytes until buffer empty, then disable TX interrupt.

ISR behavior

• On RXNE (receive not empty): read data register immediately to clear flag; push to RX buffer; if framing/parity error flags set, clear and increment error counters and stash error event queue or call error callback.
• On TXE (transmit empty): pop from TX buffer and write to data register; if buffer empty, disable TXE interrupt and set TX-complete flag or call callback.
• Keep ISR short: only register access, buffer ops, and atomic counters.

Non-blocking API (example prototypes)

// returns number of bytes actually queued
size_t uart_send_nonblocking(uart_t *u, const uint8_t *data, size_t len);

// returns number of bytes read
size_t uart_recv_nonblocking(uart_t *u, uint8_t *buf, size_t len);

// register callbacks
void uart_register_error_cb(uart_t *u, void (*cb)(uart_error_t));
void uart_register_tx_complete_cb(uart_t *u, void (*cb)(void));

Error reporting

• Maintain per-UART counters for framing, parity, and overrun.
• On error detect in ISR: increment counter, optionally push an error event to an application-visible queue or invoke error callback.
• Provide APIs to read and clear error counters:

uart_errors_t uart_get_errors(uart_t *u);
void uart_clear_errors(uart_t *u);

Notes / Best practices

• Use interrupts + optional DMA for high-throughput.
• Protect buffer pointers with atomic/critical sections if accessed from tasks and ISR.
• Document overflow policy and thread-safety for callers.

Structure alignment & padding (overview)
Compilers align each field to its natural boundary (e.g., a 4-byte int to 4B) to satisfy the CPU’s load/store requirements and to improve access speed. Padding bytes are inserted between fields or at the end so the next field/whole struct meets alignment.

Example (shows padding)

// typical layout on 32-bit (gcc)
struct S {
    uint8_t  a;   // offset 0
    // 3 bytes padding
    uint32_t b;   // offset 4
    uint16_t c;   // offset 8
    // 2 bytes padding -> sizeof(S) == 12
};

Packed layout

struct __attribute__((packed)) Sp {
    uint8_t  a;   // 0
    uint32_t b;   // 1 (unaligned)
    uint16_t c;   // 5
}; // sizeof(Sp) == 7

Or with MSVC/other:
#pragma pack(push,1) / #pragma pack(pop)

Performance and portability trade-offs

• Packed: saves memory and matches protocol formats but can cause slow unaligned loads or hardware faults on architectures that don’t support unaligned accesses (e.g., some ARM, older MIPS).
• Natural alignment: slightly larger memory footprint but faster and safe across platforms.
• Use packed only when needed (wire formats, file I/O), and document ABI.

Safe access to possibly unaligned data

• Prefer memcpy to a local aligned variable:

uint32_t tmp;
memcpy(&tmp, &packed_struct->b, sizeof tmp); // safe and optimized

• Use compiler builtins (e.g., __builtin_memcpy, or target-specific load_unaligned) or helper functions that read bytes and assemble (shifts/OR).
• Avoid direct dereference of unaligned pointers on architectures that fault.
• Where performance matters and the architecture supports unaligned accesses, enable/benchmark explicit unaligned reads or use alignment attributes selectively.

Final note: choose layout based on protocol vs performance, audit code paths that touch packed fields, and test on target hardware.

Role of the system clock & clock gating

The system clock provides the timing reference for the CPU core and buses. All synchronous logic, timers, and peripheral state machines derive their timing from clock domains. Clock gating selectively stops the clock to specific blocks (peripheral or sub-module) so flip-flops stop toggling, reducing dynamic power while preserving state if designed for gated clock use.

Clock prescalers and peripheral timing (UART example)

Prescalers divide a higher-frequency clock to generate lower-rate clocks for peripherals. For UART, baud is derived from the peripheral clock and its divisor. Typical formula:

baud = peripheral_clock / (16 * UBRR)   // for 16x oversampling UART

Plain English: increasing the prescaler (reducing peripheral_clock) lowers achievable baud or requires changing UBRR. Example: 48 MHz system clock with APB prescaler /2 => peripheral_clock = 24 MHz. To get 115200 baud:

UBRR ≈ 24_000_000 / (16 * 115200) ≈ 13

Careful: integer rounding causes baud error — check percent error vs spec.

Power optimization via enabling/disabling clocks

Enable clocks only when peripheral is used; disable otherwise. This eliminates dynamic switching in that block. Practical tips:

• Use clock gating APIs in HAL or directly write peripheral clock enable bits in RCC.
• For low-power modes, gate clocks and put unused peripherals into reset to avoid leakage/state corruption.
• Combine with disabling NVIC interrupts for idle peripherals and gating bus clocks to reduce bus activity.

I would demonstrate this in firmware by enabling UART clock before init, disabling when idle, and measuring mA reduction in power profiler.

Direct answer
Reduce filler words by replacing the urge to fill silence with a deliberate pause, by slowing down at the start of an answer, and by preparing your first sentence in advance so you're not composing it live while also speaking it.

Structured elaboration

• Replace filler with silence. A half-second pause where "um" used to go feels awkward to the speaker but is barely noticeable to a listener, and it reads as more confident than a filler sound. Practice: the next time you feel a filler word coming, close your mouth instead.
• Slow down your opening sentence. Most filler happens in the first few seconds of an answer, while you're still figuring out what to say. Preparing (even mentally, for two seconds) how you'll start, before you start talking, removes most of the pressure that produces filler.
• Chunk your answer into a structure you can hold in your head (for example, "there are two things here: first... second..."), so you're not searching for what comes next mid-sentence.
• Record yourself and count filler words in a short answer. Most people are surprised by the number until they've heard it; the awareness alone reduces the habit over the next few attempts.
• Slow your overall pace, not just remove filler. Filler words often show up when speaking too fast for the thought to keep up; a slightly slower baseline pace gives your thinking time to catch up to your mouth.

Worked example
Before: "So, um, I think the, uh, main reason is like, you know, we didn't really have enough test coverage, if that makes sense."

After (pause instead of filler, front-loaded structure): "The main reason [pause] was insufficient test coverage."

Both convey the identical fact. The second version uses a brief pause where filler used to sit and states the point directly instead of hedging around it.

Trade-offs and pitfalls

• Eliminating filler entirely in the moment, under real pressure, is unrealistic; the realistic goal is a noticeable reduction, not zero.
• Overcorrecting into a rigid, over-rehearsed cadence can read as stiff; the goal is fewer filler words, not a scripted delivery.
• Practicing alone (recording yourself) tends to work faster than trying to notice it live, because live self-monitoring competes with the cognitive effort of actually answering the question.

Situation overview — why nested interrupts cause subtle races
When ISRs run at different priorities and the CPU allows nesting, a high-priority ISR can preempt a low-priority ISR partway through manipulating shared peripheral state. If both perform read-modify-write (RMW) on the same registers or data structures, the interleaving can corrupt state even though each ISR looked correct in isolation.

Concrete example

• Peripheral: UART RX using a circular buffer (head/tail) in driver memory; low-priority ISR A handles byte-by-byte RX and increments tail; high-priority ISR B handles an urgent error/status interrupt that also clears or updates UART status register and may adjust buffer pointers (e.g., flush on framing error).
• Race scenario:
  1. ISR A reads tail = 100
  2. ISR A computes new_tail = (tail + 1) % N
  3. High-priority ISR B preempts, sees stale tail, flushes buffer by setting tail = 0
  4. ISR A resumes and writes new_tail = 101, undoing the flush — lost/invalid state

Small illustrative C sketch (non-atomic RMW)

volatile uint32_t tail;
void ISR_A_rx(void) {          // low priority
  uint32_t t = tail;          // 1
  t = (t + 1) % BUF_SZ;      // 2
  tail = t;                   // 3 (preempted between 2 and 3)
}
void ISR_B_error(void) {      // high priority
  tail = 0;                   // flush buffer
}

Strategies to make driver robust

1. Mask/unmask schemes (local critical sections)

• In the low-priority ISR temporarily mask higher-priority source(s) that touch the same state around the RMW critical section. On many MCUs you can selectively disable that peripheral interrupt.
• Example: disable UART error IRQ while updating tail, then re-enable. This keeps nesting allowed generally but prevents this specific preemption.

2. CPU interrupt priority masking

• Use CPU primitives: on Cortex-M, BASEPRI can raise the priority threshold so only higher urgent interrupts run. For small critical sections, set BASEPRI to block any ISR that would conflict, then restore. This is lighter-weight than globally disabling all interrupts (PRIMASK).
• Use sparingly; ensure nesting assumptions and interrupt latency bounds respected.

3. Hardware atomic RMW or atomic ops

• If the peripheral or CPU provides atomic RMW registers or single-instruction atomic ops (e.g., atomic increment, test-and-set, LDREX/STREX on ARM) use them.
• Example with GCC builtins:

__sync_fetch_and_add(&tail, 1); // atomic increment

• Or use EXCLUSIVE load/store (LDREX/STREX) to implement lock-free increments.

4. Design patterns to minimize shared mutable state

• Single-writer principle: guarantee only one context writes a given variable. Make ISR A be the only writer of tail; other ISRs communicate via flags/messages instead of touching tail directly.
• Defer complex work out of ISRs: let ISRs only enqueue events (e.g., push to lock-free queue using atomic ops) and wake a thread/task to handle heavy state changes.
• Use immutable read-only snapshots: high-priority ISR reads status but signals the worker to act, avoiding in-ISR modifications.
• Use versioning or sequence counters: wrap state changes with a sequence number to detect and recover from concurrent updates.

Trade-offs and best practices

• Masking reduces concurrency but is simple and low-overhead if critical sections are tiny.
• BASEPRI is precise but requires careful priority planning and timing analysis.
• Atomic ops are ideal but depend on hardware support and sometimes cost more CPU cycles.
• Minimize shared state and prefer message-passing/deferred handlers for correctness and testability.

Result
Combining single-writer invariants, minimal critical sections (via masking/BASEPRI) and hardware atomics where available yields robust drivers that tolerate nested interrupts without subtle race conditions.