Embedded Systems Interview Questions

Quick answer

Embedded systems interviews test whether you can write safe, low-level C, understand how a microcontroller and its peripherals really work, handle interrupts and real-time tasks, and debug hardware and firmware problems calmly. Most interviews start with embedded C (pointers, volatile, bit manipulation), move to microcontroller basics and interrupts, then ask about protocols such as UART, SPI, I2C and CAN, and finish with RTOS, debugging and a design scenario. The 60 questions below cover every round with short model answers you can put into your own words.

Key takeaways

1. How embedded systems interviews work in 2026

Short answer: Expect a written or online test on C, one or two technical rounds on embedded concepts and your project, sometimes a hands-on board or coding round, and an HR round.

Embedded roles carry many titles: Embedded Software Engineer, Firmware Engineer, Embedded Systems Engineer, BSP or Device Driver Engineer, and Validation Engineer. The pattern is similar across them. First, especially in fresher hiring, a written or online test checks C output questions, pointers, bit operations, basic electronics and aptitude, sometimes with a simple C coding problem. Second, a technical interviewer asks about microcontrollers, interrupts, memory and protocols. Third, a senior engineer digs into your project and gives you a design or debugging scenario. Last, HR checks communication, fit and location.

If you need a refresher on the basics first (what an embedded system is, its parts and its types), read our pillar guide on what embedded systems are. Then come back to these questions.

A simple answer formula works for almost every technical question:

2. Which questions to focus on: freshers, experienced engineers and company type

Short answer: Freshers should master about 20 core questions first, experienced engineers should go deeper on RTOS, drivers and debugging, and the type of company changes which topics get the most follow-ups.

You do not need all 60 answers on day one. Start with the set that matches your profile, then widen it.

The questions also lean in different directions depending on the employer. Treat this as a general pattern, not a promise of what any one company asks:

Experienced candidates should also expect "advanced" questions on DMA (moving data without the CPU), cache effects on shared buffers, memory protection units, and how secure boot and debug-port locking protect a product. Answer these from projects you have shipped, with the problem, your design and a measured result.

3. Embedded C and pointers (Q1 to Q8)

Short answer: These questions check that you understand how C maps to hardware: memory, registers, qualifiers and bit-level operations.

Embedded C means the C language used to write firmware, the low-level software stored in a device's flash memory that runs directly on the hardware. For a full walkthrough with examples, see our guide to embedded C programming.

Q1. What is the difference between C and embedded C?

Embedded C is standard C used for programs that run on a microcontroller, often with a few compiler extensions for hardware access. Desktop C runs on top of an operating system with plenty of memory. Embedded C usually runs on bare hardware with limited RAM and flash, talks to peripherals through registers, and must meet timing limits. It also uses fixed-width integer types, bit operations and the volatile keyword far more than desktop code does. In practice, most firmware is written in standard C (often C99 or C11) plus a vendor's device headers.

Q2. What does the volatile keyword do, and when do you use it?

Volatile tells the compiler that a variable can change at any time outside the normal flow of the code, so it must read it from memory every time and must not optimise the access away. You use it for three common cases: hardware registers (such as a status register), global variables shared between an ISR and the main loop, and variables shared between RTOS tasks. Without volatile, the compiler may keep a copy in a CPU register and your loop waiting for a flag may never see it change. Note that volatile does not make an operation atomic.

Q3. Can a variable be both const and volatile?

Yes. A read-only hardware status register is the classic example. Const means your code must not write to it. Volatile means its value can still change because the hardware updates it. So a pointer to a const volatile register lets you read fresh values every time while the compiler stops you from writing to it by mistake. Interviewers ask this to see whether you understand that the two qualifiers describe different things: who may write, and whether the value can change on its own.

Q4. What are the uses of the static keyword in embedded C?

Static has three uses. Inside a function, a static local variable keeps its value between calls and lives in fixed memory, not on the stack. At file level, a static global variable or function is visible only in that source file, which hides internal details from other modules. That is good practice for driver code. Static variables without an initial value are placed in the zero-initialised section, so the startup code sets them to zero before main runs.

Q5. How do you set, clear, toggle and check a bit?

Use bitwise operators with a mask that has a 1 in the bit position you want. To set bit n, OR the value with the mask. To clear it, AND the value with the inverted mask. To toggle it, XOR the value with the mask. To check it, AND the value with the mask and test whether the result is non-zero. Use an unsigned 1 when you build the mask so that shifting into the top bit is well defined. These operations are how you control GPIO pins and peripheral registers. Interviewers often ask you to write them as macros:

#include <stdint.h>

#define BIT(n) (1UL << (n))
#define SET_BIT(reg, n) ((reg) |= BIT(n))
#define CLEAR_BIT(reg, n) ((reg) &= ~BIT(n))
#define TOGGLE_BIT(reg, n) ((reg) ^= BIT(n))
#define CHECK_BIT(reg, n) (((reg) & BIT(n)) != 0UL)

