Recursion Interview Problems - Symlink Cycle StackOverflow

Recursion shows up in almost every senior engineering interview. It's not because interviewers love brain teasers — it's because recursion is the natural language of problems that have self-similar structure: file systems, tree traversals, divide-and-conquer algorithms, and dynamic programming all lean on it. Companies like Google, Meta, and Amazon use recursion problems specifically because they reveal whether a candidate can break a complex problem into a repeatable, trustworthy unit of work.

The real problem most developers have with recursion isn't the concept — it's pattern blindness. They see a new problem and freeze because it looks unique, when in reality it fits one of four classic shapes. Once you can spot the shape, the solution almost writes itself. The mental shift is from 'how do I solve this whole thing?' to 'what's the one small thing I need to do right now, and can I trust the rest to a recursive call?'

By the end of this article you'll be able to identify which recursion pattern a problem belongs to, write clean base cases that don't blow the stack, trace recursive calls mentally without getting lost, and confidently explain your reasoning to an interviewer — which is half the battle.

The Four Recursion Patterns Every Interviewer Tests

Every recursion problem in an interview maps to one of four patterns. Learning to spot the pattern is more valuable than memorising solutions.

Pattern 1 — Linear Recursion: One recursive call per invocation. Classic examples: factorial, sum of a list, reversing a string. The call stack grows linearly with input size.

Pattern 2 — Binary/Branching Recursion: Two recursive calls per invocation. Fibonacci, binary tree traversal, merge sort. The call tree fans out and this is where O(2^n) danger lives if you're not careful.

Pattern 3 — Tail Recursion: The recursive call is the very last operation. Many languages and compilers can optimise this into a loop, killing stack overhead. Java doesn't do this automatically — but interviewers love asking about it.

Pattern 4 — Divide and Conquer: Split the problem into independent halves, recurse on each, then combine results. Merge sort and quicksort live here.

Knowing which pattern you're in tells you immediately what your time complexity will be and whether you need memoisation. A binary recursion with overlapping subproblems screams 'add a cache'. A linear recursion on a million-element list screams 'convert to iteration'.

package io.thecodeforge.recursion;

/**
 * Production-grade examples of the 4 recursion patterns.
 */
public class RecursionPatterns {

    // PATTERN 1: Linear Recursion (Summing elements)
    public static int sumOfList(int[] numbers, int currentIndex) {
        if (currentIndex == numbers.length) return 0;
        return numbers[currentIndex] + sumOfList(numbers, currentIndex + 1);
    }

    // PATTERN 2: Binary Recursion (Naive Fibonacci - O(2^n))
    public static int fibonacciNaive(int position) {
        if (position <= 1) return position;
        return fibonacciNaive(position - 1) + fibonacciNaive(position - 2);
    }

    // PATTERN 3: Tail Recursion (Factorial with Accumulator)
    public static int factorialTailRecursive(int number, int accumulator) {
        if (number == 0) return accumulator;
        return factorialTailRecursive(number - 1, accumulator * number);
    }

    // PATTERN 4: Divide and Conquer (Recursive Binary Search)
    public static int binarySearch(int[] sortedNumbers, int target, int low, int high) {
        if (low > high) return -1;
        int mid = low + (high - low) / 2;
        if (sortedNumbers[mid] == target) return mid;
        return (sortedNumbers[mid] < target) 
            ? binarySearch(sortedNumbers, target, mid + 1, high) 
            : binarySearch(sortedNumbers, target, low, mid - 1);
    }
}

Solving the Classic Tree Problems Interviewers Love

Binary tree problems are the most common recursion questions in FAANG-style interviews. They feel hard until you realise every single one follows the same three-line mental model: handle the null base case, do something at this node, recurse left and right.

The secret is trusting your recursive calls. The biggest mistake candidates make is trying to mentally trace the entire recursion in their head. You don't need to. You only need to answer: 'If my recursive call correctly returns the answer for a subtree, what do I do with it at this node?'

Take finding the maximum depth of a binary tree. At each node, you trust that maxDepth(node.left) gives you the correct depth of the left subtree and maxDepth(node.right) gives you the right. Your only job at this node is: 1 + max(leftDepth, rightDepth). That's it. The whole algorithm is that one insight.

