We require all candidates to do a coding test before we invite them to an interview.

The purpose of the coding test is to get some idea about the way the person thinks, and to see what they can do. Often, we don’t really care about the actual solution that was sent, because the point isn’t to solve the problem in the “best” way. The “best” way is highly dependent on many factors (are we trying to optimize for readability, speed, memory consumption, etc.)?

But what I find most interesting is when we confront a candidate with their own code. Typically we have certain remarks, because even if the code is great we can change whatever it is that we are trying to get ("this is highly readable code, but we care about performance here, what would you do if we wanted…?").

A really fun exercise is to invalidate a certain assumption, and see how the candidate handles that. This is typically done on:

You called int Read(byte[] buffer, int start, int count) and you assumed that it will fill the entire buffer, but it will give you only as much as it has available right now. Your code needs to handle that. What needs to be changed?

Seeing how a candidate interacts with code is much more enlightening, especially because this is code that the candidate wrote, so they are familiar with it.