void bit_demo(void)
{
    volatile uint32_t port = 0;
    SET_BIT(port, 5); /* port is now 0x20 */
    TOGGLE_BIT(port, 0); /* port is now 0x21 */
    CLEAR_BIT(port, 5); /* port is now 0x01 */
    if (CHECK_BIT(port, 0)) {
        /* bit 0 is set */
    }
}

Wrap every macro argument in brackets so expressions such as n + 1 work correctly. Some vendor headers already define macros with names like SET_BIT, so rename yours if the compiler reports a clash.

Q6. What is a pointer to a register, and why is memory-mapped I/O used?

In memory-mapped I/O, each peripheral register has a fixed address in the processor's memory map. You create a pointer to that address, mark it volatile, and then read or write the register like a normal variable. This lets plain C code control hardware without special instructions. Vendor headers and a HAL (hardware abstraction layer, a library of ready-made driver functions) wrap these pointers in named structures, but underneath it is still a volatile pointer to a fixed address.

Q7. What is structure padding, and how can you avoid it?

The compiler inserts unused bytes between structure members so that each member sits on an address that suits its size. That makes access faster, but the structure becomes larger than the sum of its members. You can reduce padding by ordering members from largest to smallest. Some compilers offer a packed attribute that removes padding, but packed members can be slower or even fault on some processors when accessed unaligned. Never assume a structure's layout matches a protocol frame without checking its size. This example shows the effect on a typical 32-bit target:

#include <stdint.h>
#include <stdio.h>

struct padded { /* typical 32-bit target */
    uint8_t a; /* 1 byte, then 3 padding bytes */
    uint32_t b; /* 4 bytes */
    uint8_t c; /* 1 byte, then 3 padding bytes */
}; /* sizeof is usually 12 */

struct reordered {
    uint32_t b; /* 4 bytes */
    uint8_t a; /* 1 byte */
    uint8_t c; /* 1 byte, then 2 padding bytes */
}; /* sizeof is usually 8 */

int main(void)
{
    printf("%zu %zu\n", sizeof(struct padded), sizeof(struct reordered));
    return 0;
}

The exact sizes depend on the compiler and processor, which is the point: print sizeof on your target instead of guessing.

Q8. What is endianness, and how do you check it?

Endianness is the byte order used to store multi-byte values. Little-endian stores the least significant byte at the lowest address. Big-endian stores the most significant byte first. To check it, store a known 16-bit or 32-bit value, take a byte pointer to it, and read the first byte. Endianness matters when you send data over a protocol, read sensor registers that return bytes in a fixed order, or share binary files between systems. Always convert explicitly instead of copying raw structures. A simple runtime check looks like this:

#include <stdint.h>
#include <stdio.h>

int is_little_endian(void)
{
    uint16_t value = 0x0001;
    uint8_t *first_byte = (uint8_t *)&value;
    return *first_byte == 0x01; /* low byte stored first */
}

int main(void)
{
    printf("%s-endian\n", is_little_endian() ? "Little" : "Big");
    return 0;
}

Reading an object through an unsigned char or uint8_t pointer is allowed in C, so this check is safe. A union of a uint16_t and a two-byte array is another common answer.

4. Microcontroller basics (Q9 to Q14)

Short answer: These questions check that you know what is inside a microcontroller and how firmware starts and controls it.

Q9. What is the difference between a microcontroller and a microprocessor?

A microcontroller (MCU) is a single chip with a CPU, flash memory, RAM and peripherals such as timers, ADC and UART, built to control one dedicated job at low cost and low power. A microprocessor (MPU) is mainly a CPU that needs external RAM, storage and support chips, and usually runs a full operating system such as Linux. For example, an Arm Cortex-M chip is a typical microcontroller, while the application processors on phones and Linux boards are microprocessors.

Q10. What is the difference between Harvard and von Neumann architecture?

In von Neumann architecture, instructions and data share one memory and one bus, so the CPU fetches them one after the other. In Harvard architecture, instructions and data use separate memories or buses, so the CPU can fetch an instruction and access data at the same time. Many microcontrollers use a Harvard-style design internally for speed. Interviewers like this question because it connects to why some chips can run code from flash while reading data from RAM in the same cycle.

Q11. What is GPIO, and how do you configure a pin?

GPIO (general purpose input/output) pins are pins you can set in software as digital inputs or outputs. To configure one, you first enable the clock for that GPIO port, then set the pin's mode (input, output, alternate function or analog), then set options such as push-pull or open-drain output and internal pull-up or pull-down. After that, you read the input data register or write the output register. Forgetting to enable the port clock is the most common beginner mistake.

