Junior Embedded Developer Interview Preparation Guide - FAANG Standards

Direct answer

C-style cleanup is manual: acquire resources, and on every exit path (success, each early return, each error) release exactly the ones already acquired, usually by jumping to one goto out; label at the end. RAII (resource acquisition is initialisation) ties each resource's release to an object's destructor. A destructor is a function the language calls automatically when an object's lifetime ends, and for a local variable that happens when it leaves its scope (the { } block it was declared in). So the release runs on every path, in reverse order of construction. Turning exceptions off (-fno-exceptions) removes only exception unwinding, which is the compiler-generated cleanup that runs destructors while an exception travels up the call stack; destructors still run on return, break, goto and falling off the end of a scope, so RAII keeps working. What exceptions-off changes is how failure is reported: constructors cannot throw, so you use a factory (a static function that builds and returns the object) that returns an empty or failed object, check it, and keep destructors that cannot fail. The small wrapper below is a move-only owner of a FILE* (move-only means it cannot be copied, only handed over, so there is never a second owner), plus std::unique_ptr with a custom deleter (a small function object telling the pointer how to release this kind of resource) for a malloc buffer.

Structured comparison

Patterns that work without exceptions

Patterns 1 to 3 cover most code; 4 to 6 handle particular situations.

1. Scope-owned wrapper per resource (the File class below): constructor or factory acquires, destructor releases, copying is deleted, moving transfers ownership.
2. std::unique_ptr<T, Deleter> for any C handle: a deleter functor calls free, fclose, close, munmap.
3. Fallible construction through a factory (fallible: it can fail): static File open(path, mode) returns an object that is empty on failure; the caller tests it (if (!f) ...). No constructor ever needs to fail.
4. Explicit status where close can fail: a destructor cannot report an error, so give the class a close() that returns the fclose status for code that cares (writes to disk), and let the destructor be the safety net. The second example below shows it.
5. Scope guard (a tiny object running a lambda, i.e. a small inline function, in its destructor) for one-off cleanups that do not deserve a class; the second example below shows one. Arenas and pools (one object that owns many allocations and releases them all in one place) fit when many small objects share a lifetime.
6. Allocation failure: use the std::nothrow form of new (the version that returns a null pointer instead of throwing) or malloc, and test the result, since there is no handler to throw to. A function marked noexcept promises not to throw, which is what the move operations below declare.

Worked example

Compiled with g++ -std=c++17 -O2 -fno-exceptions -Wall -Wextra -fsanitize=address,undefined raii.cpp (GCC 14, Linux; run in a container). The C-style function is compiled as C++ here only so both styles share one file; in a C project it is plain C.

// build: g++ -std=c++17 -fno-exceptions -Wall -Wextra raii.cpp
#include <cstdio>
#include <cstdlib>
#include <memory>
#include <utility>

// 1. C-style: one exit label, cleanup in reverse order of acquisition
int process_c(const char* path) {
    int rc = -1;
    FILE* f = nullptr;
    char* buf = nullptr;
    f = std::fopen(path, "r");
    if (!f) goto out;
    buf = static_cast<char*>(std::malloc(64));
    if (!buf) goto out;
    if (!std::fgets(buf, 64, f)) goto out;
    rc = 0;
out:
    std::free(buf);                 // free(NULL) is a no-op
    if (f) std::fclose(f);
    return rc;
}

// 2. Small RAII wrapper: owns one FILE*, move-only, no exceptions
class File {
public:
    File() = default;
    static File open(const char* path, const char* mode) { File f; f.fp_ = std::fopen(path, mode); return f; }
    File(const File&) = delete;
    File& operator=(const File&) = delete;
    File(File&& o) noexcept : fp_(std::exchange(o.fp_, nullptr)) {}
    File& operator=(File&& o) noexcept { if (this != &o) { reset(); fp_ = std::exchange(o.fp_, nullptr); } return *this; }
    ~File() { reset(); }
    explicit operator bool() const { return fp_ != nullptr; }
    FILE* get() const { return fp_; }
private:
    void reset() { if (fp_) { std::fclose(fp_); std::puts("  (File closed)"); fp_ = nullptr; } }
    FILE* fp_ = nullptr;
};

// 3. unique_ptr with custom deleter for a C handle
struct FreeDeleter { void operator()(void* p) const { std::free(p); std::puts("  (buffer freed)"); } };
using CBuf = std::unique_ptr<char, FreeDeleter>;

