Interview Preparation Guide: Junior Embedded Developer at Airbnb

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

When legal or compliance flags a possible regulatory problem on something about to ship, that flag is new information, not an attack on the project. The first move is to separate the specific risk from the whole feature: find out exactly what triggers the concern, then look for a way to ship everything outside that blast radius (the specific data, users, or markets the flagged concern actually touches) while the risky piece gets handled properly. Treating the flag as either a full block to fight or a formality to route around are both weak answers; the senior move is to make the freeze as small as the actual risk.

Structured elaboration

1. Turn the flag into a scoped, written finding

Ask for the specific clause or regulation, the specific data flow or behavior it applies to, and which markets or user segments are affected. A flag that sounds like 'this violates a regulation' often narrows down to 'this one data field, in these two markets.' Until that scoping happens, nobody can reason about mitigation, they can only argue about the abstract freeze.

2. Sort what's actually blocked from what's just slow

Once scoped, most flags fall into three buckets: genuinely unsafe to ship anywhere (rare, but real, treat it as a hard stop); unsafe in specific markets or for specific data (the common case, often scoped out with a flag or market-level rule); or unsafe as currently designed but fixable with a smaller change than a full freeze (needs a scoped rework, not a blanket delay).

3. Bring a mitigation, not just a constraint

Offer a concrete option: disable the flagged behavior for the affected markets, gate it behind a feature flag (a toggle that turns a piece of functionality on or off without a new deployment), or ship a version that omits the specific data flow while the rest proceeds. This turns the conversation from 'can we go or not' into 'does this mitigation satisfy the concern,' which moves much faster.

4. Get joint, written sign-off before proceeding

Both the business owner and compliance need to agree in writing on what shipped, what did not, the remaining risk, and who owns closing it. This protects everyone if the interpretation is questioned later and prevents the same argument from recurring next release.

5. If a real freeze can't be avoided, negotiate the timeline explicitly

Sometimes there is no safe scoped path and the freeze has to hold for the affected piece. Here the negotiation shifts to: what's the minimum change needed to clear the concern, who is assigned to it, and can the review be fast-tracked with a dedicated reviewer instead of sitting in a general queue. A freeze with a committed, shrinking timeline is a very different conversation from an open-ended one.

Worked example

A team is about to ship a feature that logs a new field for product analytics, and legal flags that collecting that field may violate a data-protection rule in one region. Scoping the flag shows the issue is narrow: one field, one region. Instead of freezing the whole release, the team ships everywhere else immediately, and for the flagged region ships the same feature with that one field's collection disabled behind a config switch. Legal signs off on the scoped version in writing. The team opens a follow-up item, with an owner and a target date, to redesign how that field is collected (for example, aggregating it instead of storing it per user), so the region isn't stuck without the feature indefinitely.

Trade-offs and pitfalls

• Treating every compliance flag as either a full block or a nuisance to route around is the most common mistake here; both extremes erode trust with the compliance function over time.
• Scoped mitigations (flags, market gating, field exclusions) are good short-term tools but can quietly become permanent if nobody owns the follow-up fix. The sign-off should name an owner and a date, not just describe a workaround.
• Escalating past compliance to force a ship date, without addressing the underlying concern, tends to resurface later as a bigger problem: a real violation or a regulator inquiry. Speed gained by skipping the process rarely survives contact with the risk it was protecting against.
• The strongest signal of seniority isn't how fast the team got to yes, it's whether the final decision is something both sides would still defend the same way months later.

Definition — Interrupt latency
Interrupt latency is the time from when an interrupt source becomes pending (edge or level) to when the first instruction of its interrupt service routine (ISR) executes on the CPU. For hard real-time embedded systems, this defines the worst-case reaction time.

Primary contributing factors

• Hardware

  • Interrupt propagation delay from peripheral to NVIC / interrupt controller
  • Bus arbitration and DMA activity delaying peripheral or vector fetch
  • Clock domains, synchronizers, and interrupt prioritizer (NVIC) behavior
  • Cache misses and TLB/page-walks (if MMU/MMU-like present)