Q12. What is a watchdog timer, and why is it used?

A watchdog timer is a hardware counter that resets the microcontroller if the software does not "kick" or refresh it before it runs out. It protects the device when firmware hangs because of a bug, an endless loop or electrical noise. You refresh it from a point in the code that proves the whole system is healthy, not from a timer ISR that keeps running even when the main loop is stuck. In safety-related products, you also log why the last reset happened.

Q13. What happens when a microcontroller powers on, before main runs?

After reset, the CPU loads the starting stack pointer and jumps to the reset handler from the vector table. The startup code then sets up clocks if needed, copies initial values of global variables from flash to RAM, clears the zero-initialised variables, and calls system initialisation. Only then does it call main. On Arm Cortex-M parts, much of this startup code is written in C or assembly and supplied by the vendor. Knowing this sequence helps you debug crashes that happen before main.

Q14. What is a bootloader?

A bootloader is a small program that runs first after reset and decides what to do next. Usually it checks whether a valid application exists and jumps to it. If an update is requested, it receives new firmware over UART, USB, CAN or a wireless link, writes it to flash and verifies it. A good bootloader checks a checksum or signature before jumping, keeps a fallback copy if possible, and never erases itself. Bootloaders are why you can update a device in the field without a debugger.

5. Interrupts and timers (Q15 to Q20)

Short answer: These questions check that you can write interrupt-driven code that is fast, correct and safe to share data with.

Q15. What is an interrupt, and what is an ISR?

An interrupt is a signal from hardware or software that makes the CPU pause its current work and run a special function. That function is the ISR (interrupt service routine). For example, when a UART receives a byte, it raises an interrupt and the ISR copies the byte into a buffer. After the ISR finishes, the CPU continues where it stopped. Interrupts let firmware react quickly to events without wasting time polling every peripheral in a loop.

Q16. What should you avoid inside an ISR?

Keep ISRs short and predictable. Avoid long loops, delays, printf, dynamic memory allocation and blocking RTOS calls. Do not call functions that are not reentrant. Instead, do the minimum work: read the hardware, clear the interrupt flag, store data in a buffer or set a volatile flag, and let the main loop or a task do the heavy processing. Long ISRs increase latency for other interrupts and cause missed events that are very hard to debug. The classic short-ISR pattern uses a volatile flag:

#include <stdbool.h>

static volatile bool data_ready = false;

/* The handler name comes from your vendor's vector table */
void TIMER0_IRQHandler(void)
{
    /* 1. Clear the peripheral's interrupt flag here */
    data_ready = true; /* 2. Signal the main loop */
}

void process_sample(void); /* slow work, outside the ISR */

int main(void)
{
    for (;;) {
        if (data_ready) {
            data_ready = false;
            process_sample();
        }
        /* other jobs, or sleep until the next interrupt */
    }
}

Without volatile, an optimising compiler may read data_ready once, keep it in a register and never see the ISR change it. A single bool write is safe here; larger shared data needs the protection described in Q20.

Q17. What is interrupt latency, and how can you reduce it?

Interrupt latency is the time between the hardware raising an interrupt and the first instruction of the ISR running. It depends on the CPU, the current instruction, higher-priority interrupts and any code that has disabled interrupts. To reduce it, keep other ISRs short, avoid disabling interrupts for long periods, give time-critical sources higher priority, and place critical handlers in fast memory if the chip supports it. Measure latency by toggling a GPIO pin in the ISR and watching it on an oscilloscope.

Q18. What is the difference between polling and interrupts?

In polling, the CPU keeps checking a status flag in a loop to see whether an event happened. It is simple and predictable but wastes CPU time and power. With interrupts, the hardware tells the CPU when the event happens, so the CPU can do other work or sleep. Polling suits very fast or very simple cases, such as waiting a few cycles for a flag. Interrupts suit events that happen rarely or unpredictably, such as a button press or an incoming byte.

Q19. What are nested interrupts and interrupt priorities?

Each interrupt source can have a priority. If a higher-priority interrupt arrives while a lower-priority ISR is running, the CPU can pause the lower one and run the higher one first. That is nesting. On Arm Cortex-M parts, the interrupt controller (called the NVIC) handles priorities and nesting in hardware. You must set priorities carefully: a communication receive interrupt that cannot lose data usually needs higher priority than a slow housekeeping timer.

Q20. How do you share data safely between an ISR and the main code?

Declare the shared variable volatile so the compiler always reads fresh values. If the data is larger than one atomic read or write, protect access in the main code by briefly disabling that interrupt or using a critical section. For streams of data, use a ring buffer (circular buffer) where the ISR only writes the head index and the main loop only writes the tail index. This single-producer, single-consumer pattern avoids most race conditions without long interrupt lockouts. Here is a minimal version for a UART receive ISR:

