Entry-Level Embedded Developer Interview Preparation Guide - FAANG Standards

Direct answer

A proposal was about to go out to a client built on an assumption from a regulatory area outside my usual scope, and nobody had actually verified it held. Since no one else had the bandwidth and it wasn't formally assigned to me, I picked it up myself, worked it in around existing commitments over about a week and a half, and it changed the outcome directly: the assumption turned out to be wrong.

Structured elaboration

Why the gap mattered to the business, not just to me personally: committing resources to a flawed assumption would have cost far more to unwind later than the time it took to check it up front, so this wasn't learning for its own sake, it was risk that had a real dollar and reputation cost attached.

How I fit it around existing delivery: a few focused hours most days, worked around my actual deliverables rather than replacing them, which is closer to the honest reality than pretending I found a clear open runway.

What I chose to learn from and why: the primary source material for the regulation itself, plus one conversation with someone closer to that domain to sanity-check my reading, rather than a general course, because the timeline didn't allow for breadth and precision mattered more here than depth of background.

The first real application and how I checked it before it counted: I used what I'd learned to redline the specific assumption in the proposal, then had the person closer to that domain review that specific change before it went out, since being self-taught on something this consequential doesn't make me the final authority on it.

Worked example

The flawed assumption got caught and corrected before the proposal went out, which avoided a costly rework and a credibility problem with the client later. What I'd do differently next time: flag the gap the moment I noticed it, rather than only surfacing it once the proposal was nearly final, which gave less room to fix it calmly. It's also worth naming the distinction directly: this is a stronger example precisely because nobody assigned it to me, I noticed the gap and closed it on my own, which is a different and harder signal than closing a gap someone else already identified for me.

Trade-offs and pitfalls

A common wrong turn in this kind of answer is treating "learning outside my expertise" as a story about personal growth in the abstract, disconnected from why the business actually needed it. The other is overstating the depth reached: the honest version isn't "I became an expert in it," it's "I got enough to catch the specific risk and knew to verify the fix with someone deeper in the area before it shipped."

Direct answer

Convert the smaller of the two arrays to a hash set, then scan the larger array once, keeping any element that's present in that set (collecting results in a second set so duplicates in the larger array don't produce duplicate output). This is O(n + m) time. Building the set from the smaller array specifically bounds the extra memory to O(min(n, m)) rather than O(max(n, m)).

Approach

1. Determine which input array is smaller; build a hash set from it.
2. Scan the other (larger) array once. For each element, check set membership (O(1) average); if present, add it to a result set.
3. Return the result set as a list. Using a set for the result (not a list with manual duplicate-checking) means each hit is still O(1) average to record, and duplicates collapse automatically.

Complexity

Time: O(n + m): O(min(n, m)) to build the smaller set, O(max(n, m)) to scan the other array with O(1) average membership checks. Space: O(min(n, m)) for the set that gets built, plus O(result size) for the output, which is at most min(n, m).

Edge cases

• No overlap at all: returns an empty list.
• One array is empty: returns an empty list immediately (no need to even build a set from the other one).
• Duplicates on either side don't affect the result, since both membership testing and the result collection are set-based.

def intersection(nums1, nums2):
    if len(nums1) > len(nums2):
        nums1, nums2 = nums2, nums1
    small_set = set(nums1)
    result = set()
    for x in nums2:
        if x in small_set:
            result.add(x)
    return list(result)


nums1 = [1, 2, 2, 1]
nums2 = [2, 2]
print(sorted(intersection(nums1, nums2)))

nums1b = [4, 9, 5]
nums2b = [9, 4, 9, 8, 4]
print(sorted(intersection(nums1b, nums2b)))

Output:

[2]
[4, 9]

The first case matches the question's own example directly: duplicates on both sides (2 appears twice in nums1, twice in nums2) still produce a single 2 in the output. The second case shows the general behavior with distinct arrays: 4 and 9 are the only values common to both, 5 and 8 are not shared.

Trade-offs and pitfalls

