6 ms·

I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own c

I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. You should be doing everything you can to put the candidate on their own turf and letting them shine. I have a lot of advice about interviews but one of the best I've heard over the years: whatever impression you have of the candidate try to prove yourself wrong. Using that advice, I've found a lot of great programmers that other companies skip over. Some people who are great at coding are bad at interviews and bad at live problem solving with an audience. If you really feel the need for a test, a paid take home coding assignment will give you the best signal.

haggy 6y ago
I agree with this 100%. I'd also like to add that because of this I adapted the traditional whiteboarding exercise at my current company to be about problem solving and design, and not about how many data structures you've memorized. When a candidate comes in, I give them a fake-yet-realistic product requirement (like count elements in a real-time stream from field sensors) and let them run with it however they see fit. I put zero restrictions on the tech side of things in order to let the candidate shine (hopefully) in whatever tech they are most comfortable with. I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates.
- tchaffee 6y ago
  It sounds like you're trying which is encouraging. I'll give you a few tips that I hope help. > I adapted the traditional whiteboarding exercise Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. No white board. People I already knew. All I had to to do is explain my ideas to three people. I did improve. I've given many public talks sometimes to hundreds of people and today I like public speaking. But I'll never forget where I started and that the person I'm interviewing might be very nervous. Putting them up on a whiteboard and into presentation mode only amplifies that nervousness. Just talk to people. Get them into that flow that comes from talking about something familiar that they are excited about. For most people a whiteboard test is not exciting. But if you give me a paid take home coding exercise, that's exciting. I like code, and I like to get paid for it. So if you really think you need a test, consider a very high signal test that is the exact work they will be doing. > I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates. In an unequal relationship like that you are going to get a lot of false positives. If I really needed a job my response would be "loved the exercise, looking forward to talking to you more and discussing next steps if I'm the right candidate".
  - GeneralMayhem 6y ago
    >Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. That's definitely an unfortunate experience, but isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job? I'm an IC, and I present designs and project plans for feedback to groups of up to a couple dozen people, or to VPs, on a pretty regular basis. If I couldn't do that competently I would be failing at my job, because that kind of communication is just as important as actually writing the code. If I were conducting an interview and discovered that "public" speaking on the order of a few people in a conference room was extremely difficult for you, I'd probably consider that an important red flag.
    - tchaffee 6y ago
      What is an IC? > isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job? For many engineering positions it is not. There are loads of shops where the developers, even senior developers, mostly just write code. I have hired many of them and put them to work successfully building stuff while I deal with the meetings. > If I were conducting an interview and discovered that "public" speaking on the order of a few people in a conference room was extremely difficult for you And yet I worked very successfully as a junior developer for a couple of years before I ever had to attend a meeting like that. Among the other 100 devs in the shop, I was considered a top talent at coding. That's not to brag but to point out that I was adding lots of value to the company without having to attend meetings with people from other departments. My manager did that. My manager did not code, although he could if he wanted to. In fact at that company they created a separate path for highly talented engineers who wanted to continue coding but wanted to avoid management and meetings. That was a couple of decades ago and less common, but I think it's a lot more common now. And the fact that I can now publicly speak in front of hundreds of people should hopefully encourage you that it's something people can learn if they want to. Some people don't want to. There are roles for them too.
      - 6y ago
- TedDoesntTalk 6y ago
  I do something similar: I ask the candidate to take 30 minutes or so to design a system like an online library. What are the objects in the system, how do they relate, can you design a REST or graphQL API for CRUD operations. Then if it’s a front-end position we can move onto UI components for it; for back-end or full stack I focus on implement a couple of the CRUD operations. You really get to see how people think and will work on the job with questions like this. Implementing a sorting algorithm from scratch is a waste of time in many projects: use your libraries and get on with life. That’s why such interview questions are not important to me.
  - nogabebop23 6y ago
    >> You really get to see how people think and will work on the job with questions like this. Interviewing is hard and I applaud you for trying something newer and more realistic but I'd be cautious in thinking "spend 30 minutes designing a system and be prepared to defend your work with massive risk/reward hanging in the balance. Begin... NOW!!!!" is representative of how someone will work on the job. There are an awful lot of people who will solve the crux problems driving home after the interview or the next morning in the shower vs. on-demand.
    - TedDoesntTalk 6y ago
      Very true. I certainly don’t say BEGIN NOW! It’s a conversation. I continually ask questions during the design and ask the candidate to speak about the decisions being made. In all honesty this process can easily last more than 30 minutes. This is not a hard problem for someone with the experience I want, and there are many different correct answers.
  - abower 6y ago
    Agree. Its far more valuable to see how a candidate approaches problems than some memorized recital show. I don't expect perfection, but if their reasoning is sound that becomes clear fairly quickly. I usually also include some imperfect questions purposely to see how they handle that. While we wish client projects were nice and clean with orderly data and tight requirements, the truth is that is rarely the case. It's useful to see how the candidate responds to those types of things. I had one gentleman argue with me about one of those questions claiming you would never see primary and foreign keys between tables not perectly match in the real world. Well when you are matching data from entirely disparate systems, you typically do. Anyway I digress.
