RTOS Interview Questions and Answers, FreeRTOS Included

The RTOS questions embedded and firmware interviews keep returning to, with FreeRTOS-specific answers, the follow-ups to expect, and a one-week prep plan.

Most RTOS interview questions fall into four groups: how the scheduler picks a task, how tasks share resources (mutexes, semaphores, priority inversion), what code may run inside an interrupt, and how you find memory and timing bugs. Interviewers rarely stop at the definition. They give a scenario and keep asking "why" until they reach the edge of your experience. A recruiter at the staffing firm KORE1 calls priority inversion "the single highest-yield RTOS question in the loop", so if you prepare one answer properly, make it that one. The answers below use FreeRTOS terms, because searchers often name it and its free kernel book documents each behaviour in detail.

How RTOS questions show up in the loop

There is no standard embedded interview. One useful public description comes from KORE1's guide for hiring managers (updated September 2026), which recommends this shape:

• Round — Length — Where RTOS comes in
• Screen — 30 min — What you last shipped
• Core technical — 60 min — Memory, interrupts and one RTOS scenario, talked through without a coding platform
• Code review — 45 min — Firmware with seeded defects, such as a missing volatile or an ISR that calls a blocking function
• Debug and judgment — 45 min — A war story, a "printf made the bug disappear" scenario, a hard fault
• Process — 30 min, regulated roles only — Deviations, traceability, sign-off

Two things follow. First, RTOS knowledge is tested by conversation and by reading code, so practise explaining out loud and spotting bugs, not only writing code. Second, the guide treats some answers as red flags: wanting to parse a protocol inside an interrupt handler and answering a hard fault with "I'd add logging" are read as signs of inexperience, and having never measured worst-case stack depth is fine at mid-level but disqualifying at staff level. Several questions below exist to catch exactly those habits.

The questions, with what each one tests

The outlines are short on purpose. Say them in your own words, then attach one example from a project you can defend.

Scheduling and timing

1. What makes a system real-time?

Tests: whether you think in deadlines rather than speed. KORE1 wants you to separate hard from soft real-time and give a shipped example of each, rather than saying "fast".

Outline: real-time means correct output delivered by a deadline, every time. In a hard real-time system a missed deadline is a failure; in a soft one it degrades quality. Then name one of each from your own work.

2. How does the scheduler decide which task runs?

Tests: task states and preemption. Outline: most small FreeRTOS applications use fixed-priority preemptive scheduling with time slicing. The highest-priority task in the Ready state runs; equal-priority tasks take turns. A task waiting on a delay, queue or semaphore is Blocked, and Suspended tasks are invisible to the scheduler. The tick interrupt drives time slicing (configTICK_RATE_HZ of 100 gives 10 ms slices), but preemption also happens the moment an interrupt or another task readies a higher-priority task, not only on a tick.

3. When do you use `vTaskDelayUntil()` instead of `vTaskDelay()`?

Tests: periodic tasks. Outline: vTaskDelay() blocks for a period relative to when it is called, so the task's own run time adds drift. vTaskDelayUntil() wakes at an absolute tick count, which keeps a fixed frequency. Use it for anything sampled at a steady rate.

4. How would you show a set of periodic tasks will meet their deadlines? (more likely at senior level)

Tests: whether you can reason before you measure. Outline: for independent periodic tasks with deadlines equal to their periods, and ignoring blocking on shared resources and context-switch overhead, Liu and Layland's 1973 result says rate-monotonic priorities (shorter period, higher priority) are schedulable if total utilisation stays below n(2^(1/n) − 1): about 0.83 for two tasks, falling toward 0.69 as tasks are added. The test is sufficient, not necessary, so a set above it may still work; an exact test then simulates the worst case, all tasks released together, up to the lowest-priority task's first deadline. Say where your execution-time numbers came from.

Sharing resources

5. What is the difference between a mutex and a binary semaphore?

Tests: ownership. Outline: use a mutex for mutual exclusion: the task that takes it must give it back. Use a binary semaphore for signalling, often from an interrupt to a task, where it is taken and not returned. In FreeRTOS the mutex also has priority inheritance and the binary semaphore does not, which is why mutexes must not be used from interrupt service routines.

