When a candidate solves a programming problem, they typically don't do it with a minimum of abstraction or complication, because employers aren't interested in

When a candidate solves a programming problem, they typically don't do it with a minimum of abstraction or complication, because employers aren't interested in that. Instead, they'll try and pick something that they want to communicate through the medium of the exercise. If they choose unit testing, the solution might be over-engineered to be testable at a much finer level than would be necessary in production code, and have more abstractions than usual. Or the candidate might be trying to communicate some kind of design aesthetic, whether it's familiarity with functional programming, object orientation, design patterns, or some framework du jour that requires a lot of boilerplate. All these will smell a lot like over-engineering on typical toy problems seen in programming problems. IMO it's very easy to get a mismatch in expectations and presentation in the solution to a programming problem, such that the company and the candidate aren't communicating on the same wavelength. Unambiguous, very simple problems with binary solutions may be better as a basic filter (e.g. Codility or something like it), followed up with pair programming in something more similar to a working environment, where pair communication and direction can get people on the same page.