What they're testing
Whether you think about stack limits, and know JavaScript has no tail-call optimisation in practice.
The short answer~30 seconds
Recursion reads considerably better when the data is tree- or graph-shaped — tree traversal, backtracking, divide and conquer. Iteration is better when depth can be large, because each call costs a stack frame and the stack has a hard limit. In Java that's a few thousand frames by default; recursing over a 100,000-element linked list overflows where a loop wouldn't.
The long answer
Worth knowing: tail-call optimisation — turning the final recursive call into a jump so no new frame is needed — is NOT present in several common environments. The JVM doesn't do it; V8 has it in the ES6 spec but never shipped it. So "write it tail-recursive to be safe" is correct advice in Scala or Kotlin and wrong in Java or JavaScript.
When you want recursion's readability with iteration's safety, the standard move is managing the stack explicitly: a Deque used as a stack instead of the call stack. It's slightly more verbose and gives you full control over depth, and for traversing large graphs it's nearly always the right choice.
What they'll ask next
?Can recursion be dramatically slower?
Yes, when it recomputes the same subproblem repeatedly — naive recursive fib(n) is O(2ⁿ). Adding memoisation brings it to O(n), and that same step is the bridge from recursion to dynamic programming.
These lose points
- Recursing over user-supplied data with no depth limit. That's a denial-of-service hole.