Ask your interview candidates to ask you an algorithm question in return

Here’s a potential idea to improve the technical interviews that you run: if you use algorithm questions in interviews, ask candidates to ask you an algorithm question as well.

I think it could be beneficial to tell candidates that they should prepare an algorithm question to pose to their interviewer and work through together in the same way. This could have a similar vibe to the general questions at the end of the interview, when we ask candidates if they have any questions for us.

As an interviewer, overall I wouldn’t object to this, and I think as a concept it could help everyone to gain some insight into the whole process and improve it a little bit.

This is only a semi-serious suggestion. This post isn’t a complaint about the existence of algorithm questions, but an attempt to be more thoughtful about their use from the perspective of interviewers and hiring managers. I’m more interested in the thoughts and responses it generates from interviewers, and what the idea demonstrates about how the industry runs technical interviews.

To try and hedge this even more, this is not intended to be a strong criticism of algorithm questions – I’ve run several hundred such interviews as an interviewer, and have mixed feelings (rather than outright negative feelings) about them as both an interviewer and as a candidate. My point here is really to try and examine some of the attitudes in the industry and produce a little bit of perspective.

If you are an interviewer who runs technical interviews using algorithm questions, you might not like the idea of the candidate also asking you an algorithm question at the end of the interview. Maybe this post will convince you that it’s at least an interesting thought experiment.

Every justification for asking the candidate an algorithm question, and every objection to them asking their interviewer an algorithm question in return, seems to apply both ways. Again, this isn’t a criticism of algorithm questions, but an observation that there seems to be some useful insight if we consider the idea of candidates also asking the interviewer an algorithm question. We tend to encourage candidates to ask their interviewer almost any other question that might be relevant to the role.

From the hiring manager’s perspective, having the candidate go through the process of trying to select an appropriate algorithm question and plan out the discussion seems like a good exercise. It could provide some extra insight into what it would be like to work with them.

Getting a bit more rhetorical, surely the interviewer’s ability to work through a previously unseen algorithm problem isn’t that relevant to whether the candidate should want to work at this company? But the candidate might want to ensure they’re working with high-performing, like-minded people. If the team doesn’t want to work with someone who can’t work though an algorithm problem collaboratively, then why should the candidate want to work with a team who can’t demonstrate the same?

The candidate might explain that they’re not expecting the interviewer to churn out an optimal solution on the spot, and instead to have a conversation and work through the problem together. This sounds very good, and is commonly how interviewers describe their interviewing technique. Again it seems like a good reason to have candidates do the same thing with us in reverse.

How can we be sure the candidate will be reasonable and fair in their choice of algorithm question, and in their assessment of the interviewer’s solution for it? We can’t, and we also can’t be sure that interviewers are reasonable and fair when doing this.

The candidate is unlikely to choose an algorithm question that they themselves genuinely solved from scratch in the given time without having seen it before. They’ll probably choose a pet question, something they watched a tutorial on, or something tricky they once had to deal with at work and that took hours or days to figure out. They might choose something culturally specific, or something related to their obscure hobby that they think the interviewer should also be familiar with if they are a true geek. The interviewer won’t feel able to point out how unreasonable any of this is if they don’t want to damage their chances of the candidate accepting them as a potential colleague.

Will the candidate give any feedback to the interviewer about their solution? They might be patronising when giving the feedback, and the interviewer will be obliged to accept it politely. The candidate might never give any feedback at all, and ghost the interviewer and their company afterwards. The interviewer will probably dwell on this for some time, and have to quell their resentment at the unfair treatment. This situation is common for candidates, so I’m not sure that interviewers can object on these grounds.

If candidates could ask their interviewers algorithm questions, it would be scary for the interviewer, and make regular interviewing more stressful than it already is. Candidates already have to deal with this fear and stress, and the industry seems to think it is worthwhile. Maybe we could all be kinder to each other if we ran it both ways.

The odds that the candidate asks a question that the interviewer isn’t able to finish in time seem to be quite high, and that situation would be quite embarrassing. We wouldn’t want the interviewer to be made to feel foolish. But then why do we think this is OK when we do it to candidates?

Could we ask the candidate to give us a heads-up about roughly what kind of question they’re planning to ask? That sounds like a good idea and one that we should probably apply more generally.

It would require some humility from the interviewer. The interviewer has run through their algorithm question dozens or hundreds of times with numerous candidates and is familiar with all sorts of details and edge cases. When the candidate springs an unknown question on the interviewer, suddenly the interviewer would find themselves back at square one, having to think everything through from scratch, and possibily get flustered. Meanwhile (in the universe where this is standard practice), the candidate has probably asked this question to multiple other interviewers and is aware of all sorts of details and edge cases. Why is it a good interview technique in one direction but not in the other?

I hope that this idea can generate a little more empathy and thoughtfulness from interviewers and hiring managers in the industry. We all know that technical interviewing is difficult for the interviewer, and that algorithm questions are problematic. There’s no easy solution, but I think everyone would benefit if people on the hiring side could remember to be humble and acknowledge the flaws in the process that they have designed and are asking other people to go through.


Tech mentioned