6 ms·

I've hired close to 100 developers across three companies that I started, and it has never occurred to me to compel a candidate to regurgitate memorized algorit

I've hired close to 100 developers across three companies that I started, and it has never occurred to me to compel a candidate to regurgitate memorized algorithms in an awkward, stressful moment because that doesn't test anything close to what they will actually do in a typical day. Key point: I've never met anyone in the industry whose job it is to implement algorithms without reference materials all day long. It's more like... you might find yourself needing 1-2 clever bits a year, and the rest of the time you're tweaking model classes and hunting down UI bugs. Algorithms are both easy to Google and these days, CoPilot will do the hard 4/5ths for you if you actually need them. It's also common that the really intense stuff is written by the PhD braintrust cofounder, not the people being hired after the fact. What I want to know when I'm interviewing is simple: how do you approach solving problems; do you have an interesting personality that I'd like to interact with every day; are you the sort of person who has a strong instinct about what the next thing to do is, and will default to working on that thing without prompting? Do you think learning new things is exciting? Are you able to admit you don't know something and do you feel comfortable asking for help when you're stuck? Do you seem reliable? Are you a starter, a finisher or both? Do you have a sense of humour? What do you do on the weekend? Ultimately, I care what you know... but I am far more interested in your capacity to quickly master new things.

skatanski 4y ago
Agreed. Its often easier to teach someone a technical skill, but impossible to change them, if their personality is not a good fit. If they have a tendency to be passive-aggressive or have a code related ocd. Not saying its easy to recognize these characteristics during an interview. I had much more trouble with poor communication skills, rather than lack of technical prowess.
isaacremuant 4y ago
Agree with everything but this: > Do you have a sense of humour? What do you do on the weekend? It's none of your business what I do on the weekend. It doesn't need to be similar to what you do. Otherwise you'll tend to only hire people like you and reduce the pool of talent because you can only work with a very specific type of people.
- peteforde 4y ago
  I think that your reaction to what I wrote is fair, but please allow me to further qualify. My intention for the question is not to judge the answer, or compare it to what I like to do; the important issue is that they have an answer! I cannot tell you how many folks I've interviewed (and not hired) who, when asked about their hobbies, immediately start listing programming languages and frameworks. This is not the answer I'm looking for. In fairness to me, there's an almost infinite number of great answers to the question. You can say "music"! I will really respect someone who tells me that they like television. That person is honest. Cooking! Model rockets. Literally just say anything other than a bunch of acronyms. I'm specifically not asking about which church or sex club they go to, and that's made contextually apparent from the conversation leading to that point. I have a strong belief that a well-rounded candidate has interests beyond coding. If they live to code, they probably aren't going to be a good fit, so I save everyone the trouble.
FabHK 4y ago
> compel a candidate to regurgitate memorized algorithms That's not what the author's question was about. Rather, it presented a problem, and wanted to see some approaches to that problem and a discussion of their properties (runtime, limitations, etc.). > how do you approach solving problems > Do you think learning new things is exciting? Are you able to admit you don't know something and do you feel comfortable asking for help when you're stuck? All very reasonable criteria. So how do you evaluate a candidate on those metrics, if not by giving example problems? (ideally different ones: a few theoretical ones like the one under discussion here, a few practical ones with access to google/Stackoverflow/etc.) > do you have an interesting personality that I'd like to interact with every day That's your prerogative, of course, but I wouldn't make that a hiring criterion. I have colleagues who are incredibly boring, yet deliver solid consistent results. Who cares about their personality?
- peteforde 4y ago
  > Rather, it presented a problem, and wanted to see some approaches to that problem and a discussion of their properties I suppose I perceive the narrative differently; it really sounds like the author has a complex roleplaying scenario in mind, where there's a base assumption that he is the smartest person in the room and pre-plans 3-4 moments where he can assert this. If I was the candidate, I would be praying that this guy isn't my direct boss. > So how do you evaluate a candidate on those metrics, if not by giving example problems? Simple: 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. > Who cares about their personality? We have to agree to disagree here. Personality is huge, probably just behind potential. In real terms, if I am going to spend more time with my coworkers than I am with my life partner, they better be trending towards great company. One of the questions I ask myself during an interview is whether I would want to be in a band with this person. If I wouldn't enjoy driving across the country in a van with them, what makes me think I would be able to do my best work if I'm trapped doing it with someone I don't like? There are enough brilliant nice people in the world that I can comfortably avoid hiring brilliant jerks and come out way ahead on every metric.
