Airbnb Entry-Level Embedded Developer Interview Preparation Guide

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.

Design in one paragraph. Subscribers live in a fixed array of slots in static memory (.bss, the section for zero-initialised static variables, sized at build time, no heap). Each slot holds a callback pointer and a context pointer (the context is a void * the subscriber gets back on every call, usually its own state structure). The ISR (interrupt service routine, the function the hardware runs when an interrupt fires) is the only reader and takes no lock: it scans the slots and calls every one whose callback is non-NULL. Registration and removal run in thread context only, and are serialized with each other by the caller (so two of them never run at the same time; bare metal: only the main loop registers; with an RTOS: one mutex around register and unregister, which the ISR never takes). Correctness against the ISR comes from the order of the writes, not from masking interrupts, so registering never delays an interrupt.

Prototypes (evt.h).

#ifndef EVT_H
#define EVT_H
#include <stdint.h>

#define EVT_MAX_SUBSCRIBERS 4

typedef void (*evt_cb)(void *ctx, uint32_t event);

/* Thread context only, callers serialized (one thread, or one mutex).
   Returns a handle (slot index) or -1 if all slots are used. */
int  evt_register(evt_cb cb, void *ctx);
/* Thread context only. After it returns, the callback is never started again. */
void evt_unregister(int handle);
/* Called from the ISR. Never blocks, allocates or takes a lock. */
void evt_dispatch(uint32_t event);

#endif

typedef void (*evt_cb)(void *ctx, uint32_t event); names a function-pointer type: evt_cb is a pointer to a function that takes a context pointer and an event number and returns nothing. _Atomic(evt_cb) in the implementation below is the C11 way to declare that such a pointer is an atomic object: reads and writes of it are indivisible and carry the ordering requested at each access.

Implementation (evt.c).

#include "evt.h"
#include <stddef.h>
#include <stdatomic.h>

#ifdef EVT_TEST_HOOK
void evt_test_hook(int step);              /* the test calls evt_dispatch() from here */
#define STEP(n) evt_test_hook(n)
#else
#define STEP(n) ((void)0)
#endif

/* Storage: static, sized at build time, in .bss. An empty slot has cb == NULL. */
static struct {
    _Atomic(evt_cb) cb;                    /* published last, cleared first */
    void *ctx;
} slots[EVT_MAX_SUBSCRIBERS];

int evt_register(evt_cb cb, void *ctx)
{
    int h = -1;
    for (int i = 0; i < EVT_MAX_SUBSCRIBERS; i++) {
        if (atomic_load_explicit(&slots[i].cb, memory_order_relaxed) == NULL) {
            slots[i].ctx = ctx;            /* 1: fill in the context while the slot is still empty */
            STEP(1);
            atomic_store_explicit(&slots[i].cb, cb, memory_order_release);  /* 2: publish */
            h = i;
            break;
        }
    }
    return h;
}

void evt_unregister(int h)
{
    if (h < 0 || h >= EVT_MAX_SUBSCRIBERS) return;
    atomic_store_explicit(&slots[h].cb, NULL, memory_order_release);       /* unpublish; leave ctx alone */
}

void evt_dispatch(uint32_t event)
{
    for (int i = 0; i < EVT_MAX_SUBSCRIBERS; i++) {
        evt_cb cb = atomic_load_explicit(&slots[i].cb, memory_order_acquire);
        if (cb != NULL)
            cb(slots[i].ctx, event);
    }
}

Why this is race-free against the ISR.