kypro 6y ago
I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. Personally I'm way too anxious in interview settings to produce decent code. In interviews I find myself trying to get everything right first time, but in reality that's not how I work. I prefer to develop iteratively and debug as I go. I'm also quite a slow and deep thinker. It's not uncommon for me to think about a problem for a good 15-20 minutes before writing any code. In this case I guess you would have some time to prep the night before, but I'd still be very nervous about coding on the day. I prefer home assignments and that's typically what I'll do when interviewing people. I like to keep it simple and open ended. Simple because I don't want to waste their time and open ended to allow them some room for creativity because often we don't have explicit requirements in the real world. This has always worked quite well.
- fatnoah 6y ago
  >I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. I've never been a big fan of giving code interviews, however when I have to give them, I'm far more interested in the candidate's thought process around how they understand the problem and what needs to be considered in building the solution.
  - redblacktree 6y ago
    I agree, and I think this is where the value in these kinds of interview techniques lie. As the interviewee though, I have to say that the high-pressure situation makes me feel very... exposed(?) when I have to elucidate my thought process in real time. I will say that one of the best "interviews" I've had included a portion where I worked with one of their engineers on a design problem they were actually having. It felt very collaborative, which allowed me to relax a bit, and I think we came up with a pretty good solution. I didn't mind doing "free work," because for me, it's fun to solve problems like these.
heavyset_go 6y ago
> Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. Agreed. The best jobs I've taken had interviews like this, or paid assignments.
Taek 6y ago
Talking about code that someone has already written is missing the element of productivity. Since we pay you by the week and only get so many hours a week out of you, we need some way before we hire you to understand what type of output we can expect. The best way I know would be to work with someone for a week or two on a real problem, but that's way too expensive to trial a junior role. At least for us, the system is more optimized around avoiding false positives than ensuring we don't pass over someone good.
- sushshshsh 6y ago
  Your current system is better. I'm happy to take 15 minutes of my life to prepare for your interview instead of 1 week. Since the denial rate in our industry is so high, you can see which one is more preferable.
- Yajirobe 6y ago
  Programming in an interview environment is completely different from programming at your 9-5 desk.
  - recursive 6y ago
    Everything else in an interview is also completely different from 9-5 engineering.
    - tchaffee 6y ago
      Due to a lack of imagination and people who don't host interviews on a regular basis so they never put in the effort to get good at it. When I conduct a technical interview we are going to end up doing some stuff you do in your 9-5. And you probably won't even notice it. And if there is a budget available for it, I'm going to pay you to do a very small coding assignment. A few hours. Almost exactly your 9-5.
      - recursive 6y ago
        The fundamental difference is that a job is directly at stake based on your performance. For many people, this makes them more nervous than they would ever generally be during work. Due to the nature of interviews, I don't think there's really a way for it to be otherwise.
