Real-Time Feedback: My Closing Move in Every Interview

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.