Google Embedded Software Engineer Interview Preparation Guide - Junior Level

Overview
Hardware timers/counters are peripherals that increment/decrement a register at a clock-derived rate to measure time, count edges, or generate timed outputs. They’re essential in embedded firmware for precise timing without CPU polling.

Common timer modes

• Up: counter counts 0 → ARR (auto-reload register) then overflows and optionally triggers interrupt.
• Down: counts ARR → 0 then underflows.
• Up/Down (center-aligned): counts up then down for symmetric PWM.

Key building blocks

• Prescaler (PSC): divides peripheral clock to slow the tick rate.
• Auto-reload / Period register (ARR): top value that defines period.
• Capture/Compare channels (CCx): used to capture timestamp on input edges or compare to generate outputs (PWM, toggles).
• Overflow/underflow interrupts: fired when counter wraps — useful for periodic tasks or extending range.

Typical uses

• Event timing / measuring intervals (input capture stores counter on edge)
• PWM generation (set ARR = period, CCx = duty)
• Edge counting (external pulses as clock source)
• Scheduling periodic tasks without RTOS tick

Prescaler effects
Use formula for timer period:

Timer period (seconds) = (PSC + 1) * (ARR + 1) / F_timer_clock

• Increasing PSC increases maximum measurable interval but reduces time resolution (granularity = (PSC+1)/F_timer_clock).
• To maximize resolution choose smallest PSC that keeps ARR within range; to measure long intervals increase PSC and/or cascade counters.

Practical tip
Combine capture with DMA to log high-rate events; use center-aligned mode to reduce harmonic content in motors.

Direct answer
Defend a bounds-checked read by explicitly rejecting negative offsets/lengths, checking for integer overflow when computing offset+length (which can wrap around to a small or negative number and defeat a naive bounds check), and rejecting anything past the buffer's actual length, returning an explicit error rather than panicking on any of these conditions.

Structured elaboration

