3 ms·

This absolutely! The interview process is totally broken, as it tests mainly how much someone is willing to prepare for the interview, which might actually sho

by harha 6y ago

This absolutely! The interview process is totally broken, as it tests mainly how much someone is willing to prepare for the interview, which might actually show more how little they focus on doing more productive things in their current job, at university or by starting interesting projects. It also scares away people who might actually be better at the job but not as good or interested in interviews - at least this was my experience at Google compared to the usually more interesting people I worked with at university. It’s just more difficult to test beforehand how someone might actually solve a problem in a good way as you describe. If applicable it’s possible to look at prior work, if you have any other good ways I’d be very interested. Edit: this is actually a good thread to get some ideas on improving interviews.

munchbunny 6y ago
I still do algorithms interviews, sort of. The one-hour interview format is an external constraint, so within that constraint I will do ~40 minutes of coding and ~15 minutes of discussing past projects. I ask a question where the algorithm itself is at most some list iterations or tree traversals, but the real difficulty is thinking through the data and figuring out the right generalizations and transformations to apply. It seems to control decently well for people who have practiced for interviews, because they do the usual dance of asking some clarification questions, mocking the functions, and narrating their code, but many of them hit a wall five minutes in. It's not because their algorithm doesn't work. They're using the right algorithm. The problem is that they haven't thought through "ok what do you do with the data now that you've traversed the tree?" In my experience, for my job, that's usually the actual hard question. For example, if you're checking a JWT, are you validating it in a way that is hard to subvert? Are you taking any time to think about pathological data inputs? The counterpoint would be "what about a candidate who has solid coding skills but stumbles on the problem space because they're unfamiliar with it?" In my sample size of approximately n=10 since I started interviewing candidates this way (admittedly a small sample, but it's the sample I have), I have yet to see someone who writes code well who neglects thinking through the characteristics of the data up front. That said, it's a real issue. Data is usually contextual, so you're at an advantage if you have experience in the corresponding problem domain, which is not something I'm measuring for in the coding exercise. While I try to pick topics that should be universal, I inevitably get surprised, so I offer three different topics based on the candidate's resume, and I give the candidate a choice. The biggest weakness I've seen in my interview process (within the scope of what you can do with only one hour) is that it doesn't control for nervousness or people who just don't operate well under time pressure. Unfortunately that's an unavoidable consequence of the mandated form factor, so I have to try my best to help relax the candidate and then rely on my gut for how much nervousness or pressure affected the interviewee.
- harha 6y ago
  This all makes sense, thanks for the details. I think the key element is how you calibrate towards the candidate, bringing common sense into the process. This is something Google tried to cancel out to increase fairness, which failed in my experience. Maybe another issue is setting the bar too high during the interview to improve the metric on retention, sometimes it might just not be the match that the interview appeared to have. I usually try to work with people on something small to get a feeling for how well we work together before committing to larger projects, but at some point I’ll need to start hiring, so I’m very interested in this topic.

by harha 6y ago

munchbunny 6y ago

I still do algorithms interviews, sort of. The one-hour interview format is an external constraint, so within that constraint I will do ~40 minutes of coding and ~15 minutes of discussing past projects. I ask a question where the algorithm itself is at most some list iterations or tree traversals, but the real difficulty is thinking through the data and figuring out the right generalizations and transformations to apply. It seems to control decently well for people who have practiced for interviews, because they do the usual dance of asking some clarification questions, mocking the functions, and narrating their code, but many of them hit a wall five minutes in. It's not because their algorithm doesn't work. They're using the right algorithm. The problem is that they haven't thought through "ok what do you do with the data now that you've traversed the tree?" In my experience, for my job, that's usually the actual hard question. For example, if you're checking a JWT, are you validating it in a way that is hard to subvert? Are you taking any time to think about pathological data inputs? The counterpoint would be "what about a candidate who has solid coding skills but stumbles on the problem space because they're unfamiliar with it?" In my sample size of approximately n=10 since I started interviewing candidates this way (admittedly a small sample, but it's the sample I have), I have yet to see someone who writes code well who neglects thinking through the characteristics of the data up front. That said, it's a real issue. Data is usually contextual, so you're at an advantage if you have experience in the corresponding problem domain, which is not something I'm measuring for in the coding exercise. While I try to pick topics that should be universal, I inevitably get surprised, so I offer three different topics based on the candidate's resume, and I give the candidate a choice. The biggest weakness I've seen in my interview process (within the scope of what you can do with only one hour) is that it doesn't control for nervousness or people who just don't operate well under time pressure. Unfortunately that's an unavoidable consequence of the mandated form factor, so I have to try my best to help relax the candidate and then rely on my gut for how much nervousness or pressure affected the interviewee.

harha 6y ago
This all makes sense, thanks for the details. I think the key element is how you calibrate towards the candidate, bringing common sense into the process. This is something Google tried to cancel out to increase fairness, which failed in my experience. Maybe another issue is setting the bar too high during the interview to improve the metric on retention, sometimes it might just not be the match that the interview appeared to have. I usually try to work with people on something small to get a feeling for how well we work together before committing to larger projects, but at some point I’ll need to start hiring, so I’m very interested in this topic.