6 ms·

> There was no white-boarding, no solving difficult algorithms on the spot and no trick questions. > I got through to the second stage on one job I applied for

> There was no white-boarding, no solving difficult algorithms on the spot and no trick questions. > I got through to the second stage on one job I applied for which was a take home coding exercise. The other interview I was offered the job on the spot. This is how you interview. She obviously is very self-driven and a good communicator. If she were hurled some leetcode, there's a good chance she would have failed (as do so many devs with years more experience than her) and yet even reading this post made me think she's a great hire. Managers: fight to change your hiring process. Throw out coding tests, leetcode and white board shenanigans. Invest in your own skills so you can quickly and accurately identify talented people. Take chances on unusual backgrounds. Not only will you save a bunch of everyone's time, you'll have a more organic culture and pick up diamonds that places like Google will pass over every time.

notus 7y ago
My favorite interviews are when they give me a take home project that takes 2-3 hours and then during the technical interview you go over the solution and talk about ways to improve it. It gives applicants a chance to actually prepare for the interview in a meaningful way and I personally am much less nervous for this type of interview.
- malvosenior 7y ago
  I think this is a great way to do it. I don't even give people take home assignments, but a small project coded on the applicant's own time, not in real-time with the interviewers watching is far superior to the alternative. Live coding a problem you were just given, in front of strangers that are also evaluating you for a job is not a good way to evaluate candidates. Interviewing for a job is already a stressful situation, adding live coding to the mix takes it far into absurdly difficult territory. No real life job conditions match that type of situation, and if they do then there are other much bigger problems at play in that company.
- 11thEarlOfMar 7y ago
  This is our approach. Choose one of five assignments, we ask for 100 lines of code, take it home, take as much time as you need. When you come back, we do a code walk through with the team. We've hired only great people with this approach, and they've told me after the fact that they really appreciated that it tested them in a natural manner, rather than a type of competition.
  - ebiester 7y ago
    I'm starting to feel like we're self-organizing a bit into types of companies based on our interviewing styles. There are developers who excel at whiteboarding. There are those who excel at presenting their own projects from their github experience. There are yet others that excel in small code samples on company-driven problems, and some that excel in larger code samples. The truth is that no one interviewing style works best for finding all developers that are a match for the company. Either we need to accommodate multiple interviewing practices, or we need to accept that we are going to gather in the companies that match our interviewing styles the best. I wonder sometimes if there isn't room for a company that hires everyone who can fizzbuzz and is a good fit for the company as determined by behavioral interviews, and then accept a large attrition within the first 3 months. I think the honest truth is that no matter what we do, interviewing is a hard problem.
  - manthedudeguy 7y ago
    > we ask for 100 lines of code Why?
    - 11thEarlOfMar 7y ago
      We don't want them to spend too much time. I tell them we don't expect them to spend more than 2 hours, and we're looking for 100 lines. I don't think it's reasonable to ask for much more of their time than that. Turns out they all wind up spending 8+ hours and most really get into the task.
      - shantly 7y ago
        I love a rough lines/size guide and will be stealing that idea :-) The biggest risk with those take-home projects is that you'll lose out on the "2-3 hour project" because someone else spent 5-6 hours and had time not to just finish it, but to make it look very polished—unreasonably polished for 2-3 hours. So you either do it as directed and worry, or spend way more time on it (enough that I'd probably just pass unless it was one hell of a job) Keep it small enough and you don't run into the thing where you're excluding the semi-happily employed, competent devs, because they don't really have to put up with your shit to find new employment, which is the case with those defined time (but not really) larger projects.
asdfman123 7y ago
Outside of SV these kind of saner interviews are the norm. It's totally possible to get a job if you straight up refuse to do whiteboarding.
- algaeontoast 7y ago
  This is also a standard in Boston and now Austin TX.
  - chrshawkes 7y ago
    Lots of places in DC do this as well. I think it's mostly a startup thing. I commonly refer to one of the greatest C++ programmers of all time (Scott Meyers) as an authority on this stupid hazing ritual. "I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate." https://en.wikipedia.org/wiki/Scott_Meyers https://en.wikipedia.org/wiki/Scott_Meyers
    - shantly 7y ago
      Places with ex-FAANGers in decision-making positions seem to favor it. Nevermind their business is a boring-ass CRUD app and their anticipated usage patterns will only require solving "hard" problems to scale if they totally fuck it up. [EDIT] and on the topic of your quote, in actual work screwing up while working through problems in a meeting or while collaborating is (or had better be) normal, and everyone's working together to find the right solutions. If you miss something you missed it, that's fine, even if it was something dumb, everyone does that all the time, NBD, unless you're doing it just constantly no-one will think a thing of it. Expectations, explicit and implicit, in an interview make it way less friendly and safe feeling than even a very important or relatively high-stress task in actual work life. It's not even in the same category of activity as solving problems at work.