#include <stdint.h>
#include <stdbool.h>
#define RB_SIZE 64u /* one slot always stays empty */

static volatile uint8_t rb_data[RB_SIZE];
static volatile uint8_t rb_head; /* written only by the ISR */
static volatile uint8_t rb_tail; /* written only by main */

bool rb_put(uint8_t byte) /* call from the UART ISR */
{
    uint8_t next = (uint8_t)((rb_head + 1u) % RB_SIZE);
    if (next == rb_tail) return false; /* full: count overflow */
    rb_data[rb_head] = byte;
    rb_head = next;
    return true;
}

bool rb_get(uint8_t *byte) /* call from the main loop */
{
    if (rb_tail == rb_head) return false; /* empty */
    *byte = rb_data[rb_tail];
    rb_tail = (uint8_t)((rb_tail + 1u) % RB_SIZE);
    return true;
}

The indices are 8-bit so that each read and write is a single access, even on an 8-bit microcontroller. Each index has exactly one writer, so no lock is needed. On processors that reorder memory accesses, add the memory barrier your vendor recommends.

6. Memory (Q21 to Q26)

Short answer: These questions check that you know where code and data live and how to avoid running out of memory.

Q21. What types of memory does a microcontroller have?

A typical microcontroller has flash memory for program code and constant data, which keeps its contents without power. It has RAM (usually SRAM) for variables, the stack and the heap, which loses its contents at power off. Many parts also offer EEPROM or emulate it in flash for small settings that must survive resets. Registers inside the CPU and peripherals are a separate, very small set of storage. Knowing the size of each helps you choose data types and buffers wisely.

Q22. What is the difference between stack and heap?

The stack holds local variables, function parameters and return addresses. It grows and shrinks automatically with each function call and is fast. The heap is a pool of memory you request at run time with malloc and release with free. In embedded systems, the stack is fixed in size, so deep recursion or large local arrays can overflow it and corrupt other data. The heap can fragment over time. That is why many firmware teams use mostly static allocation.

Q23. Why is malloc often avoided in embedded systems?

Dynamic allocation has three problems on small devices. First, the time malloc takes can vary, which hurts real-time behaviour. Second, after many allocations and frees, the heap can fragment so that a request fails even though enough total memory is free. Third, a failed allocation at run time is hard to handle safely in a device with no user. Many teams allocate everything at startup or use fixed-size memory pools instead. Coding guidelines such as MISRA C also restrict dynamic memory.

Q24. What are the text, data and bss sections?

These are sections the linker creates. The text section holds program code and usually constants, stored in flash. The data section holds global and static variables that have an initial value. Their initial values are stored in flash and copied to RAM at startup. The bss section holds global and static variables with no initial value, or zero, and the startup code clears it to zero in RAM. The linker script tells the linker where each section goes in the memory map.

Q25. How do you detect a stack overflow?

Common methods are: fill the stack area with a known pattern at startup and later check how much of it was overwritten (stack painting); place a guard region at the end of the stack and check it; use a memory protection unit, if the chip has one, to fault on access beyond the stack; and use the RTOS's built-in stack checking. FreeRTOS, for example, offers optional stack overflow checking hooks. Also check the linker map file and the compiler's stack usage reports for large functions.

Q26. What is a memory leak, and how is it a problem in firmware?

A memory leak happens when code allocates memory and never frees it. On a desktop, a restart often hides the problem. On an embedded device that runs for months, even a small leak in a loop slowly uses up the heap until an allocation fails and the device crashes or resets. Prevent it by avoiding dynamic allocation in long-running loops, pairing every allocation with a free on every path, and tracking heap usage during long soak tests.

7. Communication protocols: UART, SPI, I2C and CAN (Q27 to Q34)

Short answer: These questions check that you know how devices talk to each other, which protocol fits which job, and how to debug a link that does not work.

Q27. How does UART work?

UART (universal asynchronous receiver-transmitter) sends data one bit at a time over a transmit line and receives on a separate receive line, with no shared clock. Both sides must agree on the baud rate (bits per second), the number of data bits, parity and stop bits. Each frame starts with a start bit, then the data bits, an optional parity bit and one or more stop bits. Because there is no clock line, a baud-rate mismatch produces garbage characters, which is the first thing to check when debugging.

Q28. How does SPI work?

SPI (serial peripheral interface) is a synchronous, full-duplex bus with one controller and one or more peripherals. It uses a clock line, a data line from controller to peripheral, a data line from peripheral to controller and a chip-select line for each peripheral. The controller pulls one chip-select low, then sends and receives one bit on each clock edge at the same time. SPI is fast and simple, but each extra device needs another chip-select pin, and there is no built-in acknowledgement.

Q29. What are SPI modes?

