I think turn this on its head - You're not trying to evaluate the correctness of the thing, you're trying to evaluate the value add of the candidate. So instea

I think turn this on its head - You're not trying to evaluate the correctness of the thing, you're trying to evaluate the value add of the candidate. So instead of you trying to judge the value of the implementation based on some undefinable "technical correctness" have a discussion about the what the candidate has done/built. In this case - so many opportunities for great discussion around the tradeoffs of this approach: - What sort of load does it handle? - How portable is it? - What does developer setup for this environment look like, and what tools might you need to introduce the team to for them to be productive? - What might you do instead of this if we had requirement X, or challenge Y (ex: Network latency, computations/second, real time processing requirements, tooling/language constraints, etc)? - What are the scaling costs? - How do you put tests in place? - Etc. And then you expect to receive believable answers, and interesting conversation. Because at least in this case, it's pretty trivial to determine that the solution either does or does not work for at least a small subset of fizzbuzz. It can be really insightful to step back from the expectation that an interview is always "Interviewer is more experienced than interviewee" and instead just try to get an understanding of what working/talking with that person is like. For context - I've done about 150 software dev interviews over the last two years (principle/senior to junior/intern)