int process_cpp(const char* path) {
    File f = File::open(path, "r");
    if (!f) return -1;                              // nothing to clean by hand
    CBuf buf(static_cast<char*>(std::malloc(64)));
    if (!buf) return -1;
    if (!std::fgets(buf.get(), 64, f.get())) return -1;   // early return: both destructors still run
    std::printf("  read: %s", buf.get());
    return 0;
}

int main() {
    std::FILE* t = std::fopen("sample.txt", "w"); std::fputs("hello\n", t); std::fclose(t);
    std::printf("C style rc=%d\n", process_c("sample.txt"));
    std::printf("RAII rc=%d\n", process_cpp("sample.txt"));
    std::printf("RAII missing file rc=%d\n", process_cpp("nope.txt"));
}

C style rc=0
  read: hello
  (buffer freed)
  (File closed)
RAII rc=0
RAII missing file rc=-1

Reading it: in process_cpp, f was constructed before buf, and the output shows (buffer freed) before (File closed), so destruction ran in reverse order of construction with no code written for it. In the missing-file call the function returned before buf existed; the empty File destructor printed nothing, because it had nothing to close. No leak report appeared from the sanitizer run. The goto out version works too, but each new resource and each new early exit is a place to make a mistake.

The non-obvious lines of File:

• std::exchange(o.fp_, nullptr) stores nullptr in o.fp_ and returns the old value (cppreference: "Replaces the value of obj with new_value and returns the old value of obj"). In the move constructor it takes the handle and leaves the source empty, so only one object will ever close it.
• File(File&& o) noexcept is the move constructor; noexcept promises it never throws, which it cannot, since it only copies a pointer.
• reset() closes the file if there is one and sets the pointer to null, so calling it twice is harmless. The destructor and the move assignment both use it.
• explicit operator bool() lets if (!f) ask "did the open succeed?"; explicit stops a File from silently converting to a number elsewhere.

Scope guard and a checked close

The same approach applies to a one-off cleanup and to a close that can fail. Built the same way as above (g++ -std=c++17 -O2 -fno-exceptions -Wall -Wextra -fsanitize=address,undefined, GCC 14, Linux):

#include <cstdio>
#include <utility>

// Runs a callable when the object leaves scope.
template <class F>
class ScopeGuard {
public:
    explicit ScopeGuard(F f) : f_(std::move(f)) {}
    ScopeGuard(const ScopeGuard&) = delete;
    ScopeGuard& operator=(const ScopeGuard&) = delete;
    ~ScopeGuard() { f_(); }
private:
    F f_;
};

// A file wrapper whose close() reports the fclose result.
class OutFile {
public:
    OutFile() = default;
    OutFile(const OutFile&) = delete;
    OutFile& operator=(const OutFile&) = delete;
    OutFile(OutFile&& o) noexcept : fp_(std::exchange(o.fp_, nullptr)) {}
    static OutFile open(const char* path) { OutFile f; f.fp_ = std::fopen(path, "w"); return f; }
    explicit operator bool() const { return fp_ != nullptr; }
    std::FILE* get() const { return fp_; }
    int close() {                       // 0 on success, EOF on failure; safe to call twice
        if (!fp_) return 0;
        int rc = std::fclose(fp_);
        fp_ = nullptr;
        return rc;
    }
    ~OutFile() { close(); }             // safety net: result ignored here
private:
    std::FILE* fp_ = nullptr;
};

int save(const char* path) {
    OutFile out = OutFile::open(path);
    if (!out) return -1;
    ScopeGuard log([] { std::puts("  (save() finished)"); });
    std::fputs("data\n", out.get());
    return out.close() == 0 ? 0 : -2;   // the caller learns whether the flush worked
}

int main() {
    std::printf("save rc=%d\n", save("out.txt"));
    std::printf("save to missing dir rc=%d\n", save("no_such_dir/out.txt"));
}

  (save() finished)
save rc=0
save to missing dir rc=-1

The guard's lambda ran when save returned, without any cleanup call in the body. The checked close() returns the fclose result, so a failed flush becomes the return code -2 instead of being lost. The missing directory made open fail, and the early return -1 ran no guard because it had not been constructed yet.

Pitfalls