SPI has four modes formed from two settings. Clock polarity (CPOL) sets whether the clock idles low or high. Clock phase (CPHA) sets whether data is sampled on the first or second clock edge. Together they give modes 0, 1, 2 and 3. The controller and the peripheral must use the same mode, which you find in the peripheral's datasheet. A wrong mode often shows up as data that is shifted by one bit or looks almost right, so check the mode early when you debug SPI.

Q30. How does I2C work?

I2C is a two-wire bus. A TI application note explains that controller and target devices share the bus over only 2 wires, SCL (clock) and SDA (data), using open-drain outputs (TI, SLVA704A). The controller sends a start condition, a 7-bit target address and a read or write bit, and the addressed target replies with an acknowledge (ACK) bit. Data then moves one byte at a time, each followed by an ACK or NACK, and a stop condition ends the transfer.

Q31. Why does I2C need pull-up resistors?

I2C devices use open-drain outputs, which means they can only pull a line low. They never drive it high. Pull-up resistors bring SCL and SDA back to high when no device is pulling them down. Without pull-ups, the lines float and nothing works. If the resistors are too large, edges rise slowly and the bus fails at higher speeds. If they are too small, devices may not be able to pull the line low enough. Always check pull-ups first when an I2C bus stays stuck.

Q32. What is the difference between UART, SPI and I2C?

UART is asynchronous, point-to-point and uses two data lines with no clock. SPI is synchronous, full duplex, fast, and uses a separate chip-select per device. I2C is synchronous, half duplex, uses only two wires and supports many devices by address, but is usually slower than SPI. Choose UART for debug consoles and modules such as GPS or GSM, SPI for fast devices such as displays, flash memory and ADCs, and I2C for many slower sensors on the same board.

Q33. What is CAN, and why is it used in vehicles?

CAN (Controller Area Network) is a robust two-wire differential bus used for communication between electronic control units in vehicles and industrial machines. A TI application note describes CAN as developed by Bosch as a "multi-master, message broadcast system", standardised as ISO 11898 (TI, SLOA101B). Any node can send, every node hears every message, and messages carry an identifier instead of a destination address. Built-in error detection and fault confinement make it reliable in noisy environments.

Q34. How does CAN arbitration work, and what are CAN FD and CAN XL?

When two nodes start sending at the same time, they compare identifier bits as they go. A dominant bit (0) overwrites a recessive bit (1) on the bus. A node that sends recessive but reads dominant stops sending, so the message with the lowest identifier, which means the highest priority, wins without being corrupted. Bosch states that CAN FD was introduced in 2012 and that CAN XL supports up to 20 Mbit/s and 2048 data bytes (Bosch, October 2026).

8. RTOS (Q35 to Q42)

Short answer: These questions check that you understand how a real-time operating system schedules tasks and how tasks share data and resources safely.

An RTOS (real-time operating system) is a small operating system that runs tasks so they meet timing deadlines. Our detailed guide to the RTOS in embedded systems covers each concept with examples. These are the questions that come up most.

Q35. What is an RTOS, and how is it different from a general-purpose OS?

An RTOS is designed for predictable timing. It always runs the highest-priority ready task and has short, bounded response times. A general-purpose OS such as Windows or desktop Linux is designed for overall throughput and fairness, so its timing can vary. RTOSes are also much smaller. FreeRTOS describes itself as a real-time operating system for microcontrollers and small microprocessors, maintained by AWS under the MIT licence (FreeRTOS, October 2026). Other names you may hear include Zephyr, Eclipse ThreadX, VxWorks and QNX.

Q36. What is the difference between hard and soft real time?

In a hard real-time system, missing a deadline is a failure that can cause harm, for example an airbag controller or a motor's safety cut-off. In a soft real-time system, a missed deadline lowers quality but the system still works, for example a dropped video frame. Some people also describe firm real time, where a late result is useless but not dangerous. Real time means predictable, not necessarily fast. Your design must prove the worst case, not just the average.

Q37. What is the difference between a superloop and an RTOS?

A superloop (bare-metal) design is a single endless loop in main that calls each job in turn, with ISRs handling urgent events. It is simple, small and easy to debug, and it suits small devices with few jobs. An RTOS splits the work into tasks with priorities and a scheduler. It suits systems with many independent jobs that have different deadlines, such as networking plus sensing plus a display. The cost is more memory, more complexity and new problems such as deadlocks.

Q38. What is preemptive scheduling, and what is a context switch?

In preemptive scheduling, the scheduler can stop a running task as soon as a higher-priority task becomes ready, without waiting for the running task to give up the CPU. A context switch is the act of saving the current task's CPU registers and stack pointer and loading those of the next task. Context switches are triggered by the system tick timer, by an ISR that wakes a task, or by a task blocking. Each switch costs a little time, so too many tiny tasks waste CPU.

