Trace a recursive function with a call-stack table

A recursive function is easier to explain when you can show what each call is waiting for. Instead of memorising a definition, trace a small input, record the unfinished work and follow each returned value back to its caller. The aim of this exercise is a table you can check, not a clever one-line answer.

We will use a short JavaScript example that adds the integers from zero to a small non-negative input. It is an illustrative learning exercise, not an efficient general-purpose calculator or a claim about a particular interview. You need basic familiarity with functions, conditions and return values.

Start with a function whose input is deliberately small

function sumTo(n) {
  if (
    !Number.isInteger(n) ||
    n < 0 || n > 10
  ) {
    throw new RangeError(
      "Use an integer from 0 to 10"
    );
  }
  if (n === 0) return 0;
  return n + sumTo(n - 1);
}

console.log(sumTo(3)); // 6

The input guard keeps this worksheet within its intended range. The base case is n === 0. Every other accepted input requests a smaller problem, sumTo(n - 1), and then adds its own value of n to the answer. For the allowed inputs, subtracting one eventually reaches zero.

Before running the code, write down the expected answers for zero, one and three. Explain why zero returns immediately. An expected result should come from your reasoning about the problem, not from copying the program's output into your notes.

Draw the calls going down

MDN's call-stack explanation describes how JavaScript keeps track of active function calls and resumes a caller when the function it called returns. For this exercise, draw the oldest call at the bottom of your stack sketch and the newest at the top. Label that convention so another reader can follow it.

At sumTo(3), the expression cannot finish adding three until sumTo(2) has produced a value. The second call waits for sumTo(1), which waits for sumTo(0). Treat each call as a separate row with its own input and unfinished addition. Do not erase the earlier row when a new call begins.

At the deepest point there are four active sumTo calls, including the base case. This count refers only to this function's calls, not every frame that a browser or debugger might display around the program.

Now follow the answers coming back

Start at the last row, not the first. The zero returned by sumTo(0) completes the addition waiting in sumTo(1). That call returns one. The next waiting addition becomes two plus one, returning three. Finally, the first call adds three to that returned three and produces six.

1. sumTo(0) returns 0.
2. sumTo(1) returns 1 + 0 = 1.
3. sumTo(2) returns 2 + 1 = 3.
4. sumTo(3) returns 3 + 3 = 6.

Keep the input column separate from the answer column. In the third row, two is the input and three is the answer. Mixing those numbers is a common way to produce a plausible-looking trace that no longer matches the expression being evaluated.

Use the table to locate an error

Suppose a handwritten solution says that sumTo(2) returns two. Ask which value came back from sumTo(1) and where it was added. The table exposes the missing step without requiring a guess about the whole program.

For a second reasoning exercise, imagine replacing n - 1 with n + 1. Starting at three, the sequence moves away from the base case. In this guarded example, it eventually reaches an input above ten and throws the specified error; it does not return the intended sum. Predict that path on paper before changing anything.

MDN's functions guide explains recursive calls and the need for a stopping condition. A useful review asks both whether a base case exists and whether each permitted recursive step makes progress towards it. Merely spotting an if statement is not enough.

Check the boundaries as well as the example

Run the unchanged function in a local JavaScript environment. Record the actual result beside each prediction: sumTo(0) should give zero, sumTo(1) one, sumTo(3) six and sumTo(10) fifty-five. Negative numbers, fractions, strings and eleven should be rejected by the guard.

If a result differs, preserve the exact input and the code you ran. Check the first row where your trace and execution disagree. Avoid changing several lines at once; a small correction is easier to explain when the original failing case remains visible.

Turn one trace into a practice submission

Prepare a fresh trace for sumTo(4) without looking at the worked table. Include the input contract, descending calls, deepest active-call count, ascending return values and final answer. Add a short sentence describing what happens for an invalid input.

Then compare the exercise with a simple loop on paper. Which variables must you track? Where is the unfinished work stored in your explanation? The purpose is to justify a choice, not declare recursion better for every task. Keep this tiny recursive example within its ten-step limit; do not use it to process large real-world inputs.

Common questions

Does the base case count as a call?

Yes. In this example, sumTo(0) is entered and returns a value even though it does not make another recursive call.

Should I memorise the trace?

Practise producing it for another small input. Being able to explain each pending addition is more useful than remembering these four rows.

Is this enough preparation for a data structures interview?

No single exercise covers an interview. Use it to practise careful explanation, then work on other problems and check their requirements separately.

Explore Data Structures and Algorithm or Interview Preparation with DSA. Bring your completed trace to a course discussion and ask how solution explanations receive feedback.