|
I have to agree with Veedrac and idontpost. My first thought is, "This looks like a snippet of code completely made up or taken out of context and then anonymized by renaming variables. I have no idea what it's supposed to do, I have no idea why I'm looking at it, and I have no fucking idea what the interviewer wants form me, and I don't play guess-the-rules type of games." If this were real code, I'd have context. Not just a snippet. I'd see the things I don't see in the snippet, and I'd know why I'm looking at it and what I'm looking for. In real work, there is always a motivation for everything you do. In this case, there is none. You might as well show a sequence of bits. "What do you think of these bits?" So by your prejudice, you'd probably categorize me in the first camp. Congrats, you probably turned down someone who's been coding for 20 years. Then again, if this really is the kind of line of business code you regularly deal with, maybe it's for the (my) best. This is a pattern I see all the time. Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react. They think they came up with something clever, they always do. They have no idea. I get the impression that good people get regularly turned down because they didn't guess the rules of the game right, or they don't even play because they got an offer at some place that doesn't play these silly games. Then there is so much complaining about talent shortage, and complaining about terrible interview practices, and complaining about having to deal with a stack of 1000 job applications. |
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.