Question 1

What is the difference between the stack and the heap?

Accepted Answer

Frame the answer as a comparison — that reads as clarity: What it stores: stack — function calls, parameters, locals, pointers; heap — objects, arrays, collections. Lifetime: a stack frame disappears the moment the function returns; a heap object lives as long as something references it (then the GC reclaims it). Speed: the stack is very fast (a pointer moves); heap allocation is more expensive. Size: the stack is bounded (a few MB) — exceed it and you get a StackOverflowError; the heap is large — fill it and you get out-of-memory. Close with a concrete example: "With const arr = [1,2,3], the variable arr holds an address on the stack while the three-element array itself lives on the heap. That's why arr.push(4) is allowed but arr = [] is a const error."

Question 2

Explain shallow vs deep copy. When do you need each?

Accepted Answer

Keep the definition + example + practical consequence structure. A shallow copy duplicates only the first level; references to nested objects are shared. JS: {...obj}, Object.assign({}, obj), arr.slice(). Kotlin: a data class's copy() (yes, that is shallow too). Dart: List.of(...), Map.of(...). A deep copy recreates the whole hierarchy: structuredClone(obj) in JS, a hand-written recursive function, or a JSON round-trip (which loses Date, Map, undefined and functions — mentioning that detail leaves a good impression). When to use which: a shallow copy is cheap and enough for flat structures; a deep copy is needed when you mutate nested objects (state management, undo/redo, test fixtures). Also mention the alternative: using immutable structures removes the problem entirely instead of copying around it.

Question 3

How does garbage collection work, and can you leak memory in a GC language?

Accepted Answer

Answer in two halves. How it works: modern GCs use reachability. The GC starts from roots (globals, live stack frames, CPU registers), walks the reference graph, marks everything reachable and frees the rest (mark-and-sweep). In practice it is generational: most objects die young, so the "young" region is collected often and cheaply while the "old" region is collected rarely. Unlike reference counting, this handles reference cycles without special cases. Can you leak: yes. The GC frees the unreachable, not the unneeded. If something you no longer need is still referenced, it stays forever. Concrete cases: an unbounded global cache (needs a size limit or LRU eviction), event listeners that are never removed, timers and stream subscriptions that are never cancelled, closures surviving after the component that owned them was torn down. Finish with diagnostics: take heap snapshots, diff two points in time, and follow the retainer chain to see which root is holding the object alive.

Question 4

How does the memory model differ between JavaScript, Kotlin and Dart?

Accepted Answer

Start with what is common, then move to the differences — that structure lands well. Common ground: all three are garbage collected, objects live on the heap in all three and are passed by reference, and none require manual deallocation. Differences: JavaScript — primitives (number, string, boolean, null, undefined, symbol, bigint) have value semantics; everything else is an object. There is no null safety in the type system; undefined and null are the main source of runtime errors (TypeScript moves that to compile time). Kotlin (JVM) — types like Int and Double are stored as JVM primitives where possible, but are boxed on the heap in generic and nullable contexts (Int? forces boxing — a valuable detail in performance discussions). Null safety is baked into the type system: String and String? are distinct types. Dart — in the model everything is an object, but int, double, bool and String are immutable and behave like values. It has sound null safety. The isolate model also matters: each isolate has its own heap and its own GC, isolates share no memory and communicate by messages — so there are no classic data races. Wrap up: "The practical consequence is the same everywhere — passing an object passes a reference, not a copy; the differences are mostly in null safety and the concurrency model."

Question 5

How do you deal with infinite or very deep recursion?

Accepted Answer

Start with the diagnosis: a StackOverflowError (Kotlin/JVM) or RangeError: Maximum call stack size exceeded (JS) means every call takes a stack frame and the stack is bounded. Then list the fixes: Check the base case — infinite recursion is usually just a bug or a stop condition that is never reached. Rewrite iteratively — linear recursion (walking a list, summing values) converts to a plain while loop; memory drops from O(d) to O(1). Use an explicit stack — for tree and graph traversal, keep an ArrayDeque/array on the heap instead of using the call stack. The heap is large, so the depth limit effectively disappears. Memoization — if the same sub-problem is recomputed, a cache cuts both time and call count. Tail recursion — Kotlin's tailrec keyword tells the compiler to turn it into a loop; you cannot rely on that in most JS runtimes or in Dart. The closing line of a strong answer: "As a rule, if the depth depends on user input, I don't rely on recursion — because I can't guarantee the depth."

Concept	JavaScript	Kotlin	Dart
Primitive values	number, string, boolean, null, undefined, symbol, bigint — value semantics	Int, Double, Boolean etc. — on the stack when the JVM can, boxed on the heap otherwise	Technically everything is an object, but int/double/bool/String are immutable and behave like values
Objects	Object, Array, Map, Set, functions — heap, reference semantics	All class instances live on the heap, reference semantics	All objects live on the heap, reference semantics
Null safety	None — `undefined`/`null` blow up at runtime	In the type system: `String` vs `String?`, `?.`, `?:`, checked by the compiler	Sound null safety: `String` vs `String?`, `!`, `??`, checked by the compiler
Shallow copy	`{...obj}`, `[...arr]`; `structuredClone()` for a deep copy	`copy()` on a `data class` (shallow!), `toList()`	`List.of(x)`, `Map.of(m)`, `{...map}`
Garbage collection	Generational, mark-and-sweep (the V8 engine)	The JVM's GC — G1, ZGC and others	Generational; each isolate has its own GC

Memory model: stack and heap

📚 Sources and documentation