As a candidate, I’ve had some interesting (and some stupid) questions come my way. Like:
If you were an animal, what animal would you be?
How would you work out how many glass windows there are in the city?
What is the volume of water that flows through a cylinder with a radius of x, and the water is y high (asked, oddly, of someone interviewing to manage software engineers, not pipes).
What these have in common isn’t just that they are stupid questions, it’s that they are one-directional. The candidate performs, the interviewer judges, and that judgment never makes it back to the candidate.
To be fair, I’ve probably asked my share of bad questions as an interviewer. But over time (and I’ve probably interviewed more than a thousand people), I’ve settled on this as my favourite and most valuable question to ask at the end of an interview:
“I’d like to give you some feedback. First, so you can get some feedback on the interview, but also so you have the chance to correct anything that I have misinterpreted. Is that ok with you?”
Ok. It’s not really a question. The ‘is that ok’ isn’t really seeking permission; it’s giving the candidate a few seconds to prepare for what’s coming. As in, “I’m about to shift from interview mode to feedback mode, here’s a moment to reset.” The valuable bit isn’t asking that question; it’s what happens next that’s valuable. From there, I go into depth with feedback (also inviting the other interviewers to do the same).
So, regardless of what else you ask in the interview, this question makes the interview two-way instead of one-way.
The feedback I give is then highly opinionated, direct and transparent about what I’m thinking. I will talk about both what was positive and my concerns.
On the positive side, I have said things like:
“Your architecture walkthrough was clear. You explained the context well, clearly stepped into each level of the architecture and explained the tradeoffs well, showing us that you are senior and have a solid grasp of architecture concepts”
“Your explanation about how you go about forming a new team and creating psychological safety was deep and had some great examples of how you’ve done this in the past, demonstrating deep knowledge of how to do this effectively”
“You seemed quite nervous when answering questions about the projects that you worked on, but I’m not too worried about how you interview, more about how well you understand the topics, which you showed you understand very well. Well done. For any future interviews you do, it’s probably worth brushing up on those projects so you can speak with more confidence”
You can see that these examples are specific enough that the candidate can actually take something away from them.
On the constructive side, I have said things like:
“When you explained to me how to get a team to deliver effectively, you described how you have worked in the past, and the mechanics involved there, but when I pressed for more on how you’d get a team delivering effectively, I didn’t get much beyond what you’d already described. I’m not worried about whether you could work effectively within a team using those practices. You demonstrated that well. But not getting further than that initial description makes me concerned you might not have the depth in the underlying principles to uplift a team’s practices if that was needed.”
“Looking at your background, you’ve had much more senior roles in the past. That makes me concerned about retention. About whether this role would hold your interest for long enough. I’d be interested to hear what’s drawing you to this role.”
“You explained the concepts of what makes a good team, but no matter how much I probed, I couldn’t get anything concrete from you about how to actually build a team. Neither examples of how you would go about doing it. Not being able to get past the concepts into specifics is what makes me concerned about whether you’ve put this into practice yourself, or that you only understand it at a high level.”
There are many other examples, but you see that the key thing is to actually go into depth and state what you think. Doing this allows the candidate not only to receive feedback but also a chance to correct any misunderstandings. It’s important to note that the feedback needs to be about capabilities, which they can act on, not their personality traits, which gives them nothing but the feeling of being judged.
The challenge when doing this is to synthesise your thoughts concisely and quickly enough to play them back at the end of the interview. This takes some practice, but also a bit of courage to just say what you are thinking.
After I give that feedback, I ask the candidate what they think and allow them to correct any misunderstanding I may have (which I’ll cover in more detail later)
There are a few different categories of responses to the feedback, but what is common in almost all of them is simply gratitude for actually receiving feedback. I can’t tell genuine gratitude from a candidate who is performing it for someone who holds the decision, so I don’t read it as proof the feedback was right, only that candidates value getting any feedback at all.
My absolute favourite type of response is where I have genuinely misunderstood something, or I had a concern that they can alleviate. Some examples:
I gave one candidate feedback along the lines of “when you explained the app that you built, you talked about the testing that you did at only a very high level, so I’m worried about your depth of testing knowledge, particularly around Test Driven Development (TDD)”. The response was along the lines of “Oh. You’re right. I didn’t really delve into detail, but here’s how I went about doing the testing and here is my general approach in other examples”. The candidate then went into significant depth explaining how they had done TDD over the last 10 years, which clearly demonstrated their understanding and maturity of the practice. Misunderstanding corrected.
The candidate that I was worried about being too senior for the role explained to me why he was after this particular role. Explaining the burnout experienced in the previous role, and that he was now looking for something more sustainable and looking to get closer to the team. Again, I voiced the concern, and he alleviated it.
These clarifications happen occasionally, maybe one interview in five (not always such a large correction, sometimes just a minor correction).
Sometimes people disagree with what I have said and try to correct my misunderstanding, but only manage to confirm my thoughts more strongly. As in, the candidate will try to explain why they have deeper knowledge in an area I said they didn’t, or more depth of experience than I implied. But when they try to correct, they give more examples or go into more depth and only expose their weakness further, failing to add any more detail and succeeding in confirming it.
For example, in one interview, I explained to a candidate that his answers to the technology questions lacked depth and didn’t give me confidence that he understood the concepts at the level of a Senior Engineer. He then explained the concepts in more depth, but the deeper he went, the less clear his descriptions were and the more mistakes he made.
Two things could undermine this category. First, by voicing the concern, I tell the candidate exactly what to address, which risks letting a shallow candidate aim a clean-sounding answer at the gap. But I’m not testing for that. When I probe, I’m looking for application, not just “what makes a good team” but “how have you built one” and “how would you build one here”, and rote answers don’t survive that. You can’t improvise experience you don’t have. Second, once I’ve voiced a doubt, I’m partly invested in it, so I can’t fully rule out that some of these were candidates who were right and lost me early. Both are reasons I treat a confirmed concern as a flag to check against the earlier stages, not a verdict.
When this happens, I simply thank them for their input and continue the process. If they disagree but can’t demonstrate effectively why that is the case, there’s no point arguing with them. It would turn the feedback experience into a negative one instead of a positive one, and most of the candidates in this case still respond positively to the feedback.
This occurrence is uncommon, though not as rare as outright negative responses.
The vast majority of responses simply accept the feedback gratefully. There is such a lack of feedback on most interviews that people are generally extremely appreciative of receiving any feedback. Even for candidates for whom my feedback was scathing, they are still generally positive about the experience. Quite often, candidates will state that they agree with most of the feedback. This may be due to most of my interviews being for technology roles, and anecdotally, they tend to be quite introspective.
This happens the majority of the time.
On the very rare occasion, the candidate will respond negatively. On one occasion, I explained to a candidate that his answers to questions were very confident, which was good, but some of the discussion might feel arrogant to the team, and I was concerned about how he would get on with the team. He did not take the feedback well, and his response was to criticise all of the things he saw wrong with the company and interviews, in a less-than-constructive way.
Looking back, the problem was how I delivered the feedback, not that I gave it. The feedback I gave was about personality rather than capability. Capability feedback gives the candidate something to address, whereas telling someone they come across as arrogant gives them nothing to act on except the feeling of being judged. I still think giving him the feedback was necessary because I had major concerns about his ability to fit in the team, but I should have given feedback on what he said or did, rather than his personality. For example, “when I tried to probe deeply for alternative answers to some of the questions, you dismissed them as unnecessary because your first answer was good enough, which makes me concerned about how you will accept alternative suggestions from the team.”
This type of negative response is very rare.
Interview candidates are so starved of feedback that giving them feedback right there in the interview is usually a positive experience for them. It demonstrates a level of transparency that will (hopefully) align with your company’s values and thereby demonstrate that value in action. Importantly, it allows the candidate to correct any misunderstandings, which gives you better information for your hiring decision.
My experience is mostly (but far from solely) with technology roles, and the response rates I’ve described may well differ in other fields. I think the core of it, forming your opinion during the interview and being open with your thoughts and concerns rather than keeping them for the debrief, isn’t specific to tech. So next time you interview, try it. Against the alternative, staying silent until the debrief, I think it’s a better way to interview, and most candidates will at least appreciate that you tried.