One of the more valuable training exercises I've had in my career was a slide deck on interview feedback. It reinforced two points that I try to keep in mind when conducting interviews and giving interview feedback:
- My goal when interviewing is to evaluate the person for the job I'm interviewing them for.
- My feedback and conclusions should relate specifically to the job the candidate is interviewing for.
A lot of common interview feedback (often negative feedback) doesn't do this, being either generally vague or specific but not obviously related to the position.
When I see these types of statements in my own feedback, it's a cue to think more carefully about the candidate. Often my point can be made more precise; this helps make for a more productive interview feedback session. Sometimes vague sentiments or gut feelings vanish under closer examination; when this happens, I learn something important about my blind spots and biases.
I also try to keep this in mind when listening to the feedback of others during candidate sync ups. If I hear a negative appraisal of a candidate without specific, clearly relevant justification, it's a cue to ask follow up questions.
Some examples that come to mind for me (having seen/heard them fairly commonly): 1
- Many points about communication skills. 2
- Lack of "passion" / lack of growth mentality. 3
- Many things related to culture fit. 4
- Whether the candidate seems excited about the position. 5
I would love to read about how other developers handle this. Do you have particular types of feedback you take as a cue to go back and think more about a candidate, or ask other people to do so? Do you have an engineering culture where you feel empowered to do this?
I don't mean to imply that these are always invalid things to consider in feedback. Only that they are frequently (in my experience) raised as self-evident reasons to pass on a candidate, without specifics and without reflection about whether they are actually relevant for the job. ↩
"Poor communication skills" is not great feedback. "The candidate was not able to clearly articulate the service boundaries of his design in our panel; he would be expected to do this as a principal engineer here" is better; it provides more specifics, and explains why this concern is relevant. ↩
Often, in my experience, raised for more senior, older, or non-traditional candidates who don't have a bunch of GitHub repositories showing off side projects and the like. Does not by itself say anything about how well the candidate would work as an employee. ↩
Self-evident, I hope. ↩
A great many developers manage to be good at their jobs without being excited about them. Some developers may be excited without reading that way (e.g., they're quieter, mellower). It is also really easy to fake being excited. This just doesn't seem like a great thing to look at. ↩