> Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react.
Agreed that a lot of interviewing issues that I've seen boil down to a misunderstanding of the rules/expectations of an interview, which can be problematic on both sides. Some examples:
* I've had candidates do poorly on a warm-up question because they expect it will be difficult. Ideally, they would say the easy answer they know, but I've had candidates stay quiet while thinking of a hard solution that doesn't exist, then get frustrated when they find that the easy answer is what I was looking for. On my end, this problem is especially tricky because I don't necessarily want to say that something is a warm-up question.
* I've had candidates who have had trouble because they viewed problems as either too concrete or too open-ended. In some cases, I hope that candidates will notice ambiguities in the problem and ask clarifying questions, or come up with creative alternate solutions. In other cases, I know that a particular high-level structure makes a good, consistent problem, and I want them to follow that structure.
* I've had candidates who have written code that's either too hacky/messy/unpolished or too professional such that it slows them down.
My best advice to interviewers is to be straightforward about expectations and open-minded about what assumptions the candidate might have coming in. For example, these days, I try to explain the code quality balance I'm looking for, something like "I'm looking for reasonably production-quality code that might pass code review, but it's still an interview setting, so it's fine to leave off things like docs and unit tests".
I think my best advice to interviewees is to keep a conversation going and be open about your thought process and your assumptions. If you're interpreting the problem wrong, a reasonable interviewer should be able to notice and correct that. The main failure mode I've seen here is people being hesitant to communicate their thought process or ask clarifying questions, which means the interviewer isn't able to know when the candidate is doing poorly because they've misunderstood the problem.
The last two places I interviewed with, there was none of this puzzling or challenges or problem solving. No warm up questions. No games, no rules. We just had introductions and then chatter about what I've done, the tools I've used, how I prefer to work, that kind of stuff. The second place didn't even ask to see any code even though I'd prepared to show them some and had my laptop open on the table. I presume both places trusted I know how to code and solve problems, since both offered a position and even tried to outbid each other.
I really liked this type of interview. It's not so much an evaluation of coding skill as it is a way to get to know the candidate.
With offers lined up, I turned down interview invites from other shops that were publicly complaining about talent shortage and simultaneously had a needlessly complicated & time consuming interview pipeline. I think companies are overthinking it.
Agreed that a lot of interviewing issues that I've seen boil down to a misunderstanding of the rules/expectations of an interview, which can be problematic on both sides. Some examples:
* I've had candidates do poorly on a warm-up question because they expect it will be difficult. Ideally, they would say the easy answer they know, but I've had candidates stay quiet while thinking of a hard solution that doesn't exist, then get frustrated when they find that the easy answer is what I was looking for. On my end, this problem is especially tricky because I don't necessarily want to say that something is a warm-up question.
* I've had candidates who have had trouble because they viewed problems as either too concrete or too open-ended. In some cases, I hope that candidates will notice ambiguities in the problem and ask clarifying questions, or come up with creative alternate solutions. In other cases, I know that a particular high-level structure makes a good, consistent problem, and I want them to follow that structure.
* I've had candidates who have written code that's either too hacky/messy/unpolished or too professional such that it slows them down.
My best advice to interviewers is to be straightforward about expectations and open-minded about what assumptions the candidate might have coming in. For example, these days, I try to explain the code quality balance I'm looking for, something like "I'm looking for reasonably production-quality code that might pass code review, but it's still an interview setting, so it's fine to leave off things like docs and unit tests".
I think my best advice to interviewees is to keep a conversation going and be open about your thought process and your assumptions. If you're interpreting the problem wrong, a reasonable interviewer should be able to notice and correct that. The main failure mode I've seen here is people being hesitant to communicate their thought process or ask clarifying questions, which means the interviewer isn't able to know when the candidate is doing poorly because they've misunderstood the problem.