3 ms·

My favorite interview question is a real life issue I faced where a short sighted database design wound biting us in a pretty serious way. It's a good technical

My favorite interview question is a real life issue I faced where a short sighted database design wound biting us in a pretty serious way. It's a good technical problem to talk through, and provides a lot of useful information about the candidate, but it's also an excuse to set very clear expectations that I'm not looking for the "right" answer (in real life it took half a dozen smart people a couple hours to come up with a right-ish answer). I try to use it early in the interview, and I find it sets a helpful tone, avoiding a lot of that posturing you describe.

cheez 7y ago
Ah so a good interview question for a candidate is something that YOU have experience in. Does that seem odd? Do you think you would be an expert in something the candidate had experience in? Probably not. Should you find out how they speak about something THEY are experts in? Probably. But like the OP said, tech interviews are about posturing so that the interviewer feels better about themselves.
- bagacrap 7y ago
  does that seem odd? Not at all! How can anyone evaluate a someone else's performance in a domain if they don't know the domain? You ask the question many times over so you can judge performance relative to others. Yes, the interviewer should be familiar with the topic of the interview.
  - cheez 7y ago
    If the idea is the answer is not important, the process is, then how many variables should you have? Your way, you have two variables: 1. Knowledge of the domain 2. Process So, your question is not matching your goals.
jameshart 7y ago
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.

cheez 7y ago

Ah so a good interview question for a candidate is something that YOU have experience in. Does that seem odd? Do you think you would be an expert in something the candidate had experience in? Probably not. Should you find out how they speak about something THEY are experts in? Probably. But like the OP said, tech interviews are about posturing so that the interviewer feels better about themselves.

bagacrap 7y ago
does that seem odd? Not at all! How can anyone evaluate a someone else's performance in a domain if they don't know the domain? You ask the question many times over so you can judge performance relative to others. Yes, the interviewer should be familiar with the topic of the interview.
- cheez 7y ago
  If the idea is the answer is not important, the process is, then how many variables should you have? Your way, you have two variables: 1. Knowledge of the domain 2. Process So, your question is not matching your goals.

jameshart 7y ago

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.