How would a build system decide the order to build targets?

A strong answer

A strong candidate frames How would a build system decide the order to build targets? around the exact memory layout, compiler semantics, and hardware execution model covered in Topological sort. Model dependencies as a DAG, produce a topological order, detect cycles, and extend it to parallel and incremental builds.

Many problems come with dependencies: a course must be taken after its prerequisites, a source file compiled after the headers it includes, a package installed after the packages it imports, a spreadsheet cell computed after the cells its formula reads. Model each task as a vertex and each "must come before" as a directed edge from the earlier task to the later one. The question is then: in what order can the vertices be listed so that every edge points forward? Such a list is a topological order.

It exists exactly when the graph has no directed cycle. With a cycle, each of its tasks would have to come before the next one all the way around, which is impossible. A directed graph without cycles is called a directed acyclic graph, or DAG, and every DAG has at least one topological order, usually many.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Explain what a topological order is and when one exists.
• Mastery of core invariant: Compute one with Kahn's algorithm, using in-degrees and a queue.
• Mastery of core invariant: Compute one with depth-first search by reversing the finish order, and detect impossible orders.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.