• Software / CPU

  • Global interrupt disable windows in firmware or critical sections
  • ISR entry overhead: stacking registers, switching modes, saving context
  • Nested/priority handling, tail-chaining, and interrupt masking policies
  • RTOS context switch cost (if ISR triggers a task wake)
  • Compiler prologue/epilogue and function-call overhead if ISR not optimized

Three practical steps to reduce latency

1. Prioritize and minimize ISR work
   • Give time-critical interrupts highest NVIC priority; do minimal processing in ISR and defer heavy work to deferred-service tasks/queues.
2. Reduce entry overhead
   • Use compiler attributes/assembly to write ISR with "naked" or optimized prologue where safe; disable large critical sections; enable tail-chaining in NVIC if available.
3. Improve hardware fetch and arbitration
   • Place vector table and ISR code in fast (tightly-coupled) memory; disable caches or use cache-locking for ISR code/data; minimize DMA/bus contention for time-critical peripherals.

These actions together lower both deterministic and average interrupt latency in microcontroller systems.

Clarify goals & constraints

• Minimize power while preserving real-time deadlines; MCU supports discrete frequency/voltage steps with non-zero transition latency and energy cost.
• Assume FreeRTOS preemptive scheduler, configGENERATE_RUN_TIME_STATS enabled, and access to hw power manager.

High-level placement

• Implement a DVFS "governor" as a FreeRTOS daemon task (low priority) + CPU driver layer. Governor subscribes to scheduler events and reads per-task statistics; driver performs safe frequency/voltage transitions using MCU power API.

Obtaining per-task usage/slack

• Use FreeRTOS run-time stats (uxTaskGetSystemState or configGENERATE_RUN_TIME_STATS timestamps) to get runtime per task over sliding windows.
• For finer slack, enable tickless idle and track idle durations + wake events.
• Optionally instrument context switch hook (traceTASK_SWITCHED_IN/OUT) to measure actual execution time and remaining budget for periodic tasks.
• Derive instantaneous utilization U = sum( execution_time_window / window_length ) and per-task slack = period - observed_execution.

Governor/policy design

• Two-layer approach:
  • Policy module: decides target frequency based on utilization, slack, and deadlines (e.g., conservative ramp: pick lowest f where worst-case execution time scaled by f still meets deadlines).
  • Reactive controller: quick upscaling on deadline pressure (e.g., missed budget or proximity threshold).
• Use queuing of requested changes + hysteresis to avoid oscillation.

API design (example)
Provide simple C API for tasks and system components to hint or request:

// Request a hint: non-binding, increases priority of higher freq
void DVFS_RequestHint(const char *tag, uint32_t suggested_freq_hz);

// Hard reservation: must be honored; returns false if infeasible
bool DVFS_ReserveFrequency(uint32_t min_freq_hz, TickType_t duration_ticks);

// Revoke reservation/hint
void DVFS_ReleaseReservation(uint32_t reservation_id);

• Internally each reservation updates the governor's constraint set. Hints are aggregated.

Ensuring deadlines during transitions

• Model WCET as function of frequency: WCET_f = WCET_ref * (f_ref / f). Use conservative WCET scaling for schedulability tests (RMS or response-time analysis).
• Before lowering frequency, governor runs a quick schedulability check against current ready set + reservations; reject if unsafe.
• Consider transition latency: account for time_to_change when computing available CPU time (t_available -= time_to_change). If voltage scaling requires a lock (no interrupts), avoid during critical sections.
• Use frequency change points during idle or known safe windows (e.g., at tick boundary or when no high-priority deadlines are imminent). If immediate upscaling needed, preempt governor to request fast transition.

Driver integration & safety

• Driver performs voltage change first when raising V, then change clock; reverse when lowering. Provide callback hooks to suspend peripherals if required.
• Protect transitions with a DVFS mutex and reference counting for reservations to prevent conflicting transitions.