• Negative values: reject immediately; a negative offset or length is never valid for a byte-buffer read.
• Overflow on offset+length: if both are large positive int64 values, their sum can wrap around to a smaller (or negative) number, which would then incorrectly pass a naive end > len(buf) check; detect this by checking end < offset (the sum wrapping past int64's max means the result becomes smaller than one of its inputs).
• Actual bounds: after the overflow check, confirm end doesn't exceed the buffer's real length.

Worked example (executed against Go's actual runtime; all assertions passed)

func safeSliceRead(buf []byte, offset int64, length int64) ([]byte, error) {
    if offset < 0 || length < 0 {
        return nil, fmt.Errorf("negative offset or length: %w", ErrOutOfBounds)
    }
    end := offset + length
    if end < offset { // overflow wrapped around
        return nil, fmt.Errorf("offset=%d length=%d: %w", offset, length, ErrOverflow)
    }
    if end > int64(len(buf)) {
        return nil, fmt.Errorf("offset=%d length=%d exceeds buffer len=%d: %w", offset, length, len(buf), ErrOutOfBounds)
    }
    return buf[offset:end], nil
}

Verified: a normal in-range read returns the correct slice; a negative offset, an out-of-bounds range, and an offset near math.MaxInt64 (which triggers the overflow branch specifically, not just the plain out-of-bounds branch) all correctly return an error instead of panicking or, worse, silently returning wrong data.
A complementary design for an 'expected-empty' case rather than an out-of-range error: C++'s std::optional<int> safe_pop(std::stack<int>& s) returns an empty optional when popping an empty stack, instead of throwing or returning a sentinel like -1 that could collide with a real value; this is preferable when 'nothing there' is a normal, expected outcome (not a caller bug), whereas safeSliceRead's explicit error is right because an out-of-bounds read usually DOES indicate a caller bug worth surfacing loudly.

Trade-offs and pitfalls
The end < offset overflow check works here specifically because Go's integer overflow wraps (rather than panicking or being undefined behavior), which is exactly the property that makes it possible to detect after the fact by checking if the sum became smaller than an input; in a language with undefined behavior on signed overflow (C, in the strict standard sense), this same check is not safe to rely on and you'd need to check BEFORE the addition (e.g., if length > math.MaxInt64 - offset) instead.

Direct answer: Pick one real obstacle, not the project's general level of difficulty, and be honest that something didn't work on the first attempt. State what the failure looked like, what you tried, what actually worked, and why.

What "biggest challenge" means to the interviewer

Distinguish ambient difficulty (the project was generally hard) from a specific moment where you were stuck, wrong, or something broke. The question wants the latter: a real obstacle with a resolution arc, not just "the project was hard."

Framework for the answer

1. Name the specific obstacle in one sentence (a bug, a wrong initial approach, a constraint discovered late).
2. State what you tried first and why it seemed reasonable at the time.
3. State why that didn't work, and what new information surfaced.
4. State what you changed and why it worked.
5. State what you'd do differently to catch it earlier next time.

Common obstacle types

Worked example (illustrative, no fabricated precision)

Midway through a service migration, the new system passed all pre-launch load tests but started timing out under real production traffic within the first day. The load tests had used synthetic requests with a flat size distribution. Investigating production logs pointed to a long-tail payload size distribution; illustrative assumption for this example: the largest requests ran roughly 50 times the median size, and those large requests were serialized on a single-threaded parser that the flat synthetic test data never exercised. The fix: moved parsing for large payloads onto a separate worker pool bounded by a queue, instead of the shared request-handling thread pool, isolating the slow path without touching the common case. Verified by replaying a sample of real production traffic against the new code path in staging before rollout, rather than trusting the original synthetic load test again.

Trade-offs and pitfalls

• Picking a challenge that wasn't really yours to solve undermines the whole answer once probed.
• Describing only the technical fix without naming what changed in your process afterward misses half the point of the question.
• Avoiding admitting the first approach failed reads as defensive rather than reflective.
• Choosing an obstacle that resolved mostly by luck doesn't showcase reasoning the way a diagnosed-and-fixed obstacle does.

Overview / goal
I’d follow a methodical, low-intrusion workflow to localize the heap corruption without masking timing-sensitive bugs.

1. Baseline & reproduce

• Reproduce with deterministic inputs; collect core dump, task list, free/used heap stats, and timestamps.
• Run with hardware trace or SWO to avoid printf-induced timing changes.

2. Passive instrumentation

• Enable lightweight heap guards (red zones) and stack canaries globally but keep logging minimal.
• Turn on malloc/free logging with sampling or ring buffer to avoid timing perturbation.

3. Isolate by partitioning

• Convert global heap into per-task or per-subsystem pools one at a time (or use slab allocators). If corruption disappears when a task uses its own pool, that task is suspect.

4. Selective hardening

• Add bigger canaries and guard pages only around allocations from suspected pools.
• Use compiler options to insert stack canaries for individual tasks.

5. Watchpoints & link-map analysis

• Use the map file to find heap/RO/data ranges; set data-breakpoint/watchpoints on canary/footer addresses or frequently-corrupted buffers.
• If hardware breakpoints limited, set conditional watchpoints in the allocator (check pattern on free).

6. Binary-search tests

• Disable half the tasks, or bisect test cases to find minimal reproducer. Use task-enable masks to preserve timing for remaining tasks.

7. Minimize instrumentation impact

• Prefer hardware tracing, JTAG breakpoints, and sampling over heavy logging.
• Use assertion-based checks that only run in a sampled subset of runs or triggered after suspicious events.
• When needed, replicate the scenario on a simulator/emulator where heavy instrumentation won’t affect timing.

8. Confirm & fix

• Once source found, add deterministic unit tests, fix bounds/ownership errors, add durable per-module pools or hardened allocator, and keep regression tests with stress runs.

This approach balances broad detection, focused isolation, and minimal timing interference so the bug isn’t hidden by the debugger itself.

SRAM

• Volatility: volatile (loses content when power removed).
• Access speed: very fast, single-cycle on many MCUs.
• Endurance: effectively unlimited (read/write cycles not a concern).
• Common uses: stack, CPU registers, heap, runtime variables, small data buffers.
• Notes: used for deterministic access (real-time tasks).

DRAM

• Volatility: volatile, requires refresh.
• Access speed: slower than SRAM (higher latency), but higher density.
• Endurance: not a limiting factor.
• Common uses: system/main memory in gateways or SoCs where large RAM needed (not typical on small MCUs).
• Notes: needs refresh controller and more power.

Flash (NOR/NAND)

• Volatility: non-volatile.
• Access speed: read fast (NOR supports XIP), write slower, block erase required.
• Endurance: limited (typically 10k–100k erase cycles for NOR, varies).
• Common uses: code storage (firmware image), filesystem (NAND + FTL), large non-volatile data.
• Notes: wear-leveling and erase-block management required.

EEPROM

• Volatility: non-volatile.
• Access speed: slower writes than flash, byte- or page-programmable.
• Endurance: typically 100k–1M cycles depending on type.
• Common uses: small configuration parameters, calibration data, persistent settings.
• Notes: easier byte-level updates than flash, used for infrequent writes.

IoT Gateway vs Constrained MCU Sensor Node

• Gateway: has DRAM and larger flash/NAND + storage (SSD/SD). Uses OS, dynamic memory, file systems, complex networking stacks; memory footprint large, can trade latency for capacity.
• Constrained MCU: relies on SRAM + onboard flash (and sometimes EEPROM). Code often runs XIP or is copied to RAM; tight RAM footprint forces static allocation, stack/heap limits, minimal OS or RTOS; wear-management for flash critical.
• Design implications: gateways focus on throughput and concurrency; sensor nodes prioritize deterministic timing, low power, and careful flash/EEPROM write budgeting.

Direct answer

Slide a window over the string while tracking, for each character, the index where it was last seen. When you hit a character already inside the current window, jump the window's left edge to just past that character's previous occurrence, then update the best length seen. Each index is visited a bounded number of times, so the whole scan is O(n).

Structured elaboration

The sliding window invariant

Maintain two indices, left and right, that always bound a substring with no repeated characters. right advances one character at a time. last_seen is a hash map from character to the most recent index where it appeared. When the character at right was last seen at an index that is still inside the current window (last_seen[ch] >= left), move left forward to last_seen[ch] + 1, the smallest new left edge that excludes the earlier occurrence. If the last occurrence is outside the window, or the character has never been seen, the window simply grows.

Why it is O(n)

right moves forward exactly once per character, n times total. left only ever moves forward too, and it never exceeds right, so across the whole scan left advances at most n times as well. Neither pointer ever moves backward. That gives a total of at most 2n pointer movements, so the algorithm is O(n) time, with O(min(n, alphabet size)) space for the hash map, bounded by how many distinct characters can appear in a window at once.

Maintaining character indices correctly

The subtle part is the last_seen[ch] >= left check. Without it, a stale entry from far in the past (before the current window even started) could incorrectly shrink the window, because the map keeps the LAST time a character was seen, which might be from before the window's current left edge if that character has not reappeared since.

Worked example

def length_of_longest_substring(s):
    last_seen = {}
    left = 0
    best = 0
    for right, ch in enumerate(s):
        if ch in last_seen and last_seen[ch] >= left:
            left = last_seen[ch] + 1
        last_seen[ch] = right
        best = max(best, right - left + 1)
    return best

print(length_of_longest_substring("abcabcbb"))

Output:

3

Tracing it by hand: at right=3 the window holds "abc" and the next character is a, last seen at index 0, which is still inside the window (0 >= left=0), so left jumps to 1. The window is now "bca", length 3. The same pattern repeats through the rest of the string, and the best length never exceeds 3, matching the printed result and the question's own stated expectation. The same technique ports directly: a Java solution uses a HashMap<Character, Integer> in place of the dict, and a JavaScript solution uses a Map or a plain object, with identical pointer logic.

Trade-offs and pitfalls

A common wrong turn is checking if ch in last_seen alone and moving left on every repeat ever seen, even ones from before the current window, which can move left backward and silently break correctness. Another is recomputing "is this character in the current window" by scanning the window itself on every step, which turns the algorithm back into O(n^2) or O(n * alphabet size). For very large alphabets (full Unicode rather than ASCII), the map can grow larger, but it is still bounded by the number of distinct characters that actually appear, not by the input length.

Overview — when an interrupt triggers a preemptive context switch
Briefly: the CPU’s exception entry does the first level saving, the ISR requests a context switch (typically by setting PendSV), the scheduler picks the next ready task, and the PendSV handler completes the full context switch by saving/restoring the remaining registers and swapping the PSP.

1) Hardware (automatic) stacking on exception entry

• Cortex‑M hardware automatically pushes this “stack frame” onto the active stack:
  • R0, R1, R2, R3, R12, LR (R14), PC (R15), xPSR
• That stack frame is placed on the stack in use by the interrupted thread (usually PSP when threads run); note FPU cores may also push S0–S15 and FPSCR (lazy stacking) if FP in use.

2) ISR context and requesting a switch

