Efficient coding interviews

Something that comes up often in coding interviews is manual testing. In the age of in-person whiteboard interviews, you could often wave your hand and say, "imagine I have a working heap class." The interviewer might ask you to explain the properties of a heap, but the actual implementation could be left to the imagination.

Some companies still use no-compile environments, where you cannot run your code at all. In that setting, interviewers usually care more about your reasoning than whether every semicolon is perfect. You need to be able to walk through the code carefully, track state by hand, and explain why it works.

But that is no longer the norm. Most companies now use runnable IDE-like tools such as CoderPad or CodeSignal. If you can run your code, you are expected to test it. Syntax errors and small logic bugs can make or break an interview, so testing needs to be part of your default workflow rather than something you improvise at the end.

After you finish an initial solution, it is tempting to throw a few print statements at the problem and hope the output looks right. That works for one or two examples, but it gets messy quickly. You lose track of which output belongs to which case, edge cases get skipped, and you spend valuable interview time debugging your debugging.

A better habit is to use a small test table: a list of inputs and expected outputs that you can run in a loop. This makes your testing obvious to the interviewer, keeps your examples organized, and lets you add edge cases without changing the structure of your code.

The goal is not to build a full unit-test suite. The goal is to make correctness cheap to check. You want to be able to say: here are the normal cases, here are the edge cases, and here is the evidence that the function behaves correctly.

In JavaScript, I usually use an array of boolean assertions and print the results in a table:

const tests = [
  solution([5, 3, 2, 4, 1], 14) === 1,
  solution([5, 3, 2, 4, 1], 15) === 1,
  solution([5, 3, 2, 4, 1], 16) === 0,
]

console.table(tests)

This gives you a quick pass/fail view without a pile of disconnected console.log statements. If something fails, you can temporarily expand that case to print the actual value.

In Python, I usually store the inputs and expected output together:

tests = [
  ((params1,), expected1),
  ((params2,), expected2),
]

for params, expected in tests:
  actual = f(*params)
  if actual != expected:
    print(f"Failed for {params}. Expected: {expected}, Actual: {actual}")
  else:
    print(f"Passed for {params}")

This is simple, but it is enough. It shows the interviewer that you are methodical, catches mistakes early, and gives you a repeatable way to validate changes as you refine the solution.