There are many things you need to find out about engineering candidates in an interview. One of the most important things is how they approach coding. In this age of AI, developers may spend less of their time coding than in the past, but it is still an important skill to evaluate.

However, coding exercises are often poorly thought out in interviews.

While board coding is perhaps the most egregious example of a poor coding exercise. Developers write code on a computer, not on a whiteboard. At best, this shows whether they can remember syntax. However, for the last twenty-five years or so, recalling syntax has become less and less important. Engineers use IDE with auto-complete features; they look up linguistic nuances on the internet, and more recently can ask AI.

Coding exercises that require engineers to know and recall specific algorithms are also testing for the wrong thing. It is only a slight exaggeration to say that knowing the details of coding a linked list are useful in two settings: getting your CS degree and passing interviews. In my career, I have never needed to code a linked list. If it did come up, I know how to look it up. I know when it would be useful; which is a relevant skill for a software engineer.

The approach that I took when interviewing candidates for my most recent role was a two-part exercise. Part Two followed on from Part One. Junior candidates should be able to complete one within the interview. More senior ones should be able to complete both parts. There was a set of requirements that were incomplete, and some ambiguity. The test also came with a set of unit tests; some of which added to the requirements. I would tell candidates that they could look things up and/or ask questions of me.

I would tell them that they should tell me as they coded why they were making the choices as they coded. Stronger engineers would explain that they were writing code in a way that enabled them to complete the exercise on time and that they would take a different approach if this were production code. For example, there was some validation code that appeared in multiple functions. Noting that in production they would factor this into a helper function was a good sign.

One frequently occurring negative sign was when candidates did not read the test cases... The test cases covered various edge cases and how they should be handled.

The exercise was to build a very simple task manager. In part 2 tasks had a priority (High, Medium, or Low). Missing from the requirements and the test cases was how to handle the creation of a task if no priority was passed. The best candidates asked what the code should do. Good candidates said that they were going to assign a default priority of medium; not as good as asking, but still showing recognition of the issue.

This structured approach to evaluating candidates not only identifies strong technical talent but also reveals their ability to navigate ambiguity, communicate effectively, and balance speed with quality. By focusing on practical problem solving rather than rote memorization, I have consistently built high-performing engineering teams that deliver meaningful business impact.

Thoughts on this approach?