Top 60 Dart Interview Questions (2026)

Dart is a client-optimized, statically typed programming language from Google, first released in 2011. It compiles to native machine code for mobile and desktop through ahead-of-time compilation, and to JavaScript or WebAssembly for the web, so one codebase runs across every platform.

Its popularity comes almost entirely from Flutter: teams write UI once and ship to iOS, Android, web, and desktop. Stateful hot reload during development and ahead-of-time compilation for release give a fast feedback loop while you build and quick startup for users.

var declares a variable whose type is inferred and whose value can change. final holds a value set exactly once, at runtime, and can't be reassigned. const is a compile-time constant: its value must be known when the code compiles, and it's deeply immutable.

The quick rule: use final for values fixed after one assignment, const for values baked in at compile time, and var only when you genuinely need to reassign.

Sound null safety means types are non-nullable by default: a String can't hold null, and to allow null you write String?. The compiler tracks nullability and rejects code that might dereference null, so a whole class of runtime null errors becomes a compile error instead.

The word sound matters: if the type says non-nullable, the runtime guarantees it, no escape hatches from mixed legacy code. This is the single most asked Dart topic in interviews.

? in a type (String?) makes it nullable. ?? gives a default: a ?? b returns a if non-null, else b. ?. calls a member only if the target is non-null, otherwise the whole expression is null. ! asserts a nullable value is actually non-null and throws if it's wrong.

The everyday types are int and double (both num), String, bool, and the collections List, Set, and Map. There's also the special Object (base of everything except Null), dynamic (opts out of static checks), and Null.

One detail interviewers like: int and double are both subtypes of num, so you can type a variable as num when it might be either. And there's no separate char type; a single character is just a one-length String.

A List is an ordered collection that allows duplicates and indexes by position. A Set is an unordered collection of unique values with fast membership tests. A Map stores key-value pairs with unique keys and fast lookup by key.

Pick by need: order and duplicates mean List, uniqueness means Set, lookup by a key means Map.

A Dart function declares a return type, a name, and parameters, then a body in braces. When the body is a single expression, arrow syntax (=> expr) replaces { return expr; } with a shorter form.

Functions are first-class in Dart: you can store them in variables, pass them as arguments, and return them, which is what makes callbacks and higher-order functions natural.

Positional parameters come in order. Optional positional parameters go in square brackets and can be omitted. Named parameters go in curly braces and are passed by name, which reads clearly at the call site. A named parameter marked required must be supplied.

Named parameters are everywhere in Flutter widget constructors, so the question expects fluency here.

You embed an expression in a string with $name for a simple variable, or ${expression} for anything more complex like a method call or arithmetic. It's the readable way to build strings in Dart, and it beats gluing pieces together with the + operator, which reads worse and is easy to get wrong.

Dart also has adjacent string literals (two quoted strings next to each other join automatically) and triple-quoted strings for multi-line text.

A class groups fields and methods. The constructor initializes fields, and Dart's shorthand this.field syntax assigns a parameter straight to a field without a body. Every class has a default no-argument constructor unless you define your own.

A named constructor gives a class more than one way to build an instance, using ClassName.name syntax. It's how Dart works around the lack of constructor overloading, and it documents intent at the call site.

You'll see this constantly in Flutter and core libraries, like Point.origin() or DateTime.utc(...).

A class extends exactly one superclass, inheriting its fields and methods. You call the parent's constructor with super, and override a method by writing it again with the @override annotation. Dart has single inheritance, and mixins fill the gap when you need to share code across unrelated classes.

A getter computes a value that callers read like a field (obj.area), and a setter intercepts assignment (obj.width = 5). You define them with get and set, so a class can expose a clean property interface while hiding logic or validation behind it.

The point is evolution: you can a plain field and later swap in a getter or setter without changing a single caller comes first.

The cascade lets you run several operations on the same object without repeating the variable. obj..a()..b()..c = 1 calls a and b and sets c, then returns the object itself, which is handy when you're configuring one thing.

The catch worth mentioning: a cascade returns the original object, not the result of the last call, so it's for side effects, not for chaining transformations.

Inside a list, set, or map literal, Dart lets you use if and for directly to build the collection conditionally or from another iterable. It replaces awkward temporary lists and reads cleanly, especially in Flutter widget trees.

The spread operator inserts all the elements of one collection directly into another literal, so you build a combined list, set, or map in one expression. Writing ...list unpacks a list inline, and the null-aware form ...?list does the same but safely skips the whole thing when the source is null.

A Future represents a value that isn't ready yet, like the result of a network call. An async function returns a Future, and await pauses that function until the Future completes, then hands back the value. The event loop keeps running other work during the wait, so nothing blocks.

The mental model: async/await is sequential-looking code that's actually non-blocking underneath.