• The core memory trade-off: the hash-set approach spends O(min(n, m)) extra memory to buy O(n + m) time; that memory cost is the price of O(1) average membership checks, and choosing to build the set from the smaller array specifically minimizes how much of that price you pay.
• Time-vs-space alternative: if both arrays are already sorted (or can be sorted), a two-pointer sweep over both does the same job in O((n + m) log(n + m)) time (dominated by the sort, if not already sorted) but only O(1) extra space beyond the output, trading time for space. This matters when memory is the binding constraint and the arrays are large enough that even the smaller hash set doesn't comfortably fit.
• Hashability requirement: the set-based approach only works directly on hashable elements (ints, strings, tuples of hashables); a list of unhashable items (e.g. dicts) needs a different comparison strategy, such as sorting by a derived key or using a hashable representation of each element.
• Streaming / memory-bound variant, tied to the question's "overlapping users between datasets" framing: if one of the two "arrays" is really a live dataset too large to hold entirely in memory, you can still build the in-memory set from whichever side is smaller and stream the larger side through it one record at a time without ever materializing the larger side fully, which is the same core technique as above just applied to a data pipeline instead of an in-memory list. If even the smaller side doesn't fit in memory, that's a genuinely different problem (approximate membership / external-memory joins), and calls for infrastructure well beyond this warm-up technique.
• Common miscount: returning a list built by iterating nums2 and appending on every match without deduplication reproduces the multiplicity of matches (intersect with repeats) rather than the "unique elements only" result the question asks for.

Definition & why it matters
Re-entrant code can be safely interrupted and re-entered (e.g., by an ISR) without corrupting its state. For embedded systems, ISRs can preempt main-context functions — non-reentrant code leads to data corruption, crashes, or missed deadlines.

Three common mistakes and fixes

1. Shared non-atomic globals (e.g., counters)

• Bug: main() and ISR update same int without protection — torn reads/writes or race.
• Fix: make accesses atomic or protect with interrupt disable or lock-free atomic ops.

volatile uint32_t counter; // OK with atomic ops
/* ISR */ __atomic_fetch_add(&counter, 1, __ATOMIC_SEQ_CST);

2. Using static/local state (persistent buffer/index)

• Bug: function uses static buffer; ISR re-enters and overwrites it.
• Fix: avoid static; pass caller-owned buffers, or allocate per-call, or disable interrupts during critical section.

// Instead of static char buf[...], use:
void process(char *buf, size_t n);

3. Calling non-reentrant library routines (e.g., malloc, printf)

• Bug: ISR calls printf while main also prints → internal state corruption.
• Fix: don't call non-reentrant APIs from ISRs. Use lock-free signaling: set a flag or enqueue data into an ISR-safe ring buffer, and let main handle printing.

Closing
Prefer simple, deterministic fixes: minimize ISR work, use atomic primitives, keep shared state small and well-synchronized, mark shared vars volatile, and document reentrancy requirements.

Clarify constraints & goals
Device has no hardware secure element, limited flash/CPU, must verify firmware authenticity, prevent rollback, minimize key extraction risk, and allow remediation if keys leak.

High-level design

• Use asymmetric code signing: manufacturer holds ECDSA (P-256) or Ed25519 private key; device holds public key.
• Immutable boot ROM (or first-stage bootloader in write-protected region) contains verifier code and a public-key digest (pinned root).
• Firmware images signed; metadata includes version + monotonic counter + hash.

Where/how keys are stored

• Store a single root public key (or its SHA-256 digest) in ROM/One-time-programmable fuses; if ROM not writable, store in protected flash area with CRC and copy-on-boot verification.
• Do NOT store private keys on device.

Verification flow

1. Boot ROM loads verifier, reads signed firmware header.
2. Verify signature with pinned public key.
3. Check image integrity (hash), then check version/monotonic counter against stored anti-rollback value.
4. If valid, jump to firmware; otherwise enter recovery.

Anti-rollback

• Maintain a monotonic counter (rollback counter) stored in flash with redundancy and cryptographic binding: store {counter, nonce, HMAC(counter||nonce, session_key)} where session_key derived from root public key using KDF. Increment-only write pattern and majority-copy with wear-leveling.
• Alternatively use monotonic hardware counter if available later.

Reduce key-extraction risk

• Minimize public key exposure (store digest rather than full key).
• Obfuscate stored anti-rollback state (encrypted or HMACed).
• Use firmware encryption for sensitive blobs; rotate keys per manufacturing batch.
• Employ code hardening: disable debugging interfaces in production, lock JTAG/SWD via option bytes, secure boot fuses, erase debug on tamper.
• Use return-oriented mitigations and NX bit to reduce exploit surface.

Compromise & remediation

