Describe the Dart event loop and queue execution order

What's really being asked

The interviewer is checking whether you understand Dart's single-threaded concurrency model at a deep level. They want to see that you know an isolate runs one event loop with two distinct queues, and that you can predict which asynchronous work runs first based on queue rules rather than call order alone.

The full answer

First, state that every Dart isolate has exactly one event loop and two queues, the microtask queue and the event queue. Second, explain the execution rule: after any synchronous code completes, the loop always drains the entire microtask queue before it processes even a single event from the event queue. Third, clarify that scheduleMicrotask adds work to the microtask queue, while Future and timers add work to the event queue. Fourth, describe the cycle: drain all microtasks, process one event, then repeat. Fifth, note that microtasks are intended for small internal asynchronous completions that must happen before the next event, while events handle I/O, timers, and user interaction.

The mistakes people make

A critical red flag is claiming that tasks run in simple call order without respecting queue boundaries, which would mean a Future called before a microtask runs first. Another mistake is conflating microtasks with events or saying Future.value always goes to the event queue. Some candidates incorrectly bring up threads, thread pools, or the JavaScript event loop without acknowledging Dart's stricter microtask-draining semantics. Saying the queues have equal priority is also wrong.

What usually comes next

The interviewer may ask what happens if a microtask recursively schedules another microtask. The correct answer is that the loop continues draining microtasks until the queue is empty, which can starve the event queue. They might ask where Future.delayed, Stream listeners, or user gestures land, which is always the event queue. They could also ask how this relates to the build method in Flutter, where setState triggers a microtask-like frame callback but the principle of queue priority still matters for post-frame callbacks.

A concrete example

Imagine a main function that prints sync start, then calls scheduleMicrotask with a callback printing microtask A, then calls Future with a callback printing event A, then calls scheduleMicrotask again with a callback printing microtask B. The output order is sync start, microtask A, microtask B, event A. This occurs because both scheduleMicrotask calls populate the microtask queue, and the event loop empties that entire queue before pulling the Future callback from the event queue. If the candidate cannot produce this ordering, they do not understand the queue priority.