Q39. What is the difference between a semaphore and a mutex?

A semaphore is a signalling tool. A binary semaphore is often given by an ISR and taken by a task to say "an event happened". A counting semaphore tracks how many resources or events are available. A mutex (mutual exclusion) is a lock that protects a shared resource, such as a UART or an SPI bus, so only one task uses it at a time. A mutex has an owner, and only the owner should release it. Many RTOSes also add priority inheritance to mutexes.

Q40. What is priority inversion, and how is it solved?

Priority inversion happens when a high-priority task waits for a mutex held by a low-priority task, and a medium-priority task keeps preempting the low-priority one. The high-priority task is then effectively blocked by the medium one. The common fix is priority inheritance: while the low-priority task holds the mutex, the RTOS raises its priority to match the waiting high-priority task, so it finishes quickly and releases the lock. Another fix is the priority ceiling protocol. Keeping critical sections short also helps.

Q41. What is a deadlock, and how do you prevent it?

A deadlock happens when two or more tasks each hold a resource and wait for a resource the other holds, so none can continue. For example, task A holds the SPI mutex and waits for the I2C mutex, while task B holds the I2C mutex and waits for SPI. Prevent it by always taking locks in the same fixed order, holding locks for as short a time as possible, using timeouts when waiting, and avoiding nested locks where you can.

Q42. Can you call any RTOS function from an ISR?

No. Functions that can block, such as waiting on a semaphore or a queue, must never be called from an ISR, because an ISR cannot be suspended like a task. Most RTOSes provide special ISR-safe versions. In FreeRTOS, these end in FromISR, such as the queue send and semaphore give functions with that suffix. The usual pattern is that the ISR gives a semaphore or sends to a queue using the ISR-safe call, then requests a context switch if it woke a higher-priority task.

9. Debugging and testing (Q43 to Q48)

Short answer: These questions check that you can find faults methodically with the right tools, not by guessing.

Q43. What tools do you use to debug embedded firmware?