- unlinked_dll 7y ago
  Outside SV they'll send you absurd hackerrank problems after a 5 min phone call with a recruiter on contingency. Which is arguably worse than whiteboarding.
rvz 7y ago
I agree. For this particular role, there is little to no justification to use whiteboarding or Leetcode that would be relevant to this role. Being self taught + open-source contributions or projects is enough to get hired. If this was for a more senior role with many candidates, I would raise the bar a bit to filter those that aren't serious or are unable to critically reason with technical/non-technical decisions. It's funny to see that most startups adopting whiteboarding practices can't justify their questions other than mimicking FAANG or stroking their egos over candidates by asking ridiculous algorithms questions they are unlikely to use, unless they can justified it otherwise. Hiring is difficult because of managers that are still obsessed with finding the so-called "talent" when they're actually looking for that legendary senior 10x developer who knows them and the interview konami code, which wastes time and doesn't exist. The interview process in this article gets straight to the point which results in a justified hire of a very qualified candidate. Well Done!
algaeontoast 7y ago
Sorry, but this is simply not the reality in software dev interviewing. This is a great story and all, but this kind of media is setting up people to fail.
notadoc 7y ago
Making candidates white board is basically an ego driven hazing process, "we had to do this stupid exercise, so you have to as well! Ha ha!" It also gives people a bad taste in their mouth, don't ever forget the candidate is interviewing the company as well. The best response is to immediately walk up and leave when asked to white board something, stating something to the effect of "sorry but if this is your company culture, I'm not a good fit". I know several people who have done this and were hired anyway. Look at a candidates successes and body of work, if their competency isn't obvious from what they have demonstrably accomplished, they probably aren't the right candidate. No amount of white boarding (or the nonsensical "thought exercise" questions) is going to change that.
- chrshawkes 7y ago
  I do this but clarify what the interview process is like as a first step to communicating with a company. As soon as they state this as their intention I tell them I'm not interested. I've been hired at places anyways. My personal opinion is that I have enough projects, years of experience getting a paycheck each week and GitHub/Stack Overflow contributions to verify I at least have a grasp of what it takes to be a web programmer. I refuse the white board exercises outright. I won't do large homework assignments either.
- souprock 7y ago
  There is no public body of work if the person kept busy working under an NDA. You certainly couldn't see the code (not that you could know who did what as part of a team) and you might not even get to know what the project was.
runT1ME 7y ago
I've been involved in software for almost twenty years, and while I'd agree the a majority of whiteboard interviewing is done poorly, it is something that developed out of necessity to both filter bad candidates and have a more objective interivew process. When I first got into the industry, it was much more rare to have coding tests vs. just general interviews, and that meant teams often hired the best talkers or the folks who boasted the most about their accomplishments, and those two skills had very little correlation to how well someone could code. Even worse, 'team fit' was often prioritized above others, so be it on purpose or implicitly, good candidates from diverse backgrounds were much easier to overlook. When you have the majority of engineers solely focusing on 'can this person solve a problem', it is harder to argue against strong candidates just because they look older/younger/darker/lighter/more feminine/masculine etc. Take home tests are incredibly biased against candidates without free time, and as I've pointed out in other places, can easily be abused by spamming candidates with them which is just not possible with whiteboard coding. Coding tests are the best way to hire, if they are done right. They aren't perfect, but so much better than take home tests and 'discussion' based interviews.
- malvosenior 7y ago
  As someone who also has 20 years of experience I strongly disagree. I've never experienced the mythical person who can talk their way through the depths and details of a project but can't code. I think that concept got cargo culted at some point, but it's not nearly as big of a risk as people make it out to be.
  - shantly 7y ago
    I think it'd be really fucking impressive if someone could discuss the ins and outs of systems they've used, likes and dislikes, taking conversational questions about it that they don't know about in advance, without setting off any alarms, while not actually knowing anything. That'd be wild. I think a lot of the whiteboarding/leetcode stuff is just hazing, a desire for "standard" processes (every candidate has a different background, so a well-done conversational interview will differ a ton per-candidate), as a bit of a time-filler ("that's right [C-suite person who's asking questions] we have very rigorous hiring, look, it takes six hours, and see all these steps! Only getting the best of the best, I assure you."), and because if it's scripted you can have mid-level devs do it—poorly, for the most part, since conducting a good whiteboard/leetcode interview is possible, so far as that goes, but it's not easy and requires serious people skills, which is a big part of where places go wrong I think, and also tends to make it look so non-cookie-cutter that if you squint it's not really that much more "standardized" than the conversational version.
