5 exercises — choose the best-structured answer to common embedded systems interview questions. Focus on technical precision, hardware vocabulary, and practical debugging experience.
Structure for embedded systems questions
Hardware layer: describe the physical signals or pins involved
Mechanism: explain the protocol or process step by step
Trade-offs: compare speed, complexity, or power vs alternatives
Practical context: give a real use case or failure mode
0 / 5 completed
1 / 5
The interviewer asks: "What is an interrupt and why is it important in embedded systems?" Which answer is most technically accurate?
Option A is the strongest: it defines the concept precisely (pauses the CPU's normal execution to handle a higher-priority event), explains the mechanism step by step (save state → jump to ISR → execute → resume), uses the correct term (Interrupt Service Routine), and explains the alternative (polling) and its cost (wastes CPU cycles). Option D is accurate and mentions polling as the alternative — a key technical insight — but doesn't explain the state-save/restore mechanism. Option C mentions multiple use cases (timers, UART, GPIO) which shows breadth but lacks definitional precision. Option B is technically correct but very surface-level. Structure: define → mechanism steps → why it's needed → what the alternative costs.
2 / 5
The interviewer asks: "What is the difference between bare-metal programming and using an RTOS?" Choose the most complete answer.
Option A is the best: it defines both terms clearly, explains what the RTOS adds (scheduler, concurrent tasks, timing guarantees), and most importantly gives the decision criteria for choosing each — this is what separates candidates with real design experience. Option D mentions FreeRTOS and lists primitives (tasks, queues, semaphores, timers) — excellent concrete details — but incorrectly equates bare-metal with "no HAL" (HALs exist on bare-metal too) and doesn't give the selection criteria. Option B is too brief and the "easier to write" claim is debatable. Option C is accurate but lacks the decision-making dimension. Tip: for comparison questions, always include when you would choose each option.
3 / 5
The interviewer asks: "Can you explain the I2C protocol?" Which explanation is most complete?
Option A is the strongest: it names the wires with their full names (SDA, SCL), states the device limit (127 for 7-bit addressing), explains the communication sequence (start → address + R/W bit → data), gives a use case (sensors, EEPROMs), and provides concrete speed figures (100 kHz / 400 kHz). Option D is also technically impressive: it mentions half-duplex, synchronous, multi-master, 7/10-bit addressing, and open-drain pull-up requirement — all accurate and deep details. Option C is accurate but lacks the protocol sequence and speed figures. Option B compares to SPI — useful context — but is too brief. For protocol questions: name the physical layer, the addressing scheme, the communication sequence, and typical speed/use-case numbers.
4 / 5
The interviewer asks: "What is a watchdog timer and when would you use it?" Choose the best answer.
Option A is the best: it defines the watchdog precisely (hardware timer that resets the MCU if firmware fails to kick it), uses the correct verb ("kick" or reset), lists the failure modes it addresses (bug, deadlock, unexpected state), and gives the key use case context (deployed systems that cannot be manually rebooted). Option C is technically accurate and mentions its key use case for remote devices — a strong practical point — but lacks the precise definition of the mechanism. Option B is simple and accurate but doesn't explain the failure modes. Option D uses "feeds" (also correct terminology) but is too brief. Key principle: for safety/reliability mechanisms, explain what failure mode the mechanism handles and when it is indispensable.
5 / 5
The interviewer asks: "How do you debug a firmware issue on hardware without a debugger?" Which answer best demonstrates practical embedded experience?
Option A is the best structured answer for a practical question: it names four distinct techniques with brief descriptions of each tool's role, shows breadth (oscilloscope, logic analyser, UART, LEDs, memory dumps), gives the structured approach (divide-and-conquer), and ends with the professional meta-principle — the choice depends on available tools. Option C is good and mentions checking unexpected watchdog fires — an insightful diagnostic technique. Option B is accurate but too brief — lists techniques without explaining how or when you'd use each. Option D mentions assert macros — a useful software engineering technique — but focuses on only one approach. For practical "how do you debug" questions: list multiple techniques, explain each briefly, and show a systematic approach.