7 ms·

I think the tide is turning against this type of interview. The industry is starting to notice how ineffective and stupid it is. The big tech companies don't

I think the tide is turning against this type of interview. The industry is starting to notice how ineffective and stupid it is. The big tech companies don't care and will continue doing it because success hides all failures. When there's an endless flood of new college graduate applicants and near-monopoly positions bringing in billions of revenue, nobody cares if the hiring process is bad. They will care someday if those conditions change, but that's in the distant future. Most companies, especially small companies, are not in this position and should have a different process. It's becoming a competitive advantage, especially if a company is looking for senior engineers, to not have this interview process. For example, this list of companies was in a HN story a while ago: https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards The trend is growing and it's a good change for the industry.

dv_dt 9y ago
> The big tech companies don't care and will continue doing it because success hides all failures. Cynically, big companies might be selecting for a modicum of technical expertise along with demonstrating capacity to put up with some amount of abusive processes.
- aanm1988 9y ago
  I think Hanlon's Razor applies. They have no impetus to change and think they have found an approach that works reasonable well when given absurd amounts of candidates. The problem is the ridiculous false negative rate. I struggle to think of a better system. Using experience is unfair and misleading (I worked on awesome stuff... that I can tell you nothing about, I was totally the lead on this software, etc...). Take home stuff is fine with me but a lot of people have problems with it. Come in for a week type things are incredibly applicant hostile. Sit down with me and lets try and fix this bug seems like a more reasonable solution to me. Dev environment has the most popular ide with their devs, the source for whatever, internet access, and a bug report. Person is there to assist.
  - gaylemcd 9y ago
    They have lots of impetus to change. It's just that they struggle to find a better system. Talking about prior experience? Flawed for the reasons you mentioned. Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment). Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here. Sit down and help me fix this bug? Flawed: 1. Huge bias based on whether they know this particular skill set -- the right tools, etc. 2. Pretty arbitrary as to whether they find that particular bug. 3. It can't be a real bug. It has to be a toy project in order to get a consistent evaluation.
    - kaspiCZ 9y ago
      I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right. You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one. I'd argue that they should not be asked to find the bug. Only to fix it. It does not have to be the same bug. I'd argue for a pool they can pick from. You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did. Pairing with someone from the team they'd work in could also provide some insight into the dynamic. I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised.
      - TulliusCicero 9y ago
        > You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail. > Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.
jondubois 9y ago
Yes, the only people/entities who benefit from this type of interview process are the interviewers themselves - They make the interview process needlessly complicated and pointless and then they sell books giving people specific instructions on how to pass those interviews. They create the problem and then they sell the solution as a book or as an online self-help service. All the interview questions do is demonstrate that you've bought the right books and spent hundreds of hours practising pointless coding problems because you have nothing better to do with your time. Maybe big companies are only interested in hiring sheep-like engineers who have no side projects to maintain and no sense of pragmatism... But then why do such companies (e.g. Google) spend hundreds of millions of dollars each year on acquiring startups full of ambitious and pragmatic (wolf-like) people (people who probably would not pass the technical tests). With that strategy, over time, big companies just end up with a few pragmatic wolves at the top and a large number of sheep at the bottom. It's not natural and they're missing out on more balanced candidates who are neither sheep nor wolf but are excellent engineers nonetheless.
- Buge 9y ago
  >Maybe big companies are only interested in hiring sheep-like engineers who have no side projects But the article said that they are interested in people with side projects.
- UncleMeat 9y ago
  Whiteboard interviews are more complicated? The alternatives that people usually put forward are either "code a homework assignment for a few days", "pair program with a full timer for a few hours", or "look closely at the applicant's open source contributions". All of those sound complicated as hell. Perhaps they are more effective, but the whiteboard interview is obviously less complex. And the side projects approach is just laughable considering the number of excellent engineers I know who don't have time or interest to code on their off hours. A good whiteboard question can tell you a bit about the applicant's design sense, knowledge of key data structures and algorithms, and ability to integrate new ideas. It also has the nice benefit of quickly weeding out the huge number of applicants who can't write DFS on a tree.