• If private key compromised: publish new root public key and issue signed firmware that replaces pinned key — but boot ROM must accept key rotation via an authenticated key-rotation mechanism:
  • Use a two-tier chain: device trusts a ROM-pinned manufacturer key that can authorize a short-lived key (update key) via a certificate with embedded expiry and revocation list.
  • Revoke compromised key by having devices accept only updates signed by a new key that is itself signed by ROM root.
• If ROM cannot change and private key of ROM-pinned root is leaked, worst-case requires hardware recall; mitigate by multi-key quorum (threshold signatures) or embedding device-unique keys at provisioning.

Trade-offs

• Storing root key in writable flash is practical but raises extraction risk; ROM/fuse is safest but inflexible.
• HMAC-based anti-rollback uses symmetric secrets derived from public key — simpler but relies on secrecy of derived key stored; stronger option is monotonic hardware.
• Complexity vs recoverability: adding key-rotation/cert chain increases boot code size and complexity but enables recovery without recalls.

Practical notes

• Use Ed25519 for compact signatures and fast verification in constrained MCUs.
• Keep verifier minimal, well-audited C code; avoid dynamic allocation.
• Test failure modes: power loss during update, multiple corrupt copies, and rollback attempts.

Overview
For a small MCU doing sensor sampling, comms, and a simple UI, the superloop (bare-metal event loop) and RTOS each have trade-offs. Below I compare key attributes and give a practical checklist to choose.

Comparison

• Scheduling predictability: Superloop = very predictable if simple sequential tasks; RTOS = deterministic if using fixed priorities and careful design (helpful when tasks have hard deadlines).
• Memory & CPU overhead: Superloop minimal stack/heap; RTOS adds kernel code, threads, stacks — higher flash/RAM and context-switch cost.
• Latency: Superloop can have lower best-case latency; RTOS offers bounded worst-case latency with priority-based preemption.
• Power management: Superloop easily sleeps between events; RTOS requires integration with tickless mode or explicit power APIs to avoid wake-ups.
• Concurrency primitives: Superloop uses flags/state machines — simple but error-prone for complex sharing; RTOS gives mutexes/semaphores/queues, simplifying design but needing careful deadlock handling.
• Debugging: Superloop: easier call trace, fewer moving parts; RTOS: harder timing bugs, but tools (thread-aware debuggers, trace) help.

Criteria & Checklist
Choose superloop if:

• <4 periodic tasks, simple state machine
• Tight flash/RAM budget
• Soft real-time with tolerant deadlines

Choose RTOS if:

• Multiple independent timing constraints
• Need IPC, priority inversion handling, or modular task separation
• Future feature growth expected

Example checklist:

• Task count & deadlines
• RAM/Flash budget
• Need for preemption or IPC
• Power-management strategy (tickless?)
• Maintainability and team familiarity

I’d prototype a superloop first; move to RTOS if scheduling/complexity becomes unmanageable.

Design overview
Implement a portable bit-banged SPI driver written in C with a pluggable “port” layer for GPIO set/clear/read. Expose a transfer API: int spi_transfer(const spi_cfg_t *cfg, const uint8_t *tx, uint8_t *rx, size_t len). cfg includes CPOL/CPHA, SCLK pin, MOSI, MISO, mode, and target frequency (<=1 MHz). The driver implements full-duplex by sampling MISO on the configured phase while toggling SCLK and outputting MOSI bits.

Timing choices

• Target: 1 MHz -> 500 ns half-period. For Cortex-M, prefer DWT_CYCCNT or SysTick/hardware timer to get accurate delays when available.
• Busy-wait loops (tight cycle-counted NOP sequences) are simplest and lowest-overhead if you can guarantee no preemption and know core clock. Use only when running with IRQs masked or at high priority.
• Hardware-timer driven delays (single-shot compare) give accurate timing without burning CPU but add ISR overhead; good when preemption/RTOS coexist or lower CPU load is desired.

Recommendation: use a hybrid: prefer cycle-counter busy-waits when DWT available and driver runs with IRQs allowed but briefly temporarily elevated; fall back to a high-resolution hardware timer when DWT missing or when OS preemption cannot be controlled.

Optimizations

