Fundamentals
Verification & Testing
How to review AI output, write effective tests, and catch bugs before they compound.
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, which is 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.
How you approach testing depends on the format.
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. This is test-driven development (TDD), and it becomes especially powerful when you're working with AI. It can feel counterintuitive when the clock is ticking, but it's one of the highest-leverage things you can do.
Writing tests first and using them to guide AI-generated code is how a lot of engineers already work day to day. The habit you build for your interview carries straight into the job.
Start by agreeing on the test cases with your interviewer. Walk them through the inputs and expected outputs you're planning to test against, and make sure you're both aligned on what "correct" looks like before you write any implementation code. This conversation often surfaces misunderstandings about the requirements that would have cost you significant time to discover later through debugging. It also gives you a shared definition of "done" for each phase, so when the tests pass, you can both confidently agree that the implementation is working and move on to the next step.
Once you have agreed-upon tests, the AI produces significantly better code because it has clear targets to hit. A prompt like "implement this function so that these test cases pass" gives the model much more to work with than "implement this function." The tests constrain the output in exactly the right ways, reducing the chance of the AI drifting into a different interpretation of the problem.
Your verification workflow also becomes much simpler. Instead of reading through every line of AI-generated code to check correctness, you run the tests. If they pass, the code does what you agreed it should do. Your main job shifts from verifying the implementation to verifying the tests themselves, which is a much smaller surface area.
After writing your core test cases, prompt the AI to generate additional tests for corner cases like empty input, single elements, duplicates, overflow, and invalid input. Review these generated tests carefully though. AI-generated tests can 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
A good test suite covers these categories:
- Happy path - the standard case that should obviously work
- Empty/zero input - empty arrays, empty strings, zero values, null
- Single element - one item in a collection, one character in a string
- Boundary values - min/max integers, first/last index, exactly at a limit
- Duplicates - repeated values, duplicate keys, identical objects
- Invalid or unexpected input - negative numbers, wrong types, malformed data
- Scale - if the problem has a performance component, a test with larger input to confirm it doesn't time out
You don't need all of these for every function, but scanning this list before moving on helps you catch the gaps that are most likely to bite you later.
Adding tests in structured interviews
Structured interviews often come with provided test cases, but don't assume these are comprehensive. They usually cover the happy path and maybe one or two basic edge cases, but they're rarely exhaustive. The provided tests are there to get you started, not to fully validate your solution.
It's worth adding your own test cases for the corner cases and boundary conditions that the provided tests don't cover. If the problem involves a grid, what happens with a 1x1 grid? If it involves string matching, what about empty strings or single characters? These take seconds to write and they can catch the kinds of subtle bugs that would otherwise cost you ten minutes of confused debugging later in the interview.
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 any regression, where new code breaks something that was already working.
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 in interviews. Every type error the compiler catches is a bug you didn't have to find by running code or reading through 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 also prevents cascading failures where a mismatch in one file breaks several others right before the optimization phase.
Watch out for the AI taking shortcuts with the type system. In TypeScript, it'll sometimes use any to silence a type error rather than fixing the underlying issue. In other languages, it might add unnecessary casts or ignore nullability. Treat these the same way you'd treat a deleted failing test. It's a correctness shortcut that needs to be fixed, not accepted. An interviewer who notices any sprinkled through your codebase will ask about it.
Keeping your types clean pays off in any language. Go's interface system, Java's generics, and Python's type annotations with mypy each give you a way to catch type errors before running a single test. Use whichever 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 to see if everything works together 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" is 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 here: 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. You're just running two parallel investigations. Whichever one finds the root cause first wins.
Don't skip testing because you're worried about time. Candidates who skip tests consistently run into more debugging issues in the final third of the interview, which costs far more time than writing the tests would have. Testing is an investment that pays for itself almost immediately.
Mark as read
Your account is free and you can post anonymously if you choose.