• An empty slot has cb == NULL. The ISR skips such a slot, whatever is in ctx.
• Register writes the context first, while cb is still NULL, then publishes cb with a release store. If the ISR fires between the two writes it sees cb == NULL and skips the slot. If it fires after, the acquire load of cb guarantees it also sees the new ctx. The ISR therefore never calls a callback with a missing or stale context. (Release and acquire are the C11 atomic orderings: everything written before the release store is visible to a reader that sees the stored value through an acquire load. Applied here: register writes ctx and then does a release store of cb. If the ISR's acquire load reads the new non-NULL cb, the earlier write of ctx is guaranteed to be visible to the ISR as well, so it cannot pair the new callback with an old context. If the ISR's load still reads NULL, it skips the slot.)
• Unregister clears cb first and leaves ctx alone. The ISR sees either the old, complete pair or an empty slot. A slot freed and reused immediately goes through the same write order again.
• The ISR does not take locks, allocate or block, so it cannot deadlock against the code it interrupted, which is the failure a lock shared between thread code and an ISR would create.
• A callback may be running when evt_unregister is called only if the caller is itself running at a higher interrupt priority or on another core. On a single core, thread code cannot run in the middle of an ISR, so once evt_unregister returns, the callback will not be started again and the context can be freed. On a multi-core part (where another core can run the dispatcher at the same moment), or if a higher-priority ISR may unregister, you need an extra step: a per-slot "in use" counter or a quiesce wait (waiting until no dispatch can still be executing that callback) before freeing the context.
• The pointer accesses are single aligned 32-bit loads and stores, which Cortex-M performs as single accesses that an interrupt cannot split, and _Atomic stops the compiler reordering or caching them. Compiled for Cortex-M0+ (-mcpu=cortex-m0plus -mthumb -Os, 14.2.1), the dispatcher loop is plain ldr loads plus a dmb for the acquire, with no calls into an atomics library. The relevant lines of objdump -d are:

evt_dispatch:
   4c:	ldr	r3, [r4, #0]     @ cb = slots[i].cb  (the acquire load)
   4e:	dmb	ish              @ data memory barrier: later accesses stay after the load
   52:	cmp	r3, #0
   54:	beq.n	5c               @ NULL: skip this slot
   58:	ldr	r0, [r4, #4]     @ ctx, read only after cb was seen
   5a:	blx	r3               @ call the callback

evt_register:
   12:	str	r1, [r3, #4]     @ 1: write ctx while cb is still NULL
   14:	dmb	ish              @ release: ctx is ordered before the cb store
   18:	str	r2, [r3, #0]     @ 2: publish cb

dmb (data memory barrier) keeps the memory accesses on either side of it in order. These are lines picked from the compiler's output (14.2.1, -mcpu=cortex-m0plus -mthumb -Os), shortened with comments added.

Where the storage lives and what it costs. slots is static: 8 bytes per subscriber on a 32-bit part (4 for cb, 4 for ctx), so EVT_MAX_SUBSCRIBERS 4 is 32 bytes of .bss. A fixed limit is deliberate: registration fails with -1 and the caller must handle it, which is better than a heap allocation that can fail in the field, and the worst-case ISR time is bounded by the slot count times the callback's own time.

Evidence. The code was built and run on the host (gcc -O1 -Wall -Wextra -fsanitize=address,undefined -DEVT_TEST_HOOK evt.c test_evt.c, gcc:14). The EVT_TEST_HOOK build calls evt_dispatch(), the stand-in for the ISR, at the point inside evt_register between the two writes, and the test also dispatches between API calls. Each callback checks that it received its own context:

/* test_evt.c */
#define EVT_TEST_HOOK 1
#include <stdio.h>
#include <stdlib.h>
#include "evt.h"

struct sub { int id; int calls; };
static int bad_pairs, total_calls, hook_calls;

/* Each callback checks that it was handed its own context. */
#define MAKE_CB(NAME, ID) \
    static void NAME(void *ctx, uint32_t ev) { \
        struct sub *s = ctx; (void)ev; total_calls++; \
        if (s == NULL || s->id != (ID)) bad_pairs++; else s->calls++; }
MAKE_CB(cb_a, 1)
MAKE_CB(cb_b, 2)
MAKE_CB(cb_c, 3)

/* Test seam: an "interrupt" fires at every step inside evt_register(). */
void evt_test_hook(int step) { (void)step; hook_calls++; evt_dispatch(7); }

int main(void)
{
    struct sub a = {1, 0}, b = {2, 0}, c = {3, 0};
    int ha = evt_register(cb_a, &a);  evt_dispatch(7);
    int hb = evt_register(cb_b, &b);  evt_dispatch(7);
    evt_unregister(ha);               evt_dispatch(7);
    int hc = evt_register(cb_c, &c);  evt_dispatch(7);   /* reuses the slot A left behind */
    int hd = evt_register(cb_a, &a);
    int he = evt_register(cb_b, &b);
    int hf = evt_register(cb_c, &c);                      /* all four slots are now used */
    printf("handles: a=%d b=%d c=%d d=%d e=%d f=%d\n", ha, hb, hc, hd, he, hf);
    evt_unregister(hb); evt_dispatch(7);
    printf("hook fired %d times, callbacks ran %d times, wrong ctx %d times\n",
           hook_calls, total_calls, bad_pairs);
    printf("a.calls=%d b.calls=%d c.calls=%d\n", a.calls, b.calls, c.calls);
    int ok = bad_pairs == 0 && ha == 0 && hb == 1 && hc == 0 && hf == -1;
    printf(ok ? "PASS\n" : "FAIL\n");
    return !ok;
}

The test is built from three pieces. MAKE_CB(NAME, ID) is a preprocessor macro that writes three near-identical callback functions (cb_a, cb_b, cb_c); the trailing backslashes continue the macro over several lines, and each generated function counts a call, checks that the context it received carries the expected id, and counts a wrong pairing otherwise. evt_test_hook is the test seam: with EVT_TEST_HOOK defined, STEP(1) inside evt_register calls it, and it calls evt_dispatch(7) exactly as if an interrupt had fired between the two writes. main then registers, unregisters and dispatches in a fixed order.

Output (deterministic):

handles: a=0 b=1 c=0 d=2 e=3 f=-1
hook fired 5 times, callbacks ran 16 times, wrong ctx 0 times
a.calls=5 b.calls=7 c.calls=4
PASS

c took the slot a left behind (handle 0) and the sixth call, f, fails with -1: the four slots hold c, b, d and e by then, so f would be a fifth live subscriber. The counts can be derived by hand. The hook runs once for each registration that finds a free slot: a, b, c, d and e, so 5 times (f finds none and never reaches the hook). Counting each dispatch as one call per non-empty slot: after a, one explicit dispatch runs a (1 call); registering b fires the hook with a present (1) and the explicit dispatch runs a and b (2); after unregister(a) it runs b (1); registering c fires the hook with b present (1) and the explicit dispatch runs c and b (2); registering d runs c and b (2); registering e runs c, b and a (3); and the last dispatch after unregister(hb) runs c, a and b (3). That is 1 + 1 + 2 + 1 + 1 + 2 + 2 + 3 + 3 = 16 callbacks. As a check that the test can fail, a copy of evt.c with the two writes swapped (publish cb, then set ctx) printed wrong ctx 5 times and FAIL on the same test. What this does not cover: real interrupts on hardware, and the multi-core case, where the extra step above applies. The interleaving test places the ISR at the one point between the two writes, which is the point where the order matters.

Extensions. Subscribing to a subset of events: add an event mask to the slot, written before cb is published, and have the ISR test mask & event. Registering from an ISR, or from several interrupt priority levels: the writers can then preempt each other (one interrupts the other part-way through an update), so wrap each register and unregister in a short critical section with interrupts masked (PRIMASK is the Cortex-M register that blocks interrupts: save it, set it, restore it), and that masked window is the added interrupt latency: it covers the whole slot search and update, and in the Cortex-M0+ listing above evt_register compiles to about 40 instructions when all four slots are scanned (eight per slot, plus entry and exit), so keep EVT_MAX_SUBSCRIBERS small.

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

Set the decision at the right altitude before setting the decision itself: agree in advance on what counts as reversible-and-cheap versus irreversible-or-expensive, let anyone decide locally within a pre-agreed threshold for the first kind, require explicit escalation for the second, and write down every non-trivial call so it can be revisited once real outcome data exists. That same underlying pattern holds whether the tension is shipping speed against general quality controls, or, on a machine-learning team, shipping velocity against model safety and accuracy checks.

Structured elaboration

• Decision criteria: for any trade-off, ask how reversible it is (can it be rolled back quickly if wrong), what its blast radius is (one customer or all of them), and whether a hard external commitment, a compliance deadline or a contractual date, is forcing the timeline.
• Risk thresholds: define numeric or categorical thresholds in advance, before anyone is negotiating under pressure mid-incident, for example, "a change affecting under 5% of traffic that's reversible within an hour can ship without extra sign-off," or, for a model team, "a model change with an accuracy drop under 1 percentage point on the offline evaluation set ships with standard review, anything larger requires a dedicated safety review." Those figures are a team's own chosen starting values, not a benchmark to copy from somewhere else, and that is the point: a written number can be argued with and revised, where a phrase like "a small change" cannot. Expect an interviewer to ask where your number came from, and the honest answer is usually "we picked a starting point we could defend and agreed what evidence would move it," not "this is the industry figure."
• Pick the metric before you pick the number: a threshold is only as good as the quantity it is written on. On a fraud model, writing the gate on overall accuracy is close to useless, because fraud is rare enough that a model can lose most of its useful behaviour while overall accuracy barely moves, which is why the fraud example below writes its threshold on false-positive rate instead.
• Escalate versus decide locally: escalate when a threshold is exceeded, when a decision sets precedent beyond the one case in front of you, or when the people closest to the decision disagree with each other. Decide locally when it's within threshold and there's local agreement.
• Documenting and revisiting: write a short record of what was decided, what alternative was rejected and why, and what threshold or assumption it relied on, then set a specific trigger, for example "revisit after the next two incidents," to check whether the threshold was actually set correctly rather than leaving it to be re-litigated from scratch every time.

Worked example

Two versions of the same framework. General engineering: a team keeps clashing over shipping a feature via a small partial rollout versus running a longer manual QA pass first. They agree that rollouts to 5% or fewer of users, reversible with a feature flag within minutes, ship on the engineer's own judgment, while anything wider, or anything touching payments, needs QA sign-off first. They also agree up front what would justify widening the cap, because "it's been fine so far" is not a number: twenty consecutive rollouts inside the cap with zero rollbacks. Even that is weaker evidence than it feels. Zero failures in twenty tries still leaves room for a true rollback rate around 15% (the rule of three: with no failures in n tries, the rate could still be roughly 3 divided by n, so 3/20). That's precisely why they widen the cap from 5% to 10% rather than removing it, and set the same evidence bar again at the new level. Machine-learning variant: a fraud-model team keeps clashing over releasing model updates quickly versus running a full safety review every time. They agree that an update with a false-positive-rate change under 0.5 percentage points versus last month's data ships with standard review, while anything larger, or any change to a customer-facing risk threshold, requires a safety review with a second reviewer. After a quarter, they compare every release's actual measured drift against that threshold and adjust it based on how often it was close to being wrong.

Trade-offs and pitfalls

The biggest failure is setting a threshold once and never revisiting it, a threshold calibrated for a smaller, lower-stakes system becomes dangerously loose as the system scales, or unnecessarily strict once a team has demonstrated it can be trusted at a lower tier. That gap between a real framework and a one-time compromise is exactly what the revisit step protects against. The mirror-image failure is revisiting on the wrong evidence, loosening a safety gate after a short clean run, since a run of zero failures is compatible with a failure rate high enough to hurt you and feels far more reassuring than it should. The other failure is treating every disagreement as needing escalation, which quietly kills the local decision-making the framework was meant to protect, and teams that over-escalate end up right back at "everything goes through a committee," the speed problem the framework was supposed to solve in the first place.

Direct answer

counter += 1 is not one operation. The hardware does a load, an add and a store, and a second thread can run its own load between your load and your store. Both threads then compute from the same old value and one increment is overwritten (a lost update). Fix it by making the read-modify-write indivisible: protect it with a mutex, or use an atomic increment instruction. Choose an atomic for a single independent word; choose a lock when more than one variable or a check-then-act must change together.

Exactly how the interleaving loses an update

Here is what the compiler produced for void inc(void) { counter += 1; } with gcc:14 on aarch64 (gcc -O0 -S, then -O2 -S). The -O0 listing is adrp/add/ldr/add/adrp/add/str; at -O2 it is shorter but is still one load, one add and one store:

inc:                                  (gcc -O2, aarch64)
	adrp	x1, .LANCHOR0
	ldr	x0, [x1, #:lo12:.LANCHOR0]    ; load counter
	add	x0, x0, 1                      ; add 1 in a register
	str	x0, [x1, #:lo12:.LANCHOR0]    ; store back
	ret

Reading the listing: adrp loads the address of the 4 KB memory page that holds counter into register x1 (a register is one of the CPU's few fast storage slots); :lo12:.LANCHOR0 is the low 12 bits of the address, the offset inside that page, so [x1, #:lo12:.LANCHOR0] means "the memory at the counter's address". x0 is the register that does the arithmetic. The comments mark the three separate steps: load, add, store.

Starting from counter = 5:

Two increments ran, the value moved from 5 to 6. The window is only a few instructions wide, so any single increment is rarely hurt, but a million of them make it near-certain that some are.

Why it is intermittent

The loss needs the scheduler to switch threads, or another core to touch the cache line (the small block of memory, commonly 64 bytes, that cores hold in their private caches and hand to each other; only one core at a time may write it), inside that tiny window. Different runs interleave differently, and anything that changes timing (a print, a debugger, a different compiler flag) changes how often it happens. Below, five runs of the same program lost different amounts.

The fixes, compared in one harness

#include <pthread.h>
#include <stdatomic.h>
#include <stdio.h>
#define N 1000000
static long plain = 0;
static long locked = 0;
static atomic_long atom = 0;
static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;

static void *work(void *arg) {
    (void)arg;
    for (int i = 0; i < N; i++) {
        plain += 1;                                   /* data race */
        pthread_mutex_lock(&m); locked += 1; pthread_mutex_unlock(&m);
        atomic_fetch_add_explicit(&atom, 1, memory_order_relaxed);
    }
    return NULL;
}
int main(void) {
    pthread_t t[2];
    for (int i = 0; i < 2; i++) pthread_create(&t[i], NULL, work, NULL);
    for (int i = 0; i < 2; i++) pthread_join(t[i], NULL);
    printf("expected=%d plain=%ld locked=%ld atomic=%ld\n", 2 * N, plain, locked, atom);
    return 0;
}

gcc -O0 -pthread counter.c -o c && ./c, five runs in a gcc:14 container (aarch64):

expected=2000000 plain=1975751 locked=2000000 atomic=2000000
expected=2000000 plain=1986956 locked=2000000 atomic=2000000
expected=2000000 plain=1998485 locked=2000000 atomic=2000000
expected=2000000 plain=1954567 locked=2000000 atomic=2000000
expected=2000000 plain=1982365 locked=2000000 atomic=2000000

Under -fsanitize=thread the plain line is reported as a data race at counter.c:13 and the locked and atomic lines print 2000000 with no report. (I used memory_order_relaxed for the atomic. A memory order says how much an atomic operation also orders the surrounding reads and writes: relaxed promises only that the operation itself is indivisible; acquire/release is the pairing used to hand other data from one thread to another; sequentially consistent, the default, makes all threads agree on one order for all such operations. The counter publishes no other data, so only the atomicity of the increment matters here.)

Which hardware instruction backs the atomic

The atomic increment compiles to a single indivisible read-modify-write, and which one depends on the target. From gcc:14: on x86-64 (--platform linux/amd64, -O2) it is lock addq $1, counter(%rip); on aarch64 with -march=armv8-a -mno-outline-atomics it is a load-exclusive / store-exclusive loop (ldxr, add, stxr, cbnz back if the store failed); with -march=armv8.1-a it is one ldadd. Reading these: lock addq is an ordinary add to memory with a lock prefix that makes the whole read-modify-write indivisible. ldxr loads the value and marks the location as exclusively watched by this core, stxr stores only if nobody wrote the location since and writes a success flag, and cbnz (compare and branch if nonzero) jumps back to retry when that flag says the store failed; so the exclusive pair retries if another core wrote the location in between. ldadd does the whole atomic add in one instruction. These instruction names are context for how hardware provides the guarantee; what matters is that the hardware offers one indivisible read-modify-write.

Lock or atomic

• Atomic: one word, one independent operation (counter, flag, sequence number, pointer swap). No sleeping, no lock to forget to release, safe from signal handlers (functions the OS runs asynchronously, interrupting your thread, when a signal arrives) and, for lock-free types (atomic types implemented with real atomic instructions rather than a hidden lock; is_lock_free() tells you), interrupt handlers.
• Mutex: more than one variable must change together, or you have check-then-act ("increment only if below the cap"), or the critical section calls other code. Two separate atomic variables are never one atomic update: AtomicInteger used and AtomicInteger limit read one after the other still allow another thread's change in between (the same holds for AtomicInteger on Android: each call is atomic, a sequence of calls is not).
• Under contention (many threads using the same variable at the same time) both serialise on the same cache line. A contended mutex can additionally put a waiting thread to sleep in the kernel and wake it later, which costs context switches; an atomic add just waits for the cache line. When one counter is hot, the usual real fix is neither: keep a counter per thread (or per shard, one of several independent slices of the data) and sum when read, so threads stop sharing the line. I did not time these variants here, so the comparison above is a reasoning claim, not a measurement.
• Shared cache (a map plus eviction order): the invariant spans several fields, so use a lock (sharded by key to reduce contention). A lock-free repair is realistic for one counter or one pointer, not for an invariant over a whole structure.

Pitfalls

• volatile does not make counter += 1 atomic; it only stops the compiler from caching the value.
• On an embedded target the same loss occurs between a task and an interrupt service routine; the fix there is a brief interrupt mask or a hardware atomic, not a mutex that the ISR cannot take.
• Reading the final value after pthread_join is safe because join orders the writes before the read.

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.

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.

Approach summary
Design around a dedicated hardware timer driven by a stable clock, keep the 100 μs loop triggered in hardware with minimal ISR work, and move non-deterministic work to lower-priority tasks or DMA.

Clock sources

• Use a low-drift crystal/PLL (e.g., HSE + PLL) for MCU core and timer. If absolute long-term accuracy needed, discipline with external TCXO or GPS.
• Avoid internal RC for the control loop; it adds ppm jitter.

Hardware timers

• Use a 32-bit general-purpose timer in compare mode or a hardware PWM/timer interrupt that can generate an interrupt every 100 μs.
• Where possible use timer in “one-shot” reload or master mode to trigger ADC via hardware TRGO and use DMA to move samples to memory—this removes software latency from sensing.

Interrupt priorities & preemption

• Assign the 100 μs timer ISR highest deterministic priority. Keep ISR very short: acknowledge timer, snapshot data pointers, kick a control task (e.g., set flag or use RTOS semaphore).
• If running bare-metal: handle full control step inside ISR only if WCET ≤ budget and nesting is controlled. Otherwise, ISR should be minimal and schedule a non-preemptive control context.
• Use priority grouping so only the timer and critical fault handlers can preempt the control path; mask lower priority IRQs during the deterministic window if necessary.

Kernel vs bare-metal

• Prefer a small preemptive RTOS with priority-based scheduler (e.g., FreeRTOS) if you need threads and drivers. Use static priorities and avoid priority inheritance surprises.
• For the tightest jitter (≤5 μs) a bare-metal or tickless RTOS approach is often safer: use hardware timer as source-of-truth and avoid periodic kernel tick interference. If using RTOS, make it tickless or ensure kernel ticks don’t coincide with loop.

CPU budgeting

• Compute WCET for ISR and control function (measure on target). Budget: keep control path ≤ 30–40% of 100 μs ideally (30–40 μs) leaving headroom for interrupts and jitter. Reserve slack and a low-priority background for logging/comms. Use DMA and hardware peripherals to offload work.

Verification & testing

• Instrument: use GPIO toggle at loop start/end and measure with high-bandwidth oscilloscope or logic analyzer to capture period and jitter distribution.
• Use hardware trace (ETM/SWO/ITM) and cycle counters to measure latency and WCET. Run synthetic worst-case loads (enable all interrupts, DMA bursts, bus contention).
• Metrics: report min/mean/max/stddev and worst-case latency; ensure max jitter < 5 μs with margin.
• Add watchdog and diagnostic counters; run long soak tests and thermal/voltage variation tests.

Trade-offs

• Full in-ISR control minimizes scheduling jitter but reduces maintainability and complicates debugging. RTOS increases structure but must be configured (tickless, priorities) to preserve determinism.

This architecture yields deterministic 100 μs loops with controllable jitter by using stable clocks, hardware-triggered sensing, minimal high-priority ISRs, measured WCET budgeting, and rigorous lab verification.

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.