• Copying a handle wrapper would double-close the same FILE*; that is why copy is = delete and move uses std::exchange to null the source.
• A destructor that does real work and can fail has nowhere to report it with exceptions off; keep it to the release call and expose close() for checked shutdown.
• Skipped destructors: RAII does not run on exit() called mid-function, abort(), _exit() or a crash, and longjmp (the C function that jumps straight back to an earlier saved point, abandoning the frames in between) over C++ frames is undefined behaviour if it skips non-trivial destructors (destructors that do real work). Return error codes up the stack instead.
• Two-phase initialisation (default-construct then init()) recreates the C problem of half-built objects; the factory approach avoids it.
• Mixing styles: when a C API requires a callback with a raw pointer, keep the owner object alive in the caller's scope and pass .get().

Judgement

In a codebase with exceptions disabled, commit to RAII wrappers with factory-style construction and explicit status codes; keep the goto cleanup idiom only in actual C files or in a C library you must match. If a resource is used once in a tiny function, a goto is fine; as soon as there are two resources or more than one exit, wrap them.

Overview / goals
Provide atomic configuration updates across power-fail, support rollback to last-known-good (LKG), and spread wear across three 512‑byte EEPROM pages to minimize erases.

Layout (per 512B page)

• Header (16B): magic (4B), version/counter (4B, monotonic), flags (1B: VALID/COMMIT/ERASED), CRC32 (4B), reserved.
• Payload (~480B): configuration blob.
• Footer (last 12B): copy of version and CRC for quick scan.

Always maintain at most one page marked COMMIT (new valid) after update. At boot, pages with VALID/COMMIT indicate current and candidate.

State machine & invariants

• States per page: ERASED, VALID (stable committed config), CANDIDATE (being written), COMMIT (write completed and atomic marker set).
• Invariant: there must always be at least one VALID page containing LKG config.

Update algorithm (write new config)

1. Choose next ERASED page in circular order (wear-leveling).
2. Write header with magic + version (version = prev_version + 1) and flags = CANDIDATE (no CRC yet).
3. Write payload.
4. Compute CRC, write CRC fields.
5. Atomically set flags = COMMIT (single-byte write). If flag flip succeeds, this page is new candidate committed.
6. Set previous VALID page's flags = ERASED_MARK (or simply invalidate with a single-byte flag), then erase that page in background when safe to reclaim.

If power fails:

• If a COMMIT page exists (CRC matches), treat it as VALID.
• If only CANDIDATE with missing CRC or bad CRC, ignore and keep previous VALID.

Rollback

• LKG is the highest-version page with valid CRC and flags VALID or COMMIT. If new COMMIT fails CRC or incomplete, boot uses LKG. Provide explicit rollback command: mark current page INVALID and revert to previous version by marking previous VALID/COMMIT.

Minimizing erases

• Only erase one page per full update (the one being reclaimed), rotate pages circularly to spread wear.
• Use single-byte flag updates to change state (no full erase).
• Batch erases during idle time; keep at least one ERASED page ready.

Boot scan

• Scan three pages, validate magic+CRC, pick highest version with VALID/COMMIT. If none valid, fallback to factory default in ROM.

Notes

• Use monotonic 32-bit version counter (wrap handling via compare-by-distance).
• Protect flag writes with read-verify to ensure atomicity.
• Ensure EEPROM supports atomic single-byte write; otherwise use checksum + dual-marker technique.

Direct answer

A stack frame is the block of stack memory one function call owns. On x86-64 Linux it holds, from high to low addresses: the return address pushed by call, usually the caller's saved rbp (when a frame pointer is used), then any callee-saved registers the function saved, its local variables, spilled values (arguments or temporaries that did not fit in registers) and space for outgoing stack arguments. A spilled value is one the compiler wrote from a register into the frame because it ran out of registers or needed the value across a call. In gdb you find it by stopping in the frame and examining memory relative to rbp and rsp: x/2gx $rbp shows the saved rbp and the return address, info frame states where gdb believes the saved rip and registers are, info locals and p &var give the locals, and x/16gx $rsp shows the raw words so you can see spills and saved registers.

Layout on x86-64

higher addresses
  [rbp + 16 ...]  stack-passed arguments (7th integer argument and up)
  [rbp + 8]       return address (pushed by call)
  [rbp + 0]       saved rbp of the caller
  [rbp - 8 ...]   saved callee-saved registers, locals, spilled arguments
  [rsp]           lowest word of the frame
lower addresses

A probe function compiled at -O0 with -fno-omit-frame-pointer (GCC 14.4, run emulated under linux/amd64) reads its own frame and prints the following, and its disassembly matches:

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

