Skip to content
Embedded Level
Sign in
Theme

Plans and pricing

All topics are open on the free plan, with up to 5 questions a day. The paid plan removes the daily limit and adds Interview prep: practice questions written for a job description you provide, and a readiness report for that role.

No daily limit30 questions per jobReadiness report
Paste a job description, get 30 questions for that role, and see how ready you are for each of its topics.Example
Free and paid plans compared
FeatureFreePaid
Full question bank, all topicsIncludedIncluded
Level test and full learning pathIncludedIncluded
Practice questions per day5No daily limit
Weak areas reportIncludedIncluded
Interview prepPaste a job description and receive 30 questions written for that roleNot includedIncluded
Readiness report for your interviewNot includedIncluded
PriceUS$0US$13
PaymentNo card requiredOne payment for 30 days. Charged in US dollars.
RenewalNot applicableNo automatic renewal

Paid plan

30 days, no automatic renewal

US$13

Charged in US dollars.

  • No daily limit on practice
  • Interview prep: 30 questions per job
  • Readiness report for your interview
Sign in to upgrade

By paying, you agree to our Terms. Questions about your purchase? Contact support@embeddedlevel.com.

Sample questions for one role

Paste a job description and we write 30 questions for that role. Below is an example job description with 3 of its questions.

Example job description

Embedded Firmware Engineer

Automotive body electronics

You will own the firmware for a door and seat control module: window lift, mirror adjustment, seat memory and door locking. The module runs FreeRTOS on an STM32 (Cortex-M4) and talks to the body controller over CAN.

What you will do

  • Write and maintain the module firmware in C on STM32 (Cortex-M4) with FreeRTOS.
  • Implement CAN bus communication with the body controller, including diagnostic messages.
  • Keep the current draw of a parked car within budget, using low-power modes and wake-up sources.
  • Bring up new boards with the hardware team, using an oscilloscope and a logic analyzer.
  • Find and fix field faults from event logs and HardFault records.

What you bring

  • Three or more years of embedded C on ARM Cortex-M microcontrollers.
  • Experience with an RTOS, ideally FreeRTOS.
  • CAN or LIN in a vehicle or industrial product.
  • Comfortable reading schematics and datasheets.

Nice to have: AUTOSAR basics, awareness of ISO 26262, Python for test tools.

  1. Question 1

    CAN bus

    Your module starts sending a seat position frame with identifier 0x3A0. In the same bit time, the body controller starts sending a door lock frame with identifier 0x120. Which frame is transmitted first, and why?

    • AThe door lock frame, because a lower identifier wins arbitrationCorrect
    • BThe seat frame, because it was queued in the driver a moment earlier
    • CThe frame with the shorter payload, so the bus is busy for less time
    • DWhichever node has the lower address in the network configuration

    CAN arbitrates bit by bit on the identifier. A dominant 0 overrides a recessive 1, so the numerically lower identifier wins. High-priority frames are therefore given low identifiers.

  2. Question 2

    FreeRTOS

    A FreeRTOS task samples the seat motor current every 10 ms, using vTaskDelay(pdMS_TO_TICKS(10)) at the end of its loop. After an hour, the sample times have drifted well behind schedule. Which change keeps the period exact?

    • AUse vTaskDelayUntil with a wake time carried across iterationsCorrect
    • BRaise the task priority above every other task in the system
    • CReplace the delay with taskYIELD so the scheduler runs sooner
    • DMove the sampling into the idle hook so no other task delays it

    vTaskDelay counts from the moment it is called, so each period is 10 ms plus the time the work took. vTaskDelayUntil wakes at fixed absolute tick counts, so the period stays 10 ms while the work fits inside it.

  3. Question 3

    Low power

    With the ignition off, the module must keep its RAM contents, draw as little current as possible and wake as soon as the door handle is pulled. On the STM32, which combination meets these requirements?

    • AStop mode with the handle input configured as an EXTI wake-up lineCorrect
    • BSleep mode with the RTOS tick left running for the handle task
    • CStandby mode, polling the handle input from the RTC alarm handler
    • DRun mode at the lowest clock, with all peripheral clocks gated off

    Stop mode halts the core-domain clocks but keeps SRAM and register contents, so current falls far below Sleep mode, and an EXTI line wakes the core directly. Sleep mode stops only the CPU clock. Standby loses the SRAM contents, and an RTC alarm checks the handle only at intervals.

When you practice, the options appear in random order and the answer is shown after you choose.

Frequently asked questions

Does the paid plan renew automatically?
No. One payment gives you 30 days of paid access. You are not charged again unless you choose to pay again. If you pay while you still have paid days, 30 days are added to the end of your current period.
How do I pay?
By card, on the Ziina payment page. You enter your card details with Ziina, and they never reach our site.
What is Ziina?
Ziina is a licensed payment provider. It processes your payment and confirms the result to us.
Can I get an invoice?
Your payments are listed on the Settings page. To request an invoice, contact support and we will send it to you.
Can I get a refund?
Paid access starts immediately, so the purchase is final. If a paid feature does not work because of a fault on our side, contact support while your paid days are running. We will fix the fault, refund the payment or add back the lost days.

Payments are processed by Ziina. The paid plan is a one-off purchase of 30 days, so there is nothing to cancel.

For full details, read our Terms and Privacy policy.