A typedef gives a name to a type, most usefully a function type. Instead of writing bool Function(int) everywhere, you name it and reuse the name, which makes signatures readable. In modern Dart it also aliases any type, not just functions.

main is the entry point every Dart program runs first. It returns void (or Future<void> if it awaits) and can take an optional List<String> for command-line arguments. Execution starts here, and the app ends when main and any pending async work finish.

In a Flutter app, main is where you call runApp to boot the widget tree, so it's the one function you're guaranteed to write.

??= assigns a value to a variable only if that variable is currently null. a ??= b leaves a alone when it already has a value, and sets it to b otherwise. It's the one-line way to lazily set a default without an if check.

It pairs with nullable fields and caches: assign the computed value the first time, then reuse it.

An enum defines a fixed set of named values, like Status.active. Dart's enhanced enums (from Dart 2.17) go further: an enum can have fields, a constructor, and methods, so each value carries data and behavior instead of just a name.

A Future delivers a single asynchronous value once, then it's done. A Stream delivers a sequence of asynchronous events over time, and you listen to it, reacting to each one. Think Future for a one-off request and Stream for an ongoing feed.

You consume a Future with await; you consume a Stream with await for in an async function, or by calling .listen with a callback.

A mixin is a bundle of methods and fields you add to a class with the with keyword, sharing behavior across classes that don't share a superclass. Because Dart allows only single inheritance, mixins are how you compose reusable behavior without deep class trees.

The difference: extends is an is-a relationship with one parent, while with layers in capabilities from several mixins. A class can mix in many, and their order matters because later mixins can override earlier ones.

An abstract class can't be instantiated and can hold both concrete and abstract methods, so it's for sharing partial implementation. Dart has no separate interface keyword: every class defines an implicit interface, and any class can implement another with the implements keyword, which forces it to provide every member.

So the choice is extends (inherit implementation) versus implements (adopt the contract only, write everything yourself).

A factory constructor is declared with the factory keyword and, unlike a normal constructor, doesn't have to create a fresh instance. It can return a cached object, an instance of a subtype, or an object built from complex logic. That flexibility is what enables caching, singletons, and parsing from JSON.

A const constructor lets you create compile-time constant instances of a class, as long as all fields are final. Two const objects built with the same arguments are the identical object in memory, not just equal, which saves allocations.

In Flutter this matters for performance: a const widget is created once and skipped during rebuilds, so const constructors are a real optimization, not just style.

Dart handles failures with try, catch, and finally. The catch clause can take one argument (the error) or two (the error and its stack trace), and an on clause narrows to a specific exception type so you handle each kind differently. You raise a failure with throw, and any finally block always runs for cleanup, whether or not something threw.