Validation & testing

• Unit test governor with synthetic task sets (periodic tasks) and worst-case scaled WCETs.
• Use trace tools to verify no deadline misses; perform stress tests that trigger up/down ramps.

Trade-offs

• Frequent fine-grained DVFS complexity vs. energy savings. Conservative approach (coarse windows + reservations) reduces risk for RT guarantees.

Opening / framing
I’d start by aligning on the user impact: “You’ve asked for 5 ms end-to-end latency. Let me explain what that means in hardware+firmware terms, what I measured, and the realistic options (and trade‑offs) to get there.”

Key metrics I’d present

• Measured baseline: current E2E = X ms (breakdown: ISR-to-task = A ms, processing = B ms, comms = C ms).
• CPU budget: cycles required per event = ~N cycles → translates to required clock = N / 0.005.
• Memory needs: stack + buffers + DMA descriptors = M KB; current MCU RAM = R KB → headroom?
• IO and bus latencies: SPI/I2C/UART worst-case delays, DMA vs CPU copy.
• Power and BOM delta: estimated cost increase and mA impact for candidate MCUs.

Trade-offs

• Higher-clock MCU: lower latency, but higher BOM cost, power, and sometimes longer qualification.
• More RAM: reduces fragmentation and avoids blocking due to memory pressure.
• Cache and pipeline hazards: can improve throughput but add jitter — affects determinism.
• Offload (DMA/co-processor): keeps MCU cheap but adds hardware complexity and design time.

Graceful degradation & incremental options

• Immediate: profile hot paths, optimize ISR/code (inline, lock-free queues, reduce copies), enable DMA — often 20–50% improvement with no hardware change.
• Mid-term: RTOS tuning (priority inheritance, reduce context switch), static allocation to avoid malloc jitter.
• Hardware-lite: move high-cost processing to a small DSP or dedicated accelerator on existing board.
• Full upgrade: select an MCU with required clock/RAM—present 2–3 SKUs with cost/power/lead-time.
• Tiered product: offer “standard” (current HW, optimized FW) vs “low-latency” (upgraded MCU) SKUs.

Recommendation
I’d propose a two-step plan: (1) immediate profiling + firmware optimizations to see if 5 ms is achievable without new MCU; (2) parallel evaluation of 2 candidate MCUs with prototype to measure real E2E latency and BOM impact. That balances risk, cost, and schedule while giving a clear data-driven decision for the PM.

Direct answer

I treat "getting up to speed" as a series of checkpoints where I test my own understanding against something real, not a quiet study period followed by a reveal. What actually made me useful was checking early and often against people who already owned the domain, and the real signal that I had become genuinely useful was when they started using my output instead of re-deriving it themselves.

Situation, what I did, how I checked it

I was moved onto a project supporting a freight-pricing team after the person who normally handled that relationship left, and I had no background in logistics or freight contracts. In the first week I read the existing pricing agreements and sat in on calls with two carriers, mostly to build a glossary of terms I did not understand, like accessorial charges and fuel surcharges. Rather than waiting until I felt ready, I produced a first draft of a rate analysis by day ten and walked it through with the account lead who did know the domain, asking her specifically to find what was wrong with it. She caught two mistakes: I had treated a seasonal surcharge as a permanent rate change, and I had missed that one lane's pricing was governed by a separate contract entirely. Both were errors that would have looked reasonable to me and obviously wrong to anyone who actually knew freight contracts, which is exactly why I needed that check instead of trusting my own read of the documents.

By week four, the account lead started forwarding pricing questions to me directly instead of answering them herself, which is the signal I actually use for "genuinely useful": not that I felt confident, but that someone who owned the domain started trusting my output enough to stop double-checking it. Learning the domain also changed how I approached the underlying analysis, not just the words I used to describe it. Once I understood that fuel surcharges moved independently of base rates, I restructured the pricing model to track them as a separate line instead of folding them into a blended rate, which is a decision I would not have known to make without the domain context.

