Junior Embedded Developer Interview Preparation Guide - FAANG Standards

Problem / atomicity issue
On a 32-bit MCU a 64-bit counter split into two 32-bit registers can be torn: the main thread may read the low half and then be preempted while the ISR increments the low half and carries to the high half. The main thread then reads the high half — producing an inconsistent value.

Safe approaches (>=2)

1) Disable interrupts around the 64-bit access

• Simple, deterministic, minimal code.
• Use a critical section so read/write is non-preemptible.

#include <stdint.h>
volatile uint32_t ts_low, ts_high;

uint64_t read_ts(void) {
    uint32_t prim = __get_PRIMASK();    // save interrupt state (Cortex-M example)
    __disable_irq();
    uint64_t v = ((uint64_t)ts_high << 32) | ts_low;
    if (!prim) __enable_irq();          // restore
    return v;
}

• Use same pattern when updating from thread context. Keep critical sections short.

2) Read-with-validation (double-read or sequence counter)

• No disabling interrupts; good when interrupts must stay enabled.

Double-read method:

uint64_t read_ts_safe(void) {
    uint32_t hi1, lo, hi2;
    do {
        hi1 = ts_high;
        lo  = ts_low;
        hi2 = ts_high;
    } while (hi1 != hi2);
    return ((uint64_t)hi1 << 32) | lo;
}

Sequence-counter method (ISR increments seq before/after update):

volatile uint32_t seq;
volatile uint32_t ts_low, ts_high;

uint64_t read_ts_seq(void) {
    uint32_t s;
    uint32_t hi, lo;
    do {
        s = seq;
        if (s & 1) continue;            // writer in progress
        hi = ts_high;
        lo = ts_low;
    } while (s != seq);
    return ((uint64_t)hi << 32) | lo;
}

Notes / best practices

• Mark shared variables volatile.
• Ensure proper memory barriers if compiler reorders (use atomic/volatile or compiler intrinsics).
• Keep critical sections short; prefer validation method if ISR latency must be minimal.

Function prototype & attributes

• Use the vendor/compiler ISR attribute so the compiler generates proper prologue/epilogue. Example (GCC/Cortex-M):

void TIM2_IRQHandler(void) __attribute__((interrupt)); // or simply the CMSIS name
void TIM2_IRQHandler(void) {
    // ISR body
}

• Prefer CMSIS weak vector names (e.g., TIM2_IRQHandler) or compiler-specific attributes (interrupt, ISR). Avoid naked unless you handle context manually.

Keep ISR work minimal

• Do only essential, time-critical operations: clear hardware flags, read/write registers, capture timestamps.
• Defer heavy work to tasks/threads or workqueues.

Signaling without blocking

• Use a volatile flag or lock-free queue, or RTOS-safe FromISR APIs:

volatile uint8_t data_ready = 0;
void TIM2_IRQHandler(void) {
    TIM2->SR = 0; // clear interrupt
    data_ready = 1; // signal main loop
}

• With FreeRTOS:

BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(sem, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

Reentrancy & shared data

• Mark shared variables volatile; protect multi-byte data with atomic ops or disable nesting briefly.
• Avoid non-reentrant library calls (malloc, printf). If unavoidable, protect with locks but keep duration tiny.

Stack usage

• Keep local variables small and fixed-size; avoid deep call chains.
• Measure worst-case stack with link-time info and stack-use analysis tools; add margin for interrupts.

Saving/restoring context

• Let compiler/architecture auto-save registers. Only use manual save/restore when using naked ISRs or assembly—save minimal registers and preserve LR/PSR correctly.

Follow these practices to keep ISRs fast, safe, and predictable in resource-constrained embedded systems.

Best design
I would not hand out a bare char ** with mixed ownership and no metadata. I would return a small list object that carries the tokens plus one ownership flag per slot.

Rule: if owned[i] is true, the caller frees items[i]. If it is false, the token is a slice into the original buffer and must not be freed. The caller owns the container and releases it with one cleanup function that walks the list, frees only owned tokens, then frees the arrays.

Concrete example: token 0 could be strdup("abc") and token 1 could point into the input line abc def. If the caller filters out token 0, it frees that string, but leaves token 1 alone. I would also require the source buffer to stay alive until cleanup, or duplicate everything if I want the simplest contract.

for (size_t i = 0; i < list->len; ++i) {
    if (list->owned[i]) free(list->items[i]);
}
free(list->items);
free(list->owned);

Direct answer
Beyond word choice, deliberate pacing, brief pauses at key transitions, and periodic checkpoints where you invite a question all help a live audience stay oriented during a longer explanation.

Structured elaboration

• Pacing: slowing down slightly at the most important sentence (a conclusion, a number, a decision point) signals to the listener that this part matters more than the surrounding context, the same way bolding a phrase does on a page.
• Pauses at transitions: a brief pause when moving from one idea to the next gives the listener a moment to finish processing the previous point instead of having it run together with the next one.
• Checkpoints for questions: explicitly stopping every few minutes to ask "does that make sense so far, any questions before I move on?" catches confusion early, while it's still cheap to address, rather than at the end when the listener has been lost for a while.
• Choosing two or three of these deliberately, rather than trying to do everything at once, is more sustainable; trying to consciously manage every aspect of delivery simultaneously tends to make a speaker sound stilted.

Worked example
During a fifteen-minute technical walkthrough: slow down and pause briefly right before stating the recommendation ("...and so, the option we're proposing is [pause] option two"), then at the two natural section breaks (after background, and after the options), stop explicitly and ask "any questions before I move to the next part?" rather than only checking in at the very end.

Trade-offs and pitfalls

• Overusing dramatic pauses or slowing down on things that aren't actually the key point dilutes the technique; it works because it's used selectively.
• Checkpoints can eat into your time budget if the audience takes them as an invitation for a lengthy tangent; it can help to explicitly frame them as "quick check" rather than opening the floor fully.
• These techniques don't substitute for a clear structure; a well-paced explanation of a confusing structure is still confusing, just more pleasant to listen to.

Brief summary / target: sample 0–3.3 V up to 2 kS/s, 60 dB SNR. I’d choose an ADC and data path that meet SNR/ENOB, sample-rate, input loading, anti-aliasing, and low-latency transfer via DMA with robust driver handling.

ADC resolution & SNR justification

• 60 dB SNR ⇒ ENOB ≈ (SNR − 1.76) / 6.02 ≈ 9.6 bits.
• Choose a 12-bit ADC (gives margin for front-end noise and nonidealities). If power/size allows, a 16-bit delta-sigma ADC optional for higher dynamic range.

Sampling rate

• Set ADC sampling rate ≥ 2 kS/s per spec. If multi-channel multiplexing, ensure per-channel sample rate still ≥ 2 kS/s.
• Use programmable sample timing to allow oversampling (e.g., 8 kS/s with digital decimation) if extra SNR needed.

Input impedance and front-end

• ADC input impedance >> sensor source impedance. Target input impedance ≥ 10× source impedance and ideally > 100 kΩ to avoid loading.
• Add front-end buffer op-amp (rail-to-rail) if sensor source impedance is moderate/high or to drive ADC acquisition capacitor.
• Anti-aliasing: implement an analog low-pass filter with cutoff ≈ 1.2 kHz (Nyquist = 1 kHz for 2 kS/s) — 2nd-order or 3rd-order active filter to get >40 dB attenuation above Nyquist. If oversampling, adjust cutoff accordingly.

Noise & grounding

• Budget noise: ADC LSB = 3.3 / 2^12 ≈ 0.8 mV; ensure front-end noise RMS << LSB to meet 60 dB. Use low-noise op-amps, proper layout, ground plane, and decoupling.

DMA & buffer sizing

• Require DMA support: peripheral-to-memory circular DMA with half-transfer/full-transfer interrupts for continuous streaming and low CPU load.
• Buffer sizing: choose buffer to balance latency and memory. Example target latency 100 ms → samples = 2 kS/s * 0.1 s = 200 samples. Use double-buffer (ping-pong) of 256 samples (power of two) per channel.
• For multi-channel interleaved data, size accordingly (samples × channels × bytes).

Driver responsibilities

• Configure ADC sampling time, channel sequence, and calibration.
• Configure DMA: circular mode, correct data width, memory increment, cache coherency handling (invalidate/clean as needed).
• Implement ISR or RTOS task on half/full-transfer: process or hand off buffer to processing thread, maintain timestamps/sequence numbers.
• Handle errors, ADC overrun, DMA errors, and dynamic reconfiguration (rate changes).
• Provide APIs: start/stop, set sample rate, get buffer pointer, register callback, blocking read with timeout.
• Offer runtime diagnostics: SNR/noise monitoring, sample clock jitter detection, overrange counters.

Trade-offs

• Sigma-delta ADCs: great SNR but have latency and limited input bandwidth — OK if throughput and latency fit.
• SAR ADCs: lower latency, simpler; need careful analog anti-aliasing and amplification.

This set of criteria ensures you meet the 60 dB SNR at 2 kS/s with reliable, low-CPU data transfer and maintainable firmware.

Requirements & assumptions

• 20 ECUs, each periodic control messages (typ. 10–100 ms), emergency messages must preempt.
• Classical CAN (or CAN FD) at 500 kb/s (or 2 Mb/s for FD).
• Hard real-time deadlines known per message.

High-level architecture

• Single CAN bus with 3 protected segments via high-speed transceivers and terminating resistors; optional gateway ECU for segmentation/failover.
• Use CAN IDs for static priority (lower numeric ID = higher priority). Reserve ID ranges:
  • 0x000–0x0FF: Emergency/heartbeat preemptive
  • 0x100–0x3FF: High-rate control
  • 0x400–0x7FF: Low-rate telemetry

Message prioritization & arbitration

• Assign top 8 IDs to emergency classes (e.g., brake cut, fault stop). Configure each ECU to use emergency ID only on assertion; emergency frames are short and retransmitted with backoff.
• Periodic messages scheduled with static offsets to avoid coincident arbitration losing. Use time-triggered slotting (TT-CAN) for tight determinism or staggered periodic offsets.

Bus loading analysis

• Use utilization U = sum( C_i / T_i ), where C_i is transmission time (including worst-case arbitration and ACK).
• Example: 500 kb/s, 8 byte payload, CAN frame ~128 bit -> C_i ≈ 256 μs. For 20 ECUs at 50 ms: U ≈ 20*(0.000256/0.05)=0.102 ~10.2% — safe headroom for emergency bursts.
• Ensure U < ~50% for mixed-critical systems; use CAN FD or higher bitrate if near limit.

C_i = (bits_per_frame) / bitrate
U = sum( C_i / T_i )

Fault containment

• Hardware: per-ECU transceivers with bus-off recovery policy, isolating transceivers with FET switches on repeated errors.
• Software: monitor error counters; force ECU into Listen-Only or bus-off on persistent faults; gateway to quarantine misbehaving node by filtering its IDs.
• Use CRC checks, sequence counters in payload for ECUs to detect silent failures or replay.

Diagnostics & monitoring

• Central logger ECU sampling bus load, error counters (TEC, REC), and arbitration losses; expose diagnostics via UART/OTA.
• Health messages: periodic heartbeat IDs; NACK/ack protocol for critical commands.
• Implement on-ECU self-tests reporting via diagnostic IDs (DTCs). Store event timestamps for post-mortem.
• Watchdog integration: if heartbeat missed > N thresholds, trigger safe state.

Trade-offs

• Single bus simplicity vs. segmentation for safety. Use CAN FD + TT scheduling for high utilization/determinism.

Direct answer

When an urgent security issue and a sales-critical demo land the same day, the deciding factor is exposure, not who asked more forcefully: what could go wrong if the security issue waits, and what can still be preserved for the demo without touching the risky path. Usually both can be partially served: contain or fix the security issue first, and give sales something real to show that doesn't depend on the vulnerable code.

Structured elaboration

1. Triage both in parallel, fast

Read the security bulletin and the demo request together. Identify exactly which services, data, or endpoints the vulnerability touches, and exactly what the demo needs to show.

2. Weigh exposure, not urgency of the ask

A security issue usually carries broader exposure (any affected customer, potential data risk) than a single demo (one prospective deal). That asymmetry is normally the tiebreaker, but it should be checked rather than assumed: a demo that's the last step before a major renewal can occasionally weigh more than a low-severity, well-contained finding.

3. Look for a path that serves both

A scoped hotfix with a canary rollout (releasing the fix to a small slice of traffic first, watching it closely, then rolling out to everyone once it looks clean) for the security issue, paired with a sandboxed or stubbed version of the feature for the demo, often means sales isn't actually blocked on the mainline fix landing first.

4. Communicate the decision and the reasoning immediately

Both sides need a concrete plan with timestamps, not just a priority call: what's happening, by when, and what the other side gets in the meantime.

Worked example

The patch ships to a small share of traffic first while being monitored, then rolls out fully once confirmed clean. In parallel, a second engineer builds a stubbed version of the requested feature specifically for the demo environment, so sales can present it without depending on the code currently under remediation. Both sides get an update within a couple of hours: security gets an ETA for full rollout, sales gets confirmation the demo will work and exactly how.

Trade-offs and pitfalls

• Defaulting to whichever request comes from the louder or more senior stakeholder, rather than actual exposure, is the most common failure mode here.
• Building a demo-only workaround without labeling it clearly as temporary risks it quietly becoming the real implementation, skipping the proper fix.
• Failing to give both sides a concrete timeline turns a reasonable prioritization call into a trust problem, even when the call itself was correct.
• Treating this as strictly either/or, instead of looking for a path that partially serves both, wastes an option that's usually available.

Required types/variables

#include "FreeRTOS.h"
#include "queue.h"
#include <stdint.h>

typedef uint8_t data_t;                /* buffer element type */
typedef data_t * data_ptr_t;          /* pointer passed to task */

extern QueueHandle_t xDataQueue;      /* created elsewhere with xQueueCreate */

ISR function body

void PERIPH_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    data_ptr_t pxBuffer = NULL;

    /* 1) Clear peripheral interrupt flag (device-specific register) */
    PERIPH->INTFLAG = PERIPH_INTFLAG_CLEAR; /* replace with actual MCU register */

    /* Prepare pointer to filled buffer (acquired from DMA/driver) */
    pxBuffer = GetFilledBufferFromDriver(); /* should be ISR-safe and fast */

    /* 2) Push pointer into RTOS queue from ISR */
    xQueueSendFromISR(xDataQueue, &pxBuffer, &xHigherPriorityTaskWoken);

    /* 3) Request context switch if higher-priority task was woken */
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Notes:

• Replace PERIPH register names with target MCU specifics.
• Ensure GetFilledBufferFromDriver() is safe in ISR context (no blocking).

Direct answer

Give the buffer two free-running counters, head and tail, that only ever increment (never masked back into range) and mask them with & (N-1) purely to index into the array; since N is a power of two, this lets tail - head (computed in the counters' own wrapping integer width) give the exact number of stored elements without a separate count variable. The buffer is empty when head == tail and full when tail - head == N, both computed directly from the two counters, and the same trick works if the counters are shrunk to 16-bit width, as long as N still divides that width's wraparound point (for a power-of-two N, it always does).

Structured elaboration

The free-running-counter trick

Rather than storing head and tail as values already wrapped into [0, N), let them keep counting upward indefinitely (they wrap naturally when the integer type itself overflows, for example at 256 for uint8_t). Use the masked value (head & (N-1)) only when indexing into the array. Because N is a power of two, tail - head computed in that same wrapping arithmetic gives exactly the number of elements currently stored, regardless of how many times the counters have individually wrapped, as long as the true count never exceeds the counter type's range. Full is tail - head == N; empty is tail - head == 0, i.e. head == tail. This is the interrupt-service-routine (ISR, the short function a microcontroller runs when a hardware interrupt fires) friendly version of the fix, because a single producer (the ISR) and a single consumer (the main loop) can each own one counter without ever writing the other's counter, avoiding a shared count variable that both sides would need to update atomically.

Interrupt-safety for single-producer single-consumer

If the producer runs in an ISR and the consumer runs in normal (non-interrupt) context, and each side only ever writes its own counter (producer writes tail, consumer writes head) and only reads the other's, no lock is needed as long as: the counter type is read and written atomically by the target architecture (true for a single machine word on essentially all microcontrollers), and the compiler is told not to reorder or cache those reads (mark head and tail volatile). If a second producer or consumer is added on either side, that single-writer guarantee breaks, and real synchronization (disabling interrupts briefly, or a proper lock) becomes necessary.

Shrinking the index footprint

If even two full-width counters are too much RAM, the same free-running-counter trick works with 16-bit (or 8-bit) counters, provided N remains a power of two: the wraparound point of the counter type itself becomes the modulus, so tail - head in 16-bit arithmetic still correctly reports the count as long as it never exceeds 65535. Shrinking further to 8-bit counters (as in the code below) caps the maximum distinguishable count at 255, which is a real constraint to check against the largest N you will ever configure.

Worked example

#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>

#define N 8 /* power of two */
#define MASK (N - 1)

typedef struct {
    uint8_t buf[N];
    uint8_t head; /* next byte to read */
    uint8_t tail; /* next slot to write */
} ring_t;

/* Called from normal (non-ISR) context: the consumer. */
bool ring_dequeue(ring_t *r, uint8_t *out) {
    if (r->head == r->tail) return false; /* empty */
    *out = r->buf[r->head & MASK];
    r->head++;
    return true;
}

/* Called from ISR or normal context: the producer. */
bool ring_enqueue(ring_t *r, uint8_t b) {
    uint8_t next_tail = r->tail + 1;
    if ((uint8_t)(next_tail - r->head) > N) return false; /* full */
    r->buf[r->tail & MASK] = b;
    r->tail = next_tail;
    return true;
}

int main(void) {
    ring_t r = {0};
    for (uint8_t i = 0; i < 8; i++) {
        bool ok = ring_enqueue(&r, i);
        printf("enqueue %u -> %s\n", i, ok ? "ok" : "full");
    }
    bool overflow = ring_enqueue(&r, 99);
    printf("enqueue 99 -> %s\n", overflow ? "ok" : "full");

    uint8_t v;
    while (ring_dequeue(&r, &v)) {
        printf("dequeue -> %u\n", v);
    }
    return 0;
}

Compiling and running this (clang -std=c11 -Wall -Wextra, no warnings) prints:

enqueue 0 -> ok
enqueue 1 -> ok
enqueue 2 -> ok
enqueue 3 -> ok
enqueue 4 -> ok
enqueue 5 -> ok
enqueue 6 -> ok
enqueue 7 -> ok
enqueue 99 -> full
dequeue -> 0
dequeue -> 1
dequeue -> 2
dequeue -> 3
dequeue -> 4
dequeue -> 5
dequeue -> 6
dequeue -> 7

With N=8, the buffer accepts exactly 8 enqueues before tail - head == 8 == N makes the 9th (99) report full, and draining afterward returns the original 8 values in first-in-first-out order, confirming both the wraparound (indices computed via & MASK) and the full/empty detection (computed via the raw counter difference) are correct.

Complexity

Time: $O(1)$ for enqueue and dequeue. Space: $O(N)$ for the data array, plus two small fixed-width counters, no separate count variable and no wasted slot.

Edge cases

• Enqueue on a full buffer and dequeue on an empty buffer both fail cleanly (return false) rather than corrupting head or tail.
• N must be a power of two for the mask-based indexing to be correct; a non-power-of-two N requires a true modulo operation instead, which is slower and not needed here.
• The counter width must be large enough that the true element count never exceeds it; with 8-bit counters and N=8, this is comfortably satisfied, but shrinking further while keeping N the same removes that margin.
• If a second producer is later added while the buffer is still designed for one, both producers writing the shared tail counter without synchronization is a race condition, not a variant of the existing design.

Trade-offs & pitfalls

The free-running-counter trick is preferable to the classic "reserve one slot" fix in an embedded context, because it wastes zero capacity and needs no branch on a comparison against capacity - 1; the cost is that it depends on the counter type actually wrapping the way the arithmetic assumes, which must be double-checked against the compiler's integer-promotion rules (a uint8_t subtraction can be promoted to int before the wraparound happens, so the subtraction and comparison should be done, or cast back, in the original unsigned width). A common wrong turn in the ISR-safety framing is assuming that "no lock is used" means "no synchronization discipline is needed": the single-writer-per-counter invariant, and the volatile qualifier that stops the compiler from caching stale copies of head or tail in a register, are both still required, and dropping either one reintroduces the exact race the design was meant to avoid.

Overview — what nested interrupts are
Nested interrupts allow a higher-priority exception to preempt an ISR that is already running. On Cortex-M this is hardware-supported: each exception has a priority level (numerical), and the NVIC plus the core decide preemption based on priority and mask state.

Implementation & control on Cortex-M

• NVIC holds configurable priority fields (usually 3–8 bits implemented). When an exception occurs, core compares active exception priority vs new exception priority; if new has numerically lower (higher logical) priority, it preempts.
• The core automatically saves context (R0–R3, R12, LR, PC, xPSR) on the stack on exception entry and restores on return, enabling nesting with separate stacked frames per ISR.

Role of PRIMASK and BASEPRI

• PRIMASK: single-bit global mask. When set, it disables all configurable exceptions (except NMI and HardFault). Use for very short critical sections — simple, fast, non-prioritized masking.
• BASEPRI: byte mask that disables exceptions with priority value equal or numerically higher than BASEPRI threshold while allowing higher-priority (lower numerical) exceptions. Use for priority-aware masking to allow selective preemption.
• Usage pattern: use BASEPRI in ISRs or scheduler-critical code to allow high-priority interrupts while preventing interference from mid/low priorities.

Stack & context implications

• Each nested entry pushes a full exception frame; deep nesting increases stack usage — must size MSP appropriately.
• Latency: deeper nesting increases worst-case interrupt latency for lower-priority handlers and increases interrupt handling time.
• Re-entrancy and shared state: deeper nesting demands careful use of volatile/shared protection, and awareness that ISRs may run concurrently in nested fashion.

Trade-offs: deep nesting vs limited nesting for determinism

• Deep nesting: higher responsiveness for urgent events, better prioritization, but larger stack use, harder WCET analysis, more complex timing and potential priority inversion scenarios.
• Limited nesting (using BASEPRI or disabling preemption): simpler timing analysis and stronger determinism (good for hard real-time), smaller stack budgets, but increased latency for high-priority events.
• Practical guidance: use BASEPRI to allow only truly higher-priority exceptions; keep ISRs short, defer work to threads/tasks; size stacks with conservative worst-case nesting; for safety-critical systems prefer bounded nesting/policy to guarantee WCET and deadlines.