• The ISR runs (often on MSP or exception context) and must not perform the full task switch itself.
• To request a switch it sets the PendSV pending bit via the Interrupt Control and State Register (ICSR) — e.g., write to NVIC->ICSR = (1 << PENDSVSET) — or calls the RTOS API that does this.
• Setting PendSV defers the expensive stack manipulation until a lower-priority exception (PendSV) runs after all higher-priority IRQs complete.

3) Scheduler decision

• The ISR or RTOS scheduler computes the next task (priority-based, round‑robin, or RTOS-specific ready lists).
• Scheduler selects the highest-priority READY task; it updates TCBs but does not yet change CPU registers.

4) PendSV handler: full context switch

• PendSV runs in exception context. Typical sequence (assembly/C):
  • Read current PSP (process stack pointer) — this points to the interrupted task’s stack frame.
  • Push callee-saved registers R4–R11 (and FP callee-saved regs if used) onto the task stack at PSP. These are not saved by hardware and must be preserved.
  • Save the new PSP to the current task’s TCB (store task stack pointer).
  • Load the next task’s stack pointer from its TCB into PSP.
  • Pop R4–R11 from the new task’s stack (restoring its callee-saved registers).
  • Execute exception return (BX LR with EXC_RETURN value) which causes the CPU to pop the hardware-stacked frame (R0–R3,R12,LR,PC,xPSR) from the new task’s stack and resume thread mode in that task.

