Photo by Kaleidico on Unsplash
As a senior developer, a part of my job is giving technical interviews to candidates for developer positions at Fut...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Interesting post! I'd love to know how you interview a more intermediate developer?
Well, the principles remain the same, no matter the experience level. I think everything in the post should be applicable to any developer interview.
Questions will vary, especially in specifics. I might start a topic with the same or similar question always, but since the follow-up is guided by the answers, different amounts or kinds of experience of the interviewee will lead to different places. And some topics, for instance, technical leadership or coaching others, will usually only make sense for people with more experience.
And my expectations will definitely vary. As a simplified example, consider any somewhat popular architectural pattern. A junior developer I might expect to have heard of it, a more intermediate one to have tried it, and a senior one to be able to discuss its applicability, benefits and drawbacks. And the more experienced the person, the more I expect them to be concerned with the big picture, to understand and consider the wider context of the work, not just the piece they're directly responsible for right now.
Does that answer your question?