3 ms·

I also do a lot of hiring, and the most important thing I see is to filter out the candidates who basically can't code at all. When you never did any hiring, y

I also do a lot of hiring, and the most important thing I see is to filter out the candidates who basically can't code at all. When you never did any hiring, you assume you're mainly looking for good candidates. When you actually have the experience, you know that at least 30% of applicants can't even code the most basic thing. So I was wondering how you, hiring more than 100 developers, weeded out those candidates who "do the talk but can't walk". Another thing: how many of those 100 developers you hired were bad hires?

peteforde 4y ago
I talk to them and get them talking about how they have solved problems in the past. I will dig in on interesting points and take careful note of telling details. Perhaps this will help: I have enough experience as a developer that I can tell very quickly where the person I'm talking to falls on the skill spectrum. Part of my negative reaction to this post is that I sense the author does as well; however, where he chooses to make them feel small, I just keep asking questions because I want to give them more opportunities to sell me on their strengths. Their ability to whiteboard leetcode in an interview has laughably close to zero relationship to how they will perform on a Wednesday in jeans without feeling like they are being interrogated, so I largely skip that. If you cannot quickly tell someone's experience (or BS level) from talking with them, then this interview style will not work for you. I have had a dud rate of about 8-12% over the past 15 years. However, only 1/3rd of those were duds because they fooled me. It was almost always personality issues that I didn't anticipate; not getting on well with other people on the team, etc. One of those that fooled me came in hot because he had started a popular testing framework, so I didn't dig. I fooled myself by accepting him based on the reputation of the project, not the person. Lesson learned. However, I would like to turn the question around and brag a moment about how amazing some of the hires were. I hired the creator of Sass, a future Basecamp developer, several future founders. No whiteboards in sight.
- koonsolo 4y ago
  Maybe the difference is that I do a lot of hiring of junior frontend devs. I interview people that never developed before and now took a 3 month bootcamp for example. The things they can tell me is basically their curriculum. What I found was working the best was showing them code and they they explain to me what's happening, and I ask some practical questions on that code ("what would happen if I change this?", etc) I moved from your kind of inteview to a more technical "explain this piece of code to me, what would it do?". But it's possible the kind of developers I see have different experience level than the ones you see. I also still interview seniors (maybe 1 out of 10). Maybe I have to think about changing their interview a bit. The thing is with frontend, you can get a senior that basically did mostly html and never serious programming. And so if you build a complex web app, you really need to see how far they can go with their development skills.
  - peteforde 4y ago
    I can't address most of your reply without sounding like an evil gatekeeper, but yes - it's safe to say that when I'm hiring, I'm interviewing the people our team needs to rely on today, not someone who might grow into the role after the company fails. To be honest, it's super frustrating that we can't have that conversation without an army of bootcamp grads accusing us of elitism. Only a decade ago, it wasn't controversial to expect that people applying for highly demanding technical positions were ready to start on Monday. I digress. As to the senior HTML artist... I feel like that's on you to suss out in the conversation. Another one of my elitist views is that someone who can only do HTML - literally, text markup - is not a senior talent. If you want to make sure that a candidate understands how an MVC framework works, ask them to talk about their thoughts on service objects, or when they use Redis vs Postgres, or whether they have used Sidekiq jobs to do cool things. You can interrogate them to a wild degree and check off all of your boxes while making it feel like you're just shooting the shit. It's almost impossible to bullshit your way through explaining how you implemented a key-based authentication mechanism over websockets. Writing out the code on a board accomplishes nothing. I know how it's done, and I'll know in 15 seconds if a person shuts down, terrified, when talking about it.

peteforde 4y ago

I talk to them and get them talking about how they have solved problems in the past. I will dig in on interesting points and take careful note of telling details. Perhaps this will help: I have enough experience as a developer that I can tell very quickly where the person I'm talking to falls on the skill spectrum. Part of my negative reaction to this post is that I sense the author does as well; however, where he chooses to make them feel small, I just keep asking questions because I want to give them more opportunities to sell me on their strengths. Their ability to whiteboard leetcode in an interview has laughably close to zero relationship to how they will perform on a Wednesday in jeans without feeling like they are being interrogated, so I largely skip that. If you cannot quickly tell someone's experience (or BS level) from talking with them, then this interview style will not work for you. I have had a dud rate of about 8-12% over the past 15 years. However, only 1/3rd of those were duds because they fooled me. It was almost always personality issues that I didn't anticipate; not getting on well with other people on the team, etc. One of those that fooled me came in hot because he had started a popular testing framework, so I didn't dig. I fooled myself by accepting him based on the reputation of the project, not the person. Lesson learned. However, I would like to turn the question around and brag a moment about how amazing some of the hires were. I hired the creator of Sass, a future Basecamp developer, several future founders. No whiteboards in sight.

koonsolo 4y ago
Maybe the difference is that I do a lot of hiring of junior frontend devs. I interview people that never developed before and now took a 3 month bootcamp for example. The things they can tell me is basically their curriculum. What I found was working the best was showing them code and they they explain to me what's happening, and I ask some practical questions on that code ("what would happen if I change this?", etc) I moved from your kind of inteview to a more technical "explain this piece of code to me, what would it do?". But it's possible the kind of developers I see have different experience level than the ones you see. I also still interview seniors (maybe 1 out of 10). Maybe I have to think about changing their interview a bit. The thing is with frontend, you can get a senior that basically did mostly html and never serious programming. And so if you build a complex web app, you really need to see how far they can go with their development skills.
- peteforde 4y ago
  I can't address most of your reply without sounding like an evil gatekeeper, but yes - it's safe to say that when I'm hiring, I'm interviewing the people our team needs to rely on today, not someone who might grow into the role after the company fails. To be honest, it's super frustrating that we can't have that conversation without an army of bootcamp grads accusing us of elitism. Only a decade ago, it wasn't controversial to expect that people applying for highly demanding technical positions were ready to start on Monday. I digress. As to the senior HTML artist... I feel like that's on you to suss out in the conversation. Another one of my elitist views is that someone who can only do HTML - literally, text markup - is not a senior talent. If you want to make sure that a candidate understands how an MVC framework works, ask them to talk about their thoughts on service objects, or when they use Redis vs Postgres, or whether they have used Sidekiq jobs to do cool things. You can interrogate them to a wild degree and check off all of your boxes while making it feel like you're just shooting the shit. It's almost impossible to bullshit your way through explaining how you implemented a key-based authentication mechanism over websockets. Writing out the code on a board accomplishes nothing. I know how it's done, and I'll know in 15 seconds if a person shuts down, terrified, when talking about it.