Polling has the CPU repeatedly check a condition in a loop, which wastes cycles spinning when nothing has happened and ties up the processor so it can't do other work or sleep. An interrupt inverts the relationship: you configure the hardware to signal the CPU only when the event actually occurs, so the CPU runs useful work (or enters a low-power sleep) and is woken precisely when needed. This buys three things, efficiency (no cycles burned watching), responsiveness (the hardware reacts immediately rather than waiting for the next poll iteration), and power savings (the core can sleep between events, critical for battery devices). Polling still has its place, for very high-frequency events where interrupt overhead would dominate, or simple tight loops, but for sporadic events like a button press, a received byte, or a timer expiry, interrupts are the right model. The tradeoff is added complexity: concurrency between ISR and main code, which requires volatile and atomicity discipline.
Embedded Systems Fundamentals · Interview question
Why use interrupts instead of polling?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Interrupts & ISRs
Let hardware tap the CPU on the shoulder instead of polling: the NVIC, the vector table, interrupt latency, and the hard rules for writing a correct ISR.