sushshshsh 6y ago
Good thing you don't want it because I'll happily take it.
sufyanadam 6y ago
You nailed it. This is the fairest proposal with the best outcome for all sides. Thank you for posting.
shecky 6y ago
> Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal where have you been all my life? ;) I'm an autodidact, zero formal bg in comp sci. I suck at timed tests and algo interviews. Fifteen years I've been at this and I've worked with several 'full stack' teams, none of which had a single engineer who was within a thousand miles of what I could do with CSS (and they're mostly utter slobs wrt HTML). And as to the endless javascript demands, I will never be of interest to google (and the feeling's mutual) but I always get the job done, and often the job is something FE that none of my esteemed colleagues would know the first thing about how to achieve, comp sci degrees and recursion expertise notwithstanding ... not to mention that every one of them has as many stack overflow tabs open as me. I'll get back to my sorry little js projects now, maybe I'll get another job before I grow old and die ;)
ajzinsbwbs 6y ago
How to filter out candidates who are only good at talking? I’ve worked with people like that and it’s miserable.

haggy 6y ago

I agree with this 100%. I'd also like to add that because of this I adapted the traditional whiteboarding exercise at my current company to be about problem solving and design, and not about how many data structures you've memorized. When a candidate comes in, I give them a fake-yet-realistic product requirement (like count elements in a real-time stream from field sensors) and let them run with it however they see fit. I put zero restrictions on the tech side of things in order to let the candidate shine (hopefully) in whatever tech they are most comfortable with. I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates.

tchaffee 6y ago
It sounds like you're trying which is encouraging. I'll give you a few tips that I hope help. > I adapted the traditional whiteboarding exercise Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. No white board. People I already knew. All I had to to do is explain my ideas to three people. I did improve. I've given many public talks sometimes to hundreds of people and today I like public speaking. But I'll never forget where I started and that the person I'm interviewing might be very nervous. Putting them up on a whiteboard and into presentation mode only amplifies that nervousness. Just talk to people. Get them into that flow that comes from talking about something familiar that they are excited about. For most people a whiteboard test is not exciting. But if you give me a paid take home coding exercise, that's exciting. I like code, and I like to get paid for it. So if you really think you need a test, consider a very high signal test that is the exact work they will be doing. > I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates. In an unequal relationship like that you are going to get a lot of false positives. If I really needed a job my response would be "loved the exercise, looking forward to talking to you more and discussing next steps if I'm the right candidate".
- GeneralMayhem 6y ago
  >Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. That's definitely an unfortunate experience, but isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job? I'm an IC, and I present designs and project plans for feedback to groups of up to a couple dozen people, or to VPs, on a pretty regular basis. If I couldn't do that competently I would be failing at my job, because that kind of communication is just as important as actually writing the code. If I were conducting an interview and discovered that "public" speaking on the order of a few people in a conference room was extremely difficult for you, I'd probably consider that an important red flag.
  - tchaffee 6y ago
    What is an IC? > isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job? For many engineering positions it is not. There are loads of shops where the developers, even senior developers, mostly just write code. I have hired many of them and put them to work successfully building stuff while I deal with the meetings. > If I were conducting an interview and discovered that "public" speaking on the order of a few people in a conference room was extremely difficult for you And yet I worked very successfully as a junior developer for a couple of years before I ever had to attend a meeting like that. Among the other 100 devs in the shop, I was considered a top talent at coding. That's not to brag but to point out that I was adding lots of value to the company without having to attend meetings with people from other departments. My manager did that. My manager did not code, although he could if he wanted to. In fact at that company they created a separate path for highly talented engineers who wanted to continue coding but wanted to avoid management and meetings. That was a couple of decades ago and less common, but I think it's a lot more common now. And the fact that I can now publicly speak in front of hundreds of people should hopefully encourage you that it's something people can learn if they want to. Some people don't want to. There are roles for them too.
    - 6y ago
TedDoesntTalk 6y ago
I do something similar: I ask the candidate to take 30 minutes or so to design a system like an online library. What are the objects in the system, how do they relate, can you design a REST or graphQL API for CRUD operations. Then if it’s a front-end position we can move onto UI components for it; for back-end or full stack I focus on implement a couple of the CRUD operations. You really get to see how people think and will work on the job with questions like this. Implementing a sorting algorithm from scratch is a waste of time in many projects: use your libraries and get on with life. That’s why such interview questions are not important to me.
- nogabebop23 6y ago
  >> You really get to see how people think and will work on the job with questions like this. Interviewing is hard and I applaud you for trying something newer and more realistic but I'd be cautious in thinking "spend 30 minutes designing a system and be prepared to defend your work with massive risk/reward hanging in the balance. Begin... NOW!!!!" is representative of how someone will work on the job. There are an awful lot of people who will solve the crux problems driving home after the interview or the next morning in the shower vs. on-demand.
  - TedDoesntTalk 6y ago
    Very true. I certainly don’t say BEGIN NOW! It’s a conversation. I continually ask questions during the design and ask the candidate to speak about the decisions being made. In all honesty this process can easily last more than 30 minutes. This is not a hard problem for someone with the experience I want, and there are many different correct answers.
- abower 6y ago
  Agree. Its far more valuable to see how a candidate approaches problems than some memorized recital show. I don't expect perfection, but if their reasoning is sound that becomes clear fairly quickly. I usually also include some imperfect questions purposely to see how they handle that. While we wish client projects were nice and clean with orderly data and tight requirements, the truth is that is rarely the case. It's useful to see how the candidate responds to those types of things. I had one gentleman argue with me about one of those questions claiming you would never see primary and foreign keys between tables not perectly match in the real world. Well when you are matching data from entirely disparate systems, you typically do. Anyway I digress.

kypro 6y ago

I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. Personally I'm way too anxious in interview settings to produce decent code. In interviews I find myself trying to get everything right first time, but in reality that's not how I work. I prefer to develop iteratively and debug as I go. I'm also quite a slow and deep thinker. It's not uncommon for me to think about a problem for a good 15-20 minutes before writing any code. In this case I guess you would have some time to prep the night before, but I'd still be very nervous about coding on the day. I prefer home assignments and that's typically what I'll do when interviewing people. I like to keep it simple and open ended. Simple because I don't want to waste their time and open ended to allow them some room for creativity because often we don't have explicit requirements in the real world. This has always worked quite well.

fatnoah 6y ago
>I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. I've never been a big fan of giving code interviews, however when I have to give them, I'm far more interested in the candidate's thought process around how they understand the problem and what needs to be considered in building the solution.
- redblacktree 6y ago
  I agree, and I think this is where the value in these kinds of interview techniques lie. As the interviewee though, I have to say that the high-pressure situation makes me feel very... exposed(?) when I have to elucidate my thought process in real time. I will say that one of the best "interviews" I've had included a portion where I worked with one of their engineers on a design problem they were actually having. It felt very collaborative, which allowed me to relax a bit, and I think we came up with a pretty good solution. I didn't mind doing "free work," because for me, it's fun to solve problems like these.

heavyset_go 6y ago

> Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. Agreed. The best jobs I've taken had interviews like this, or paid assignments.

Taek 6y ago

Talking about code that someone has already written is missing the element of productivity. Since we pay you by the week and only get so many hours a week out of you, we need some way before we hire you to understand what type of output we can expect. The best way I know would be to work with someone for a week or two on a real problem, but that's way too expensive to trial a junior role. At least for us, the system is more optimized around avoiding false positives than ensuring we don't pass over someone good.

sushshshsh 6y ago
Your current system is better. I'm happy to take 15 minutes of my life to prepare for your interview instead of 1 week. Since the denial rate in our industry is so high, you can see which one is more preferable.
Yajirobe 6y ago
Programming in an interview environment is completely different from programming at your 9-5 desk.
- recursive 6y ago
  Everything else in an interview is also completely different from 9-5 engineering.
  - tchaffee 6y ago
    Due to a lack of imagination and people who don't host interviews on a regular basis so they never put in the effort to get good at it. When I conduct a technical interview we are going to end up doing some stuff you do in your 9-5. And you probably won't even notice it. And if there is a budget available for it, I'm going to pay you to do a very small coding assignment. A few hours. Almost exactly your 9-5.
    - recursive 6y ago
      The fundamental difference is that a job is directly at stake based on your performance. For many people, this makes them more nervous than they would ever generally be during work. Due to the nature of interviews, I don't think there's really a way for it to be otherwise.

sushshshsh 6y ago

Good thing you don't want it because I'll happily take it.

sufyanadam 6y ago

You nailed it. This is the fairest proposal with the best outcome for all sides. Thank you for posting.

shecky 6y ago

> Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal where have you been all my life? ;) I'm an autodidact, zero formal bg in comp sci. I suck at timed tests and algo interviews. Fifteen years I've been at this and I've worked with several 'full stack' teams, none of which had a single engineer who was within a thousand miles of what I could do with CSS (and they're mostly utter slobs wrt HTML). And as to the endless javascript demands, I will never be of interest to google (and the feeling's mutual) but I always get the job done, and often the job is something FE that none of my esteemed colleagues would know the first thing about how to achieve, comp sci degrees and recursion expertise notwithstanding ... not to mention that every one of them has as many stack overflow tabs open as me. I'll get back to my sorry little js projects now, maybe I'll get another job before I grow old and die ;)

ajzinsbwbs 6y ago

How to filter out candidates who are only good at talking? I’ve worked with people like that and it’s miserable.