package io.thecodeforge.recursion;

public class BinaryTreeRecursion {
    static class TreeNode {
        int val; TreeNode left, right;
        TreeNode(int x) { val = x; }
    }

    // LeetCode #104: Maximum Depth of Binary Tree
    public int maxDepth(TreeNode root) {
        if (root == null) return 0;
        return 1 + Math.max(maxDepth(root.left), maxDepth(root.right));
    }

    // LeetCode #100: Same Tree
    public boolean isSameTree(TreeNode p, TreeNode q) {
        if (p == null && q == null) return true;
        if (p == null || q == null || p.val != q.val) return false;
        return isSameTree(p.left, q.left) && isSameTree(p.right, q.right);
    }
}

Memoisation — Turning Exponential Recursion into Linear

Naive binary recursion on problems with overlapping subproblems is a performance disaster. fibonacciNaive(40) makes over a billion function calls. The fix — memoisation — is one of the highest-value techniques you can demonstrate in an interview because it shows you understand both recursion and dynamic programming.

The insight is simple: if you've already computed the answer for a subproblem, cache it. On the next call with the same input, return the cached answer instantly instead of recomputing from scratch.

package io.thecodeforge.recursion;
import java.util.HashMap;
import java.util.Map;

public class MemoizedRecursion {
    private Map<Integer, Integer> memo = new HashMap<>();

    // Climbing Stairs (LeetCode #70) - O(n) Time, O(n) Space
    public int climbStairs(int n) {
        if (n <= 2) return n;
        if (memo.containsKey(n)) return memo.get(n);
        
        int result = climbStairs(n - 1) + climbStairs(n - 2);
        memo.put(n, result);
        return result;
    }
}

Backtracking — Recursion That Knows How to Undo Its Mistakes

Backtracking is recursion with a safety net. It explores a path, and if that path leads nowhere, it undoes the last step and tries another direction. Think of it like solving a maze by always drawing on the walls with chalk — if you hit a dead end, you erase back to the last junction and try a different turn.

Backtracking shows up in: generating all permutations, solving Sudoku, the N-Queens problem, and finding all subsets of a set. These are problems where you're building a solution piece-by-piece and some partial solutions turn out to be invalid.

package io.thecodeforge.recursion;
import java.util.*;

public class BacktrackingProblems {
    // Subsets (LeetCode #78)
    public List<List<Integer>> subsets(int[] nums) {
        List<List<Integer>> list = new ArrayList<>();
        backtrack(list, new ArrayList<>(), nums, 0);
        return list;
    }

    private void backtrack(List<List<Integer>> list, List<Integer> tempList, int [] nums, int start){
        list.add(new ArrayList<>(tempList)); // Capture snapshot
        for(int i = start; i < nums.length; i++){
            tempList.add(nums[i]);
            backtrack(list, tempList, nums, i + 1);
            tempList.remove(tempList.size() - 1); // The Backtrack Step
        }
    }
}

Recursion vs Iteration: When to Use Which in Production

Recursion is elegant for problems that mirror the data structure (trees, graphs). But production systems often ban recursion for anything that handles user input because of stack safety. Iteration with an explicit stack (or queue) gives you control over memory and avoids the JVM's fixed stack size.

In interviews, you can start with recursion for clarity, then mention you'd convert to iteration if depth is a concern. That's senior-level thinking.

package io.thecodeforge.recursion;

import java.util.*;

public class RecursionVsIteration {
    // Recursive DFS on a tree
    public void dfsRecursive(TreeNode node) {
        if (node == null) return;
        System.out.println(node.val);
        dfsRecursive(node.left);
        dfsRecursive(node.right);
    }

    // Iterative DFS (uses explicit stack)
    public void dfsIterative(TreeNode root) {
        if (root == null) return;
        Stack<TreeNode> stack = new Stack<>();
        stack.push(root);
        while (!stack.isEmpty()) {
            TreeNode node = stack.pop();
            System.out.println(node.val);
            if (node.right != null) stack.push(node.right);
            if (node.left != null) stack.push(node.left);
        }
    }

    static class TreeNode {
        int val; TreeNode left, right;
        TreeNode(int x) { val = x; }
    }
}