• Inline the bit loop and mark hot with inline/always_inline.
• Loop unrolling for common lengths (bytes): transmit 8 bits in an unrolled sequence to remove loop overhead.
• Precompute per-byte toggle sequences into a small table of 8 toggle actions for CPHA/CPOL variants so per-bit branching is minimized.
• Use word-sized GPIO registers (write mask) to toggle SCLK/MOSI in a single atomic register write when MCU supports it.
• Use DWT cycle reads to spin until target cycles instead of function-call delays.
• If multiple transfers to same device, cache computed timing parameters and pin masks.

RTOS preemption and IRQs

• Full-duplex bit-bang is timing-sensitive: either
  • perform short transfers with IRQs enabled but rely on cycle-counted delays (acceptable for millisecond-level transfers), or
  • take a short critical section: raise task priority / disable scheduler preemption (not global IRQs unless needed) during each byte to guarantee timing.
• Document that very long transfers should use hardware SPI to avoid blocking scheduler.
• Protect GPIO and device state with mutexes; allow ISR-driven higher-priority tasks to preempt but ensure transfer recovers if interrupted (restart byte or abort with error).

Dynamic hardware detection & switching

• Provide an SPI backend abstraction: bitbang_backend and hw_backend. At init, probe for hardware SPI by:
  • Checking SoC peripheral registers/enumeration (device tree / HAL API) and configuring chip-select pins.
  • Attempting a quick loopback transfer through hardware SPI to validate functioning.
• If hardware available and pins match (or can be remapped), switch to hw_backend which uses DMA + peripheral.
• Allow runtime override: spi_set_backend(handle, prefer_hw) so system can choose based on concurrent load, power, or timing needs.

Trade-offs

• Busy-wait: lowest latency, highest CPU usage, fragile under preemption.
• Timer/ISR: lower CPU use, higher latency and code complexity.
• Precompute/unroll: memory vs CPU trade-off — acceptable for performance-critical paths.

This design balances portability, 1 MHz timing, low CPU overhead via cycle counters and register writes, RTOS safety via short critical sections and mutexes, and runtime flexibility to use hardware SPI when available.

Approach (brief)
Use shifts and masks to isolate fields. Provide macros for masks/shifts and static inline helpers that read/modify the 32-bit register via volatile pointer to avoid races.

Macros / inline functions

#include <stdint.h>

#define REG_MODE_SHIFT   24U
#define REG_MODE_MASK    (0xFFU << REG_MODE_SHIFT)

#define REG_THRESH_SHIFT 8U
#define REG_THRESH_MASK  (0xFFU << REG_THRESH_SHIFT)

#define REG_RESET_BIT    (1U << 1)
#define REG_ENABLE_BIT   (1U << 0)

/* Set MODE (8-bit) */
static inline void reg_set_mode(volatile uint32_t *reg, uint8_t mode)
{
    uint32_t v = *reg;
    v &= ~REG_MODE_MASK;                      /* clear MODE */
    v |= ((uint32_t)mode << REG_MODE_SHIFT); /* set MODE */
    *reg = v;
}

/* Read MODE */
static inline uint8_t reg_get_mode(volatile uint32_t *reg)
{
    return (uint8_t)((*reg & REG_MODE_MASK) >> REG_MODE_SHIFT);
}

/* Set THRESH (8-bit) */
static inline void reg_set_thresh(volatile uint32_t *reg, uint8_t thresh)
{
    uint32_t v = *reg;
    v &= ~REG_THRESH_MASK;
    v |= ((uint32_t)thresh << REG_THRESH_SHIFT);
    *reg = v;
}

/* Enable / Disable */
static inline void reg_enable(volatile uint32_t *reg)  { *reg |= REG_ENABLE_BIT; }
static inline void reg_disable(volatile uint32_t *reg) { *reg &= ~REG_ENABLE_BIT; }

/* Issue RESET (write 1) - writing 1 may be self-clearing in HW */
static inline void reg_reset(volatile uint32_t *reg)   { *reg |= REG_RESET_BIT; }

Notes:

• Read-modify-write protects other fields but may need critical section if concurrent access by interrupts or DMA.
• No bitfields used; operations are portable and efficient for embedded.

Brief concept
A microcontroller memory map is the layout that assigns physical address ranges to ROM/Flash, RAM, peripheral registers, and special regions (vector table, bootloader). The linker maps logical sections (.text, .data, .bss, heap, stack) into those physical regions so the CPU and startup code know where to fetch code and place initialized data.