koonsolo 4y ago
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.
thebigspacefuck 4y ago
It might be a good interview question to give a problem then show some copilot generated code and then have the candidate analyze it, walk through whether it solves their problem, and how they would change it to make it ready for a PR.

skatanski 4y ago

Agreed. Its often easier to teach someone a technical skill, but impossible to change them, if their personality is not a good fit. If they have a tendency to be passive-aggressive or have a code related ocd. Not saying its easy to recognize these characteristics during an interview. I had much more trouble with poor communication skills, rather than lack of technical prowess.

isaacremuant 4y ago

Agree with everything but this: > Do you have a sense of humour? What do you do on the weekend? It's none of your business what I do on the weekend. It doesn't need to be similar to what you do. Otherwise you'll tend to only hire people like you and reduce the pool of talent because you can only work with a very specific type of people.

peteforde 4y ago
I think that your reaction to what I wrote is fair, but please allow me to further qualify. My intention for the question is not to judge the answer, or compare it to what I like to do; the important issue is that they have an answer! I cannot tell you how many folks I've interviewed (and not hired) who, when asked about their hobbies, immediately start listing programming languages and frameworks. This is not the answer I'm looking for. In fairness to me, there's an almost infinite number of great answers to the question. You can say "music"! I will really respect someone who tells me that they like television. That person is honest. Cooking! Model rockets. Literally just say anything other than a bunch of acronyms. I'm specifically not asking about which church or sex club they go to, and that's made contextually apparent from the conversation leading to that point. I have a strong belief that a well-rounded candidate has interests beyond coding. If they live to code, they probably aren't going to be a good fit, so I save everyone the trouble.

FabHK 4y ago

> compel a candidate to regurgitate memorized algorithms That's not what the author's question was about. Rather, it presented a problem, and wanted to see some approaches to that problem and a discussion of their properties (runtime, limitations, etc.). > how do you approach solving problems > Do you think learning new things is exciting? Are you able to admit you don't know something and do you feel comfortable asking for help when you're stuck? All very reasonable criteria. So how do you evaluate a candidate on those metrics, if not by giving example problems? (ideally different ones: a few theoretical ones like the one under discussion here, a few practical ones with access to google/Stackoverflow/etc.) > do you have an interesting personality that I'd like to interact with every day That's your prerogative, of course, but I wouldn't make that a hiring criterion. I have colleagues who are incredibly boring, yet deliver solid consistent results. Who cares about their personality?

peteforde 4y ago
> Rather, it presented a problem, and wanted to see some approaches to that problem and a discussion of their properties I suppose I perceive the narrative differently; it really sounds like the author has a complex roleplaying scenario in mind, where there's a base assumption that he is the smartest person in the room and pre-plans 3-4 moments where he can assert this. If I was the candidate, I would be praying that this guy isn't my direct boss. > So how do you evaluate a candidate on those metrics, if not by giving example problems? Simple: 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. > Who cares about their personality? We have to agree to disagree here. Personality is huge, probably just behind potential. In real terms, if I am going to spend more time with my coworkers than I am with my life partner, they better be trending towards great company. One of the questions I ask myself during an interview is whether I would want to be in a band with this person. If I wouldn't enjoy driving across the country in a van with them, what makes me think I would be able to do my best work if I'm trapped doing it with someone I don't like? There are enough brilliant nice people in the world that I can comfortably avoid hiring brilliant jerks and come out way ahead on every metric.

koonsolo 4y ago

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.

thebigspacefuck 4y ago

It might be a good interview question to give a problem then show some copilot generated code and then have the candidate analyze it, walk through whether it solves their problem, and how they would change it to make it ready for a PR.