5) Where each register ends up

• Hardware-stacked frame (R0–R3,R12,LR,PC,xPSR): on the active thread stack (PSP) by the CPU on exception entry.
• Software-saved callee-saved (R4–R11): pushed by PendSV onto the task’s stack (PSP).
• Floating-point registers: handled by lazy stacking or explicitly saved/restored by RTOS if FPU used.

6) Notes and pitfalls

• Ensure PendSV priority is lowest so it runs after all IRQs.
• Use atomic operations or disable interrupts briefly when manipulating ready lists/TCBs.
• Pay attention to stack alignment (8‑byte aligned) and EXC_RETURN codes for correct return-to-thread behavior.
• FPU and lazy stacking require explicit handling to avoid corrupting FP state.

This sequence keeps ISR short, defers heavy work to PendSV, and ensures full CPU state is restored for the next task.

Approach (brief)
Sort the array in-place (fast lookup for duplicates), then sweep once to compact unique values. Use an in-place quicksort with median-of-three pivot and insertion sort for small partitions to avoid worst-case degeneration and reduce cycle count on an MCU. Additional memory is O(1) (fixed small stack for iterative quicksort).

#include <stdint.h>
#include <stddef.h>

/* Remove duplicates in-place. Returns new length (<= N). */
size_t dedup_uint16(uint16_t *a, size_t N);

/* Implementation */
static inline void swap_u16(uint16_t *x, uint16_t *y) { uint16_t t=*x; *x=*y; *y=t; }