Gunax 7y ago
I think there can be just as many issues with that style too. There are so many critiques possible, it's difficult to know what to focus on. Some people care about algorithm efficiency, and others don't. Some interviewers require test coverage and expect you to work under tdd. Or maybe you arrive and some guy frowns when you reveal you didn't prepare DB query plans for your 3 hour assignment. I suppose what I mean is: it feels to me like just trading one kind of arbitrariness for another. Coding in general is highly opinionated (who hasn't had a disagreement during code review). I have had a particularly bad take-away experience and so I am shy of them now.

notus 7y ago

My favorite interviews are when they give me a take home project that takes 2-3 hours and then during the technical interview you go over the solution and talk about ways to improve it. It gives applicants a chance to actually prepare for the interview in a meaningful way and I personally am much less nervous for this type of interview.

malvosenior 7y ago
I think this is a great way to do it. I don't even give people take home assignments, but a small project coded on the applicant's own time, not in real-time with the interviewers watching is far superior to the alternative. Live coding a problem you were just given, in front of strangers that are also evaluating you for a job is not a good way to evaluate candidates. Interviewing for a job is already a stressful situation, adding live coding to the mix takes it far into absurdly difficult territory. No real life job conditions match that type of situation, and if they do then there are other much bigger problems at play in that company.
11thEarlOfMar 7y ago
This is our approach. Choose one of five assignments, we ask for 100 lines of code, take it home, take as much time as you need. When you come back, we do a code walk through with the team. We've hired only great people with this approach, and they've told me after the fact that they really appreciated that it tested them in a natural manner, rather than a type of competition.
- ebiester 7y ago
  I'm starting to feel like we're self-organizing a bit into types of companies based on our interviewing styles. There are developers who excel at whiteboarding. There are those who excel at presenting their own projects from their github experience. There are yet others that excel in small code samples on company-driven problems, and some that excel in larger code samples. The truth is that no one interviewing style works best for finding all developers that are a match for the company. Either we need to accommodate multiple interviewing practices, or we need to accept that we are going to gather in the companies that match our interviewing styles the best. I wonder sometimes if there isn't room for a company that hires everyone who can fizzbuzz and is a good fit for the company as determined by behavioral interviews, and then accept a large attrition within the first 3 months. I think the honest truth is that no matter what we do, interviewing is a hard problem.
- manthedudeguy 7y ago
  > we ask for 100 lines of code Why?
  - 11thEarlOfMar 7y ago
    We don't want them to spend too much time. I tell them we don't expect them to spend more than 2 hours, and we're looking for 100 lines. I don't think it's reasonable to ask for much more of their time than that. Turns out they all wind up spending 8+ hours and most really get into the task.
    - shantly 7y ago
      I love a rough lines/size guide and will be stealing that idea :-) The biggest risk with those take-home projects is that you'll lose out on the "2-3 hour project" because someone else spent 5-6 hours and had time not to just finish it, but to make it look very polished—unreasonably polished for 2-3 hours. So you either do it as directed and worry, or spend way more time on it (enough that I'd probably just pass unless it was one hell of a job) Keep it small enough and you don't run into the thing where you're excluding the semi-happily employed, competent devs, because they don't really have to put up with your shit to find new employment, which is the case with those defined time (but not really) larger projects.

asdfman123 7y ago

Outside of SV these kind of saner interviews are the norm. It's totally possible to get a job if you straight up refuse to do whiteboarding.

algaeontoast 7y ago
This is also a standard in Boston and now Austin TX.
- chrshawkes 7y ago
  Lots of places in DC do this as well. I think it's mostly a startup thing. I commonly refer to one of the greatest C++ programmers of all time (Scott Meyers) as an authority on this stupid hazing ritual. "I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate." https://en.wikipedia.org/wiki/Scott_Meyers https://en.wikipedia.org/wiki/Scott_Meyers
  - shantly 7y ago
    Places with ex-FAANGers in decision-making positions seem to favor it. Nevermind their business is a boring-ass CRUD app and their anticipated usage patterns will only require solving "hard" problems to scale if they totally fuck it up. [EDIT] and on the topic of your quote, in actual work screwing up while working through problems in a meeting or while collaborating is (or had better be) normal, and everyone's working together to find the right solutions. If you miss something you missed it, that's fine, even if it was something dumb, everyone does that all the time, NBD, unless you're doing it just constantly no-one will think a thing of it. Expectations, explicit and implicit, in an interview make it way less friendly and safe feeling than even a very important or relatively high-stress task in actual work life. It's not even in the same category of activity as solving problems at work.
unlinked_dll 7y ago
Outside SV they'll send you absurd hackerrank problems after a 5 min phone call with a recruiter on contingency. Which is arguably worse than whiteboarding.

rvz 7y ago

