Keep it short, keep it non-blocking, and defer real work. Specifically: (1) do the minimum, read the byte, capture the timestamp, set a flag or push to a ring buffer, and let the main loop or a lower-priority task do heavy processing, because an ISR delays every interrupt of equal or lower priority while it runs. (2) Never block: no delays, no busy-waiting on a flag, no waiting on another interrupt's result. (3) Always clear/acknowledge the interrupt source (often a write-1-to-clear on a pending register), or the NVIC immediately re-enters the ISR forever and hangs the system. (4) Treat data shared with the main code as volatile for visibility and protect read-modify-write access with a critical section or atomics, since volatile alone doesn't make count++ atomic. (5) Don't call non-reentrant or blocking functions (much of libc, anything using shared static state, malloc). The canonical structure is "ISR sets a flag / enqueues an event; main loop handles it."
Embedded Systems Fundamentals · Interview question
What are the rules for writing a good ISR?
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.