3 ms·

This does seem logical: here is a hard problem we actually faced and solved; we want to hire people who, faced with that sort of problem could solve it; let's s

This does seem logical: here is a hard problem we actually faced and solved; we want to hire people who, faced with that sort of problem could solve it; let's see whether the candidate can solve that sort of problem. You're also right that sharing the problem does place you in a position of vulnerability. It's perfectly possible that a candidate will think 'what a bunch of idiots to have gotten themselves in that mess in the first place'. Or worse, when they realise how you solved the problem, 'wow, they think they solved their problems? They're in an even worse spot now'. So I appreciate that you see this as being humble and exposing the candidate to an opportunity to know more than you. But the reality is, when you solved that problem, you: 1) knew all of the context and constraints, spoken and unspoken 2) had a team of folks around you to bounce ideas off and collaborate on the solution 3) had access to google, stackoverflow, etc. 4) did not have to come up with a solution inside a small interview room, within a few minutes, while being judged by someone who has decision rights over your future employment 5) crucially, had found yourself in a position where you needed to know how to solve this problem. If you hadn't had that need, you would never have acquired that knowledge. So unless the candidate had also faced this exact problem, why would they know how to solve it? You work here, and you didn't... And while it might be nice to hire someone who can, under interview conditions, jump right to the right solution shortcutting all of those processes - it would obviously fill in a knowledge gap your team demonstrably had - looking for a candidate who has already learned something that came as a hard-won lesson for your team is like a general building up an army to better fight the last war. You can do better: Use the problem as an example of the sort of thing your team has struggled with, and ask the candidate to give examples of similar problems they have solved in their own career. You are hiring them for their hard-won lessons, and adding them to your own, not looking for someone who happens to have also won the same lessons you already have.

JshWright 7y ago
I thought I made it clear in my initial description that I do not expect the candidate to come up with the "right" answer, and that I definitely didn't come up with the right answer in the given timeframe. Perhaps I didn't make it clear in my post that I am very upfront about those things with the candidate. Another nice aspect is that the "solution" is contained in a 6 line git diff, and consists of standard "intermediate" level Python/Django. After talking through the problem for a few minutes, getting a sense of their instincts for approaching the problem, I give them the solution we came up with and we talk through that. Their ability to understand the solution is equally important (and not hard... it's a standard diff, standard code, nothing tricky). To address some of your concerns: 1) The bulk of the context is easily communicated in a dozen or so lines of very standard Python/Django code. 2) Absolutely. That's partly why it's a good question. The candidate and I are acting in those roles (as much as possible, given the setting) 3) Candidates can certainly do that if they want (though for the sake of time, I generally shortcut the answer for them) 4) The circumstances under which I did come up with the solution were similarly stressful, and again, I _didn't_ come up with the solution in the timeframe of an interview, I would be shocked if the candidate did, and they know that going into the conversation. 5) Do you think we're hiring someone specifically to solve a problem we solved a couple years ago...? The question is about critical thinking, approaches to debugging/troubleshooting, collaboration, etc. These are all skills that will be very important for the _next_ unforeseen problem we're going to face. Talking about similar problems (or problem of a similar scale) that they have faced in their career is generally where the conversation heads next (depending on their experience). For what it's worth, in my experience it's pretty rare to get feedback from candidates (obviously for different reasons), but this particular question has resulted in several cases of someone reaching out later to speak positively about it.

JshWright 7y ago

I thought I made it clear in my initial description that I do not expect the candidate to come up with the "right" answer, and that I definitely didn't come up with the right answer in the given timeframe. Perhaps I didn't make it clear in my post that I am very upfront about those things with the candidate. Another nice aspect is that the "solution" is contained in a 6 line git diff, and consists of standard "intermediate" level Python/Django. After talking through the problem for a few minutes, getting a sense of their instincts for approaching the problem, I give them the solution we came up with and we talk through that. Their ability to understand the solution is equally important (and not hard... it's a standard diff, standard code, nothing tricky). To address some of your concerns: 1) The bulk of the context is easily communicated in a dozen or so lines of very standard Python/Django code. 2) Absolutely. That's partly why it's a good question. The candidate and I are acting in those roles (as much as possible, given the setting) 3) Candidates can certainly do that if they want (though for the sake of time, I generally shortcut the answer for them) 4) The circumstances under which I did come up with the solution were similarly stressful, and again, I _didn't_ come up with the solution in the timeframe of an interview, I would be shocked if the candidate did, and they know that going into the conversation. 5) Do you think we're hiring someone specifically to solve a problem we solved a couple years ago...? The question is about critical thinking, approaches to debugging/troubleshooting, collaboration, etc. These are all skills that will be very important for the _next_ unforeseen problem we're going to face. Talking about similar problems (or problem of a similar scale) that they have faced in their career is generally where the conversation heads next (depending on their experience). For what it's worth, in my experience it's pretty rare to get feedback from candidates (obviously for different reasons), but this particular question has resulted in several cases of someone reaching out later to speak positively about it.