I agree. For this particular role, there is little to no justification to use whiteboarding or Leetcode that would be relevant to this role. Being self taught + open-source contributions or projects is enough to get hired. If this was for a more senior role with many candidates, I would raise the bar a bit to filter those that aren't serious or are unable to critically reason with technical/non-technical decisions. It's funny to see that most startups adopting whiteboarding practices can't justify their questions other than mimicking FAANG or stroking their egos over candidates by asking ridiculous algorithms questions they are unlikely to use, unless they can justified it otherwise. Hiring is difficult because of managers that are still obsessed with finding the so-called "talent" when they're actually looking for that legendary senior 10x developer who knows them and the interview konami code, which wastes time and doesn't exist. The interview process in this article gets straight to the point which results in a justified hire of a very qualified candidate. Well Done!

algaeontoast 7y ago

Sorry, but this is simply not the reality in software dev interviewing. This is a great story and all, but this kind of media is setting up people to fail.

notadoc 7y ago

Making candidates white board is basically an ego driven hazing process, "we had to do this stupid exercise, so you have to as well! Ha ha!" It also gives people a bad taste in their mouth, don't ever forget the candidate is interviewing the company as well. The best response is to immediately walk up and leave when asked to white board something, stating something to the effect of "sorry but if this is your company culture, I'm not a good fit". I know several people who have done this and were hired anyway. Look at a candidates successes and body of work, if their competency isn't obvious from what they have demonstrably accomplished, they probably aren't the right candidate. No amount of white boarding (or the nonsensical "thought exercise" questions) is going to change that.

chrshawkes 7y ago
I do this but clarify what the interview process is like as a first step to communicating with a company. As soon as they state this as their intention I tell them I'm not interested. I've been hired at places anyways. My personal opinion is that I have enough projects, years of experience getting a paycheck each week and GitHub/Stack Overflow contributions to verify I at least have a grasp of what it takes to be a web programmer. I refuse the white board exercises outright. I won't do large homework assignments either.
souprock 7y ago
There is no public body of work if the person kept busy working under an NDA. You certainly couldn't see the code (not that you could know who did what as part of a team) and you might not even get to know what the project was.

runT1ME 7y ago

I've been involved in software for almost twenty years, and while I'd agree the a majority of whiteboard interviewing is done poorly, it is something that developed out of necessity to both filter bad candidates and have a more objective interivew process. When I first got into the industry, it was much more rare to have coding tests vs. just general interviews, and that meant teams often hired the best talkers or the folks who boasted the most about their accomplishments, and those two skills had very little correlation to how well someone could code. Even worse, 'team fit' was often prioritized above others, so be it on purpose or implicitly, good candidates from diverse backgrounds were much easier to overlook. When you have the majority of engineers solely focusing on 'can this person solve a problem', it is harder to argue against strong candidates just because they look older/younger/darker/lighter/more feminine/masculine etc. Take home tests are incredibly biased against candidates without free time, and as I've pointed out in other places, can easily be abused by spamming candidates with them which is just not possible with whiteboard coding. Coding tests are the best way to hire, if they are done right. They aren't perfect, but so much better than take home tests and 'discussion' based interviews.

malvosenior 7y ago
As someone who also has 20 years of experience I strongly disagree. I've never experienced the mythical person who can talk their way through the depths and details of a project but can't code. I think that concept got cargo culted at some point, but it's not nearly as big of a risk as people make it out to be.
- shantly 7y ago
  I think it'd be really fucking impressive if someone could discuss the ins and outs of systems they've used, likes and dislikes, taking conversational questions about it that they don't know about in advance, without setting off any alarms, while not actually knowing anything. That'd be wild. I think a lot of the whiteboarding/leetcode stuff is just hazing, a desire for "standard" processes (every candidate has a different background, so a well-done conversational interview will differ a ton per-candidate), as a bit of a time-filler ("that's right [C-suite person who's asking questions] we have very rigorous hiring, look, it takes six hours, and see all these steps! Only getting the best of the best, I assure you."), and because if it's scripted you can have mid-level devs do it—poorly, for the most part, since conducting a good whiteboard/leetcode interview is possible, so far as that goes, but it's not easy and requires serious people skills, which is a big part of where places go wrong I think, and also tends to make it look so non-cookie-cutter that if you squint it's not really that much more "standardized" than the conversational version.

Gunax 7y ago

I think there can be just as many issues with that style too. There are so many critiques possible, it's difficult to know what to focus on. Some people care about algorithm efficiency, and others don't. Some interviewers require test coverage and expect you to work under tdd. Or maybe you arrive and some guy frowns when you reveal you didn't prepare DB query plans for your 3 hour assignment. I suppose what I mean is: it feels to me like just trading one kind of arbitrariness for another. Coding in general is highly opinionated (who hasn't had a disagreement during code review). I have had a particularly bad take-away experience and so I am shy of them now.