6. What is priority inversion, how does priority inheritance fix it, and what does that cost?

Tests: the three-part probe KORE1 describes. Outline: a high-priority task waits for a mutex held by a low-priority task. If a medium-priority task then preempts the low one, the high task waits on work it does not depend on, with no bound. Inheritance raises the holder to the waiter's priority until it releases the mutex, so the wait becomes bounded. The cost, in the FreeRTOS book's words: it "does not 'fix' priority inversion", it complicates timing analysis, and it is not good practice to rely on it. Better to design the sharing out. The well-known case is Mars Pathfinder in 1997: a VxWorks mutex inside its inter-task communication had priority inheritance off. A low-priority science task held it, medium-priority tasks kept running, and when a high-priority bus task missed its cycle the spacecraft reset its computer. The fix, uploaded as a patch, enabled inheritance.

Likely follow-up: "The mutex is inside a vendor driver you can't modify." One answer is a gatekeeper task: give one task sole ownership of the driver and have other tasks send it requests through a queue, which the FreeRTOS book describes as mutual exclusion without the risk of priority inversion or deadlock.

7. How do you avoid deadlock?

Outline: take locks in one fixed order everywhere, and never wait forever. The FreeRTOS book suggests a timeout a little longer than the longest expected wait, so a timeout signals a design error instead of a silent hang.

8. Queue, task notification or event group: which do you use?

Tests: choosing the lightest tool that fits. Outline: a FreeRTOS queue copies data in, so the sender can reuse its buffer at once and the queue can buffer several items. A task notification is faster and uses less RAM, but has one receiving task, holds one value, and cannot send from a task to an ISR. An event group can wake several tasks at once.

Interrupts

9. What belongs in an ISR, and what doesn't?

Outline: record the cause, clear the interrupt, hand the rest to a task. KORE1's version: "Clear the flag, grab the byte, set a flag or post to a queue, get out." Long ISRs add jitter to task timing and, on some architectures, block other interrupts. Deferring work to a high-priority task gives nearly the same response while letting you set its priority and use the full API.

10. Name an RTOS API you cannot call from an interrupt, and what happens if you do.

Outline: anything that can block, such as xQueueReceive() with a timeout, because an ISR has no task to put in the Blocked state. FreeRTOS supplies "FromISR" versions instead. The deeper trap is interrupt priority: an ISR that calls the API must sit at or below configMAX_SYSCALL_INTERRUPT_PRIORITY, or critical sections stop working and failures turn intermittent. On ARM Cortex-M, a numerically low number is a logically high priority, and the FreeRTOS book names wrong interrupt priorities as its most common support request. Mentioning configASSERT(), which traps it in most ports, shows you have debugged it.

11. What does `volatile` do, and what doesn't it do?

Outline: it tells the compiler a variable can change outside the visible code flow (an ISR, a hardware register), so it must re-read it every time. It does not make access atomic, and KORE1 says a candidate who volunteers that distinction tells you more than an hour of algorithm questions. A counter that an ISR increments and a task reads and modifies still needs a critical section.

Memory and debugging

12. How do you size a task's stack, and how do you know the worst case?

Outline: start with an estimate, then measure under the worst load you can create. uxTaskGetStackHighWaterMark() reports the least free stack the task has ever had, and configCHECK_FOR_STACK_OVERFLOW calls a hook when overflow is detected, though the FreeRTOS book notes there is no real way to recover once it happens. Stack overflow is its second most common support request.

13. Why do embedded teams avoid `malloc()`?

Outline: the standard library malloc() is not deterministic, can fragment memory, and is rarely thread-safe. FreeRTOS ships five heap schemes: heap_1 never frees and so cannot fragment, which suits systems that create everything at start-up; heap_4 merges adjacent free blocks for systems that allocate and free repeatedly. Static allocation avoids the heap entirely. Explain the reason, not only the rule.

14. You add a `printf` to trace a bug and the bug disappears. Now what?

Outline: the printf changed the timing, which suggests a race. It can also be slow, not thread-safe and stack-hungry. Switch to a tracing method that disturbs less: FreeRTOS trace hook macros, run-time statistics, or a trace tool such as Tracealyzer. "Add more printfs" is one of the answers KORE1 flags.