size_t dedup_uint16(uint16_t *a, size_t N) {
    if (N <= 1) return N;

    /* Iterative quicksort with median-of-three and insertion sort threshold */
    enum { THRESH = 16, STACK_SZ = 32 };
    size_t lo_stack[STACK_SZ], hi_stack[STACK_SZ];
    int sp = 0;
    lo_stack[sp] = 0; hi_stack[sp++] = N-1;

    while (sp) {
        size_t lo = lo_stack[--sp], hi = hi_stack[sp];
        while (hi - lo + 1 > THRESH) {
            /* median-of-three */
            size_t mid = lo + ((hi - lo) >> 1);
            if (a[mid] < a[lo]) swap_u16(&a[mid], &a[lo]);
            if (a[hi]  < a[lo]) swap_u16(&a[hi], &a[lo]);
            if (a[mid] < a[hi]) swap_u16(&a[mid], &a[hi]); /* pivot -> a[hi] */

            uint16_t pivot = a[hi];
            size_t i = lo, j = hi - 1;
            while (1) {
                while (i <= j && a[i] < pivot) ++i;
                while (j >= i && a[j] >= pivot) --j;
                if (i >= j) break;
                swap_u16(&a[i++], &a[j--]);
            }
            swap_u16(&a[i], &a[hi]); /* place pivot */

            /* push larger partition, continue with smaller to bound stack */
            if (i - lo < hi - i) {
                if (i + 1 < hi) { lo_stack[sp] = i + 1; hi_stack[sp++] = hi; }
                hi = (i == 0) ? 0 : i - 1;
            } else {
                if (lo < i) { lo_stack[sp] = lo; hi_stack[sp++] = (i == 0) ? 0 : i - 1; }
                lo = i + 1;
            }
        }
        /* insertion sort on small range [lo..hi] */
        for (size_t i = lo + 1; i <= hi; ++i) {
            uint16_t v = a[i];
            size_t j = i;
            while (j > lo && a[j-1] > v) { a[j] = a[j-1]; --j; }
            a[j] = v;
        }
    }

    /* single pass to compact unique elements */
    size_t write = 1;
    for (size_t read = 1; read < N; ++read) {
        if (a[read] != a[write-1]) a[write++] = a[read];
    }
    return write;
}

Complexity & MCU worst-case behavior

• Time: average O(N log N) for quicksort + O(N) sweep. Worst-case O(N^2) for quicksort avoided by median-of-three and small-partition insertion sort; highly unlikely for random/typical data. For N <= 256 this runs very fast; insertion sort threshold reduces swap overhead.
• Space: O(1) additional memory (fixed small stacks, constant).
• MCU notes: choose THRESH based on target cycles — smaller threshold favors insertion sort for tiny arrays and reduces recursive overhead. Median-of-three avoids pathological patterns; deterministic behavior helps real-time estimation. For strict worst-case guarantees, use in-place heapsort (O(N log N) worst-case) at cost of slightly more swaps.

Approach (short)
I’d implement a low-overhead instrumented allocator that records sampled allocations into a compact in-RAM aggregate table keyed by a compressed caller fingerprint and size-bucket, tracks high-water marks, and uses an approximate top-N algorithm (space-saving) for reporting. Sampling + aggregation avoids logging every allocation.

Data structures

• Fixed-size aggregate table (power-of-two) of entries:
  • struct Entry { uint32_t key; uint32_t count; uint32_t total_bytes; uint32_t max_bytes; uint32_t last_seen_epoch; }
  • key = 32-bit fingerprint of caller (see compression) + size-bucket folded
• Global high-water mark per heap (uint32_t)
• Small reservoir buffer (N entries) optional to capture occasional full callsite for symbolication

Sampling strategy

• Probabilistic sampling on allocation: sample 1 in S allocations (configurable). Use simple LFSR or counter: if (++sample_counter & (S-1)) != 0 return; — no RNG syscall.
• For large allocations above threshold T always sample.

Capture & compress return addresses

• Capture single-level return address using compiler intrinsics: caller_ra = (uintptr_t)__builtin_return_address(0)
• Compress: compute 32-bit fingerprint = (ROTX32(mix64(caller_ra)) ^ size_bucket)
• Optionally delta-compress against previous fingerprint for reservoir entries. For symbolication, keep a tiny ring-reservoir of raw addresses (e.g., 64 entries) sampled via reservoir sampling to map fingerprints -> strings offline.

Aggregation & collision handling

• Use open-addressing hash with linear probe; when inserting, if key matches update counters; on empty slot insert. If table full, evict using the Space-Saving heuristic: replace lowest-count bucket and set count = evicted_count+1.

Top-N reporting

• Table already holds aggregated counts and total_bytes; run a scan to extract top-N by total_bytes using a small heap (O(M log N), M = table size). No per-allocation logging.

Implementation sketch (C-like)

// compact entry ~20 bytes (pad to 24)
typedef struct { uint32_t key; uint32_t count; uint32_t total; uint32_t max; uint32_t epoch; } entry_t;
entry_t table[TABLE_SZ];
uint32_t sample_mask = S-1; // S power of two

