Reverse a linked list. Solve it iteratively and recursively, and discuss the tradeoffs.

The complete answer guide: what this question really tests, two example strong answers in different angles, the common weak answer rewritten, and the trap most candidates fall into. This is a technical deep-dive archetype question — see the broader pattern guide for the structural shape.

What this question is really testing

This question isn't primarily about whether you can reverse a linked list—most candidates who've made it to an onsite can eventually stumble through it. The interviewer is testing whether you understand the fundamental tradeoffs between different algorithmic approaches and, more importantly, whether you can articulate technical decisions clearly. They're looking for evidence that you think about space-time complexity instinctively, not as an afterthought. The binary read they're making: do you write code that works, or do you write code that works and demonstrate you understand why one approach might be preferred in production over another?

The recursive solution is particularly revealing because it separates candidates who've memorized patterns from those who genuinely understand the call stack. When you discuss tradeoffs, the interviewer is listening for whether you mention stack overflow risk, whether you understand tail call optimization (and that most languages don't implement it), and whether you'd actually choose the recursive solution in production code. Candidates who breeze through both implementations but can't explain when they'd use each in a real system send a signal that they've practiced for interviews but may not make sound architectural decisions under pressure.

Two strong answers, two angles

Angle A: Implementation-first with production context

"I'll start with the iterative solution since it's more production-ready. We maintain three pointers—previous, current, and next—and reverse the links as we traverse. Time complexity is O(n), space is O(1). The recursive approach is more elegant: we recurse to the end of the list, then reverse links as we unwind the call stack. Same time complexity, but O(n) space due to stack frames. In production, I'd default to iterative unless the list is guaranteed small—say, under 1000 nodes—because the recursive version risks stack overflow on deep lists, and that's a runtime failure that's hard to debug. The iterative version is also easier for junior engineers to maintain since the pointer manipulation is explicit rather than hidden in the call stack."

Angle B: Tradeoffs-first with concrete scenarios

"Both solutions are O(n) time, but they differ significantly in space and risk profile. Iterative uses O(1) space with three pointers doing in-place reversal. Recursive uses O(n) space because each call adds a stack frame—if you're reversing a list with 10,000 nodes, that's 10,000 frames deep. I'd choose iterative for any user-facing system where list size is unbounded, like processing transaction histories or event logs. Recursive only makes sense when you're certain about size constraints and value code readability—maybe in a configuration parser where lists are capped at 50 elements. The recursive version is also harder to debug in production because stack traces become massive, and you can't easily inspect intermediate state without a debugger."

The common weak answer

"The iterative solution uses a loop to reverse the pointers, and the recursive solution calls itself until it reaches the end. Both work fine. The iterative one is probably better because it uses less memory, but the recursive one is cleaner code."

This answer fails because it treats the tradeoff discussion as a checkbox rather than demonstrating genuine engineering judgment. Saying "both work fine" suggests you don't think about failure modes—the recursive solution absolutely does not work fine on a 100,000-node list in most languages. The phrase "cleaner code" is subjective and signals you're repeating something you heard rather than thinking critically. The interviewer reads this as: this person can implement algorithms from memory but won't catch production issues during code review. Reframe it: "The iterative solution is safer for production because it won't stack overflow regardless of list size, while the recursive solution will fail at runtime once you exceed stack depth limits—typically a few thousand nodes in Python or Java."

The one trap most candidates fall into

The trap is implementing both solutions correctly but discussing tradeoffs in purely theoretical terms—"O(n) space vs O(1) space"—without connecting it to real consequences. You'll say "the recursive version uses more memory" but fail to mention that this memory is stack memory, which has hard limits and causes immediate program termination when exceeded, unlike heap memory which degrades gracefully. Interviewers notice when you don't mention stack overflow by name, because it reveals you haven't debugged this class of bug in production.

The more subtle version of this trap is treating the recursive solution as academically interesting but practically useless. Strong candidates acknowledge that recursion does have legitimate uses—it's genuinely more readable for small, bounded inputs, and in languages with tail call optimization (like Scheme or with specific compiler flags), the space penalty disappears. If you dismiss recursion entirely, you signal that you optimize prematurely without considering context. The winning move is to show you'd choose iterative as the default, but you understand the specific conditions under which recursive becomes viable: guaranteed small input sizes, readability-critical code sections, or languages/compilers with TCO support.

Common questions

Other technical deep-dive questions