Trade-offs and pitfalls

Getting up to speed while still delivering means something gets deprioritized. For me that was breadth: I deliberately went deep on the two carrier relationships that mattered most to the immediate decision and stayed shallow everywhere else until there was time to circle back. The pitfall I watch for is mistaking a plausible-sounding answer for a checked one. Both of my early mistakes sounded reasonable; only a domain owner's review caught them, which is why I build that check in early rather than waiting for the final deliverable to get feedback.

Goal & approach
Start with reproducible test case, then iterate: verify power rails & reset, check boundary interconnects, isolate subsystems, collect rich telemetry (timestamps, watchdogs, voltage/current). Work top-down: power → clocks → JTAG/boundary-scan → boot firmware → peripheral isolation.

Test points to add

• All rail voltages (pre/post regulator) and enable pins (TP_3V3_IN, TP_CPU_CORE, TP_FPGA_IO, TP_WIFI_VBAT)
• Key reset nets (CPU_NRST, FPGA_NCONFIG, PMIC_PWRGOOD)
• Clocks (main oscillator, FPGA fabric, WiFi ref clk)
• I2C/SPI/UART lines with series resistors for probes
• JTAG/TCK/TDI/TDO/TMS on CPU and FPGA
• GPIO lines bridging SoC↔FPGA and SoC↔WiFi
• Current sense shunt on major rails

JTAG & boundary-scan

• Run IEEE 1149.1 on CPU and FPGA IOCells to detect stuck/high-Z pins and shorts before powering peripherals.
• Use chain scan to confirm pin mapping and cable integrity.
• Use boundary-scan to drive/observe interconnects (toggle SoC pins, observe FPGA inputs) to validate signal levels and timing without full firmware.

Power-sequencing checks

• Log PWRGOOD transitions with logic analyzer; verify each regulator meets rise-time and ordered enables per datasheets.
• Inject controlled delays between rails using bench PSU or PMIC sequencing to test sensitivity.
• Stress-test undervoltage and brownout behavior; confirm resets align with spec.

Isolation experiments

• Reproduce issue with minimal configuration: CPU + RAM only; then add FPGA; then WiFi.
• Replace FPGA with golden bitstream that tri-states non-essential pins.
• Use software to disable WiFi driver and isolate via EMI/shielding to test interference.
• Swap modules (known-good WiFi) and use coaxial feed for antenna tests.

Logs & telemetry to collect

• Kernel logs with timestamped printk, earlycon, persistent console over UART, and circular buffer retention across resets.
• Firmware watchdog and panic hooks that dump CPU registers, stack pointer, last ISR, and mmio snapshots.
• FPGA: event counters, sync-loss, soft-reset traces, and AXI bus error registers exposed via memory-mapped debug region.
• PMIC telemetry: sequencing events, fault flags, thermal, and current measurements.
• High-resolution timestamps from logic analyzer/trace for latency spikes; correlate logs with power/clock events.

Why this works
Combines electrical validation (rails, clocks), non-invasive scan (JTAG), progressive isolation to narrow root cause, and correlated telemetry to link symptoms (latency spikes / resets) to electrical, firmware, or RF sources.

Answer (embedded developer view)

Memory map (priority & rationale)

• Internal flash (execute code / .text): store all firmware code and read-only data for reliability and fast fetch on reset.
• Internal SRAM (512 KB)
  • Vector table & interrupt stacks (top of SRAM) — highest priority, always internal and cache-coherent.
  • .data, .bss, small heap for RTOS/kernel, and latency-sensitive stacks/tasks.
  • Dedicated DMA-safe pool (uncached or cache‑managed) for peripheral transfers.
• External PSRAM (8 MB over AXI, cached)
  • Large buffers, media frames, logs, file caches (.psram.data/.psram.bss).
  • Read-mostly large datasets; optionally execute-from-PSRAM only for non-critical code if AXI/cache latency acceptable.