void instrument_malloc(size_t sz, void *ptr) {
  high_water = max(high_water, current_heap_used());
  if ((++sample_ctr & sample_mask) != 0 && sz < LARGE_T) return;
  uintptr_t ra = (uintptr_t)__builtin_return_address(0);
  uint32_t key = fingerprint(ra, size_bucket(sz));
  table_insert_or_update(key, sz);
  maybe_reservoir_add(ra);
}

Why this design

• Single RA capture is cheap (no stack-walk). Sampling + size threshold keeps runtime/RAM low. Fingerprinting gives compact keys; reservoir supports offline symbolication. Space-Saving avoids unlimited growth and gives accurate heavy-hitter detection.

Trade-offs & caveats

• Single-frame RA can conflate inlined wrappers; increase depth if frame-pointer available at cost. Hash collisions reduce precision — mitigate by occasional reservoir-backed resolution. Tune sampling rate and table size to RAM/accuracy needs.

Approach (brief)

Design a compact table-driven HSM in C using arrays and enums only, no dynamic allocation. Represent states as small integers, tables for parent, entry/exit handlers, transition targets, guards and prioritized event-action lists. Support shallow history by storing last active child index.

Key data structures

• StateId: uint8_t enum
• EventId: uint8_t enum
• Handler: function pointer type void (*)(void*)
• Tables:
  • parent[StateId]
  • entry[StateId], exit[StateId]
  • history[StateId] (uint8_t, 0 = no history)
  • transitions: array of { state, event, guard_idx, action_idx, target_state }
  • guards[], actions[] function pointer arrays

Example compact definitions:

typedef uint8_t StateId;
typedef uint8_t EventId;
typedef void (*Action)(void*);
typedef bool (*Guard)(void*);

typedef struct {
  StateId src;
  EventId evt;
  uint8_t guard;   // index into guards[], 0xFF = always true
  uint8_t action;  // index into actions[], 0xFF = none
  StateId tgt;     // target = same as src means internal
} Transition;

Table-driven dispatch algorithm (steps)

1. Build vector of candidate transitions by scanning transitions[] for src = current state or any ancestor (walk parent[]).
2. Prioritize by event and transition table ordering (table arranged highest priority first).
3. Evaluate guards in ancestor-to-descendant order; pick first true.
4. If internal transition (tgt == src) call action only.
5. For external transition:
   • Compute LCA between current and target using parent[].
   • Execute exit handlers from current up to (but not including) LCA; update shallow history for parents.
   • Execute transition action.
   • Execute entry handlers from LCA down to target (if history exists, descend to recorded child).
   • Set current = final entered state.

Pseudocode for dispatch

void dispatch(EventId e, void *ctx){
  StateId s = current;
  Transition *t = find_transition(s,e,ctx); // scan transitions[] up ancestors
  if(!t) return;
  if(t->tgt == s){ // internal
    if(t->action!=0xFF) actions[t->action](ctx);
    return;
  }
  StateId lca = find_lca(s, t->tgt);
  // exit path
  for(StateId x = s; x != lca; x = parent[x]){
    if(exit[x]) exit[x](ctx);
    if(parent[x]!=0xFF) history[parent[x]] = x; // shallow history
  }
  // action
  if(t->action!=0xFF) actions[t->action](ctx);
  // entry path stack from lca->tgt
  StateId path[DEPTH]; int n=0;
  for(StateId y = t->tgt; y != lca; y = parent[y]) path[n++]=y;
  while(n--) {
    StateId en = path[n];
    if(entry[en]) entry[en](ctx);
    // follow shallow history
    if(history[en]) en = history[en];
  }
  current = resolve_deepest_active(t->tgt);
}

Complexity & constraints

• Memory: O(#states + #transitions). Tables are packed arrays of uint8_t and small structs.
• CPU: dispatch scans ancestor chain and transitions — acceptable when tables are small; optimize by indexing transitions by event to reduce scan.

Notes / Best practices

• Store tables in flash (const) to save RAM.
• Keep function pointer tables small; use a dispatcher index-to-fn map.
• Precompute parent chains or LCA hints for deep hierarchies if dispatch time critical.
• Use 8-bit types where feasible, align structs to avoid padding.