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. ↩
Top comments (4)
I've seen interviewers bag on the school the candidate came from. I think this usually says more about the interviewer than the candidate.
One time I let my coworker dig himself a hole ranting about how a candidate came from a "cheap state school". I was seeing how long it would take for someone to point out how many of his fellow employees went to cheap state schools - myself included. It was gratifying watching him eat his own words as he tried to walk back his sweeping generalizations.
This can also come through as a bias against people without university degrees. True, a boot camp grad might not have enough experience for your role, but it's not because they came from a boot camp. Plenty of great employees come from nontraditional backgrounds.
I come from a background of a lot of school (probably too much), so I have to fight against this bias myself. A lot of people who have 4-year degrees don't demonstrate the sort of academic chops I secretly hope for during the interview (I wrote about one example here). At the same time, I've seen people without CS degrees walk circles around grads in reasoning their way through fundamentals.
It takes all kinds. 🙃
wow, being snotty about which school and not even which college/university. . . and the culture of CS Degree requirement is already bad enough as it is!
because, as you say, spending 4-years living that student life doesn't really in any way prepare you for what you actually do day-to-day as a dev.
no one will pay you for an abstract chess engine/ticketing system/academic OOD theory that has been coded before by >10,000 times by people much smarter than you.
To be clear, by "school" I did mean college/university. I'm happy to report I've never heard anyone bash on the grade/high school someone went to. 😅 (I'm from the US, in case someone's reading this coming from different nomenclature.)
One thing I can say for a 4-year degree is that it gives you time to practice coding in a way that a 12-week bootcamp doesn't. Literally just that one takes longer than the other. But there are so many confounding factors that it's still kind of a wash. You just have to evaluate on a case-by-base basis. Some people learn faster than others. Some people have spent a lot of informal time (outside of school/bootcamp/work/whatever) toying around with computers. I've known some very capable people who couldn't hack it in college, so they dropped out. I've worked with CS graduates whose code was always painful to review. And so on.
I am partial to the fundamentals you're exposed to in a CS curriculum, but (a) you can learn those anywhere and (b) it's never going to cover all the tools/skills/etc you'll need in an actual dev job. So I have to be mindful of my bias.
I'm new to interviewing, which has meant that I'm often as nervous about the interview as the candidate is (more, for some of them 😂)! Plus I'm being hypervigilant about bias, so I tend to put a lot of thought into my candidate feedback. It feels very strange to be making decisions about someone's livelihood when I'm not that far removed from being desperate for a job.
You're 100% right about the importance of making the feedback specific to the role. I've recently been involved in interview rounds for two types of roles at my company: visual designer and customer success engineer. For the visual designer role, I sat in on the portfolio review in place of my manager, who had a conflict, and the two of us discussed my feedback afterward so my manager knew what to ask about during the 1:1 interview.
I had trouble making any sort of judgement about the portfolio itself (my thoughts were limited to "that's a nice rebrand, looks way better" which doesn't say much), so I focused on the story the candidate told and how they interacted with other teams on their projects, which is something I specifically asked about.
For the customer success engineer role, the responsibilities and skill set are a lot closer to mine, so I looked for the areas where there's a lot of overlap with my role and talked about that. The director of customer success wanted me involved in hiring for this role because of the importance of user empathy for my job as a developer advocate. I asked about how they would proceed in various customer-facing scenarios I've experienced myself, and I wanted to hear how they would approach solving a problem that might involve interacting with teammates across the company, and how they would build/maintain/try to salvage the customer relationship in the process. Those things were what I strove to give feedback on.
I've learned a lot from discussing my feedback with the other interviewers, and hearing their thoughts. Sometimes a candidate is a good fit for the role in some ways, but their experience is so far from what our product is about that it would be prohibitively difficult to onboard them. There's a huge difference between "could this person succeed in this kind of role with enough time and support?" vs. "will this person succeed in this specific role now, with the limited resources we have to train them during their first 90 days?"
It's also important to hear when other interviewers have a conflicting experience with a candidate from mine. One candidate was perfectly lovely with me but disrespectful to a different interviewer. We can't afford to deal with that sort of attitude problem.
Finally, we're a small startup. Each new hire has proportionally greater impact on our decision-making and culture than any new hire at a large, established company would have. Rather than "culture fit," I specifically look for "culture add," augmenting the sum of our collective experiences as a team. Our founders and leadership come from Facebook and Google and Microsoft, but that's probably not where our prospective customers will be working.
Has this person worked in a domain that nobody else at the company has touched before? That diversity is super valuable--it grows our collective blob of experience. This is especially important in a startup where you have to wear a lot of hats and proactively be the glue among teams.
I knew before that candidate feedback is rarely binary, but I see that a lot more clearly now that I've been an interviewer myself.