Memory ManagementCall StackDynamic Allocationjunior level

Stack and heap memory

the question

What is the difference between stack and heap memory? When would data use one rather than the other?

what they're testing: The interviewer is probing whether you can reason about data lifetime, allocation, and cleanup without relying on language-specific shortcuts.

a strong answer

Stack memory follows call order; heap memory is managed independently of a particular call. In a conventional implementation, each thread has a call stack of frames. A call creates a frame for execution state and local values; returning removes it in last-in, first-out order. Reclaiming a frame is cheap, but stack storage has limited capacity and follows the call's lifetime.

Heap storage is not reclaimed just because the allocating function returns. The program may free it explicitly, an ownership system may release it, or a garbage collector may reclaim it after it becomes unreachable. This suits data that must outlive a call or whose size does not fit a fixed frame. A stack value can hold a pointer or reference to heap data.

“Primitives use the stack and objects use the heap” is not a portable rule. Placement depends on the language and implementation. A primitive field can live inside a heap allocation, while escape analysis may keep some allocations on a stack or move a local value to the heap. The practical questions are lifetime, ownership, capacity, and reclamation.

Where people slip

the tempting wrong answer, and what's actually true

Stack memory is temporary, while heap memory is permanent.
Heap data can outlive a function call, but it is not permanent. It is reclaimed explicitly, through an ownership mechanism, or by garbage collection.
Primitives always go on the stack and objects always go on the heap.
Placement depends on the language and runtime, and even a primitive field can occupy heap storage as part of an object.
Heap allocation is always much slower than stack allocation.
Heap allocation usually involves more allocator or garbage-collector work, but “always much slower” is too absolute. The cost depends on the allocator, runtime, allocation pattern, and later reclamation.
A process has exactly one stack and one heap.
A multithreaded process commonly has a separate call stack for each thread. The number and organization of heaps depend on the runtime and allocator.

If they push further

What causes a stack overflow, and how is it different from running out of heap memory?

Deep recursion or oversized frames can exhaust a thread's stack. Heap exhaustion happens when the allocator or garbage collector cannot make enough space available for an allocation.

How does a garbage collector know that heap memory can be reclaimed?

A tracing collector starts from roots such as stack references and static fields, follows reachable objects, and treats unreachable objects as garbage.

Why not put everything on the stack?

Stack storage is reclaimed with its frame, so it cannot hold data that must remain valid after that call returns. Heap allocation supports longer lifetimes without tying the storage to one frame.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.