__attribute__((noinline)) long probe(long arg)
{
    long local = 0x1111;
    char *fp = __builtin_frame_address(0);
    Dl_info info;
    void *ret = *(void **)(fp + 8);
    dladdr(ret, &info);
    printf("&local - rbp          = %ld\n", (char *)&local - fp);
    printf("&arg   - rbp          = %ld\n", (char *)&arg - fp);
    printf("[rbp+8] is inside     = %s\n", info.dli_sname);
    printf("[rbp]  - rbp          = %s (older frame is higher)\n",
           *(char **)fp > fp ? "positive" : "negative");
    return local + arg;
}

int main(void)
{
    return (int)probe(5) == 0x1116 ? 0 : 1;
}

Built with gcc -O0 -fno-omit-frame-pointer -rdynamic frame_layout.c -ldl:

&local - rbp          = -24
&arg   - rbp          = -72
[rbp+8] is inside     = main
[rbp]  - rbp          = positive (older frame is higher)

The offsets come from the compiler's frame layout; disassembling the probe on x86-64 (objdump -d -M intel) shows these instructions, listed in program order with the others left out (the loads that compute ret, the dladdr and printf calls and the epilogue): push rbp; mov rbp,rsp; sub rsp,0x50 (reserve 80 bytes), mov QWORD PTR [rbp-0x48],rdi (the prologue spills the first argument, carried in rdi, to -0x48, which is -72), mov QWORD PTR [rbp-0x18],0x1111 (the local local lives at -0x18, which is -24), mov QWORD PTR [rbp-0x8],rbp (fp) and the ret pointer at -0x10. The Dl_info structure (four pointers, 32 bytes) occupies -0x40 to -0x20. __builtin_frame_address(0) is a GCC builtin returning this function's frame pointer, dladdr looks up which shared object and symbol contain an address (its Dl_info result holds the symbol name in dli_sname), and -rdynamic exports the program's own symbols so dladdr can name main. In AT&T syntax the same spill is mov %rdi,-0x48(%rbp); [rbp+8] is a return address inside main. At -O2 the frame pointer is usually omitted, locals are addressed from rsp, and the saved registers appear as a run of push instructions at function entry, for example push r13; push r12; push rbp; push rbx in an optimized loop function; in that case gdb finds the frame through the unwind tables rather than rbp.

The gdb commands, and a real session

Commands to use on x86-64 Linux, after the process stops (breakpoint, signal, or core file); the text after # is a note for the reader, not part of the command:

(gdb) bt                       # call chain
(gdb) info frame               # CFA, saved rip, which registers are saved where
(gdb) x/2gx $rbp               # [rbp] = caller's rbp, [rbp+8] = return address
(gdb) info symbol *(long *)($rbp+8)   # which function the return address is in
(gdb) info locals              # locals (needs -g)
(gdb) p &local                 # where one lives; compare with $rbp and $rsp
(gdb) x/16gx $rsp              # raw words: spills, saved registers, canary
(gdb) up / down / frame 2      # move between frames; registers shown are per frame

An x86-64 process cannot be traced here under emulation, so the session below was captured on native AArch64 Linux (GDB 16.3, gcc -O0 -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer frames.c -o frames). The program is below (it is frames.c; leaf, mid and main are the functions in the stack listing that follows):

#include <stdio.h>
#include <stdlib.h>

__attribute__((noinline)) long leaf(long a)
{
    return a * 3 + 1;
}

__attribute__((noinline)) long mid(long a)
{
    long buf[4];
    for (int i = 0; i < 4; i++)
        buf[i] = a + i;
    return leaf(buf[a & 3]) + buf[1];
}

int main(int argc, char **argv)
{
    (void)argv;
    printf("%ld\n", mid(argc + 4));
    return 0;
}

The structure is the same, with x29 playing rbp (the frame pointer) and the return address saved by the prologue next to it: AArch64's bl (branch with link, the call instruction) keeps the return address in the link register x30 instead of pushing it, so the function's prologue stores x29 and x30 with stp (store pair) as a two-word frame record. The -mno-omit-leaf-frame-pointer flag makes GCC keep that frame record even in functions that call nothing. The session below is stopped at a breakpoint in leaf. It starts with break leaf and run, and everything those two commands print is left out of the transcript: the Breakpoint 1 at ... line, gdb's address-space-randomization and thread-library startup messages, and the Breakpoint 1, leaf (a=6) at frames.c:6 stop line with its source line. The commands shown are then typed in that order. The stack addresses differ from run to run because of address-space randomization. info frame is abridged: its source language c., Arglist at ... and Locals at ... lines are left out, the last of which also gives Previous frame's sp, the same value as frame at:

(gdb) bt
#0  leaf (a=6) at frames.c:6
#1  0x00000000004006cc in mid (a=5) at frames.c:14
#2  0x0000000000400708 in main (argc=1, argv=0xffffcaa21f18) at frames.c:20
(gdb) info frame
Stack level 0, frame at 0xffffcaa21d30:
 pc = 0x400650 in leaf (frames.c:6); saved pc = 0x4006cc
 called by frame at 0xffffcaa21d80
 Saved registers:
  x29 at 0xffffcaa21d10, x30 at 0xffffcaa21d18
(gdb) x/2gx $x29
0xffffcaa21d10:	0x0000ffffcaa21d30	0x00000000004006cc
(gdb) up
#1  0x00000000004006cc in mid (a=5) at frames.c:14
14	    return leaf(buf[a & 3]) + buf[1];
(gdb) info locals
buf = {5, 6, 7, 8}

Reading info frame field by field: Stack level 0 is the frame number (0 is the innermost); frame at 0x...d30 is the frame's address as gdb defines it (the stack pointer value the caller had at the call); pc = ... saved pc = 0x4006cc gives the current instruction and the return address, which is where mid resumes; called by frame at ...d80 is the same address for frame 1; Saved registers lists where the prologue stored x29 (at ...d10) and x30 (at ...d18), the two words dumped next. Reading the dump: [x29] is the saved frame pointer 0x...d30, which is the next frame up (the "frame at" address of level 0), and [x29+8] is 0x4006cc, the return address inside mid. That matches the saved pc line, and info locals in frame 1 shows buf. The x86-64 equivalent of the two words is exactly x/2gx $rbp. The same info frame on x86-64 reports saved rip and Saved registers: rbp at ..., rip at ... in the same fields, with the saved rbp one word below the saved rip.

The instruction pointer

The instruction pointer (rip on x86-64, pc on AArch64) holds the address of the next instruction to run. In gdb, display/i $pc (print the instruction at pc every time gdb stops) followed by stepi (execute one machine instruction) prints each instruction as you go (the transcript leaves out the break mid and run that came first and everything they print, and the source-position line that each stepi also prints before its 1: x/i $pc display: 12 and the source text for (int i = 0; i < 4; i++) after the first, 0x00000000004006a8, 12 and the same source text after the second):

