There are no items in your cart
Add More
Add More
| Item Details | Price | ||
|---|---|---|---|
Preparing for an embedded systems interview in 2026? This complete guide covers the top 40 must-know questions with in-depth answers — spanning Embedded C, RTOS, microcontrollers, memory management, communication protocols (UART, SPI, I2C, CAN), interrupts, and Embedded Linux. Ideal for freshers and experienced engineers targeting product companies, semiconductor firms, and automotive/IoT roles.
Updated: April 2026 | Author: EmbeddedShiksha
Why this guide? Hiring managers in 2026 are screening for strong fundamentals plus practical exposure to RTOS, ARM Cortex-M, Linux device drivers, and functional safety. The questions below reflect what is actually being asked in rounds at MNCs, product startups, and automotive OEMs — with answers written to help you speak confidently, not just tick keywords.
const, volatile, and static in Embedded C?Answer: const tells the compiler the value must not be modified by code; it is typically placed in flash on microcontrollers. volatile tells the compiler the value may change outside program control (hardware registers, ISR-modified variables) so reads/writes must not be optimized away. static controls linkage and lifetime — a static local keeps its value across calls; a static global/function is visible only within that file. A variable can be const volatile (e.g. a read-only status register).
volatile for hardware registers and ISR-shared variables?Answer: Without volatile, the compiler may cache the value in a CPU register and skip re-reading from memory, causing the program to miss hardware state changes or updates done inside an ISR. volatile forces every read/write to go to the actual memory location.
Answer: C only has pointers; references exist in C++. A pointer holds an address, can be reassigned, and can be NULL. A C++ reference is an alias that must be bound at initialization and cannot be null or reseated. In embedded C++ code (e.g., Zephyr, Arduino), references are preferred for function parameters when null is not a valid input.
Answer: .text holds code (in flash). .rodata holds constants (flash). .data holds initialized globals/statics (copied from flash to RAM at startup). .bss holds zero-initialized globals/statics (zeroed in RAM at startup). stack grows downward for local variables and return addresses. heap grows upward if malloc is used. The startup code (Reset_Handler) initializes .data and .bss before main() runs.
malloc() on a microcontroller? Should you use it?Answer: malloc() allocates from the heap configured in the linker script. On small MCUs it is usually avoided because of heap fragmentation, non-deterministic timing, and silent failures when out of memory. Preferred alternatives: static allocation, memory pools, or RTOS-provided fixed-block allocators (e.g., FreeRTOS xMemoryPool, Zephyr k_mem_slab).
#define and const?Answer: #define is a text substitution done by the preprocessor — no type safety, no storage, no scope beyond the file. const is a real typed variable with scope and linkage, placed in flash. Prefer const (or enum) for constants to get type checking and better debugging symbols.
Answer: Bit-fields let you define struct members that occupy a specific number of bits, useful for packing status flags or mapping hardware registers. Caveats: ordering (MSB vs LSB first) and padding are implementation-defined, so for portable register maps most teams prefer explicit bitmasks with uint32_t and bitwise operations.
Answer: Endianness is the byte order of a multi-byte value in memory. ARM Cortex-M and x86 are little-endian (LSB at lowest address). Many network protocols and some DSPs are big-endian. When parsing a CAN/Ethernet frame or reading a sensor returning 16-bit data MSB-first, you must swap bytes (e.g., __REV16 on ARM).
Answer: A microprocessor (e.g., Intel Core, ARM Cortex-A) is a CPU that needs external RAM, flash, and peripherals — used where high performance and OS support are needed. A microcontroller (e.g., STM32, ESP32, NXP Kinetis) integrates CPU + RAM + flash + peripherals (UART, SPI, ADC, timers) on a single chip — used for deterministic, low-power, cost-sensitive embedded products.
main() on an ARM Cortex-M?Answer: (1) CPU loads the initial stack pointer from vector table offset 0. (2) CPU loads the Reset_Handler address from offset 4 and jumps to it. (3) Reset_Handler copies .data from flash to RAM and zeroes .bss. (4) Clock tree is configured (SystemInit). (5) C++ global constructors run (if any). (6) main() is called.
Answer: A watchdog is a hardware timer that resets the MCU if the software fails to "kick" it within a deadline. It protects against hangs caused by stuck loops, ISR deadlocks, or corrupted state. In safety-critical systems (automotive ISO 26262, medical), an independent windowed watchdog is mandatory.
Answer: Direct Memory Access offloads bulk memory transfers (peripheral↔memory or memory↔memory) from the CPU. Use it for high-throughput I/O like audio, ADC streaming, SPI flash dumps, or filling frame buffers. The CPU is free for application work while the DMA controller runs in parallel; an interrupt fires on completion.
Answer: RAM is fast, volatile, byte-accessible; used for variables and stack. Flash is non-volatile, cheap, reprogrammed in blocks; stores code and constants. EEPROM is non-volatile, byte-erasable, has higher endurance than flash; used for small calibration or configuration data. Many modern MCUs emulate EEPROM inside flash.
Answer: A linker script defines the memory map (flash/RAM regions) and places sections (.text, .data, .bss, .vectors, .stack, custom sections like .noinit or DMA buffers). Without it, the toolchain doesn't know where code and data should live on the target.
Answer: Cortex-M has two modes (Thread, Handler) and two privilege levels (Privileged, Unprivileged). In an RTOS, kernel code runs privileged (handler mode for ISRs, privileged thread for kernel) and user tasks can run unprivileged, isolated by the MPU. This is the foundation of memory protection and fault isolation in real-time systems.
Answer: Keep it short and deterministic. Do not call blocking APIs, printf, or malloc. Acknowledge the hardware flag, move heavy work to a task/deferred handler, and return. Share data with threads only via volatile variables, atomic operations, lock-free queues, or RTOS primitives designed for ISR context (e.g., xQueueSendFromISR).
Answer: Interrupt latency is the time from the hardware event to the first instruction of the ISR. It is affected by instruction completion, pipeline flush, context save, and the length of any higher-priority or currently-executing critical section. Reduce it by minimizing critical sections, using NVIC priorities correctly, and enabling tail-chaining on Cortex-M.
Answer: Priority inversion happens when a high-priority task is blocked on a resource held by a low-priority task, while a medium-priority task preempts the low-priority one — effectively blocking the high-priority task indefinitely. Priority inheritance temporarily raises the holder's priority to the highest waiter's priority until it releases the mutex. Famous case: NASA's Mars Pathfinder.
Answer: Race condition: result depends on scheduling of concurrent accesses to shared state. Deadlock: two or more tasks each hold a resource the other needs and wait forever. Livelock: tasks keep changing state in response to each other but make no progress. Fixes: locking discipline, consistent lock order, timeouts, and lock-free designs where possible.
Answer: An operation that completes in a single indivisible step with respect to interrupts/other cores. On Cortex-M, LDREX/STREX provide atomic read-modify-write. For simple cases, disabling interrupts briefly works on single-core MCUs. On multi-core (e.g., Cortex-A, ESP32), you need proper atomics or spinlocks.
Answer: A Real-Time Operating System is a small kernel that provides deterministic task scheduling, inter-task communication (queues, semaphores, mutexes), and timing services. Use one when your firmware has multiple independent activities with timing constraints — e.g., reading a sensor at 1 kHz, running a control loop at 100 Hz, and handling UART commands. Common choices in 2026: FreeRTOS, Zephyr, ThreadX, RT-Thread.
Answer: In hard real-time systems, missing a deadline is a system failure (airbag deployment, motor control). In soft real-time, missing a deadline degrades quality but is tolerable (video streaming, UI responsiveness).
Answer: Preemptive: the scheduler can interrupt a running task to run a higher-priority ready task; needed for real-time responsiveness. Cooperative: tasks voluntarily yield; simpler but a misbehaving task starves the system. Most production RTOSes are preemptive with priority-based scheduling.
Answer: A mutex provides mutual exclusion for a shared resource and has ownership + priority inheritance. A binary semaphore is a signaling primitive with no ownership — ideal for ISR-to-task signaling. Using a semaphore for mutual exclusion is a classic bug because it lacks priority inheritance.
Answer: The kernel's per-task structure holding the stack pointer, saved registers, priority, state (ready/blocked/running), waiting object, and list links. The scheduler picks the highest-priority ready TCB and performs a context switch by saving/restoring registers from/to TCBs.
Answer: Start with a safe upper bound, run the firmware through worst-case paths (including ISR nesting), then use high-water-mark APIs (uxTaskGetStackHighWaterMark in FreeRTOS) or fill-pattern analysis to measure actual usage. Add 20–30% headroom. Never size by guesswork — stack overflow is one of the hardest bugs to debug.
Answer: UART is asynchronous, point-to-point, 2 wires (TX/RX), typical speeds up to a few Mbps, simple, no clock line. SPI is synchronous, master-multi-slave, 4 wires (MOSI/MISO/SCK/CS), full-duplex, very fast (tens of MHz), no addressing — each slave has its own CS. I2C is synchronous, multi-master-multi-slave, 2 wires (SDA/SCL) with pull-ups, addressed (7/10-bit), half-duplex, slower (100 kHz to 3.4 MHz).
Answer: Start: SDA goes low while SCL is high. Address byte: 7-bit address + R/W bit. ACK: the addressed slave pulls SDA low during the 9th clock to acknowledge. Data bytes follow, each ACKed. Stop: SDA goes high while SCL is high. A NACK signals no slave, or the master/slave ending transmission.
Answer: I2C lines are open-drain; devices only pull low, so pull-ups bring the line back high. Too high a value → slow rise time, signal looks smeared at higher speeds. Too low → excessive sink current. Typical: 4.7 kΩ at 100 kHz, 2.2 kΩ at 400 kHz, lower at 1 MHz+. The equation Rp(max) = tr / (0.8473 × Cbus) from the I2C spec is the definitive answer.
Answer: CPOL sets the idle polarity of the clock (0 = idle low, 1 = idle high). CPHA sets whether data is sampled on the first or second clock edge. Four combinations (Mode 0–3) — both master and slave must agree. A very common bug is mismatched mode causing shifted/garbled data.
Answer: CAN (Controller Area Network) is a differential, multi-master, message-based bus with built-in error detection, arbitration by message ID (lower ID wins), and deterministic latency. It is robust against noise and wiring faults, which is why it dominates in-vehicle networks. CAN FD extends payload to 64 bytes and higher data rates.
Answer: The receiver sampled the expected stop bit and found it low. Causes: baud-rate mismatch between sender and receiver, wrong number of data bits / parity setting, or noisy line. Fix: verify baud generator settings, use flow control for high rates, and check ground reference between boards.
Answer: The device tree (DTS/DTB) is a data structure that describes the hardware (CPUs, memory, peripherals, clocks, pinmux) to the kernel at boot. It decouples hardware description from driver code, so a single kernel image can boot on many boards by swapping the DTB.
Answer: Character devices (UART, sensors) stream bytes sequentially. Block devices (eMMC, SSD) read/write fixed-size blocks with random access and a page cache. Network devices expose packet-oriented send/receive through the networking stack rather than a file in /dev.
Answer: Kernel space has full privilege and access to hardware. User space is isolated by the MMU; processes access kernel services only through system calls. The boundary protects the system from buggy or malicious apps and enables memory protection, security modules, and containerization.
ioctl() and when do you use it?Answer: ioctl() is the generic "device-specific control" system call — used when an operation doesn't fit read/write semantics (e.g., set UART baud, query SPI mode, start a DMA). Modern drivers often expose the same features via sysfs, configfs, or netlink for better tooling, but ioctl remains common.
Answer: A built-in driver is compiled into the kernel image and always present. A module (.ko) is loaded/unloaded at runtime with insmod/rmmod. Modules are preferred for optional or platform-specific drivers to keep the base image small.
Answer: Use a hardware debugger (JTAG/SWD) to halt the CPU and inspect PC, LR, and stack — this almost always reveals whether you're in a HardFault, stuck in an ISR, or spinning in a loop. Check the fault status registers (CFSR on Cortex-M), and walk the stack to find the offending call. Blink an LED directly in the suspect path as a quick sanity check.
Answer: A HardFault is the catch-all exception for bus errors, usage faults, and memory faults when they aren't handled individually. Read CFSR, HFSR, MMFAR, and BFAR to find the cause and faulting address. Common causes: null/invalid pointer deref, stack overflow, misaligned access, executing from a non-executable region.
Answer: Static analysis (MISRA C, Cppcheck, Coverity) in CI; unit tests with a target-agnostic HAL; deterministic memory allocation (no heap in hot paths); explicit error handling (no silent returns); defensive watchdog feeding only in the main loop, not in ISRs; stack canaries / MPU regions; and thorough fault handlers that log and reset instead of hanging.
Week 1: Embedded C mastery — pointers, memory model, storage classes, bit manipulation, linker basics. Practice writing reentrant functions and safe ISRs.
Week 2: ARM Cortex-M internals and one MCU family end-to-end (STM32 or NXP). Boot process, NVIC, SysTick, peripheral drivers from scratch.
Week 3: RTOS fundamentals — scheduling, sync primitives, priority inversion, stack sizing. Build a small project (sensor + CLI + logger) on FreeRTOS or Zephyr.
Week 4: Embedded Linux basics — boot flow, device tree, writing a simple character driver, debugging with ftrace/perf. Mock interviews on protocols (UART/SPI/I2C/CAN).
Interviews in 2026 reward candidates who can connect theory to real hardware problems — not just recite definitions. Pick one MCU and one RTOS, build something end-to-end, and practice explaining your design decisions out loud. Pair that with this question bank and you will walk into any embedded systems interview with confidence.
Want to go deeper? Explore our in-depth guides on Embedded C, RTOS (FreeRTOS & Zephyr), Linux Kernel, and Linux Device Drivers.
EmbeddedShiksha
A California-based travel writer, lover of food, oceans, and nature.