Dart splits failures into Error (bugs you shouldn't catch, like a failed assertion) and Exception (recoverable conditions). Catch Exceptions; let Errors surface so you fix the bug.

Generics let a class or function work over a type parameter, so List<int> and List<String> reuse one implementation with type safety. You declare a placeholder like <T> and the compiler checks usage, which catches type errors at compile time instead of runtime.

You can bound a type parameter with extends to require a capability, like <T extends num> so the code can do arithmetic on T.

With async/await you wrap the await in a normal try/catch, which reads cleanly. Without await, you attach .catchError to the Future, or pass onError to .then. A Future that fails and has no handler surfaces as an unhandled async error.

The practical guidance: prefer try/catch around await for readable flow, and always handle the failure path so errors don't vanish silently.

map transforms each element, where filters, reduce and fold combine to a single value, any and every test conditions, and expand flattens. These are lazy on an Iterable, so nothing runs until you materialize with toList or iterate.

Reaching for these instead of manual loops is a strong fluency signal, and knowing they're lazy explains why you sometimes need a trailing .toList().

By default == compares identity: two objects are equal only if they're the same instance. To get value equality you override == and hashCode together, comparing the fields that define the object and hashing the same fields.

The rule interviewers check: if you override ==, you must override hashCode consistently, or the object misbehaves in Sets and Map keys. Many teams generate both with a package like equatable to avoid mistakes.

A record is a lightweight, immutable bundle of values, with positional and named fields, written in parentheses like (1, name: 'Asha'). It's the clean way to return multiple values from a function without defining a class or abusing a List.

Records have value equality built in, so two records with the same fields are equal, and you can destructure them with patterns.

Patterns let you destructure and test values in one step, in switch cases, if-case statements, and variable declarations. A switch can match on shape, extract fields, and add guards with when, replacing chains of type checks and casts.

Combined with sealed classes, switch becomes exhaustive: the compiler errors if you forget a case, which is the safety win teams care about.

A sealed class can be extended only within its own file, so the compiler knows the complete set of subtypes. That completeness makes switch statements exhaustive: cover every subtype or get a compile error, which catches the bug where you add a new case and forget to handle it.

Sealed classes pair naturally with pattern matching to model a closed set of states, like the results of an operation.

An extension adds methods or getters to an existing type you don't own, like String or int, without subclassing or wrapping it. The compiler resolves the extension statically, so it feels like the type gained a new method.

Use them to add small helpers to library types cleanly. The limitation to name: extensions are resolved by static type, so they don't participate in dynamic dispatch.

A final list can't be reassigned, but its contents can still change: you can add to it. A const list is deeply immutable: the reference is fixed and any attempt to mutate it throws at runtime. const also canonicalizes, so two identical const lists are the same object.

So final protects the variable; const protects the whole structure.

is tests whether an object has a type and returns a bool; is! is its negation. as casts an object to a type and throws if the object isn't that type. There's no as? operator; for a safe cast you combine is with a check or use pattern matching.

A useful detail: after a successful is check, Dart promotes the variable to that type inside the block, so you don't need a separate cast.

late declares a non-nullable variable that you promise to initialize before use, deferring the assignment. It's for values you can't set at declaration but that are never legitimately null, like a field set in a Flutter initState. Accessing a late variable before it's assigned throws.

late also enables lazy initialization: late final x = expensive() runs expensive() only on first access.

Dart 3 added modifiers that constrain how a class can be used. final blocks both extending and implementing it outside its library. base forces subtypes to extend (not implement) so they inherit the implementation. interface allows implementing but not extending. They let a library author control its contract.

The dart:convert library gives jsonEncode to turn a Map or List into a JSON string and jsonDecode to parse a string back into Dart objects. jsonDecode returns dynamic (usually Map<String, dynamic>), so you map it into a typed model, commonly with a fromJson factory and a toJson method.

For larger apps, code generation (json_serializable) writes those fromJson and toJson methods for you, which avoids hand-written mapping bugs.

An isolate is Dart's unit of concurrency: its own memory heap and its own event loop, running independently. Unlike threads, isolates share no memory, so there are no locks and no data races. They communicate only by passing messages over ports, and the message is copied.

This model is why Dart avoids a whole category of concurrency bugs, at the cost of not sharing objects directly. For heavy CPU work you spawn an isolate; for a one-off computation, Isolate.run is the short path.

Each isolate runs one thread with an event loop and two queues: a microtask queue and an event queue. The loop drains all microtasks first, then handles one event (like a completed I/O or a timer), then drains microtasks again. Because it's single-threaded, only one piece of Dart code runs at a time.

This is why a long synchronous computation freezes the UI: it hogs the loop. The fix is to break work up, await I/O, or move CPU work to another isolate.

Use async/await for I/O-bound waiting: network calls, file reads, timers. The work isn't running on the CPU, it's waiting, and the event loop stays free during the await, so one isolate handles thousands of concurrent I/O operations fine.

Reach for an isolate when the work is CPU-bound: parsing a huge JSON payload, image processing, heavy computation. That work would block the single event loop and drop frames, so you move it to a separate isolate that runs in parallel.

Dart runs two ways. During development it uses a just-in-time compiler, which enables stateful hot reload: you change code and see it live without losing app state. For release it uses ahead-of-time compilation to native machine code, giving fast startup and predictable performance with no runtime compilation.

So you get the best of both: a fast edit loop while building, and a lean native binary when you ship. On the web, Dart instead compiles to JavaScript or WebAssembly.

Dart uses a generational garbage collector. Most objects die young, so a fast young-space collector (a copying scavenger) reclaims short-lived objects cheaply, and survivors get promoted to old space, which a slower mark-sweep collector handles less often. The collector runs per isolate, and because isolates share no memory, collection never needs to stop other isolates.

The practical takeaway for UI work: Dart's GC is tuned to run in small steps that fit between frames, which is why Flutter apps stay smooth despite automatic memory management.

A StreamController is the object you use to create a Stream and push events into it manually with add. A single-subscription stream allows exactly one listener and is the default, right for a sequence consumed once, like reading a file. A broadcast stream allows many simultaneous listeners, right for events like user actions that several parts of the app react to.

The gotcha to name: listening to a single-subscription stream twice throws, and a broadcast stream doesn't buffer events for late listeners, so they miss anything emitted before they subscribed.

Dart generics are covariant by default: List<int> is treated as a subtype of List<num> because int is a subtype of num. That's convenient but not fully sound for writes, so Dart inserts a runtime check on assignment into a covariantly-typed collection, which can throw if you store the wrong type.

The senior point: covariance is a deliberate ergonomics-versus-soundness trade-off, and the runtime check is how Dart keeps it safe. You can also mark a parameter covariant explicitly to override a method with a narrower type.

dart:ffi (foreign function interface) lets Dart call directly into native C libraries: you load a shared library, describe the function signatures with typed bindings, and invoke them with low overhead. It's how you reuse an existing C or C++ library, or call platform APIs, without a plugin channel.

Reach for it when you need a mature native library or maximum performance for a specific routine. The cost is manual memory management across the boundary and platform-specific builds, so it's a targeted tool, not a default.

A zone is an execution context that can intercept and control asynchronous callbacks, uncaught errors, and even print. runZonedGuarded wraps code so any uncaught async error inside it lands in one handler, which is how apps install a top-level error reporter that catches failures from timers and futures that a plain try/catch would miss.

You rarely create zones by hand, but understanding them explains how error-tracking and testing frameworks capture async errors globally.

When you build two const values with the same type and arguments, Dart creates only one object and hands out the same instance everywhere, which is canonicalization. That saves allocations and makes identity comparisons cheap.

In Flutter this is a real optimization: a const widget is canonicalized and its element can be reused across rebuilds instead of reconstructed, so marking widgets const where possible cuts work in the build phase.

Even with garbage collection, memory grows when something keeps references alive: a Stream subscription that's never cancelled, a listener or timer that outlives its owner, a global cache that only grows, or a closure capturing a large object. In Flutter the classic case is not cancelling subscriptions and controllers in dispose.

Diagnosis: watch memory in DevTools, take heap snapshots and diff them over time to find the growing allocation, and trace retaining paths to see what holds the reference. The fix is almost always cancelling subscriptions, disposing controllers, and bounding caches.

Incrementally, from the bottom up. Dart supported a mixed mode where null-safe and legacy libraries coexist, so you migrate leaf packages first, then packages that depend on them, keeping the app runnable throughout. The dart migrate tool proposes nullability annotations you review rather than accept blindly.

The judgment interviewers probe: resist sprinkling ! to silence the analyzer, because that reintroduces exactly the runtime crashes null safety prevents. Prefer real nullable types, ?? defaults, and required parameters.

on restricts which classes can use a mixin: mixin M on Base means only classes that extend Base can mix in M. In return, the mixin gets to call members of Base and use super to reach the superclass's implementation. It's how a mixin declares a dependency on the behavior it augments.

A Completer gives you a Future whose completion you control by hand: you hold the Completer, hand out its .future, and later call complete(value) or completeError(error). It bridges callback-based or event-based APIs that don't already return Futures into the async/await world.

The rule to state: complete a Completer exactly once, and guard against completing an already-completed one. When an API already returns a Future, you don't need a Completer, so reaching for one on plain async code is a smell.

The test package is the standard: test files end in _test.dart, test() holds a single case with expect() assertions, and group() organizes related cases. setUp and tearDown handle per-test fixtures. You run everything with dart test, and mocktail or mockito fake out external boundaries.

A strong answer covers testing behavior over implementation, using async matchers like expectLater for streams and futures, and isolating I/O so tests stay fast and deterministic.

Dart lets a class define what operators like +, -, ==, [], and < mean for its instances by declaring them with the operator keyword. This is how value types read naturally: adding two Money objects or comparing two Vectors looks like arithmetic instead of method calls.

The discipline to mention: overload only when the operator's meaning is obvious, and keep == consistent with hashCode. A surprising + is worse than a plain method.

A generator function produces a sequence lazily with yield. sync* returns an Iterable and computes values on demand as you iterate. async* returns a Stream and can await between yields, so it emits values over time. yield* delegates to another generator, flattening it in.

Use sync* for lazy synchronous sequences and async* when producing a Stream from asynchronous steps, like paging through an API.

Clarify first: bounded size, time-based expiry, or both? Then model an entry as a value plus an insertion timestamp, stored in a Map keyed by the request. On read, check whether the entry exists and is still within its TTL; if it's stale, evict and treat it as a miss. For size bounds, track access order and evict the least-recently-used entry when full.

The closing step is the operational edges: making it generic over key and value types, guarding concurrent access if it's touched from multiple async paths, and a Timer or lazy check to purge expired entries. Structuring the answer clarify, data model, read/write paths, eviction is what the question checks.

Future.wait takes a list of Futures, starts them all, and returns a single Future that completes with the list of results once every one finishes. It's how you fan out independent I/O and wait for the whole batch instead of awaiting each in series.

The behavior to name: by default Future.wait fails fast, if any Future throws, the returned Future errors, though the others keep running. When you need every result including failures, use eagerError control or wrap each Future so one failure doesn't sink the batch.

Annotations are metadata you attach with @, like @override, @deprecated, and @pragma. Some are advisory to the analyzer (@override flags a typo in a method name), and custom annotations become inputs to code generation, where a build step reads them and emits code.

That's the pattern behind json_serializable and similar tools: you annotate a class, and a generator produces the boilerplate. Annotations themselves do nothing at runtime unless a tool or reflection reads them.