Question 1

How does Dart's event loop work?

Accepted Answer

Build the answer from three sentences, then expand. First: a Dart isolate is single-threaded — only one piece of code runs at a time; the event loop creates the illusion of concurrency. Second: there are two queues — the microtask queue (short internal work: scheduleMicrotask, Future.microtask, then on a completed future) and the event queue (timers, I/O, network, user events, isolate messages). Third, the crucial one: the microtask queue is drained completely before a single item is taken from the event queue. Then walk the loop: the current synchronous code runs to the end → the microtask queue drains (including microtasks added during the drain) → one item is taken from the event queue → the microtask queue drains again → and so on. Always add the two consequences, because they are why the question is asked: A long synchronous computation drains no queue — the whole program freezes. In Flutter, that is dropped frames. An unbounded microtask chain starves the event queue — timers and I/O never run. As a closing line, bridge to isolates: real parallelism requires a separate isolate, because each isolate has its own event loop and its own memory.

Question 2

What does this print? print('A'); Future(() => print('B')); Future.microtask(() => print('C')); print('D');

Accepted Answer

The answer: A, D, C, B. But what matters in an interview is not the result, it is how you derive it. Think out loud: 1. print('A') is synchronous → printed immediately. 2. Future(() => print('B')) goes onto the event queue (a zero-duration timer underneath). It does not run yet. 3. Future.microtask(() => print('C')) goes onto the microtask queue. 4. print('D') is synchronous → printed immediately. 5. Synchronous code is done. Now the microtask queue drains → C. 6. The microtask queue is empty, so at last the event queue gets a turn → B. Say the rule out loud: "the event queue is not touched until the microtask queue is completely empty" — that sentence is the key to every puzzle of this shape. Be ready if they extend it: Future.delayed(Duration.zero, ...) sits in the same queue as B (a timer), while Future.value(1).then(...) sits in the same queue as C (a microtask). And one trap: the part of an async function before its first await is synchronous, so it prints together with A and D.

Question 3

What is the difference between Future.microtask, Future(() {}) and Future.delayed(Duration.zero), and when do you pick each?

Accepted Answer

First separate them by queue: Future.microtask(fn) → the microtask queue. Runs as soon as the current synchronous code ends, before any timer or I/O. Future(fn) → the event queue; it creates a zero-duration timer internally. Future.delayed(Duration.zero, fn) → practically the same — also a timer. Then give the selection logic, which makes the answer practical: Future.microtask — short internal work that must run right after the current synchronous block without letting other events in first. Rare; most code never needs it. Future(fn) / Future.delayed(zero) — deferring work and giving the event loop room to breathe: other timers and I/O callbacks get to run. In a UI context it means "do this after the current frame". End with an important warning: none of the three gives parallelism — they all run on the same thread. Wrapping heavy CPU work in Future(...) solves nothing; it merely postpones the block by one step. For CPU work the only right answer is an isolate. One extra nuance signals seniority: overusing Future.microtask is dangerous precisely because microtasks have absolute priority — long or repeating work inside them starves the event queue.

Question 4

Why does a long synchronous computation block the whole program, and how do you fix it?

Accepted Answer

Explain the mechanism: the event loop takes work off a queue and runs it to completion — there is no preemption. While your synchronous loop runs, the event loop is simply not in control: no microtask, no timer, no I/O callback and no next UI frame can run. In Flutter the effect is immediately visible — any synchronous work over the 16 ms frame budget drops a frame, and a long one freezes the screen. Then explicitly name the fix that does not work, because interviewers probe for it: making the function async or wrapping it in Future(...) does not help. The async keyword parallelises nothing; the computation still runs on the same thread, just one step later. await Future.delayed(Duration.zero) only lets already-queued work in. The fixes that do work: 1. An isolate — the real answer. Isolate.run(() => heavyWork()) (or compute in Flutter) moves the computation to its own memory and its own event loop, leaving the main thread free. JSON parsing, image processing, cryptography, sorting a huge list — all belong here. 2. Chunking the work — yield with await Future.delayed(Duration.zero) every N steps. Simple, with none of an isolate's overhead, but it lengthens total runtime and keeps the work on the main thread. 3. Changing the algorithm — often the best answer: do not do the unnecessary work at all, cache the result, compute lazily, or move it to the server. A closing sentence lands well: async fixes waiting, an isolate fixes computing — I first decide which category the problem is in, and only then pick the tool.

Question 5

What is microtask starvation and how does it arise in real code?

Accepted Answer

Definition: the microtask queue has absolute priority over the event queue, and the event queue is not touched until it is empty. If microtasks keep scheduling more microtasks, the queue never empties — timers, network callbacks, I/O and UI frames wait forever. That is starvation. Give concrete ways it arises in real code, because that is what makes the answer convincing: Recursive scheduleMicrotask — the "process the next item, then reschedule myself" pattern. Invisible on a small list, it freezes the app on a large one. An unbounded then chain on completed futures — for instance a retry loop starting from Future.value() that keeps appending then with no real waiting; the whole chain runs in microtasks. A loop built on synchronously-completing Completers — if the cache always hits, the expected async pause never happens. Describe the symptom too: the app "freezes" but the CPU profile shows no single long function — the work is spread across thousands of tiny microtasks. Timers lag and animations stop. It looks different from ordinary blocking, which makes it harder to track down. The fixes: move iterative work from the microtask queue to the event queue (Future(...) or Timer.run) so other events get a turn after each step; batch the work and yield to the event queue between batches; and if the work is heavy, move it to an isolate. End with the rule: microtasks are only for short, finite work that does not reschedule itself; repeating or long work belongs on the event queue.

How you write it	Which queue	When to use it
`scheduleMicrotask(fn)`	Microtask	Short internal work that must run right after the current synchronous block
`Future.microtask(fn)`	Microtask	The same, but when you need the result as a `Future`
`completedFuture.then(fn)`	Microtask	Ordinary chaining — not a choice you make, it is how the language works
`Future(fn)` / `Future.delayed(Duration.zero, fn)`	Event queue (timer)	Deferring work and giving other events a turn
`Timer(d, fn)` / `Timer.run(fn)`	Event queue	Time-based work
I/O, network, isolate messages	Event queue	External sources — the system enqueues them, not you

The event loop and microtask queue

📚 Sources and documentation