I agree with the "An Interview Is Not an Interrogation" bit. I had a colleague who treated an interview like how you described there (rapid fire question from a list). Interviews are already stressful situations for some people, and his large and imposing stature did not help ease candidates.
My approach is to get the candidate talking about their experiences, frameworks / languages / tools used, and an example of something they coded which they felt some pride in. In those sorts of discussions, I can gauge the ability, aptitude, and attitude far better than questions like "What is the difference between a class and an object?" or "What is boxing / unboxing?".
This colleague and I have hosted a few interviews together, and there is a clear difference in the candidate's responses between the "checklist of questions" and the "discussion" approaches. Developers often do things without knowing the textbook definition of things. E.g. I have never thought "I have problem x. I know, I'll use boxing in this bit of code.", and I'm sure many developers will agree. However, it doesn't mean I've never used the notion in my code.
Even though my colleague never responded with "You're right" or "No, that's wrong", his expressions would be a visible indicator. When his expression indicates that the answer was incorrect, I could see how the candidate became more and more nervous. I've used the phrase "chalk it up to interview nerves" many times afterwards when describing what I saw in the candidate, and I believe it to be a real thing.
Contrast it with the discussion I have with the candidate, and the general mood would be a lot better and the candidate more at ease. Textbook questions can be studied for and short-term memory can answer all of those. Real experience cannot be rehearsed for, and thus will yield more real information.
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.
I agree with the "An Interview Is Not an Interrogation" bit. I had a colleague who treated an interview like how you described there (rapid fire question from a list). Interviews are already stressful situations for some people, and his large and imposing stature did not help ease candidates.
My approach is to get the candidate talking about their experiences, frameworks / languages / tools used, and an example of something they coded which they felt some pride in. In those sorts of discussions, I can gauge the ability, aptitude, and attitude far better than questions like "What is the difference between a class and an object?" or "What is boxing / unboxing?".
This colleague and I have hosted a few interviews together, and there is a clear difference in the candidate's responses between the "checklist of questions" and the "discussion" approaches. Developers often do things without knowing the textbook definition of things. E.g. I have never thought "I have problem x. I know, I'll use boxing in this bit of code.", and I'm sure many developers will agree. However, it doesn't mean I've never used the notion in my code.
Even though my colleague never responded with "You're right" or "No, that's wrong", his expressions would be a visible indicator. When his expression indicates that the answer was incorrect, I could see how the candidate became more and more nervous. I've used the phrase "chalk it up to interview nerves" many times afterwards when describing what I saw in the candidate, and I believe it to be a real thing.
Contrast it with the discussion I have with the candidate, and the general mood would be a lot better and the candidate more at ease. Textbook questions can be studied for and short-term memory can answer all of those. Real experience cannot be rehearsed for, and thus will yield more real information.