Typical small MCU memory map (ascending addresses)
0000 0000 ─────────────────────────────
Boot ROM / Bootloader (optional) — e.g. 0x0000_0000–0x0000_0FFF
Vector Table (reset/ISRs) — at start of Flash (0x0000_0000)
.text (code, const data) — continues after vector table
Read‑only data (.rodata) —
Flash reserved / option bytes —
0FFF FFFF ─────────────────────────────
2000 0000 ─────────────────────────────
SRAM start: .data (initialized) — runtime copy target
.bss (zeroed) —
Heap — grows up
(free RAM)
Stack — grows down from top of SRAM
2000 FFFF ─────────────────────────────
4000 0000 ─────────────────────────────
Peripheral register space (APB/AHB) — MMIO addresses
FFFFFFFF ─────────────────────────────

How linker scripts map sections
The linker script defines MEMORY regions and then places SECTIONS into those regions. Example excerpt (GNU ld):

MEMORY {
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 256K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 40K
}

SECTIONS {
  .vector  : { KEEP(*(.isr_vector)) } > FLASH
  .text    : { *(.text*) *(.rodata*) }   > FLASH
  .data    : { _sdata = .; *(.data*); _edata = .; } > RAM AT> FLASH
  .bss     : { _sbss = .; *(.bss*); _ebss = .; }    > RAM
  _stack_top = ORIGIN(RAM) + LENGTH(RAM);
}

• "AT> FLASH" places initializers in Flash but sets load address so startup copies them into RAM.
• Linker symbols (_sdata, _edata, _sbss, _ebss, _stack_top) are used by reset code to initialize .data, clear .bss and set the stack pointer.

Why this matters
Correct mapping ensures vectors and code execute from non-volatile Flash while mutable data lives in SRAM, peripherals are reachable via MMIO, and startup/runtime routines can initialize memory reliably.

Problem formulation (continuous frequencies)

Minimize total energy by choosing fi for each task τi (period Pi, base cycles Ci) and a feasible schedule:

Objective:

E_total = sum_i E_i(f_i),   where   E_i(f_i) = alpha * C_i * f_i^{k-1}

(assuming power P(f)=alpha f^k and WCET_i(f)=C_i / f_i)

Schedulability constraints (single CPU, preemptive EDF):

forall t: sum_i WCET_i(f_i)/P_i = sum_i (C_i / f_i) / P_i <= 1

Bounds:

f_min <= f_i <= f_max   (and f_i continuous or from discrete set F)

Why these expressions

• WCET inversely proportional to f: WCET = C_i / f_i.
• Energy per task = power * execution time = alpha f^k * (C_i / f_i) = alpha C_i f^{k-1}.

Complexity

• Continuous version (fi continuous): objective is separable; since 1/f is convex on f>0 and E_i(f) = alpha C_i f^{k-1} is convex for k>=2 (common CMOS k≈2–3), the problem is a convex program (minimize convex objective over convex feasible set) and solvable efficiently with standard convex solvers.
• Discrete-frequency hardware or additional integer scheduling decisions (task-to-core partitioning, mode switching overheads) make it a mixed-integer nonconvex problem → NP-hard in general.

Practical heuristics for embedded systems

1. Continuous-relaxation + rounding
   • Solve convex relaxation for fi, then round each f_i up to nearest supported discrete frequency to preserve schedulability.
2. Utilization-based scaling (simple, cheap)
   • Compute required scaled utilization U_req = sum_i C_i / P_i.
   • Set a single global f = max(f_min, min(f_max, U_req * f_nominal)) or f proportional to U_req; good for very constrained RTOS.
3. Per-task DVFS with greedy allocation
   • Start at f_min for all; increase frequencies for tasks with largest marginal energy savings per schedulability gain until constraint met.
4. EDF slack reclamation (dynamic)
   • Run at conservative baseline frequency; reclaim slack at runtime per job deadlines, use greedy per-job speed-up.
5. Precomputed table / mode selection
   • Offline compute a small set of frequency assignments (modes) and switch modes based on workload; stores low memory footprints.

Implementation tips for embedded developers

• Prefer continuous solve offline (or lightweight convex solver) then quantize for device frequencies.
• Account for transition overheads and fast switching limits; include switching energy/time as constraints if relevant.
• Test with worst-case phasing and jitter; validate schedulability with measurement-based WCET margins.
• Use EDF with runtime slack reclaiming for best energy vs. complexity trade-off on single-core devices.

This gives a provably optimal continuous baseline and several practical approximations suitable for resource-constrained firmware.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.