Exactly. Some people who aren't good at programming are excellent at interviewing. The best way I've found to expose those that have trained themselves to interview well for the aggressive Trivial Pursuit interviews is to have a "let's-have-coffee-and-chat-about-code" interview. A few "That's interesting. Tell me more about how you implemented a facade pattern in your web service project." type questions and you'll know if they're just reciting Wikipedia or really done the work. (Bonus if you can ask those questions with a Wonka-esque smile rather than a poker face.)
What's more, this kind of question will let you gain some insight into their personality and coding style. For example, a while back I interviewed a senior level C# programmer who would have probably aced a by-the-book OOP, design patterns and Fibonacci-on-a-whiteboard type interview. However, after a simple discussion, it was clear his coding style was radically different from the rest of the team, was rather egotistical and thus he wouldn't be a good fit.
BTW, I have worked at a programming job in medical monitoring where someone might actually die if there was a problem. It was actually less stressful and more enjoyable workplace than most run-of-the-mill business app teams since people put aside their egos to get the job done because it was really important that it be done right.
Although I probably didn't make it clear, I actually purge from my list any questions that job websites recommend people prepare for. I do prefer very open ended questions.
I don't work in any place where we have looming "we're all going to die" deadlines, but I've known a few. If you're running a major website, and a security problem slips into production, there's no denying that is super-urgent.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Exactly. Some people who aren't good at programming are excellent at interviewing. The best way I've found to expose those that have trained themselves to interview well for the aggressive Trivial Pursuit interviews is to have a "let's-have-coffee-and-chat-about-code" interview. A few "That's interesting. Tell me more about how you implemented a facade pattern in your web service project." type questions and you'll know if they're just reciting Wikipedia or really done the work. (Bonus if you can ask those questions with a Wonka-esque smile rather than a poker face.)
What's more, this kind of question will let you gain some insight into their personality and coding style. For example, a while back I interviewed a senior level C# programmer who would have probably aced a by-the-book OOP, design patterns and Fibonacci-on-a-whiteboard type interview. However, after a simple discussion, it was clear his coding style was radically different from the rest of the team, was rather egotistical and thus he wouldn't be a good fit.
BTW, I have worked at a programming job in medical monitoring where someone might actually die if there was a problem. It was actually less stressful and more enjoyable workplace than most run-of-the-mill business app teams since people put aside their egos to get the job done because it was really important that it be done right.
Although I probably didn't make it clear, I actually purge from my list any questions that job websites recommend people prepare for. I do prefer very open ended questions.
I don't work in any place where we have looming "we're all going to die" deadlines, but I've known a few. If you're running a major website, and a security problem slips into production, there's no denying that is super-urgent.