jerrylives 9y ago
The tide is definitely turning. The last two interviews I've been to were nice casual affairs where me and another engineer had a technical discussion on how I'd approach various problems they were having (such as deployment woes, wonky network topology etc). The best part is that I feel like I learned something as well, rather than just being shown my failure because I didn't get the interviewer's "trick" to how to solve his convoluted non-practical coding puzzle. Both of these companies I can gladly say are some of the best places I've ever worked with bright, motivated engineers and a great culture. I think part of it is that if you know your stuff, you'll be easily able to suss out who is bullshitting in a discussion / debate and who isn't. If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities.
- gaylemcd 9y ago
  > If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities. I agree with this. I tell companies to not ask questions from Cracking the Coding Interview. But that doesn't mean those style of interviews are fundamentally broken. It's just stupid to ask questions that candidates are likely to know.
  - jerrylives 9y ago
    Indeed, I don't write off whiteboard interviewing altogether - if you know exactly what you are hiring for, it can be very helpful to have e.g. a systems engineer write out some C code or go through tree problems. The issue comes in that a lot of people aren't entirely sure what they are hiring for, just that they need a warm body who can code to some arbitrary ability. That's why I always make sure to ask the interviewer what the burning problems are and what kind of action they are looking for on Day One.
gaylemcd 9y ago
So if whiteboard interviews are stupid and ineffective, what process do you think is better? I assure that the big tech companies absolutely do care, but they struggle to find something better.
- kafkaesq 9y ago
  Whiteboard interviews don't have to be ineffective. But empirical evidence suggests that companies greatly overestimate their ability to conduct them properly.
  - pmiller2 9y ago
    So, what's a properly-conducted whiteboard interview look like?
    - milesvp 9y ago
      Mostly talking about previous experience and especially any projects they were persoanally interested in talking about. I find there is only one thing you need to ensure a new hire can handle to avoid the major fakers. Give them a simple problem that requires a for loop. Usually it takes up like 5 minutes of the interview. I started asking it when I realized that the weakest people on my team would get stuck talking about problems that were simple iterations, they'd spend days trying to avoid a simple 'for foo in bar' coding solution. These were people who could program is the weirdest thing too. Fizzbuzz has become sort of a joke meme over the years but I've found Steve Yegge's core idea to be true, and you can see the deer in headlights with even the simplest code problem. So now it's all I do. Whiteboard coding is unnatural enough as it is, there's no reason to haze when all you care about is will they get hung up on stupid trivial things. Most code is basic CRUD there is no reason to ask about b-trees or tris, let alone implement them. If I feel the need to raise the bar even higher, I may include a simple pointer based question, since I've come to notice that indirection another concept that weaker coworkers struggle with. But the problem here, is that pointers just aren't relevant to the majority of what devs do these days, and modern languages do well to hide their usage which means fewer candidates will even have worked in a language like C. So you're likely to get a lot more false negatives. And interviews are stupidly expensive so you really want to avoid false negatives. For reference I work for a company with less than 1000 employees, serving web traffic that needs to handle 2000req/s peak 1000req/s sustained. There is little we do that doesn't fall under basic CRUD. Our biggest tech challenge is cache invalidation, followed by 3rd party API timeouts.

dv_dt 9y ago

> The big tech companies don't care and will continue doing it because success hides all failures. Cynically, big companies might be selecting for a modicum of technical expertise along with demonstrating capacity to put up with some amount of abusive processes.

aanm1988 9y ago
I think Hanlon's Razor applies. They have no impetus to change and think they have found an approach that works reasonable well when given absurd amounts of candidates. The problem is the ridiculous false negative rate. I struggle to think of a better system. Using experience is unfair and misleading (I worked on awesome stuff... that I can tell you nothing about, I was totally the lead on this software, etc...). Take home stuff is fine with me but a lot of people have problems with it. Come in for a week type things are incredibly applicant hostile. Sit down with me and lets try and fix this bug seems like a more reasonable solution to me. Dev environment has the most popular ide with their devs, the source for whatever, internet access, and a bug report. Person is there to assist.
- gaylemcd 9y ago
  They have lots of impetus to change. It's just that they struggle to find a better system. Talking about prior experience? Flawed for the reasons you mentioned. Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment). Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here. Sit down and help me fix this bug? Flawed: 1. Huge bias based on whether they know this particular skill set -- the right tools, etc. 2. Pretty arbitrary as to whether they find that particular bug. 3. It can't be a real bug. It has to be a toy project in order to get a consistent evaluation.
  - kaspiCZ 9y ago
    I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right. You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one. I'd argue that they should not be asked to find the bug. Only to fix it. It does not have to be the same bug. I'd argue for a pool they can pick from. You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did. Pairing with someone from the team they'd work in could also provide some insight into the dynamic. I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised.
    - TulliusCicero 9y ago
      > You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail. > Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.

jondubois 9y ago

