[sbenj]

For software jobs, if the coding interviews are too easy it's likely you will be working with people who are not very skilled, both because the low bar allows poor programmers in and because it's a sign that the people putting together the interview aren't very good. And of course that means you're likely to be working with lousy code, and we all know how much fun that is.

[herge]

On the other end of the stick, an interviewer really should avoid really tricky code interviews/tests. I find reading a candidate's code is more useful to evaluate their ability to write clear code, to open up conversations about harder problems around the code, or optimisations, or whatever, than to probe their knowledge of programming tricks.

Having a gotcha coding test where even good candidates would spend a lot of hours or miss entirely is not very interesting, as most working solutions will resemble themselves and not really show the strengths and weaknesses of the candidate.

[tdumitrescu]

Yeah, calibrating coding questions for timed interviews is really tricky and in my experience always requires iteration. Trick questions with an "aha!" moment lead to binary outcomes (either you pass or completely flop) and don't give much useful signal. On the other hand, simplistic questions tend to focus the interviewer on critique of stylistic details and personal coding habits/preferences which don't say much about the interviewee's effectiveness.