Related follow-up: a watchdog where the top task is alive but a lower one has died. Feed the hardware watchdog only when every registered task has checked in recently, the design Memfault's Interrupt blog walks through.

A one-week preparation plan

1. Days 1–2: read the FreeRTOS kernel book chapters on task management, resource management and interrupts. Draw the task state diagram from memory.
2. Day 3: on a dev board, create three tasks at low, medium and high priority, with the low and high tasks sharing one binary semaphore and the medium task kept busy, and watch the high task stall. Swap in a mutex and watch it recover. Having done it is the best answer to question 6.
3. Day 4: for the project you will talk about, write down every task, its priority and why, one synchronisation bug you fixed, and how you measured stack use.
4. Day 5: find the interrupt priority scheme of the microcontroller in the job posting, if one is named, and check how its numbers map to configMAX_SYSCALL_INTERRUPT_PRIORITY.
5. Days 6–7: have a friend ask questions 6, 10, 12 and 14 and keep asking "why". Answer out loud in under two minutes each. More general prompts are in our technical round questions; for hardware-leaning roles, see the electrical engineering questions.

If you use Verve AI's Interview Copilot, upload your resume and the job details, and add your project notes to its Knowledge Base, so its suggestions can draw on the documents you enable, such as your project examples and bug stories, instead of only general knowledge.

Sources

• KORE1 hiring-manager guide (Gregg Flecke, updated 2026-09-06): round structure and lengths, priority inversion as "the single highest-yield RTOS question", the three-part probe and vendor-driver follow-up, hard vs soft with shipped examples, ISR list, volatile and atomicity, stack sizing, printf and hard-fault questions, seeded defects, warning signs: https://www.kore1.com/embedded-software-engineer-interview-questions/
• FreeRTOS kernel book, task management: task states, priorities, tick interrupt and configTICK_RATE_HZ, preemption outside the tick, vTaskDelayUntil(), scheduling algorithms: https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch04.md
• FreeRTOS kernel book, resource management: mutex vs binary semaphore, priority inversion and inheritance (including "does not 'fix' priority inversion"), no mutexes from ISRs, deadlock timeouts, gatekeeper tasks: https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch08.md
• FreeRTOS kernel book, interrupt management: FromISR API, deferred interrupt processing, configMAX_SYSCALL_INTERRUPT_PRIORITY, Cortex-M priority numbering: https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch07.md
• FreeRTOS kernel book, queues (queue by copy): https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch05.md
• FreeRTOS kernel book, task notifications (faster, less RAM, limitations): https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch10.md
• FreeRTOS kernel book, heap memory management (malloc() drawbacks, heap_1, heap_4, static allocation): https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch03.md
• FreeRTOS kernel book, developer support (Tracealyzer, run-time statistics, trace hook macros): https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch12.md
• FreeRTOS kernel book, troubleshooting (interrupt priorities and stack overflow as the top two support requests, configASSERT(), high water mark, overflow hook, printf pitfalls): https://github.com/FreeRTOS/FreeRTOS-Kernel-Book/blob/main/ch13.md
• Mars Pathfinder priority inversion, Glenn Reeves' account (VxWorks, mutex in select/pipe IPC, low-priority science task, bus task missing its cycle and the reset, patch enabling inheritance): https://www.cs.unc.edu/~anderson/teach/comp790/papers/mars_pathfinder_long_version.html
• Liu and Layland bound, values for n tasks, sufficient but not necessary, rate-monotonic optimal among fixed priorities (Harvey Mudd lecture slides): https://www.cs.hmc.edu/courses/2000/spring/cs156/html17/cs156-17.pdf
• Exact test by simulating from a simultaneous release to the lowest-priority task's first deadline (University of Waterloo CS452 notes): https://student.cs.uwaterloo.ca/~cs452/F23/lectures/lec17.html
• Task watchdog that feeds the hardware watchdog only when all tasks have checked in (Chris Coleman, Interrupt by Memfault): https://interrupt.memfault.com/blog/firmware-watchdog-best-practices
• Verve Knowledge Base: https://docs.vervecopilot.com/features/knowledge-base
• Verve Interview Copilot: https://docs.vervecopilot.com/features/interview-copilot