4 ms·

The goal of an interview is to let great people through. It's not to see how well people code while you're watching their every keystroke. I used to make peopl

The goal of an interview is to let great people through. It's not to see how well people code while you're watching their every keystroke. I used to make people write code in front of me. I've missed out on some excellent candidates that don't perform at their best with that kind of pressure. What I do now is ask people to share some code with me that they're proud of. Before the interview I look through it. Then on the call we'll have a quick talk through anything good or weird I've spotted. That helps me know if they've actually written it, and understand it. Secondly I ask them to talk me through an interesting (to them) project they've worked. Then I dig into the how/why on project specifics to see how deep their understanding is. I tend to navigate to specifics that'll be important in the work I'm offering. I also give candidates a heads up that that's what I'll be doing so they're not caught off guard. It's hard for them to know exactly the path of our conversation, but if they know what they've done and why they perform well. With those tactics I've been able to hire some excellent engineers - several of which get quite anxious at the prospect of writing code in front of strangers.

sumedh 4y ago
> What I do now is ask people to share some code with me that they're proud of. What if they dont have code to share?
- starwatch 4y ago
  Good question. That can happen - though it's usually for more junior roles. In that case I give them a take home task. The important thing here is that whether or not the result is good, I commit to talking it through with them (provided it works). You might ask "why spend your time walking through code for a candidate that won't make it through?" Well, it's important for me that if people aren't a good fit for the role, they would be happy recommend us to people that they think are a good fit. Interviewing with that mindset ensures I (and my team) treat candidates like people, instead of like numbers. In the spirit of the actual Ask HN though, I have had a small number of candidates that were deceptive, or difficult. In those cases it's just a polite but firm "I'm going to have to draw this call to close because <xyz /> and I don't want to string you along." Fortunately I've not had a person different to the interview show up on day 1 though... that'd be a little more awkward.

sumedh 4y ago

> What I do now is ask people to share some code with me that they're proud of. What if they dont have code to share?

starwatch 4y ago
Good question. That can happen - though it's usually for more junior roles. In that case I give them a take home task. The important thing here is that whether or not the result is good, I commit to talking it through with them (provided it works). You might ask "why spend your time walking through code for a candidate that won't make it through?" Well, it's important for me that if people aren't a good fit for the role, they would be happy recommend us to people that they think are a good fit. Interviewing with that mindset ensures I (and my team) treat candidates like people, instead of like numbers. In the spirit of the actual Ask HN though, I have had a small number of candidates that were deceptive, or difficult. In those cases it's just a polite but firm "I'm going to have to draw this call to close because <xyz /> and I don't want to string you along." Fortunately I've not had a person different to the interview show up on day 1 though... that'd be a little more awkward.