Layout sketch (high to low in SRAM)

• 0x2007FFFF — interrupt stacks (per-core)
• ... gap for stack guard
• heap, kernel objects
• .bss/.data
• .data init copy area (flash)

Linker placement rules

• Create named sections: .vectors (RAM), .text (FLASH), .data/.bss (SRAM), .psram.data/.psram.bss/.psram_heap (PSRAM).
• Use linker script MEMORY regions and assign sections:

MEMORY {
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  SRAM  (rwx) : ORIGIN = 0x20000000, LENGTH = 512K
  PSRAM (rwx) : ORIGIN = 0x60000000, LENGTH = 8M
}
SECTIONS {
  .text : { *(.text*) } > FLASH
  .vectors : { KEEP(*(.vectors)) } > SRAM
  .data : { *(.data*) } > SRAM AT> FLASH
  .psram.data : { *(.psram.data*) } > PSRAM AT> FLASH
  .bss : { *(.bss*) } > SRAM
  .psram.bss : { *(.psram.bss*) } > PSRAM
}

• Use compiler attributes to place variables in PSRAM:

__attribute__((section(".psram.data"))) uint8_t big_frame[FRAME_SZ];

Runtime policies for DMA-safe buffers

• Prefer internal SRAM for DMA targets when latency/correctness required.
• If DMA must use PSRAM:
  • Allocate from a dedicated DMA pool in PSRAM that is either:
    • Marked uncached in MPU/MMU, or
    • Cacheable but always managed via explicit cache ops.
• Provide allocator APIs:
  • dma_alloc(size, align, flags) — flags: DMA_SAFE_INTERNAL, DMA_SAFE_PSRAM_UNCACHED, DMA_SAFE_PSRAM_CACHED.
• Enforce alignment to peripheral requirements (cache-line and DMA burst): align to max(32, peripheral_alignment).

Cache maintenance rules (correctness & perf)

• For transmit (CPU -> DMA):
  • If buffer in cached memory: Clean (write-back) cache range before launching DMA.
  • If buffer in uncached region: no op.
• For receive (DMA -> CPU):
  • If cached: Invalidate cache range after DMA completes, before CPU reads.
  • If uncached: no op.
• Always use cache-line granularity: round addresses down/up to cache line size.
• Example pseudo:

/* before DMA Tx */
cache_clean(addr_aligned, len_aligned);

/* after DMA Rx completion */
cache_invalidate(addr_aligned, len_aligned);

• Use DMA descriptors and hardware coherency hints when available (AXI QoS, buffer attributes) to reduce software overhead.

Performance trade-offs

• PSRAM + cache gives large memory but adds latency and cache maintenance cost; keep hot paths and IRQ stacks in SRAM.
• Use double-buffering and asynchronous cache ops to hide latency.
• Consider using MPU to mark PSRAM DMA pools as strongly-ordered/uncached when frequent DMA avoids maintenance.

This map and policy ensure deterministic interrupts, safe DMA, and efficient use of PSRAM for large data while keeping critical code/data in internal SRAM.

States

• IDLE (released)
• DEBOUNCE_PRESS
• PRESSED (confirmed short/holding)
• DEBOUNCE_RELEASE
• LONG_PRESS_ACTIVE
• AUTOREPEAT_ACTIVE

Timers / thresholds (typical)

• Poll / tick: 10 ms
• Debounce: 20 ms (2 ticks)
• Long-press threshold: 800 ms (80 ticks)
• Auto-repeat initial delay: 500 ms after long-press (50 ticks)
• Auto-repeat rate: 100 ms (10 ticks)

State transitions (summary)