Yes, the only people/entities who benefit from this type of interview process are the interviewers themselves - They make the interview process needlessly complicated and pointless and then they sell books giving people specific instructions on how to pass those interviews. They create the problem and then they sell the solution as a book or as an online self-help service. All the interview questions do is demonstrate that you've bought the right books and spent hundreds of hours practising pointless coding problems because you have nothing better to do with your time. Maybe big companies are only interested in hiring sheep-like engineers who have no side projects to maintain and no sense of pragmatism... But then why do such companies (e.g. Google) spend hundreds of millions of dollars each year on acquiring startups full of ambitious and pragmatic (wolf-like) people (people who probably would not pass the technical tests). With that strategy, over time, big companies just end up with a few pragmatic wolves at the top and a large number of sheep at the bottom. It's not natural and they're missing out on more balanced candidates who are neither sheep nor wolf but are excellent engineers nonetheless.

Buge 9y ago
>Maybe big companies are only interested in hiring sheep-like engineers who have no side projects But the article said that they are interested in people with side projects.
UncleMeat 9y ago
Whiteboard interviews are more complicated? The alternatives that people usually put forward are either "code a homework assignment for a few days", "pair program with a full timer for a few hours", or "look closely at the applicant's open source contributions". All of those sound complicated as hell. Perhaps they are more effective, but the whiteboard interview is obviously less complex. And the side projects approach is just laughable considering the number of excellent engineers I know who don't have time or interest to code on their off hours. A good whiteboard question can tell you a bit about the applicant's design sense, knowledge of key data structures and algorithms, and ability to integrate new ideas. It also has the nice benefit of quickly weeding out the huge number of applicants who can't write DFS on a tree.

jerrylives 9y ago

The tide is definitely turning. The last two interviews I've been to were nice casual affairs where me and another engineer had a technical discussion on how I'd approach various problems they were having (such as deployment woes, wonky network topology etc). The best part is that I feel like I learned something as well, rather than just being shown my failure because I didn't get the interviewer's "trick" to how to solve his convoluted non-practical coding puzzle. Both of these companies I can gladly say are some of the best places I've ever worked with bright, motivated engineers and a great culture. I think part of it is that if you know your stuff, you'll be easily able to suss out who is bullshitting in a discussion / debate and who isn't. If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities.

gaylemcd 9y ago
> If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities. I agree with this. I tell companies to not ask questions from Cracking the Coding Interview. But that doesn't mean those style of interviews are fundamentally broken. It's just stupid to ask questions that candidates are likely to know.
- jerrylives 9y ago
  Indeed, I don't write off whiteboard interviewing altogether - if you know exactly what you are hiring for, it can be very helpful to have e.g. a systems engineer write out some C code or go through tree problems. The issue comes in that a lot of people aren't entirely sure what they are hiring for, just that they need a warm body who can code to some arbitrary ability. That's why I always make sure to ask the interviewer what the burning problems are and what kind of action they are looking for on Day One.

gaylemcd 9y ago

So if whiteboard interviews are stupid and ineffective, what process do you think is better? I assure that the big tech companies absolutely do care, but they struggle to find something better.

kafkaesq 9y ago
Whiteboard interviews don't have to be ineffective. But empirical evidence suggests that companies greatly overestimate their ability to conduct them properly.
- pmiller2 9y ago
  So, what's a properly-conducted whiteboard interview look like?
  - milesvp 9y ago
    Mostly talking about previous experience and especially any projects they were persoanally interested in talking about. I find there is only one thing you need to ensure a new hire can handle to avoid the major fakers. Give them a simple problem that requires a for loop. Usually it takes up like 5 minutes of the interview. I started asking it when I realized that the weakest people on my team would get stuck talking about problems that were simple iterations, they'd spend days trying to avoid a simple 'for foo in bar' coding solution. These were people who could program is the weirdest thing too. Fizzbuzz has become sort of a joke meme over the years but I've found Steve Yegge's core idea to be true, and you can see the deer in headlights with even the simplest code problem. So now it's all I do. Whiteboard coding is unnatural enough as it is, there's no reason to haze when all you care about is will they get hung up on stupid trivial things. Most code is basic CRUD there is no reason to ask about b-trees or tris, let alone implement them. If I feel the need to raise the bar even higher, I may include a simple pointer based question, since I've come to notice that indirection another concept that weaker coworkers struggle with. But the problem here, is that pointers just aren't relevant to the majority of what devs do these days, and modern languages do well to hide their usage which means fewer candidates will even have worked in a language like C. So you're likely to get a lot more false negatives. And interviews are stupidly expensive so you really want to avoid false negatives. For reference I work for a company with less than 1000 employees, serving web traffic that needs to handle 2000req/s peak 1000req/s sustained. There is little we do that doesn't fall under basic CRUD. Our biggest tech challenge is cache invalidation, followed by 3rd party API timeouts.