Verification & Testing

Testing and the type system are your most powerful verification tools in an AI-enabled interview. Tests make AI-generated code better because the model has concrete targets to hit. They make verification faster because you run them instead of reading every line. And they show the interviewer you care about correctness — one of the top evaluation criteria across every company we've talked to. In a typed language, the compiler's type checks do a lot of the same work, catching a whole class of bugs before you ever run the code.

Test-driven development in open-ended interviews

In open-ended interviews where you're building from scratch, write tests before you start implementing. You write them against the interface you intend to build — the function name and the inputs and outputs you expect — so they fail until the code exists. That failing test is the target you hand the AI.

Implement a topKFrequent(nums, k) function so that these test cases pass: topKFrequent([1,1,1,2,2,3], 2) === [1,2], topKFrequent([1], 1) === [1], and the empty-array case returns [].

This is test-driven development, and it becomes especially powerful with AI. It can feel counterintuitive when the clock is ticking, but it's one of the highest-leverage things you can do — and it's how a lot of engineers already work day to day.

Agree on test cases first

Walk your interviewer through the inputs and expected outputs you plan to test against, and make sure you're both aligned on what "correct" looks like before you write implementation code. This conversation often surfaces misunderstandings about the requirements that would have cost significant time to discover later through debugging. It also gives you a shared definition of "done" for each phase — when the tests pass, you can both confidently agree the implementation works and move on.

Your verification workflow also becomes simpler. Instead of reading every line of AI-generated code to check correctness, you run the tests. If they pass, the code does what you agreed it should. Your main job shifts from verifying the implementation to verifying the tests themselves — a much smaller surface area.

After your core tests, prompt the AI to generate additional tests for corner cases. Review them carefully — AI-generated tests have the same blind spots as AI-generated code: wrong expected values, missing edge cases, or tests that pass trivially because they don't actually exercise the logic.

What makes a good test

Run through this list before moving on:

You don't need all of these for every function, but scanning the list before moving on catches the gaps most likely to bite you later.

Adding tests in structured interviews

Structured interviews often come with provided test cases — but don't assume they're comprehensive. They usually cover the happy path and maybe one or two basic edge cases. They're there to get you started, not to fully validate your solution.

Add your own tests for the corner cases the provided ones miss. If the problem involves a grid, what happens with a 1×1 grid? If it involves string matching, what about empty strings or single characters? These take seconds to write and can catch subtle bugs that would otherwise cost ten minutes of confused debugging later.

This becomes especially valuable before the optimization phase. When you're changing the underlying algorithm, a solid test suite is your safety net. Run the full suite before you start optimizing to confirm everything passes, then run it again after each change to immediately catch regressions — new code breaking something that already worked.

The type system is also a test suite

In statically typed languages, keeping your code compiling with clean types is a form of incremental verification that's easy to underuse. Every type error the compiler catches is a bug you didn't have to find by running code or reading a stack trace.

After each generation, compile and run the type checker. Type errors are concrete and actionable — hand them directly to the AI: "Fix the type error on line 42" is a precise prompt that produces better results than "something seems wrong here." Fixing types early prevents cascading failures where a mismatch in one file breaks several others right before the optimization phase.

Keep your types clean in any language: Go's interfaces, Java's generics, Python's annotations with mypy. Use whatever your environment supports.

What to test and when

Run your tests and compile/typecheck after each phase or meaningful milestone — not at the very end. If your plan has three steps, run the suite after completing each one. Candidates who wait until the end often discover cascading failures with no time left to fix them. Testing incrementally means each failure is isolated to the most recent change, which makes it dramatically faster to diagnose and fix.

When a test does fail, form a hypothesis before prompting the AI to fix it:

I think this fails because the loop doesn't handle the case where the input array is empty.

That's a much more productive starting point than pasting the error and asking the AI to fix it. It keeps you in control of the debugging process and shows the interviewer you're reasoning about the code rather than delegating the thinking.

One useful move: once you have your hypothesis, fire off an AI prompt with it at the same time you start investigating manually — "I'm going to look at this myself, but let me also ask the AI." You're not handing over the thinking; you've already formed the hypothesis, and you're running two parallel investigations. Whichever finds the root cause first wins.

Expect to defend it without the agent

A common closing move: the interviewer takes the tool away for the last ten minutes and walks you through the diff. Why this structure, what the trade-off was, what happens if this input doubles, why that abstraction and not the obvious one.

Treat that as the actual exam, because it's where ownership gets separated from relay. Every line you accepted without understanding is a debt that comes due here, and it comes due with an audience. This is the practical reason to decline output you can't defend — not purity about writing code by hand, but that you will be asked to account for it while it's on screen and the agent is closed.

The strongest thing you can produce in that stretch is a place where you overrode the AI and can say why:

It wanted to memoize this whole subtree. I left it out — the list is capped at fifty items, so the render cost is nothing and the cache invalidation is a real bug surface. If the cap ever lifts, that's the first thing I'd revisit.

Explaining why the AI was wrong demonstrates the underlying principle in a way that explaining why it was right never quite does. Anyone can agree with a correct answer. Disagreeing with a plausible one, for a stated reason, is the whole signal.

When the AI diagnoses without evidence

An AI asked "why is this failing?" will always produce an answer. It will produce one whether or not it has seen the failing code, the stack trace, or the test. Fluency is not evidence, and this is the single easiest way to lose time in the back half of an interview.

The pattern to watch for: a test starts returning a 500, you describe the symptom in chat, and you get back a confident, specific, plausible cause. Often the suggested fix is to remove something — loosen an ID-format check, drop a validation, widen a try/catch. Sometimes that makes the symptom disappear while leaving the real bug in place, or deletes a guard that was doing its job.

Before accepting any diagnosis, ask what it's based on:

The stack trace names the file and the line. That single artifact converts the AI from a guesser into a useful collaborator, and it takes seconds to obtain — re-run the test and read the output rather than the summary.

The interviewer is watching this exact moment. Accepting a confident, unevidenced explanation reads as delegating your judgment. Saying "that's plausible, but let me see the trace before I change anything" reads as engineering — and it's usually faster.