• IDLE -> DEBOUNCE_PRESS on raw GPIO=1
• DEBOUNCE_PRESS -> PRESSED if stable for debounce; else -> IDLE
• PRESSED -> DEBOUNCE_RELEASE on raw GPIO=0
• PRESSED -> LONG_PRESS_ACTIVE when hold_time >= long threshold
• LONG_PRESS_ACTIVE -> AUTOREPEAT_ACTIVE after auto-repeat initial delay
• AUTOREPEAT_ACTIVE emits repeat events every repeat interval; -> DEBOUNCE_RELEASE on GPIO=0
• DEBOUNCE_RELEASE -> IDLE if stable; else -> PRESSED

Implementation notes (minimal resources)

• Use a single periodic SysTick (10ms) to sample GPIO and advance counters — avoids many timers.
• Keep state enum + small counters (uint16_t).
• Generate events: SHORT_PRESS on DEBOUNCE_RELEASE if hold_time < long threshold; LONG_PRESS event on entering LONG_PRESS_ACTIVE; AUTOREPEAT event every repeat interval.

Sample C sketch

// tick() called every 10ms
typedef enum {IDLE, DB_PRESS, PRESSED, DB_RELEASE, LONG, REPEAT} state_t;
state_t s=IDLE; uint16_t tcnt=0, hold=0;
void tick(void){
  bool raw = read_button_gpio();
  switch(s){
    case IDLE: if(raw){ s=DB_PRESS; tcnt=0; } break;
    case DB_PRESS: if(raw){ if(++tcnt>=2){ s=PRESSED; hold=0; } } else s=IDLE; break;
    case PRESSED: if(!raw){ s=DB_RELEASE; tcnt=0; } else { if(++hold>=80){ s=LONG; tcnt=0; on_long(); } } break;
    case LONG: if(!raw){ s=DB_RELEASE; tcnt=0; } else { if(++tcnt>=50){ s=REPEAT; tcnt=0; on_repeat(); } } break;
    case REPEAT: if(!raw){ s=DB_RELEASE; tcnt=0; } else { if(++tcnt>=10){ tcnt=0; on_repeat(); } } break;
    case DB_RELEASE: if(!raw){ if(++tcnt>=2){ if(hold<80) on_short(); s=IDLE; else s=IDLE; } } else s=PRESSED; break;
  }
}

Trade-offs

• 10 ms tick reduces CPU overhead; increase resolution by reducing tick.
• Single tick + counters minimizes RAM/timers.
• Adjust thresholds per hardware ergonomics.

Approach (brief)
Use a 32-bit intermediate to hold the full 16x16 product, apply Q15 scaling by right-shifting 15 bits, add rounding bias (1<<14) for nearest rounding, then saturate to the Q15 representable range [-32768, +32767] (i.e., [-1, +0.999969482]).

Core code

#include <stdint.h>

int16_t q15_mul(int16_t a, int16_t b)
{
    int32_t prod = (int32_t)a * (int32_t)b;      /* 32-bit intermediate (fits: 32768^2 < 2^31) */
    /* Add rounding bias for nearest -> (prod + 2^14) >> 15 */
    int32_t rounded = prod + (1 << 14);
    int32_t shifted = rounded >> 15;             /* scale back to Q15 */
    /* Saturate to Q15 range */
    if (shifted >  0x7FFF) return (int16_t)0x7FFF;
    if (shifted < (int32_t)0x8000) return (int16_t)0x8000;
    return (int16_t)shifted;
}

Why these choices

• 32-bit intermediate prevents overflow of the 16x16 product and preserves sign.
• Right shift by 15 restores Q15 scaling (a and b represent values in Q15).
• Rounding bias (1<<14) gives nearest rounding instead of truncation, improving numeric accuracy in filters/loops.
• Explicit saturation clamps results to the representable Q15 interval; without it, extreme inputs could overflow the 16-bit return.

Edge cases / notes

• Multiplying -32768 by -32768 yields +1073741824; fits in int32_t and saturates correctly to +0x7FFF after scaling and rounding.
• If you want toward-zero instead of nearest, remove rounding bias.