(gdb) display/i $pc
1: x/i $pc
=> 0x400678 <mid+12>:	str	wzr, [sp, #76]
(gdb) stepi
1: x/i $pc
=> 0x40067c <mid+16>:	b	0x4006a8 <mid+60>
(gdb) stepi
1: x/i $pc
=> 0x4006a8 <mid+60>:	ldr	w0, [sp, #76]

display/i $pc prints the current instruction at once: str wzr, [sp, #76], which stores zero into the loop counter i. The first stepi stops at an unconditional jump b (an AArch64 branch) that sets pc to 0x4006a8; the second shows where it landed, an ldr w0, [sp, #76], a 32-bit load of the same local variable from the stack at sp+76. Each stop therefore shows one instruction and what the => marker says will run next.

It matters for three kinds of crash. A bad indirect call (call *%rax with garbage in rax) leaves rip equal to that garbage. A corrupted return (ret pops an overwritten return address) leaves rip equal to the overwritten word, and info symbol $pc finds no function. That holds for a canonical address that is not mapped; for a non-canonical word such as 0x4141414141414141, an x86-64 CPU may report the fault on the call or ret instruction itself, so rip still points at that instruction and the bad word has to be read from the register or from [rsp]. An invalid jump into data or an unmapped page makes rip fault at an address x/i $pc cannot even read. In a core dump from this AArch64 program, built with gcc -O0 -g -fno-stack-protector and given a 40-character argument of A for its 16-byte buffer, bt showed #0 0x0041414141414141 in ?? () and the link register held 0x4141414141414141: x30 keeps the full 64-bit word loaded from the stack, while the pc register after the faulting fetch (SIGBUS in the run) shows the same 41 pattern with the top byte cleared, so both spell the overwritten return address. The signal is SIGBUS rather than SIGSEGV because a branch to an address that is not a multiple of 4 raises an AArch64 PC alignment fault, which Linux reports as SIGBUS (BUS_ADRALN); a 4-byte-aligned unmapped target such as 0x4141414141414140 gives SIGSEGV. The pc itself is the evidence of a smashed return address.

The program (an unchecked strcpy into a 16-byte buffer):

#include <stdio.h>
#include <string.h>

__attribute__((noinline)) void copy(const char *src)
{
    char buf[16];
    strcpy(buf, src);           /* no bounds check */
    printf("%s\n", buf);
}

int main(int argc, char **argv)
{
    copy(argc > 1 ? argv[1] : "hi");
    return 0;
}

Pitfalls

• info locals and p var only work with debug info (-g); without it use x/ on offsets from rbp or rsp.
• With the frame pointer omitted, $rbp is just another register and may hold program data: use info frame and bt, which use the unwind tables, not x/2gx $rbp.
• rbp is only set up after the first two prologue instructions; at the very first instruction of a function the return address is at [rsp]. Stop after the prologue (break with a source line does this) before trusting $rbp-relative views.
• Registers shown by info registers after up are reconstructed for that frame; callee-saved ones are reconstructed from the unwind records and can be trusted. Caller-saved ones cannot: the unwind records say nothing about them, so depending on the architecture gdb prints <not saved> or simply repeats the register's current value (on the AArch64 run above, x0 in frame 1 printed 0x6, the argument of leaf, not anything mid held), so never read a caller-saved register out of an outer frame. The unwind tables gdb uses are compiler-emitted records (DWARF call frame information, in .eh_frame) that say how to find the caller's frame from any instruction.
• A stack canary is a random value the compiler places between the locals and the saved return address and checks before returning; if an overflow changed it, the program aborts instead of returning to a corrupted address. Look for it in x/16gx $rsp.

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.

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.

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
I'll use Amazon's "Customer Obsession" as the example: in plain terms it means starting from the customer's actual experience and working backward to the decision, rather than starting from what's easiest or cheapest for the team and working forward to how it will land on the customer. In day-to-day work that shows up as a specific, repeatable habit: before finalizing a decision, explicitly write down what the customer will experience as a result, not just what the team will ship.

Structured elaboration

1. State the value in plain language first, in one or two sentences, before layering on any nuance. A stated value is only useful if you can restate it without jargon; if you can't, you probably don't understand it well enough to apply it.
2. Trace two or three concrete decisions the value would actually change, not just decisions it would be compatible with. The test is not "does this decision fit the value" (almost any reasonable decision can be described as fitting almost any value after the fact); the test is "would I have decided differently without this value in mind."
3. Be specific about the mechanism, not just the outcome. It's not enough to say "I'd focus on the customer"; describe the actual practice (writing the customer-facing consequence down explicitly, reviewing a metric that measures customer impact rather than only internal effort, asking a specific question in a design review) that operationalizes the value day to day.
4. Acknowledge the value has a cost or a trade-off, because a value with no real cost usually is not being taken seriously. A genuinely operative value changes what you'd otherwise have done, which means it sometimes means doing the harder or slower thing.
5. Connect it back to your own role specifically, since the same value plays out differently for different functions; the mechanism for a backend engineer, a designer, and an analyst are all different concrete practices in service of the same underlying value.

Worked example
Say you're building a dashboard intended to help a seller reduce order defects. A team NOT applying customer obsession as a working discipline might ship the dashboard once the underlying data pipeline is stable and the metrics are technically correct, treating "the data is right" as the finish line. Applying the value changes the finish line: before shipping, you'd sit with two or three actual sellers using an early version and ask what decision they're trying to make when they open it, which might surface that they need same-day defect data to catch a bad batch before it ships further, not a metric that's accurate but a day stale. The concrete decision that changes: you invest in a same-day data refresh even though it's more engineering effort than the weekly batch job you'd planned, because the customer's real decision-making need, not the easier technical path, is what determines what "done" means. The cost is real (more pipeline complexity, tighter SLAs to maintain) which is exactly why it's evidence the value is actually operative rather than decorative.

Trade-offs & pitfalls
The most common failure is reciting the value's definition fluently and then giving an example so generic it would apply to any company with any stated value ("I always think about the user"), which demonstrates you've read the careers page rather than that you understand the mechanism. A second pitfall is picking an example where the value cost nothing: if every example you give was also simply the obviously correct engineering or business call regardless of the stated value, you haven't actually shown the value did any independent work in your reasoning. A third is over-indexing on one company's specific phrasing so heavily that the answer would sound out of place at any other employer; the goal is to show you can genuinely reason from a stated principle to a concrete decision, a transferable skill, not that you've memorized one company's vocabulary.

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.

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.

Why the bound is not a sign-off. The Liu and Layland utilisation bound, U <= n(2^(1/n) - 1) for rate-monotonic (RM) priorities, is a sufficient test. It treats tasks as independent and ignores blocking, release jitter and overheads. Passing it with margin is a good first screen, but it says nothing about a particular task's response time, and failing it does not mean the set is infeasible. Response-time analysis (RTA) is exact for fixed priorities under its assumptions (preemptive, independent worst-case execution times; when blocking and jitter are included they are upper bounds, so the result is then a safe bound on the response time): it computes each task's worst-case response time and compares it with that task's own deadline, so you can see which task has the least slack.

The iteration for one task. For task i, with execution time C_i, blocking time B_i, and the set hp(i) of higher-priority tasks, the worst-case response time R_i (release to completion) is the smallest value satisfying

R_i = C_i + B_i + sum over j in hp(i) of ceil(R_i / T_j) * C_j

Here hp(i) is the set of tasks with higher priority than task i, T_j is the period of task j, and ceil rounds up. The sum counts how many times each higher-priority task can release within R_i and preempt task i. R_i appears on both sides, so iterate: start with R = C_i + B_i, evaluate the right side, feed the result back in, and stop when the value stops changing (the fixed point: a value that the equation maps back to itself) or exceeds the deadline D_i (not schedulable). The sequence is non-decreasing because a larger R can only keep or raise each ceil term. It always terminates because, with whole-millisecond times, each pass that does not stop adds at least 1 ms, so after at most D_i passes the value either settles or passes the deadline.

Where blocking enters. B_i is the longest time task i can be held up by a lower-priority task, because that lower task holds a mutex that task i (or a task above it) needs, or runs a non-preemptible section (a stretch of code that cannot be preempted, such as one with interrupts masked). It is added once to C_i, outside the interference sum: the interference sum already counts every higher-priority job, while a lower-priority task can get in ahead of task i only once, at the moment task i becomes ready and finds the mutex already held, and then only until the holder leaves its critical section (the code between lock and unlock).

The size of B_i depends on the locking protocol. Without any protocol, B_i is unbounded: a medium-priority task can keep preempting the holder, so the holder never reaches its unlock, and the high-priority task waits as long as the medium one runs; the analysis cannot be signed off for such a design. Two protocols fix that:

• PIP (priority inheritance protocol): while task H waits for the lock, the holder temporarily runs at H's priority, so a medium task cannot preempt it. Blocking can still chain: if H needs mutex A held by L1 and mutex B held by L2, H can wait for both sections in turn. With sections of 2 ms and 3 ms, B_H can reach 2 + 3 = 5 ms, one section per lower-priority task or per resource, whichever limit is smaller.
• ICPP (immediate priority ceiling protocol; OCPP, the original ceiling variant, grants a lock only if the requester's priority is higher than the ceilings of all locks held by other tasks, and raises the holder's priority only when a task is blocked on it): each mutex has a ceiling, the highest priority of any task that uses it, and a task that locks it immediately runs at that ceiling. Task i is then blocked by at most one critical section, the longest section of a lower-priority task on a mutex whose ceiling is at or above task i's priority. For the same two mutexes B_H = max(2, 3) = 3 ms.

If the hardware or an interrupt masks interrupts for a time, that goes into B_i too. A release jitter J_j on a higher-priority task (variation in when it becomes ready after its nominal release) widens its interference to ceil((R_i + J_j) / T_j) * C_j, because the task's jobs can bunch up: one release can arrive late and the next on time. Task i's own jitter is added to its reported response time.

Worked example. Three tasks in priority order (periods equal deadlines unless stated): H with C=2, T=10; M with C=4, T=20; L with C=10, T=50. U = 0.6, below the n=3 bound 0.7798, so the bound passes. H and M share a mutex with L, and L holds it for at most 3 ms, so B_H = B_M = 3 ms and B_L = 0. Run in a python:3.12-slim container (Python 3.12):

from math import ceil

def analyse(tasks, blocking, jitter=None):
    """tasks: (name, C, T, D) in priority order, highest first. blocking: name -> B (ms).
    jitter: name -> release jitter J (ms) of that task."""
    jitter = jitter or {}
    for i, (name, c, t, d) in enumerate(tasks):
        b = blocking.get(name, 0)
        r, seq = c + b, [c + b]
        while True:
            nxt = c + b + sum(ceil((r + jitter.get(n, 0)) / tj) * cj for n, cj, tj, _ in tasks[:i])
            seq.append(nxt)
            if nxt == r or nxt > d:
                break
            r = nxt
        print(f"  {name}: B={b} iterations={seq} R={nxt} D={d} meets={nxt <= d}")

tasks = [("H", 2, 10, 10), ("M", 4, 20, 20), ("L", 10, 50, 50)]
print("U =", round(sum(c / t for _, c, t, _ in tasks), 3), " bound(3) =", round(3 * (2 ** (1 / 3) - 1), 4))
print("no blocking:");              analyse(tasks, {})
print("B_H = B_M = 3 ms:");         analyse(tasks, {"H": 3, "M": 3})
tight = [("H", 2, 10, 4)] + tasks[1:]
print("H deadline 4 ms, B = 3 ms:"); analyse(tight, {"H": 3, "M": 3})
print("H deadline 4 ms, B = 1 ms:"); analyse(tight, {"H": 1, "M": 1})
print("B = 3 ms, release jitter J_H = 2 ms:"); analyse(tasks, {"H": 3, "M": 3}, {"H": 2})

U = 0.6  bound(3) = 0.7798
no blocking:
  H: B=0 iterations=[2, 2] R=2 D=10 meets=True
  M: B=0 iterations=[4, 6, 6] R=6 D=20 meets=True
  L: B=0 iterations=[10, 16, 18, 18] R=18 D=50 meets=True
B_H = B_M = 3 ms:
  H: B=3 iterations=[5, 5] R=5 D=10 meets=True
  M: B=3 iterations=[7, 9, 9] R=9 D=20 meets=True
  L: B=0 iterations=[10, 16, 18, 18] R=18 D=50 meets=True
H deadline 4 ms, B = 3 ms:
  H: B=3 iterations=[5, 5] R=5 D=4 meets=False
  M: B=3 iterations=[7, 9, 9] R=9 D=20 meets=True
  L: B=0 iterations=[10, 16, 18, 18] R=18 D=50 meets=True
H deadline 4 ms, B = 1 ms:
  H: B=1 iterations=[3, 3] R=3 D=4 meets=True
  M: B=1 iterations=[5, 7, 7] R=7 D=20 meets=True
  L: B=0 iterations=[10, 16, 18, 18] R=18 D=50 meets=True
B = 3 ms, release jitter J_H = 2 ms:
  H: B=3 iterations=[5, 5] R=5 D=10 meets=True
  M: B=3 iterations=[7, 9, 11, 11] R=11 D=20 meets=True
  L: B=0 iterations=[10, 18, 18] R=18 D=50 meets=True

Reading the output. Each iterations list is the sequence of values of R fed through the equation, ending on the fixed point. With blocking at 3 ms, H has no higher-priority task, so R_H = C + B = 2 + 3 = 5 ms, inside its 10 ms deadline. M has one higher task (H): R = 4 + 3 + ceil(R/10)*2 gives 7, then 7 + 2 = 9, then 9 again, so R_M rises from 6 to 9 ms. L's row is identical in both runs, [10, 16, 18, 18]: B_L = 0 because no lower-priority task exists to block it, and the equation for L contains no term for the 3 ms, so its start value 10, then 10 + ceil(10/10)*2 + ceil(10/20)*4 = 16, then 10 + ceil(16/10)*2 + ceil(16/20)*4 = 18, then 18 again, are unchanged. In the variant where H has a 4 ms deadline (a deadline shorter than the period is analysed with the same equation, with priorities assigned by deadline), the utilisation bound still says nothing about this, but RTA shows R_H = 5 > 4: the set fails because of the 3 ms blocking. Shortening L's critical section to 1 ms gives R_H = 3 ms, which passes. The fix is a design change in the critical section, not a faster CPU.

Release jitter changes the interference term. With J_H = 2 ms, M's equation becomes R = 4 + 3 + ceil((R + 2)/10)*2: 7 gives ceil(9/10) = 1 so 9; 9 gives ceil(11/10) = 2 so 11; 11 gives ceil(13/10) = 2 so 11. R_M grows from 9 to 11 ms because a late H job and the next on-time one can both land inside M's window. H's own row is unchanged (no higher task) and L stays at 18 ms, since its two higher-priority tasks still release the same number of times in its window.

What to tell the lead. Utilisation is the screen, response times are the evidence. Sign off with a table of C, T, D, B, J and R per task, with margin, produced by a script that is re-run whenever a worst-case execution time, a period or a critical-section length changes.