The main tools are a debug probe connected over JTAG or SWD (serial wire debug, Arm's two-pin debug interface) with an IDE or GDB for breakpoints, stepping and memory views; a serial console over UART for logs; a logic analyser to decode digital signals and protocols; an oscilloscope to see voltage levels, noise and timing; and a multimeter for power and continuity. Open tools such as OpenOCD and sigrok are common in labs, along with vendor IDEs. Choose the tool that matches the layer where the fault lives.

Q44. What is the difference between JTAG and SWD?

JTAG is an older, widely used standard interface for testing and debugging chips. It uses several signal lines and can chain multiple devices. SWD is Arm's serial wire debug interface, which uses only two signal lines, a clock and a bidirectional data line, so it saves pins on small Arm Cortex-M boards. Both let a debugger halt the CPU, set breakpoints, read memory and flash firmware. On Cortex-M boards, SWD is the most common choice for daily development.

Q45. Your device resets randomly. How do you find the cause?

First, read the reset cause register at startup and log it, so you know whether it was a watchdog, brown-out (low voltage), software reset or a fault. If it is a watchdog reset, find which code path stopped refreshing it. If it is a brown-out, check the power supply with an oscilloscope during load changes such as a motor or radio turning on. If it is a fault, check the stack size and look for bad pointers. Change one thing at a time and reproduce the problem reliably.

Q46. What is a hard fault on Arm Cortex-M, and how do you debug it?

A hard fault is an exception the processor raises when something goes badly wrong, such as accessing an invalid address, executing an invalid instruction or an unaligned access that is not allowed. To debug it, write a fault handler that saves the stacked registers, especially the program counter and link register, then look up that address in the map file or disassembly to find the faulting line. Common causes are null or dangling pointers, stack overflow and calling a function pointer that was never set.

Q47. How do you test embedded software?

Use several levels. Unit tests check individual functions on your PC with the hardware access replaced by stubs or mocks. Integration tests run on the real board to check drivers and modules together. Hardware-in-the-loop (HIL) tests feed simulated signals to the device. System tests check full behaviour, including long soak tests for memory leaks and timing issues. Add static analysis to catch risky code before it runs. Automate as much as possible so every change is tested the same way.

Q48. What is MISRA C, and why does it matter?

MISRA C is a set of guidelines for writing safer, more reliable C, widely used in automotive, medical and industrial firmware. Its publisher, The MISRA Consortium, calls it the "de facto standard" where safety, security and code quality matter, and its FAQ says MISRA C:2025 was published in March 2025 and is the current version (MISRA, October 2026). The rules restrict risky features such as uncontrolled pointer casts and dynamic memory. Static analysis tools check code against them automatically.

10. Scenario and design questions (Q49 to Q54)

Short answer: These questions check how you think. Say your assumptions aloud, draw a block diagram, and explain the trade-offs.

Q49. How would you debounce a push button?

A mechanical button bounces, giving several quick on-off changes for one press. In software, sample the pin at a fixed interval, for example from a timer interrupt, and only accept a new state after it stays the same for several samples in a row. Alternatively, trigger on the first edge, then ignore further edges for a short lockout period. In hardware, an RC filter with a Schmitt-trigger input also works. Mention that you would check the real bounce time on an oscilloscope. A counter-based software debounce looks like this:

#include <stdint.h>
#include <stdbool.h>

#define DEBOUNCE_SAMPLES 5u /* example: 5 samples, 2 ms apart */

bool read_button_pin(void); /* raw GPIO read, true = pressed */

static bool stable_state = false;
static uint8_t same_count = 0;

/* Call every 2 ms from a timer tick. Returns true once per press. */
bool debounce_update(void)
{
    bool raw = read_button_pin();
    if (raw == stable_state) {
        same_count = 0; /* no change, reset the counter */
        return false;
    }
    if (++same_count >= DEBOUNCE_SAMPLES) {
        stable_state = raw; /* new state held long enough */
        same_count = 0;
        return stable_state; /* true only on a new press */
    }
    return false;
}

Tune the sample count and period to the bounce you measured, and explain that a longer window rejects more noise but makes the button feel slower.

Q50. Design a firmware module to receive variable-length messages over UART.

Use the UART receive interrupt, or DMA (direct memory access, which moves data without the CPU) if available, to place bytes into a ring buffer. In the main loop or a task, read bytes from the buffer and run a small state machine that looks for a start marker, reads a length field, collects the payload and checks a checksum or CRC. Add a timeout so a broken frame does not block forever. Report overflow if the buffer fills. This design separates fast hardware handling from slower parsing.

Q51. Design a battery-powered temperature logger that must run for a long time.

Start with requirements: how often to sample, how much data to store and how long the battery must last. Choose a low-power microcontroller and a sensor with a sleep mode. Most of the time the MCU stays in deep sleep, wakes on a low-power timer, powers the sensor, reads it over I2C, stores the value in flash, and sleeps again. Turn off unused peripherals and pins. Measure real current in each state and estimate battery life from the average, then confirm with a long test.

Q52. How would you design a safe firmware update for a device in the field?

Use a bootloader and two firmware slots if flash allows. The new image is downloaded into the inactive slot, then its integrity and authenticity are checked with a CRC and a digital signature. Only after the check passes does the bootloader mark the new slot as active. If the new firmware fails to start or does not confirm itself within a set time, the bootloader rolls back to the old slot. Never erase the only working copy before the new one is verified. For security, mention secure boot (the bootloader runs only firmware signed with your key) and locking or disabling the JTAG or SWD debug port on production units, so an attacker cannot read out or replace the firmware.

Q53. A sensor on I2C does not respond. How do you debug it?

Check the basics in order. Confirm power and ground at the sensor, and check that SCL and SDA have pull-ups and idle high. Confirm the 7-bit address from the datasheet and whether your library expects it shifted. Then capture the bus with a logic analyser: do you see a start condition, the right address and an ACK? A NACK points to a wrong address or an unpowered device. A bus stuck low may need a recovery sequence of clock pulses or a sensor reset.

Q54. How would you make a device that reads a sensor, updates a display and sends data over Wi-Fi?

With a few jobs that have different timing needs, an RTOS fits well. Create a sensor task at higher priority that reads at a fixed period and sends readings to a queue. A display task reads the latest value and redraws the screen. A network task, at lower priority, batches readings and sends them, retrying on failure. Protect the shared bus with a mutex if two tasks use it. Add a watchdog that is refreshed only when every task reports that it is alive.

11. HR and project questions (Q55 to Q60)

Short answer: These questions check your communication, honesty and interest in embedded work. Prepare short, true stories from your own projects.

Q55. Tell me about yourself.

Give a 60 to 90 second answer with three parts: who you are (degree, branch, current role), what you have built (one or two embedded projects with the board, the protocols and a result), and why you want this role. For example: "I am an ECE graduate. I built a data logger on an Arm Cortex-M board that reads two I2C sensors and sends data over UART. I enjoy working close to hardware, and this role builds on that." Avoid repeating your resume line by line.

Q56. Explain your embedded project.

Use a clear structure: the problem, the block diagram (MCU, sensors, actuators, communication), your firmware design (superloop or RTOS, interrupts used, main modules), one hard bug and how you fixed it, and the result. Interviewers will dig into anything you mention, so only include parts you truly built and understand. Keep your code on GitHub with a readable README, a wiring diagram and photos. If you need project ideas, our list of embedded systems projects is a good start.

Q57. Why do you want to work in embedded systems?

Give a real reason and back it with evidence. Good reasons include enjoying the link between code and physical hardware, liking problem solving at a low level, or interest in a domain such as automotive, medical devices or IoT. Then show proof: a project, a lab you enjoyed or a problem you debugged. You can also mention that India's electronics manufacturing has grown fast in recent years, but keep the focus on your own motivation rather than market statistics.

Q58. What was the hardest bug you fixed?

Pick a real bug and tell it with the STAR method: situation, task, action and result. For example, a sensor value that was correct in debug mode but wrong in release mode, which turned out to be a missing volatile on a flag shared with an ISR. Explain how you narrowed it down, which tools you used and what you changed to prevent it again. Interviewers want to see a method, not luck.

Q59. Are you comfortable working with hardware, labs and testing?

Answer honestly and with examples. Mention the instruments you have used (multimeter, oscilloscope, logic analyser, debug probe), any soldering or breadboard work, and whether you have read datasheets and schematics. If you have not used something, say so and explain how you would learn it. Embedded roles often include lab work, board bring-up and validation, so showing that you enjoy hands-on testing, not just writing code, is a strong plus for freshers.

Q60. Do you have any questions for us?

Always ask one or two. Good questions are: which microcontrollers and RTOS the team uses, how firmware is tested and reviewed, what a new joiner works on in the first three months, and whether the role includes lab or customer work. Avoid asking only about salary or leave in a technical round. Thoughtful questions show that you are serious about the work and help you judge whether the team suits you.

12. Quick revision: 10 questions in one line each

Short answer: Use this block the night before your interview. If you cannot expand any line into a full answer with an example, go back to that question above.

13. How to prepare for an embedded systems interview

Short answer: Revise embedded C daily, build or polish one hardware project, practise protocols and RTOS on a real board, and rehearse these 60 questions aloud.

Reading answers is not enough. Interviewers quickly spot whether you have used a board yourself. Follow this 4-week plan.

If you are a fresher, focus on strong C, one well-documented project and honest answers. Say "I have not used that yet, but here is how I would approach it" when needed. If you are experienced, expect deeper questions on RTOS design, drivers, debugging stories, MISRA and code reviews, and bring examples with measured results. If you already know C and have used a board, four weeks is usually enough. If you are starting C from scratch, plan for a few months of hands-on practice first.

Your branch shapes the follow-up questions. ECE and EEE students often get more on electronics, signals, power and reading schematics. CSE students often get more on C, data structures, operating system concepts and RTOS. Pick one board family, ideally Arm Cortex-M, and learn it deeply; moving to another family later is mostly a matter of reading its datasheet and reference manual. Microcontroller firmware roles focus on C, peripherals, interrupts and RTOS, while BSP and device driver roles on application processors also expect embedded Linux, such as kernel modules and character drivers. Learn microcontroller basics first, then add Linux if you target those roles.

Keep your resume short and true: every board, protocol and tool on it should be something you can discuss for five minutes. To understand the roles you are applying for and where to find openings, read our guide to embedded systems jobs for freshers. For free study, the FreeRTOS documentation and vendor application notes such as the TI I2C and CAN notes linked above are excellent primary sources.

14. How Brolly Academy helps

Short answer: Brolly Academy's Embedded Systems course combines three months of hands-on training in embedded C, ARM, RTOS and protocols with projects and mock interviews, so you can answer these questions from real experience.

The Embedded Systems Course in Hyderabad runs for 3 months with 80+ hours of expert-led training. Month 1 covers microcontrollers and embedded C on ARM Cortex, STM32 and Arduino, including timers and interrupts. Month 2 covers RTOS, IoT and the I2C, CAN, SPI and UART protocols. Month 3 covers automotive embedded, VLSI basics and a capstone project, followed by career preparation. The course page lists 31 modules, from C programming and microcontroller architecture to Linux device drivers, ARM architecture, RTOS, and testing and debugging, which match most of the questions above.

You work on projects such as an embedded Linux device driver, an embedded C sensor control system, an IoT automation system using I2C, SPI, UART and RTOS, and an automotive embedded controller. These give you real stories for the project round. Career support includes placement assistance, resume and LinkedIn help, and mock interviews: weekly in the live online course and monthly in classroom training. Classes run in classroom and online modes with weekday and weekend schedules. Fees on the course page are ₹15,000 for video recordings, ₹40,000 for the live online course and ₹45,000 for classroom training, with easy EMI available. You receive a Brolly Academy course completion certificate, which is not a vendor certification. The page lists EEE, ECE, CSE, Mechanical, Mechatronics, Aerospace, M.Sc. and M.Tech backgrounds as preferred, says C is taught from basics and beginners can join, and offers free 3-day demo classes are available before you enrol.

Frequently asked questions