Hacker News new | past | comments | ask | show | jobs | submit login
A listing of companies that don't do whiteboard job interviews (github.com)
369 points by ohjeez 54 days ago | hide | past | web | favorite | 232 comments

Its interesting how many of these companies have 'take home' challenges or projects. Even though the companies may say, "This should only take an hour", 99% of the time, it occupies my entire night/weekend, if not in coding but in thought. There's always something more you could do. Its presented as an objective test, but its very subjective, just as much as the whiteboard test.

With the whiteboard test, as a candidate, I know that when my hour is over, its done. Plus, I can get feedback during my whiteboard session to know if I'm on the right track, I can ask questions and get guidance on where to concentrate my efforts. With take home projects, I've woken up in the middle of the night and thought, "Wait, I know this is a full stack position, and they said that the UX just needs to be functional, but maybe my CSS knowledge is too old, and there's a better/newer way of doing the styles. I should really spend all night researching this, wait, BOM?! I should convert over to that, I don't want the front eng engineer reviewing this code and saying, OMG, this is so old, NOHIRE!"


Also, take home challenges are probably very discriminatory towards older candidates with families. So maybe just as subtle way of age discrimination?

> Also, take home challenges are probably very discriminatory towards older candidates with families. So maybe just as subtle way of age discrimination?

I see this sentiment fairly frequently, and TBH, it completely baffles me. I am in my mid 40s. Yes, I don't have nearly as much energy nor desire to spend all weekend doing take-home programming assignments as I did 20 years ago. But if one candidate is willing to do more work and preparation for an interview, that's not 'discrimination' - that's one person showing they are willing to put more effort into a job than another.

True, your family obligations may mean you don't have as much time to spend on that preparation. If that's the case, that's a fine, very reasonable trade-off you've made to prioritize your family over your work. But then it strikes me as entirely UNreasonable to accuse businesses of discrimination because they choose employees who have decided not to make that same trade-off.

The whole bent against white board questions is that they are unrealistic as to actual working conditions and thus are artificial. So if you are a successful engineer, using your work time efficiently, and yet, you have family obligations that prevent you from spending enough time as someone else on a take home challenge, is the take home challenge showing realistic 'working conditions'? Or is it a measure of freetime?

>If that's the case, that's a fine, very reasonable trade-off you've made to prioritize your family over your work.

I'd advise that if you are ever involved in a hiring situation you never write that down. "I'm sorry my project wasn't done so well, [my baby, pregnancy, illness, religious service] took most of my weekend".

That is a prime example of age/gender/disability discrimination. You should never assume someone's out side of work life presumes an inability to do the job during work hours.

The vast majority of jobs I've worked at have required some flexibility in working off hours. Whether it was something that went down at off hours that needed to be addressed, or an unforeseen (and unforseeable) change in a business that required a last minute scramble, these things happen.

True, there may be some jobs that are truly 9-5, and if that's the case, so be it. But frankly, as someone who is willing to put more dedication into my work, it feels like complete discrimination against me if someone willing to do less work then demands the same level of compensation and advancement opportunities.

If 'Work Hours' require someone to be oncall 24/7, you can ask that as part of your interview, but you can't infer that from other factors.

Yes: "Our job requires you to be on-call 24/7, one week a month, can you commit to that?".

No: "You said you didn't have time for the take home test because you have a family. The family will get in the way of 24/7 support"

Also yes: "you will be traveling 5 days a week for your sales job, can you do this?" No. "We don't hire people with families for this job."

And, there's no discrimination towards you putting more time into your work. That's quite a stretch, if all you have going for you is your ability to put in more that 60 hours a week, that's not saying much.

As someone who has been in this industry for a long time and seen a lot, this still baffles me.

Who agrees to being on call 24/7 for a week? Especially when you are getting paid a typical professional salary? It seems absurd. I've always been active after hours and willing to jump in when things happen.

But this idea that you are essentially working (since you need to always be somewhere you can start working within minutes) for a week out of a month every month of your life for a salary job with no equity or long term payoff on the other end, has to be the most bizarre choice a person could make.

Maybe there is something to that I don't understand? I guess if you don't have any other interests or people in your life. But that just seems really sad.

Possibly someone who does this could help me to understand this a little better?

I've been on call most of my working life. When I worked at reddit, I was on call 24/7/365. The only time I wasn't on call was for the weekend of my wedding.

When I got to Netflix, only being on call one week a month was a drastic improvement. It meant that I could plan my vacations and important family events around not being on call. On the flip side, my family understood if I suddenly got up from dinner to take a call or get out my laptop. My on call schedule was shared with the family so we could all plan accordingly. Sometimes when it was my week and I had something really important, I would ask a coworker to cover that night for me, and then do the same for them in the future.

The salary for the position accounted for this inconvenience, and it wasn't a surprise. Since everyone who does SRE has this same responsibility, it's built into the compensation. Some companies actually give you extra money when you are on call (I hear Google is one of them).

Yeah, it kinda sucks from a family perspective, but it is what it is. As long as you set expectations with everyone around you, it's not that big a deal.

As it turned out at Netflix, since I was the lead, it meant that I was the secondary or tertiary on call at all times, but again, the family knew this, and also, my coworkers knew that if I didn't answer it was because I really really couldn't take the call at that time, and everyone was fine with that. It just rolled up to next person. Only the first on call was expected to answer, all the rest of us were on a "it would be great if you could" basis.

I do call one week in 10. I typically have between one and three out-of-hours pages during this time. A typical page takes 20 minutes to deal with, although sometimes they do take longer.

30-minute response time means I can still do things like skiing or hiking during on-call weekends, if I'm a bit creative.

As a result of doing call, my team's product runs reliably and meets its SLA requirements, allowing my company to sell the product to other serious companies and therefore for my job to exist.

I get paid around $4k for each week of this (on top of my normal salary). It is worth it for me.

I have "other interests and people in my life", including a girlfriend, friends, outdoor adventuring. One week in ten hardly affects anything, and I can usually trade with a teammate if I want to go away a particular week. Most of my friends have their own careers which make far more onerous demands on their lives for less compensation (doctors, lawyers, nurses, restaurateurs).

Our company introduced this last year. The reactions ranged from "the fuck you think I'm going to do this" to "you bunch of whiners, when I did Ops I was on call 25/8/370 for $0". The way teams implemented it ranged from "you have that week to work on whatever you want/not show up" to "well we don't expect any out of hours calls so we won't implement anything except a roster". It's been fascinating.

Going on 25 years now of being oncall. It's very, very good incentive to make sure the systems are optimized and working nicely.

I get a page about once a month, maybe. Because I do my job.


Automate well enough and you almost never get called.

> Who agrees to being on call 24/7 for a week? Especially when you are getting paid a typical professional salary? It seems absurd. I've always been active after hours and willing to jump in when things happen.

That's called being on-call 24/7 for the entire span of your job.

I agree with all of your examples - it is discrimination if an employer says "your family will get in the way of you working off hours."

What I find obnoxious, though, is when an employer has standard rules for everyone (e.g. "all prospective applicants must produce a 3 hour at home project as part of the interview process") and then balk at "discrimination" because you'd rather spend your time at your kid's soccer game.

This also strikes me as the height of white-collar privilege, because there are tons of other jobs (e.g. military jobs, oil rig workers, construction jobs, etc.) that require a hell of a lot more family sacrifice, but it's mainly highly paid software developers that protest so much at a couple hour non-9-5 project.

The challenge with substantial take home tests is that they have the potential skew your applicant pool in a number of ways that are not ideal for your business.

Firstly, as a general rule of thumb, the very best developers who are in the highest demand are unlikely to jump through the hoops, so immediately you're filtering out the very best applicants. As a business owner, that's not something I want to do.

Secondly, and equally importantly, you are likely to get more, young financially stable people with less outside of work commitments (including families which naturally correlate with age which in turn correlates with experience).

If you want to over-index on people with less experience and at the same time reduce the number of applications from people for whom the time commitment is problematic (including but not limited to females who statistically take on a disproportionate percentage of child care responsibilities and some members of traditionally under represented minorities) all you do is reduce the likely diversity of talent you might otherwise get to pick from for your dev team.

>...the very best developers who are in the highest demand are unlikely to jump through the hoops...

I think that this applies for the best anything but, conversely, companies still want them to jump through the hoops. You need to convince the company you're a worthwhile hire and the company, in all of it's arrogance and self-righteous glory, spends little to no effort convincing you its a worthwhile place to work[0].

You see this in questions like, "So, why do you want to work here?" If we're pointedly blunt, we could just say, "You're hiring for 'x', I can do 'x'; also, I like having money versus not having it," but that would be taken as arrogant and/or "not be a team player" or "not very interested in the company or the role".

Let's face it: The world is filling itself with the "drink the kool-aid" types and, so, companies use that as a gatekeeper, so to speak. "A good company fit." "We just want to see if you're a fit for the company."

An experienced <x> is probably far less concerned with the pointless fact 'y' of your company versus, say, the company's culture or if you have matching contributions. If they've put in the time to make themselves an industry expert in something, then - of course - they're going to be a good company fit, at the end of the day. You're just looking for people who will be acquiescent and/or will jump through the hoops. ...but why...? For an entry-level position, I can understand it. For someone who's dev'ed for the last 10 years at 'zed' company, what function does that hurdle hope to accomplish, if not the aforementioned?

[0]-Not really true for Europe, though, so thank feck for that, but have seen it in the states.

> You see this in questions like, "So, why do you want to work here?" If we're pointedly blunt, we could just say, "You're hiring for 'x', I can do 'x'; also, I like having money versus not having it," but that would be taken as arrogant and/or "not be a team player" or "not very interested in the company or the role".

I've never failed in taking the latter approach in any interview I've ever faced. (I've been rejected; that's different).

I tend to think this is more about whether you're... 'politically risk-averse', for lack of better terminology.

Almost all of the companies that have found a "real" response to that sort of question bad (e.g. given me the gasp or whatever) have been drone-shops. To some extent it was a sort of 'soft-reject' on my side. A minority in any case.

Maybe one day it'll hurt me. I'm not sure. I think it's a pretty good filter against working with dickheads.

I am in Europe, mind. For a month or so at least. ;)

I work 10 hours a day, my wife does as well, and we start at substantially different times. We have a child who can stay up until 11.

If I'm doing multiple interviews (which everyone should be doing) and each requires 3 hours of my time (generous underestimate) then what am I going to do? Hire a sitter for a potential job for each of these companies?

Give me whiteboarding interviews -- at least the studying is cross applicable.

Last time I went interviewing, that’s exactly what I did for the take home projects: hire a sitter.

When you're looking at $60 an interview and looking at probably 10+ interviews to find a good fit then why am I going to spend $600 when I can brush up on information that I already know from school and work at a fraction of the cost?

It’s a place you want to work? I’ve never done more than 3 interviews in a go, but I also only apply to jobs I really want.

> then what am I going to do? Hire a sitter for a potential job for each of these companies?

Yes, why not? For many people taking time off their existing job during the work day to interview is difficult, but they find a way to do it.

My whole point in this thread is not that interviewing isn't onerous, or that some companies may require more of a time investment than some people are willing to make (and, if that's the case, it's fine to say that job/company isn't for you). What I find obnoxious is when people turn their unwillingness to spend time on the interview or homework as "you are discriminating against me because I am older or because children."

Because that's absurd when I can just apply to companies that have reasonable hiring practices that aren't effectively lock in.

How does someone know that their coworker with family isn't just a better negotiator than them or that they didn't come at an opportune time when their employer was more desperate for the coworker's skillset?

There's a reason there's so much room for plausible deniability in these matters.

Traditionally, having a family is viewed as a positive because you are more likely to get a more stable, longer term worker.

"some" being the keyword. It's understandable if there's a scramble if the codebase you're directly responsible for goes down.

I think it depends on how much sysops/devops is involved in your job or if that's a separate team. And how robust your codebase is etc.

Couldn't you use the time that you would have been doing the whiteboard interview to do the take home work? If you have time to go to an interview in the middle of the day, you should have time in the middle of the day to do a take home project.

A take home test rarely means there is no in person interview. You will still get 'soft' questions from managers, product managers etc for half a day.

whiteboard = artificial. I don't agree. When I interview I don't expect working code on WB, I expect discussion about what is written there. Also I expect when interviewed that there will be discussion about approach I took.

WB usage is also testing presentation skills. It is used in companies when you want to present your ideas to others, etc.

I agree with what you say as-is, but the other side of it is that the company might not be making optimal hiring decisions by doing this discrimination. A 22 year-old can choose to spend a full weekend on an interview task and do a great job, but once hired that doesn't mean they will actually work more hours (though they might). If we assume that once hired both the 20yo and the 40yo will work 40 hour weeks (i'm in europe), then it wouldn't be optimal to compare their take-homes evenly if the 20yo had spent way more time on it.

Anyway its complicated. Seems like on-site open-book 90 minute real-world problems would be a nice solution.

> Seems like on-site open-book 90 minute real-world problems would be a nice solution.

It is. And it's superior to a take-home test because you know the candidate wrote the code, you know how long it took them, and you can turn it into a pair-programming exercise.

People whose kids are older may have forgotten how hard it is to get even five minutes to one's self at home, when there are infants or toddlers in the house, let alone an hour or two. Without an adequate support network in place, a parent might have to pay a babysitter to get the time to do the take-home. So yes, take-homes which are expected to be done in one's "free time" are discriminatory against those with families.

Who says that they are expected to be done in one’s “free time”? What responsibility or business is it of an employer to know how candidates are making time for the job interview process?

If any non-zero time required to obtain a particular job is descriminatory then every existent hiring process is discriminatory. What do you suggest, drawing lots?

> if one candidate is willing to do more work ... that's one person showing they are willing to put more effort into a job than another

I'm not happy with this logic. It's harmful. If you extend it further, it motivates everybody to work more hours too.

"If a person is willing to put more effort into a job than another let him do that! Oh and by the way, let's fire those who are not and hire those who are".

And we're back to 12+ hour work day and a lot of great specialists are out of their jobs or forced to sacrifice their time with families, friends, hobbies, physical activities, etc.

There are ways to conduct interviews without whiteboarding AND without take home assignments.

> I am in my mid 40s. Yes, I don't have nearly as much energy...

Do people in their mid 40's have less energy for some reason? Do you exercise regularly? Do you get enough sleep? Do you eat healthily? You don't mention anything about a family obligation taking up your time. I am 41 and I don't have any lack of energy issues. I don't think it's a 40's thing, more of decades of bad lifestyle decisions catching up. Which I don't think should be out of bounds for a company to consider when hiring as long as it isn't due to health issues beyond the candidate's control. I guess this distinction can get fuzzy, but I stress that there shouldn't be any reason why in your 40s you should have dramatically lower levels of energy than in your 20s.

Honestly depicting people in their 40s as having less energy does more harm than good. It's just feeding into the perception of older people as less capable when it's not true across the board. It's not OK. I don't have less energy, I have tons of energy and I'm sure many people older than me do as well.

It's more that family demands tend to be less friendly to time shifting. You can't just put off feeding your kids, grounding them for getting into trouble, or changing their wet sheets at 2 a.m.

Single people (and empty nesters to be fair) can more often skip some happy hours or some intramural games.

And to be even more fair, once employed, it seems parental excuses (my kids blah blah) get more understanding than single excuses (I need to actually date, my boyfriend blah blah). But I'll wager the interview process is more complicated for people with families.

Family obligations taking up time I can understand, but the person I am replying to just seemed to equate 40s as being in a state of having less energy without mentioning family obligations. I am taking issue with 40's being a state where you have less energy. I don't believe it is true, unless there's an underlying health condition that has little to do with age.

It's not a trade-off! We as a species absolutely require people to have kids. Discriminating against those who do is the most fundamantally wrong thing I can think of.

It is what we are here for, if nothing else.

It is interesting that you use, “... willing to put more effort...”. It isn’t about will, it’s about time. But hey, if we’re going to generalize, I bet a dev with a family is more “willing” to do hard work for a company than some single dev.

> Also, take home challenges are probably very discriminatory towards older candidates with families. So maybe just as subtle way of age discrimination?

And whiteboard interviews are discriminatory towards people with anxiety who have trouble thinking clearly when they are in the spotlight with all eyes on them, no? Where does the microaggressions game start and end?

My current company does,

-Offer choice between live coding and take home assignment. Regardless of picking the assignment, we do have multiple questions like "given this piece of code find the bug", but they won't require writing actual code.

-Home assignment for remote candidates. With a second round where we discuss and provide feedback (or the candidate explains their thought process) if needed. The candidate is also judged how feedback is received and argued about. If adequate documentation has been supplied we skip the second round too, or just do it in email back n forth.

-And if you have an impressive active blog and an active github profile you probably evade both live coding and assignment (but still get asked the usual questions about architecture, algorithm use, whether you 'll be a good personality/culture-fit etc).

Despite being "nice" our rejection ratio is quite high (at least in my team), and people who picked the assignment themselves/no-pressure applied then bitched about it on glassdoor. Even though they had the option to not have to do it at all. I don't get it.

>And whiteboard interviews are discriminatory towards people with anxiety who have trouble thinking clearly when they are in the spotlight with all eyes on them, no? Where does the microaggressions game start and end?

So Gender/Age/Disabilty discrimination are now microagrssions? It seems from your description of your hiring practice, someone has thought of the implications of take home questions given the choice between live and take home.

My point is, replacing white board questions with entirely take home questions is probably discriminatory.

Not to parse words too cutely, but, to hire someone requires discriminating amongst all of the applicants to choose the best fits. This is different from discrimination (which is “unjust”). There are certain protected classes that you are ethically not allowed to discriminate against. It is supposed to be merit based, but there is no perfect system. You would have to double blind reviewers, etc. so bias will always happen. As long as you arent doing it on purpose based on a protected class, I think whiteboard / take home are pretty tame and acceptable. Take home assignments work fine IMO. We have them and our company skews much older than SV. We have approx half or more of the company with kids and families and they have all gone through the same hiring process.

> So Gender/Age/Disabilty discrimination are now microagrssions?

Do you have any cases to cite for the proposition that take home interview assignments to be per se “Gender/Age/Disability” discrimination? From any court anywhere?

I have taken multiple of these take home assignments. One from Microsoft as well. What was a 2 day affair turned out to be a week long affair. I was asked to implement one of the iOS outlook features which involved multiple nesting of scrollviews in gridviews and what not. Took me 4 days and when I submitted the repo, the response I got was 'sorry this doesn't cut it and we can't proceed'. I mean, can't the reviewers at least provide some comment in the repo ?

OTOH, I took a Facebook remote test that was timed (I think 30 mins) and the reviewer exactly told me why I didn't clear the test within 24 hours of submission. I don't necessarily agree with everything Facebook does but I really appreciate this level of response.

So, I'll happily do a whiteboard test no matter how unrealistic it is.

This is the fundamental problem with take home tests. The amount of time the candidate spends is way too high compared to the amount of feedback they get.

We do the take home tests because it allows the candidate to work in a more natural way, without the pressure of completing in an hour, under scrutiny and in such a highly consequential circumstance. Also, we allow as much time as they need to take to get it done. Some come back in a couple of days, some in a week.

Then we have them present their code in a code review in front of the team. This gives a good indication of their ability to explain their thinking and approach clearly and is a good read on their communication skills.

So far, no complaints, though it is true that many of them get a bit wrapped up in the exercise and spend far more than the 2 hours we are asking for.

Also take home tests introduce asymmetry. Even take home test takes one hour to do, it takes 5 minutes to check. So, company can go through more candidates, wasting their time. In traditional interview, for every hour candidate spends, the interviewer needs to spend the same amount of time. Therefore, it's forcing companies to choose candidates wisely.

Well, we have made the experience that people that are not seriously considering to take the job are filtered out by a homework. It helps both to save a lot of time and energy interviewing people.

I'm genuinely not trying to be snarky, but how can you say that with any certainty?

The only way to know this for sure would be to ask half your applicant pool to do the test, and the other half to go through the exact same battery of interviews sans take home test and then see how many of the offers you extend are accepted.

Obviously this requires that you're a big enough company to split your applicants into two pools and still have a big enough sample size.

Whenever I talk to people involved in hiring about this, they balk at the idea (for okay reasons -- in theory doing that would mean less people filtered out by homework and more applicants rejected during in person interviews that take up engineer time.)

I guess you are right, we haven’t done a proper A/B test for this. We had no homework before however, and the overall results were different. It is my strong feeling though that many cancel after seeing the homework that are not completely convinced, which is ok.

Yes, I've interviewed at companies that have interview type puzzles and coding, and take home tests. I greatly prefer the former regarding time use.

And, knowing the basic CS algorithms and data structures seems to be a good thing, since they make solving problems easier and lead to cleaner solutions. There's a reason they are considered the fundamentals in CS, even if they are baked into most languages nowadays.

> There's a reason [basic CS algorithms and data structures] are considered the fundamentals in CS, even if they are baked into most languages nowadays.

A linked list is such a fundamental piece of technology, and so obvious to anyone that's been working in a language for a while, that I feel it's perfectly acceptable to rule out a candidate who cannot write one.

It doesn't have to be perfect, and it doesn't have to have all of the optimizations and utility methods that you find in the standard libraries, but the ability to understand and work with a node that has a value and a pointer to the next node is kind of bare-minimum competency, isn't it?

The linked list is such a fundamental piece of technology that you never have to implement it.

I mean, I understand the linked list quite well, but in my multi decade software career, I've probably actually implemented one less than once a decade. So I think it's a very unrealistic interview question, and will sigh quite hard (internally) when asked to implement one in an interview.

You just can't please everyone...

I agree, if you implement a linked list in production code, you've almost certainly made a mistake.

My point is that a linked list is such a simple concept that anyone with real programming experience should be able to write a basic implementation.

It's a Shibboleth; I only care about your ability to perform the task because it tells me something else about you.

OK, I have to kinda agree.

It almost levels the playing field in the sense that since no one actually writes these things, we're probably all equally half clumsy with them :)

For linked lists I'd regard the question really being about whether the candidate understands pointers.

Fizzbuzz serves a similar role.

> The linked list is such a fundamental piece of technology that you never have to implement it.

Is this a good reason not to ask it in an interview?

I'd expect any competent software engineer to be able to implement a linked list without too much trouble. It's maybe not a great interview question (depending on your point of view, you may not consider it to contribute much positive or negative hiring signal), but I don't consider it a "gotcha" question the way a lot of people seem to.

When I do whiteboard questions, its never to see someone regurgitate a common question. Its just nice to see someone solve a problem and what their thought patterns are. CS is pretty much an art, would you hire a violinist without hearing them in person?

Would you ask a violinist to draw the chords they would play on a whiteboard, or would you hand them a violin?

No but I'd have an architect give me plans for a house written out. I'm not hiring artists I'm hiring engineer's. I'm not hiring your for your gorgeous code in x language, I'm hiring for problem solving skills and communication. And I do let people use computer or whiteboard, computer tends to more complicated logistically (wifi, preference of ide, power, logins, etc). A whiteboard only fails to work if I don't have new pens.

Software is far more art than you think, and rigid, formulaic thinking can be a detriment to good problem solving skills. Especially when solving something you can't just look up on the internet.

If your engineers aren't writing clean, readable, maintainable code that solves problems as simply as possible (ie, gorgeous), I'm not sure your hiring practices are doing you any good.


I was responding to these lines:

I'm not hiring artists I'm hiring engineer's. I'm not hiring your for your gorgeous code in x language, I'm hiring for problem solving skills and communication.

I agree with the second half (problem solving and communication) but take some issue with the the way you dismissed the art of it all. Maybe we have different ideas of what an artist is?

I tend to think of software in more blue-collar terms myself, perhaps more like a carpenter (who has to consider more than just aesthetics, but certainly can't ignore them) than a violinist, but my earlier comment was just continuing the established metaphor. Either way, I get the sense we agree more than we disagree here.

For Godsakes drop the architect - sw developer analogy already ! Its broken in so many ways. A developer must be able to produce code that works - compiles and runs and solves the problem at hand.

Bonus points for making code reusable, reliable, readable, testable, functional or what-the-heck-ever-able.

Unless you write code and run and compile it, there's nothing to be discussed.

> Would you ask a violinist to draw the chords they would play on a whiteboard, or would you hand them a violin?

The violin is not generally considered chordal instrument. While you can technically pluck all the strings at once, or bow two strings at once, it's most often used for melodic and not harmonic parts. ;)

You would of course, you can do the exact same questions on a whiteboard with a shared computer. In my experience of doing either, some people are better at one or the other, but the challenge is essentially the same.

How many nights and weekends should be uselessly wasted on LeetCode to get in shape before the whiteboard interview?

At least learning of new things in CSS will give you new useful knowledge which you can potentially apply in future.

How many nights and weekends should be uselessly wasted on homework for every interview?

At least whiteboard requieres practicing for real once in a life time.

Seems so simple to just say “let us know when you have 1 hour to do this take home and we will send it to you at that time. Sumbissions will be accepted for one hour after we send you the coding challenge”

Problem solved

I'd say in the list of companies, probably 2% of the 'take home projects' describe that. A one hour question is most of the time the phone screen or the replacement of it with an automated online exam.

When they say "take 1-2 hours on this" I take them at their word and do just that. On more that one occasion it has cost me an onsite.

Hacker rank allows a company to set up a time limited programming challenge. The company gets back a score based on how many of the tests were passed and the code itself.

Maybe not a bad means of ensuring that “this should only take an hour of your time” really means that.

The flip side is that fast and good aren’t one in the same, but I don’t think there’s any perfect answers here.

I've used similar online coding challenges, even proctored ones. I've had very mixed results, and the challengers are typically nearly identical to ones put on whiteboards. They are often used instead of phone screens.

A lot of these hacker- rank like coding tests often require some extensive preparation. I've used codility (I think that was the one ), and it actually mentioned that ideally it requires at least 2-3 weeks of preparation or more.

I’ve worked at three companies that usually had candidates complete take home assignments. The subjectivity is part of the point. They want you to only spend an hour or two so they can level you accurately and determine what the interview will look like, if there will be one at all. Most people submitting solutions are usually screened out because they’re empirically inexperienced or unsuited for the role. It’s a red flag if you took more time than suggested. If it’s a long assignment, you could simply say what you would work on next had you more time. If it’s a screening-type assignment you’ll be screened out, and if it’s not, you’ll be invited to onsite if what you said gels with the reviewer.

Most take home submissions I’ve seen are rejected — because of copy-pasted stack overflow code patched together, incorrect solutions, or poor style or organization.

I ran into exactly one company that attempted to get me to do a take-home; they were gibbering idiots, statistical imbeciles, and their company proved it in the 5-6 years since then. They're still around: a clown car run by frauds and mountebanks, powered by gas, hype and free labor.

The right way to do a take home exam if you must do this: give them something real and pay them consulting rates for it. If the result is good, you've hired a great worker. If the result is bad, you will know, they'll get a few bucks for their time, and no hard feelings. If you can't screen them to the point where you you can't screen for decent odds on a take home, you should consider a new career. Maybe picking potatoes.

And sometimes after you have spent so much time on take home exercise companies don’t even respond back.

Has happened to me. Was given an assignment that basically requires me to setup an entire ETL pipeline with full/incremental loading (with inputs varying from CSV/Json APIs etc), do data cleansing, create charts, data warehouse modelling + another coding assignment - all within a week's time. It was a very busy week and despite trying my best couldn't finish it. I sent what was completed - total silence with no feedback.

I don't want the front eng engineer reviewing this code and saying, OMG, this is so old, NOHIRE!"

I know trend-chasing seems to be common in the web development industry, but I would be wary of anyone who likes to make such changes for the sake of showing off or otherwise.

Question for all of the people claiming ageism because companies won't make special cases for folks with kids:

I have a dog. A young dog that requires a lot of work around the clock. Do you also think I deserve concessions?

I ask most candidates to write code on a whiteboard in front of me and I’m not apologizing for it!

The problem is usually fairly easy and if the candidate cannot get to a “describe solution in words” milestone then I will guide them to one. After that I ask them to write code. I will also tell them “the code is the part I care about”.

The specific competency I am evaluating here is “can you turn thoughts into code”. I repeat that phrase in interview training so much I think people make fun of me for it.

Imagine I give you a python list with 100 elements and I ask you to write code that will find all instances of the number “5” and move them to the front of the list. I don’t care about performance.

You know you have to write a loop and whenever you see a 5, remove it and put it at the front. Easy. Not even really an “algorithm”. Some people can make code happen very easily and accurately. But some people really need to really think about it - what control flow to use, off by one errors, bounds issues - and make mistakes. Some people don’t see their own bugs. Some people do weird stuff that makes me think they haven’t seen a lot of code before.

I teach interviewers to evaluate the act of the writing as much as the end product, kind of like when airport security asks you “where did you stay in New York” and doesn’t really care about the answer so much as how shifty you look when answering it. It doesn’t mean you have to materialize perfect code on the board to pass - not even close! But this exercise provides information, and when other exercises corroborate that information we use it to make a hire/nohire decision.

Anyway, bottom line is whiteboard code is a completely reasonable technique to deploy in an interview setting and if you do this you shouldn’t feel bad about it. Much more depends on (a) whether the interviewer is trained and calibrated and (b) whether the company knows what it is even trying to evaluate than the question format.

Thank you for writing this post. Whiteboard code interviews get a lot of hate on HN and I suspect that folks who have come to rely on them for part of their hiring signal have simply stopped posting.

I've done a lot of lower level systems work and the fact is that even with a long career and history of very successful product I get whiteboard coding interviews when I look for a job ... and it's just fine. Yes it's not the same as day to day work, but it's related, and I have to admit that I find them kind of fun.

Maybe there are 2 types of "programming jobs": 1) you will have to implement data structures and algorithms, or 2) everything will be provided for you in a language or framework. For job type 2) CS is not needed - it's not a computer science related position ... it's "frameworking". I'm guessing that a lot of the whiteboard hate comes from type 2) people applying for type 1) jobs, OR type 2) companies asking type 1) questions.

For more history around whiteboard coding, there's the excellent "Why Can't Programmers Program" post: https://blog.codinghorror.com/why-cant-programmers-program/

I would like to actually figure out what is the bet way to do interviewing for coding positions but it's super hard to actually have these kinds of discussions on HN now without people getting upset at even suggesting whiteboard coding interviews.

> Thank you for writing this post. Whiteboard code interviews get a lot of hate on HN and I suspect that folks who have come to rely on them for part of their hiring signal have simply stopped posting.

It seems like there's a population of engineers that is perpetually interviewing. I think the people that post significantly about this are people that are struggling with frequent interviews, and correctly or not, lash out at whiteboarding as why they are having trouble.

Maybe there's some large pool of otherwise qualified people that just can't pass interviews and are being passed over because of it, but I really doubt this is significant.

My personal opinion: I don't mind white board interviews. I'd do a take home test, but I would prefer a traditional interview. And being a short term contractor (also comes up frequently in these threads) as an interview process is obviously impractical.

The pay in software engineering, esp. in the bay area, is very high. Companies here never have enough engineers for one reason or other - the situation makes current engineers always looking for higher pay regardless of their skill level, and people not in the industry wanting to be in the high pay field.

You forgot to mention the permutation of companies "wanting" 2), but using the search strategy optimized for 1) approach due to:

- poor HR communication

- poor ability of hiring managers to know what the job entails

- hiring managers past experience hiring primarily for 1), but assuming projects that now need 2)

As a hiring manager, I agree wholeheartedly with the root comment.

I love whiteboard interviews. Really. I do.

The problem is -- most start-ups are terrible at them. And most people interviewing at FAANG don't understand the reason those companies ask these types of questions.

Top tech companies ask hard interview questions for a few reasons.

They're not necessarily trying to hire the best people. They're trying to ensure the people that they do hire aren't incompetent. Hardly anyone incompetent is going to pass Google's interview process. Period.

Why are they so focused on not hiring incompetent people? It's not easy to fire people for being incompetent (or even worse -- toxic).

So if they're just trying to not hire incompetent people, why are the algorithms questions MUCH harder than the problems you face on an average day?

Two reasons. One, they have so many people interviewing, why would they not set the bar arbitrarily high? Two, the amount of people willing to cram and do almost anything for the job means they HAVE to set the bar high.

Now let's talk about the beef with start-up whiteboard interviews. Most of these interviewers have never been formally trained. They're just winging it. They ask questions that don't lend themselves well to a whiteboard. And they don't know what to look for during the interview!

A good whiteboard question does not rely on a trick or an obscure data structure. It doesn't have any gotchas that if you "get it" make it much easier.

A good question is slightly difficult to solve, but has many possible ways to solve it -- each with it's own trade offs. Ideally, none of them are much easier or harder than the others.

It's MUCH more impressive if a candidate can come up with 2-4 ways to solve a hard LeetCode easy problem or an easy LeetCode medium problem -- then for a candidate to happen to know the right combination of obscure knowledge to solve 1 LeetCode hard problem.

If you have 2-3 whiteboard interviews, and a candidate can come up with 2-4 totally different ways to solve the problem, and he materialize those thoughts into code -- there's a very slim chance s/he's bad.

The ideal candidate can discuss the tradeoffs of different solutions, and ask clarifying questions about the usage to figure out an optimal solution.

When you get to performance tweaks for edge cases, can the candidate weigh the pros and cons of adding the complexity for a certain gain.

Is it worth it to add some complexity to class to take an algorithm from 2n to n? Maybe. It depends on a lot of things...

I once worked with a guy who would ask a question that could be solved in O(N) time and O(N) space somewhat easily. But the question could also be solved in O(N) time and O(1) space IFF you knew some (discreet) discreet math. Almost everyone who didn't get the O(1) space solution he would say was a no hire.

Probably less than 10% of the engineers I've worked with have taken discreet math...

Another guy would ask a question that MOST candidates couldn't even comprehend, let alone come up with a solution. Most of the people that solved it would solve it O(n!) Or O(n^3). Occasionally, people would solve it O(n^2). But there is an O(n) solution. And that's what he was looking for. Literally NO ONE ever got it.

These are not good interview questions!

If you're testing for their coding process, why do you make them write it out on a whiteboard? Why not provide them a code editor or at least text editor?

I like whiteboard interviews, but they should be testing high level design ("describe solution in words / detail in pseudocode"), not coding skills.

How is providing a code editor or text editor different than writing it out on the whiteboard?

I do a similar process and don't care if their syntax is exactly correct. I, maybe different from the person you're responding to, don't care if they use exact libraries in the precisely correct way. But I do care that they're able to come up with a plausible solution.

At a point, I see people gripe about whiteboard interviews and "specific answers" to questions enough that I'm all in on whiteboard interviews. If someone has an attitude problem over it, I don't want to work with them. God only knows how unwilling they'll be to do something simple like look into the source code of some library they're using. "The job description didn't say I had to do this!"

I realize I am being overly-emotional here, but the HN and broader attitude problems around something as simple as writing a for loop on a whiteboard irk me so much at this point, babying and coddling people, apparently older people who I thought knew how to adapt to whatever life sends their way since they weren't the everyone-gets-a-trophy generation.

The process of scribbling characters with a marker on a whiteboard is quite tedious and takes up a lot of time and effort. And doing it feels more akin to multitasking than a normal coding process, since so much of the effort goes into scribbling out things (as opposed to the actual coding process). Ability to draw glyphs on a whiteboard will become a confounding factor here.

Being able to type out things in a text editor simply makes the interview process much more efficient.

Note: I share your annoyance with people who gripe about whiteboard problems and algorithms / data structures problems not being representative of everyday work.

> How is providing a code editor or text editor different than writing it out on the whiteboard?

At least for me, it's vastly better. In an editor, I'm in my element, I have autocomplete, things work they way they usually do and everything is much more comfortable.

I could even throw together some quick tests and test drive my code!

That's if your used to using your laptop not your desktop, you didn't forget to charge it, the WiFi is working, you aren't missing your mouse keyboard montitor, etc. Ive had candidates many fuck all that up and spend 15 minutes fixing the ergonomics. Guess what it's a 25 minute coding exercise, good luck. If I give them a laptop, same deal.

After it all I still give them the option. Their computer ours or whiteboard.

Statistically ive found that the in ide ones don't get as far because they get hung up on syntax or project setup.

Interviewer and candidate tend to let things like missing curlys slide on whiteboard or just text editor. I don't even care if you get the size function name correct on a collection (I can't remember between the 7 languages I use) or similar.

This is data pulled from 500 interviews.

I don't think places would stop you if you wanted to use your laptop but I do think you're actually optimizing for the wrong thing.

I'll admit this mostly comes from frustration standing by a whiteboard. If I did the same thing on a computer, I'd maybe just have a different set of frustrations.

As someone who does a lot of TDD, I is quite frustrating that a whiteboard can't run tests though...

What I have seen work well, from both sides, is interviewing by pair programming. Not for everyone, for sure.

Just write the test cases as bullet points and actually run through the algorithm with them when done coding. Don't declare success the instant you wirte that last curly.

Doing that gets a big plus from me (I'm 100% tdd personally).

Remember I know the answer to the question. The instant I can tell you do and for reasoning is good, I'm going to stop waisting time getting fro 95% sure to 100% sure on that part of the question and get another piece of data.

Usually that for me is to add some system design, speed consideration or other area of investigation and try to get another overall compentency covered. And just keep doing that till we run out of time.

It's very often other interviewers aren't able to hit things so backup signals are great.

And interviews are risk mitigation really. The more 80% certainties I can get on the more areas of coverage the Better if the interview team is doing a good job.

As an interviewer I'd prefer a whiteboard and an open discussion. With a computer I have to deal with pedantic reality instead of discussing the concepts or approach. You also need a projector or a large screen if it's more than one other person in the room.

At one interview I was given a coding test (this was alone and timed). I was put into a separate room and pointed to a computer. It was a Windows box and Notepad.exe was the only thing I saw. I may have found Nodepad++, but I'm pretty sure it didn't have a Python interpreter. I hadn't used a Windows box in 10 years and my preferred environment is Vim. After the test they pulled me into a different room with the interviewers and discussed the code. This test was terrible for multiple reasons. I was asked to interview by a senior person who was working there who admitted that part of the process sucked and was pushing to improve it.

Even at large places that invest heavily in hiring, I don't see them developing/maintaining a test candidate environment, they're not likely going to hand you someone else's account in a production environment, and if they have a generic PC with a guest account, things are going to be missing or out of date. It'd be preferable for me to bring in my own laptop (but that discriminates against people with desktops or who don't have home computers).

I agree with the 'easier discussion' aspect of a whiteboard, but I feel that any whiteboard test should therefore be asking for pseudocode and explicitly disregarding the pedantic reality of syntax.

Yes. I do think there's a benefit in having a reference language--just don't be pedantic. For example, certain design patterns might be needed for C++ that are built into a language like Python. Knowing which libraries the candidate (or the company) leans on is a good topic to discuss. Pure pseudocode might be too generic to suss this out. It depends what you're evaluating them for. There's little to no value in testing them on things like mismatching parens or typos in variable names (I've heard stories about people getting called out on those things using a whiteboard).

> How is providing a code editor or text editor different than writing it out on the whiteboard?

Muscle memory. If you do all your coding in an IDE on a keyboard, it's quote common not to remember how to write a basic loop because at that point it is so engrained in your muscle memory that you just sort of hit the right keys.

If I gave you a foot operated keyboard and then asked you to take a typing test, would that be fair? It's still typing, it's just a different way of typing.

With white board you have to worry about

-legibility and penmanship -size of your letters because you don’t want to run out of space

These are things not related to programming or the problem at hand.

These things are related to "communicating effectively", which is a significant part of the job.

I give whiteboard interviews. Believe it or not, I am intelligent. I am not going to disregard you because you got some minor syntax wrong on the whiteboard. I can tell the difference between a fundamental misunderstanding and a mistake that happens due to using a language that wasn't designed to be written on whiteboards. If you, the candidate, don't understand that, then I guess you are not fit for the role anyway.

I don’t really understand the whiteboard hate either. Take home tests don’t reveal how a person communicates or collaborates. Maybe it’ll predict competency for siloed heads down work, but even for those positions you need to be able to explain solutions, get feedback on the approach, and be able to incrementally adapt to new requirements quickly. Even when programming solo I’d wager most people are using pen and paper to sketch out solutions so it’s not like it’s an implicitly unreasonable request to then do this on a whiteboard in a group setting.

And to address the OP more directly, are loops, maps, trees and graphs really “CS trivia”? They seem more like fundamentals to me, and those are usually the subjects whiteboard tests revolve around.

As a manager, finding folks who can turn thought into code is certainly required. However, a whiteboard does not and cannot measure that. The only effective way to measure the ability to turn thought into code is for them do it for real. Writing on a whiteboard is simply not coding nor is it an adequate proxy.

Hiring people is also about portraying your company in a positive light. Your allusions to the TSA security screen, and how you have to be "trained and calibrated" seem to imply a robotic kind of detachment that would probably be very off-putting to me.

Often employers seem to be of the mind that they have the treasure and it's up to them to filter out the best candidates (sellers market I suppose) regardless of how they appear in the process. I would imagine that a lot of brilliant people get turned off by this. Which (oddly enough) is also fine by me - like dating, I'd rather spend my time finding an open minded/humane place to work, and I find hiring practices are often a rough initial proxy for that.

Whiteboard interviews are great, just not for writing code. I want to see how you can communicate a design and have a discussion. So we always gave someone a design problem where there really wasn’t a right way to solve it but lots of ways. Then we asked them to tell us what they are thinking as they go thru it. Some people just can’t communicate their thinking or think on their feet under pressure. It was good at finding that.

I ended up trying not having it with some candidates and later I realized it was a mistake. It would have given me some additional insights into their communication skills I didn’t pickup on otherwise.

I recently interviewed at Square (who is on that list), and they don't have whiteboard coding challenges. There was still a design challenge that involved a whiteboard on which I could draw basic aspects of my design, which sounds like exactly what you're talking about.

This list is those that don't expect you to write code on a whiteboard, from what I gather. Not those that don't have design questions.

Though FWIW I don't view ability to "think on their feet under pressure" that important for most SWEs. It's not the military, an ER, etc. The fact that somebody gets panicky when being interviewed by strangers, and then can't think as clearly, doesn't really say anything about their ability to sit down and write code on a typical workday. It just says they're bad at being interviewed.

Communication is important, but it's important not to conflate "bad in a high pressure interview situation" with "can't communicate in a normal office environment".

> Some people just can't ... think on their feet under pressure. It was good at finding that.

What was the relevance of finding that? Do you always do system design under a strict clock at your company?

In my experience some of the biggest problems are solved best by the slowest thinkers

Those slow thinkers might have a good idea of the answer they likely want to give straight away - but maybe want to take another day or two before committing

Short meetings around a table can be quite frustrating for people that think slow - which is why many discussions can reach a better conclusion using email and time

Completely agree. My best decisions are not made on my feet, and I have often been responsible for difficult technical tasks. I also prefer to "communicate my thinking" in the form of readable, well-tested code that can be verified by a machine.

If that code is unsatisfactory for some reason, I'd rather figure that out after writing it, based on concrete evidence, than during an upfront design meeting with folks who likely won't be doing the actual work, but often feel the need to impose themselves in arbitrary ways. When a team focuses on excellent communication through writing, I find less planning and verbalizing is necessary, and a lot more gets done.

As a partial aside, one of my greatest annoyances when starting a new job is when after being grilled for technical skills during the interview, they walk you in to a messy, amateur codebase, where many of the ideals discussed during the interview clearly haven't been applied, but no one seems to acknowledge it. This has happened to me repeatedly, enough so that when these sorts of questions come up during the interview, I mentally start preparing for the disappointment. People sometimes seem to take more pride in trying to rattle candidates than they do in building anything admirable. Luckily, there are many fine places to work where the team can be honest with itself and with candidates. I don't really care about the current state of projects when I'm starting; I don't mind being a janitor (except in extreme cases). Just don't start our relationship off with a load of BS. I feel like this is such an elephant in the industry. A lot of our code is bad, real bad, but we can't admit it.

That hasn't been my experience at all. The opposite in fact.

Sure the biggest problems aren't solved in 5 minutes at a whiteboard, but they are solved by people who are able to think on their feet at a whiteboard discussion.

Not to put too fine a point on it, but when the decision is made on your feet at a whiteboard, only the people who are able to think on their feet at a whiteboard discussion can participate. If you have a whiteboard discussion and then say, "come back to me tomorrow with specific feedback" -- and privately ask people directly who you know are unlikely to make comments in public, I think you will get a completely different point of view (if you haven't weeded out all the good meticulous thinkers already, of course).

I think you missed my point. Hard problems are not solved at whiteboards (usually). But the ability to "do whiteboards" seems to correlate with the ability to solve hard problems.

Well it’s certainly relevant if the job requires a lot of thinking on your feet. Like consulting and solutioning with clients under pressure...

None of these interview practices are by themselves good or bad, it depends on what the actual job will demand.

When I worked as an independent consultant I'd get clients who needed fast turnaround on designing new feature architecture to a product I had not seen before, which is the closest analogy to the interview whiteboard design that I've experienced.

Even then, it's completely different. I'll first spend a couple hours with someone senior who can fill me in on all the relevant context. The dynamic is different because they need my help and are paying for it so they are highly motivated to give me all the context I need to help them. Only after that we go to the step where I whiteboard a few proposals and then we collaboratively decide which way to go. I'm quite good at this.

Interview whiteboard design is a different skill entirely, one which I don't believe has any relevance to job performance. Might be a good way to hire improv theater actors, but not engineers. Having to go from zero to solution in 45 minutes or less is not how it works in the real world. And doing so while being nitpicked by an interviewer more interested in showing off doesn't help. Instead of collaborating, the interviewer is there to grudgingly drop the occasional hint and then count it against you.

This was my experience interviewing at a big company. I had a coding interview to prove that I could write working code with test cases. I opted to write that on a computer and project it onto the screen where the interviewer could follow along. The architecture round took place on the whiteboard. It was a tool to help communicate the design I had in my mind.

Sorry, this is too black-and-white.

Of course it's stupid to ask somebody to write down red-black-tree rebalancing algorithms from memory. Especially on the whiteboard without any syntax/compiler help.

But given a more-or-less concrete basic problem that every programmer should be able to solve with just basic knowledge of the chosen language hands-on (at a computer, not the whiteboard) is a different thing. It can be a collaborative process where the candidate can sketch an approach on paper/whiteboard, then write code. While doing that they can query API question to the interviewer, which, if they are doing a good job, will be giving that information willingly. Watching the candidate building their solution towards something that works tells a lot. It's not just whether the code works. It's communication too. Code organization. How they think, how they approach a problem, what to do when they get stuck (ask for help? run in circles? just get confused?), what do do when their code has a bug etc.

Take-home exercises seem to be praised as the key solution, but I think that's fundamentally flawed as already discussed here. If done badly, it's just as bad as from-memory-whiteboard stuff. In-person-problem-solving can be done quite well.

And the market proves that it works. Successful companies do it. If their hiring would suffer substantially, then they'd have stopped doing it, because their competition would have a substantial edge.

Using a whiteboard, or even having trivia-like questions isn't the problem. The problem is that people think those tools are trying to test your ability to get the answer right. No. They are a medium through which you can see how someone approaches problems, their thought processes, how they structure their ideas, what they do when they get stuck, how well they communicate, how well they understand directions, how well they dig for more information, etc.

None of those things has anything to do with whether you memorized an algorithm or whether you got the answer right. Quite the opposite, slamming in a memorized algorithm with the right answer has been a reason for 'no hire' in my experience. Because all it shows is that you can code. And to work well on a team requires so much more.

> Quite the opposite, slamming in a memorized algorithm with the right answer has been a reason for 'no hire' in my experience. Because all it shows is that you can code.

So the people who already know the solution to your problem are supposed to pretend to have an "aha moment"? Really this is one of the reasons the process doesn't work as well as you hope, people will memorize algorithms and pretend to have that genius moment that you look for.

Honestly, I'd much prefer if you tell me if you're familiar with the problem.

I previously interviewed at a company and of the three interviews, I knew, and informed them that I knew, 2 of the problems they asked. I solved all 3 and got the job, likely because after I implemented an lru cache in ~10 mins on a whiteboard, we turned around and I actually coded it up in an ide, added tests, and then we had some extra time to fix a few small bugs and discuss caching strategies.

I'm still torn on the value of that interview though. And I'd much prefer to ask you a question you don't know than to have you write down a rote memorized answer, or pretend to be uncertain. I can usually tell and it wastes both of our time.

After a few interviews, the fake "aha" moments are pretty obvious.

If someone does know the solution, ask them them to teach it to you - why is that the correct solution and not some other approach?

If the problem is really an "aha"-type with a single, explicit solution then it's not a good problem to be asking in an interview.

It really is about your approach, problem-solving technique, communication, etc.

An interview is a special scenario where the pressure is several orders of magnitude beyond anything you'll usually encounter in the work environment. Some folks' reasoning skills utterly fall apart in such situations. Without understanding that, you may miss out on some stellar performers who have no issues reasoning or solving problems when left alone to work.

It is often a great disappointment to people looking for jobs when they figure out that employers just don't care if they miss out on someone. They are trying to avoid a bad hire more than they need to hit a 100% rate identifying all good hires.

(Not to mention, if you cannot perform under stress, that is a negative aspect of your capabilities, and a fair reason to bring in someone who doesn't fail under stress.)

> They are trying to avoid a bad hire more than they need to hit a 100% rate identifying all good hires.

This is absolutely correct.

I mean, sure, hiring great people is hard enough that I hate to miss out on somebody great, but not nearly as much as I hate making a bad hire.

Bad hires cost a lot, and not just directly (cost of hiring, salary, etc.), but in time, stress, and motivation of the people they work with.

I don't like the term 'bad hire' as it grossly simplifies things. I think some companies are better off letting in some types of bad hires to acquire the rock star introverts(some of my best performing co-workers would fail miserably at modern interviews). I'm not saying that hiring a sociopath won't kill your team's productivity. I'm saying hiring someone who doesn't know algorithms won't necessarily kill your team. There is probably grunt work you could pass on to them and actually figure out how to make them work. I don't agree with this modern approach to having a moat around your devs in all cases. The reality is more nuanced

As a candidate, here's what I like about white boarding, and conversely what I dislike about take-home problems: at least with whiteboarding I'm guaranteed to be wasting the employer's time and not just my own. I've spent hours completing a code challenge only to be rejected with no explanation in the past.

This is pretty much where I've landed; the filter can go both ways. If I make dumb (minor) syntax errors on a whiteboard and it bothers the interviewer enough to not hire me, or if the question is some "cycle a red-black subtree" BS, I'd really rather not work there anyway, and not have it take 4+ hours of my personal time.

A list of companies to avoid for sure.

Take home challenges are terrible. The worst I had was the following. I was given the following prompt (translated into English):

"Please write a line-by-line sort of a large text file that doesn't fit into memory. To test the functionality also write a generator of such files [...]. Programming language doesn't matter. It is recommended to spend no more than 4 hours on this task"

I quickly whipped up a solution (in like 1.5 hours) based that you can see here [1] and sent it in. Obviously not "production-ready" solution, but it uses the optimal algorithm and satisfies the sparse requirements that were given. It didn't get accepted and the feedback was:

* the solution doesn't work with very long lines because CHUNK_SIZE is constant

* the solution stores the name of each chunk which technically makes it O(n_lines) in space (though the constant is very small)

Both of these are really uncharitable nitpicks, since the algorithm could be trivially adjusted to take these into account were it a whiteboard interview.

And people are complaining about having to invert a binary tree? Get a grip.

[1] https://gist.github.com/tshatrov/3c862eced64b25dd4256c02e985...

Instead of this subjective us/them mentality, I'd be more interested in some hard data showing that not using a white board leads to higher quality hires. I'm really not convinced this is the case.

Besides, that list is not what the title is. It's a list of companies that don't do brain teasers. But a lot of them use white boards.

And to be honest, using a white board is important. You will be doing that a lot in any kind of developer capacity, especially the more senior ones. You need to be able to explain things clearly on a white board.

Factoring this in the interview process is a plus, not a minus in my opinion.

But we can all agree that questions should be about writing code, not brain teasers. This has been a well accepted idea for more than ten years.

> It's a list of companies that don't do brain teasers

Facebook, Google, Apple, LinkedIn, Netflix, etc don't do brain teasers and they're not on this list.

EDIT: whoops, Netflix is on this list, my bad

I'm curious to know what are the biggest companies on the GitHub list. It looks like some of these methods may work fine for a company hiring a dozen people a year, but when you're a large tech company (like your list), hiring 10,000 people a year and interviewing probably 50-100x that, you need a method that scales up and is more cheat proof.

Netflix is in the list.

While the term isn’t very precise, in this context “brainteaser” means precisely the kind of questions asked by Google, etc.

Mmmh, no, I don't think so.

Brain teasers are typically understood as questions such as "How many ping pong balls can you put into an airplane?", and other silly, non-coding related questions.

This type of question has been banned in most tech companies for years.

Given that you are the one who used the term, I’m curious why you used it in the way I described then and not the way you just did. The article here clearly is including LeetCode style questions as “whiteboard questions” — this is explicitly stated. Maybe you hadn’t read the article? That is fairly likely, given that your comments about physical whiteboards are addressed in the article as well.

That's a Fermi problem, not a brain teaser. Brain teasers are problem with one solution that you solve by a spark of insight (or memory) with no solving process.

Serious question, because I see this view all the time: how are the algorithms design, architecture, and coding questions asked by Google and friends brain teasers?

They tend to be contrived, artificial, aggressively timeboxed, unrealistically isolated from normal tools one might use, and the desired solution tends to be one that depends on having one or two central creative insights.

Whether they’re a good or bad interviewing technique is a separate topic — I only mean to describe the usage of the term as I’ve seen it in the last 5-10 years.

(Also, to be clear, not every question asked by Google necessarily falls into this category. System design questions in particular tend not to.)

I've easily spent more time at whiteboar in interviews than at a white hard in all my time on the actual job, over many years.

A good design discussion is written up and discussed. Ad hoc scribbles on a board don't add much anything, not in the 21st century with good computer drawing tools

There's stages.

I get a lot of work done at a white hard with 1-3 coworkers. We reach a consensus there, and then you formalize and write up the design and break out lucidchart or whatever.

It's not worth spending time making a design when you're going to forget something important and have to rework it. Use a whiteboard until you're confident you aren't going to erase again, that's my rule.

Where I'm currently working we do pair programming interviews (usually with ping pong). Some candidates don't like it. Sometimes we have technical hitches. However, it's been the best method I've seen in my fairly long career. I can't think of a single time that we've hired someone and been surprised when they showed up to work. The strengths we've seen have actually been there and the weaknesses as well. We may well miss some good people, but I think that's inevitable. Having a predictable hiring practice is much more valuable to me.

Our practice is pretty interesting. We do a telephone pre-screen and then 2 hours of pair programming (4 25 minute pomodoros pairing with a different person each pomodoro). We generally do the pair programming remotely. I can't even remember the last time we did an in person interview. We also try to accommodate people who want to interview outside of normal business hours. It's a fairly long interview, but skipping the commute helps a bit (I hope).

Just for people who aren't familiar with ping pong, one person writes a failing test, the next person fulfills that test and then writes the next failing test. It ensures you pass the keyboard back and forth frequently and that both partners are plugged in.

Like I said, some candidates really don't like it. There is still a lot of stress having to produce while being watched. Also, not very many people have experience with pair programming and TDD, so ping pong is pretty foreign. However, the interviewer can help quite a bit, driving the process and even solving the problem. Over the period of 2 hours, hopefully the candidate can settle down and just program naturally. It also gives the interviewer a lot of leeway to ask questions like, "What do you think of this idea?" and see how they react.

Thanks for posting! Your process sounds really great at getting to know and feel how a candidate thinks and works with people.

Is the ping pong approach, tdd, and time involved communicated to candidates before the interview date?

Some companies list a take-home assignment as an alternative.

IMO, that's worse than a whiteboard interview. My time is valuable, and I don't want to spend my evenings or weekends on an assignment.

I think take home assignments could be done well, but I've never seen it happen. You often need to spend time setting up which is a total waste of time for a throwaway project.

You should provide the candidates with a starter project in their language of choice, already set up and ready for them to start working. And you should give everyone at least some time limit (maybe one or two hours at most) so everyone is on equal footing.

And the worst part is, all the take home assignments I've done are just used as an initial filter, not as a final check in the interview process. I'd have maybe one phone conversation beforehand, spend hours working on the take-home, and then get a short rejection email with no useful feedback.

Why is a starter project so important that it needs to be provided by the company and why in the language of choice of the candidate? How long does it take for you to setup a starter project?

When I solved the challenge that we give our applicants it took me about 5 seconds to setup the project with everything I needed to solve the challenge. In any language I use it does not take long at all to setup a new project. Especially small ones like that.

It depends on the language/framework you're using, something Rails would be very easy to get up and running, but something like a modern Javascript app SSR or Webpack, Babel, etc. might be very time consuming.

My point is your project should be a test of someone's actual development/programming ability, not project setup. You don't want to have people spend an hour configuring CMake or webpack.

The thing is though that we don't have the ability to setup starter projects for any language that anyone might use.

For one thing because we don't know every language and every type of project you might use. For instance I don't think we have anyone that could setup a JavaScript SSR app. I certainly have no idea how that works. I am not a JavaScript developer. If you want to solve our challenge that way then you are certainly welcome to do so, but in that case you would need to set it up yourself. If setting up a JavaScript SSR is time consuming or a major hurdle to you then maybe use something else? If we where providing starter projects JavaScript SSR wouldn't be one we would offer anyways.

CMake isn't that much to set up for simple projects if you know CMake.

I personally think it is fair to include project setup in this test, because it will show me how well you understand the tools you use.

For me, it depends a lot on the scale of the assignment. I’ve seen some that would require an entire weekend to complete and others that would take a couple hours.

The latter are pretty reasonable and IMO both more pleasant to complete and a better indicator of eventual performance than whiteboard interviews.

The former seem to mostly measure the candidate’s level of desperation/willingness to be exploited.

I find some take-home assignments to be completely reasonable and preferable to whiteboard interviews.

For example, Klaviyo in Boston (no relation, I just interviewed with them at one point) has a take-home assignment listed here [0]. It is simple enough that I can finish it in the same time as phone technical interviews and applies to the company's product and job requirements.

Though I am certain there are companies that have unreasonable take-home assignments.

[0] https://www.klaviyo.com/weather-app

Different strokes, take home is way more to my liking and much better at demonstrating non-algo work like UI development.

Curious: how does it better demonstrate non-algo work? How does the interviewer know that you didn't spend the entire weekend googling how to do it? (Although that may be perfectly acceptable to them.)

When a company insists on a take-home assignment, I send them a quote at my standard contracting rate.

Curiously enough, some agree

Would you do the same for an in person interview? Why is it different for a take-home assignment?

In-person interview is both them and me spending time on each other.

Take home is just you wasting time. Or do you suspect they will spend as many hours evaluating your answers as you took to create them?

Yes I do. Maybe even more. When I evaluate challenges for our company I do actually spend a lot more time going through the challenge then what it took me to solve it myself and I am not the only one evaluating each one. We also got a lot of feedback that our "estimation" of how long this challenge takes is very accurate, so I assume they take roughly the same amount of time that it took me to do it.

I don't think it is wasting time. Even with the very simple challenge we give out we are always surprised at the wide variety of solutions we get. We found it very useful in our hiring process.

Of course that is just us, but when I was on the other side the people evaluating me where asking detailed questions about my solution more often then not. So I assume it is fairly common that the companies actually do also spend a lot of time on each challenge.

I interview a lot of candidates and we do whiteboarding - to see how candidates can communicate architecture designs and decisions.

The interviews have made me realise that countless candidates are unable to:

1. Give a high level overview of a product

2. Critique design choices and suggest improvements

3. Communicate well as to what the value of components are to the broader business.

Many of the developers can explain a particular piece of logic very well, others can't even do that. But in an enterprise scenario, we need excellent communicators.

But communication on-the-fly, on-your-feet, in a high pressure environment, which is what a whiteboard test is, is not most communication.

Most communication gets thought about, drafted, revised, critiqued, socialized, ahead of distribution.

If your whiteboarding comes after hours or days of consideration and review, that sounds like a great way to vet good communicators. Otherwise, aren't you optimizing only for speed? If someone cracks a joke in the moment, they're a wit; but we only pay money to and call comedians those who worked on it for a while.

Of course the candidate is under more pressure than they would be at work - that's why we don't expect them to create a Leonardo masterpiece in front of us and we give the candidate the benefit of the doubt.

You would be surprised at how poor some of the candidates are at this. Candidates who are unable to draw a few squares on a board to describe the last thing they worked on, and candidates who have never questioned any of the work they were assigned or don't understand that there are often multiple options for a solution, each with pros and cons.

If someone can't even draw a simple diagram on a board, I don't want to have to plan and come up with highly complex solutions over whole months with them.

I think an important point is that you are assuming someone’s design communication moves along a spectrum from good to bad as you increase time pressure or stress, and so you can accordingly adjust your expectations along a spectrum and still be well-calibrated to evaluate the meaning of the candidate’s performance.

I propose it doesn’t work like that at all. Rather, if someone’s brain is loaded with time pressure or interview jitters, and they are not the type of person who thrives on stress, then it will be more like you have totally switched off the part of their brain that is good at communicating design thinking, and their performance in the interview will be entirely unrepresentative of what their performance would be in a regular day-to-day team meeting on the job.

I think the same effect is even more severe with any type of coding / mathematics / puzzle solving questions done inside a short timed session or using things like Coderpad or HackerRank.

I was on a phone interview where my anxiety crossed a threshold and my brain just shut down. I literally could not comprehend the code I had just written. For a few minutes, I forgot how to program. I've programmed for 21 years professionally, across many languages, but still fell apart. I recovered after about 5-10 minutes, but at that point it was too late. A couple hours later I went back and breezed through the problem, wrote a few test cases, and ran them without issues.

And how do you propose a removal of all stress? Shall we hire everyone and fire them if they turn out to be dreadful after a week? That would ensure EVERYONE is under pressure all the time...

Evaluate software engineering candidates the same way virtually every other skilled profession on the planet evaluates their candidates: through a series of conversational interviews that involve technical communication about their skills and past experiences, and perhaps some version of “sample work” that ideally should just come from GitHub, school project, Stack Overflow answers, etc., and only be based on some take-home (with tons of time to complete it) in the rare cases the candidate doesn’t have any samples they want to discuss with you.

I don’t understand why people keep overthinking it and believing you need any type of timed testing aspect at all.

Through many years of leading engineer hiring for my teams, a simple conversational style has helped me successfully hire effective software engineers much, much more than traditional software tests.

Imagine asking a plumber, lawyer, or tax accountant to solve a pipe problem, law problem, or accounting problem in ~40 minutes while you watch over their shoulder and iteratively add complicating details, while telling them to use some foreign interface they never use for their own work and confusing them by saying you don’t care about syntactical correctness and just want high level communication to “see how they think,” despite the very nature of the problem being rooted in sweating micro details about correctness.

Yes, exactly!

I've been in the tech (software) industry over 25 years now, nearly all of those years here in Silicon Valley. Worked in everything from 3 person startups to the largest of enterprises.

I feel good about saying I've never made a bad hire (meaning: I've never come to regret saying "hire", everyone I have given the thumbs up after an interview has turned out to be a fine contributor).

I don't ask candidates to code, I don't ask them to come up with whiteboard architectures out of the blue or any of these silly artificial techniques that don't measure anything relevant.

Here's what I do: I carefully read their resume. I have a conversation about the projects they have worked on. I encourage them to talk about what jobs/projects/tasks they liked and disliked and why. What they found easy vs. hard and why. And what they want to work on next and why.

That's it. Works extremely well.

I wish everyone would try it. You'll find it is very easy to pick out those who padded their resume. You can't actually have a meaningful conversation about what you loved and hated about working on foo if you didn't do it.

This is what take home projects or allowing someone to present their own code help fix.

Ever been in a tense meeting?

Most (almost all) verbal communication comes with time pressure.

Speak too long (ramble) and your message is lost and your coworkers are annoyed.

Don't speak fast enough and now someone else is using all the air in the room.

Yes. They're still nothing like an interview. It's a different kind of pressure.

> Ever been in a tense meeting?

This should not be what interviews are like.

If anything, my interviews are less tense and stressful than my meetings. On both sides of the table.

(If anything, this is probably not what meetings should be like. I wish to god my coworkers would have real agendas for meetings — and a one-sentence subject does not count as an "agenda", and ideally, written material detailing any proposal that will be proposed, s.t. I can arrive at the meeting already understanding what it is that someone wants to do.)

We shouldn't setting up interviews that are biased toward to hiring people who will make the company even more toxic and counterproductive.

What makes you think they'll be toxic and counterproductive? If, as you seem to think, whiteboarding is a test for this, then everyone should have whiteboarding tests where the good whiteboarders don't get a job.

However, just like like whiteboard coding is completely unrelated to real-world coding, this type of whiteboard design is also completely unrelated to the real-world whiteboard design people do in non-interview settings.

How many times has a scenario like this happened to anyone: Your manager pulls you in with no warning into a conference room and asks you to architect on the whiteboard a new product completely unrelated to anything the company does or has done so far. And you get 45 minutes to get it correct or you're fired. Right.. never. That's the scenario interview whiteboarding is testing for and it has no real world relevance at all.

In an actual job even the most impromptu whiteboarding sessions are related to product context already in your head. And most sessions are scheduled in advance so get to do research and prep work.

... You are making a load of assumptions that are wrong.

We ask the candidate to describe a system they have recently built. Therefore they should have product context, they are not being tested on inventing whatsoever (unless they are actually doing an impressive con, in which case, they'll have to be extra skillfull). As mentioned below, we give candidates the benefit of the doubt, but quite a lot of candidates are unable to give even a simple explanation of what they've worked on.

As for the amount of pressure - all of the pressure is circumstantial. We try as hard as possible to put candidates at ease. Obviously it's not entirely possible, but we try our best. Secondly, scenarios like that happen all the time. Maybe I won't get fired, but if there is a pressing issue, for example, I often need to draw diagrams to explain what is happening to a part of a distributed system. It is impossible to do without diagrams. And communicating these issues clearly and concisely often leads to quicker resolution times and happier clients/stakeholders

Can I just use words to describe it though? Or pseudocode? Short lists of issues that need to be considered in the design, with various options and their pros and cons, in words?

It's the expectation of drawing pictures on a whiteboard that's so strange to me, that's completely alien to the way I think about software. I think in text.

+ we don't set a hard time limit in the interviews. The whiteboarding piece is last and the candidate can spend as much time as he would like to. Often candidates have shown something we are happy with in just 5 minutes or so.

The assumption you seem to be making is that anyone with a whiteboard is also an evil villain that wants to interrogate you violently you and pick on any mistakes that you might make. In reality, it is a higher level check to see if you can communicate at all.

The theoretical coding interview based on undergrad CS topics has become a cottage industry by itself with books,online sites etc. Very few people know that this is used for indirect age discrimination to favor young folks. Not sure when this insanity will stop. Human beings went to moon before we had this coding interviews.

And what makes older folks incapable of solving questions using basic algorithms and data structures?

They've probably been working for 10 years without needing to write a sort algorithm by hand since it's built into every language these days, and get annoyed at having to re-learn it just for an interview.

> Solving CS trivia, technical puzzles, riddles, brainteasers...

I never know what people are talking about when they complain about brainteasers and riddles. In my career, I've interviewed at Amazon (x2), Google (x2), Apple, Facebook, Pinterest, Dropbox, and Fitbit (5 offers, 3 hires).

At all of these companies, solving coding problems was part of the interview process, as were systems design questions, and behavioral interviewing. At none of them was I asked questions that I considered "CS trivia" let alone brainteasers and riddles. Instead the focus was on problem solving, algorithms and data structures, concurrency and other topics. You know, the things you use as a working programmer.

I get that this interview style is not to everyone's liking, but to just call it "bad interview practices" without either defining what it is or why it is bad is lazy and unhelpful. There is genuine signal that comes out of these interviews and the companies seem to be doing alright.

Good for you?

Personally I prefer in person interviews as take homes take a long time and I really only have time for that for positions I'm super interested in.

When I'm intereviewing people, I let them use what they're comfortable with. If they want to use a laptop, fine, if they want to use the one we provided, fine. If they want to use the whiteboard, fine. I can adapt. If they want to use any given programming language, also fine, I can read most of them and if I can't then it gives me a read on communication as they explain different lambda or whatever syntaxes to me.

I will say (and advise candidates) that you should use languages you are most comfortable in, and use what you're actually comfortable using for coding. Don't do java because you heard company X uses java and you learned it this weekend.

That said if you know python or ruby or similar language it's better for most interviews with algorithms or string manipulation. If the coding question is about byte arrays and memory allocation, c would be better. So I personally will flip languages in an interview I'm taking.

Having given around 500 interviews in the last 3 years, I will say that when people use computers they tend to focus on things like syntax more, as do the interviewers. These things tend to get ignored more on a whiteboard or without syntax highlighting.

I believe most mid to upper level programming interviews focus more on problem solving and communication, which does mean that if you get hung up on syntax (or the interviewer does) then you are burning valuable time on things that don't really get you that senior level signal you are looking for.

Eg the more time you can focus on showing you can solve problems, communicate, and design systems, and the less you are just arguing with the compiler, the better signal the interviewer is going to get on your experience.

At the end of the day, the only real interview that can get a good signal is working with the other person for a meaty period of time, usually several months. Thus all interviews are are inherently an artificial evaluation. It's just like taking standardized tests. You can get mad at the process or you can just get over it and optimize for getting the highest evaluation you can.

They acknowledge that the term "whiteboard interview"/"whiteboarding" is a simplification and a proxy for a style of interviewing they don't like, but I really wish they didn't pick "whiteboard" as that simplified negative term. Whiteboards don't get enough credit, from my experience.

I really like collaborating with someone with a whiteboard: it's fun, it's social, and it feels like a dramatically more effective form of collaboration and explanation than common alternatives like chat conversations and shared docs. I've had jobs where whiteboard-style collaboration is common, and I've had jobs where it almost never happens, and I greatly prefer to be in a culture where it's the norm. So for me, if I go through an interview process and no whiteboards were used in the process at all, it makes me worry that I wouldn't be happy there.

There are a lot of companies on this list who list homework. I'm not sure if this is supposed to be a selling point or not, maybe for some candidates. At PlanGrid, we basically stopped giving homework because it wasn't respecting either of the interviewer's or interviewee's time.

There are some exceptional cases when giving homework is acceptable/can be useful, but if you're giving it to all applicants, you're certainly selecting for an audience that has a lot of time to spare.

This makes me realize that a giant list of every tech company would have been really great when I was last looking for a job. I looked for weeks for every small company in the Seattle area and didn't find a few of the ones on this list.

Discussions of interviews always cast a practice as definitively “good” or “bad”. The reality is it depends what the real job will entail. If the job actually requires a lot of white boarding style problem solving, then why not a whiteboard problem solving interview? If the job is a pure heads down coding job, then a more heads down interview seems best...

Not only that, most of those companies probably hire a handful of people per year, but not all of these methods scale to a company hiring thousands. Many of these can also be easily abused and cheated.

As a lefty, my biggest problem with whiteboard interviews is writing code on the whiteboard. I just can't write text in straight lines very easily because my hand is occluding it, and so I write slower and use more strength doing it, getting tired pretty quickly. I have no problem drawing on a white board (I draw my shapes in counter directions like most lefties), or writing simple labels/lists, or whatever, but coding on a freaking whiteboard should be illegal :).

And then they expect me to talk while writing code on the whiteboard...

Here’s a curve ball: has there ever been a study on companies that do be those that don’t do whiteboard interviews and the relative performance of the company or the staff?

I've read that Google has tried to find correlations between interview ratings and job success. They didn't find a correlation, and this is only for those that they did hire (so the difference between an "acceptable" hire and an "exceptional" hire at the interview made no difference later on).

I think that correlation would be impossible to interpret due to the obvious confounding factors. A randomized controlled trial would be interesting though...

Companies can, at least somewhat, figure out their false positive rate, but it’s very difficult to determine the false negative rate. Maybe someone like LinkedIn could do it depending on what their data collection agreement says (I’m betting it’s pretty permissive.)

Absolutely. The giant companies who do whiteboard interviews have studied this intensely, because making quality hires quickly is a critical part of their business.

The people who say the industry should stop doing whiteboard interviews, in contrast, have no data.

The giant companies who whiteboard are full of people who have a strong incentive to reach the conclusion that the process that selected themselves over other people is a good one.

Unconcious bias is a tough thing to control for.

What are you basing this opinion on?

These companies are also full of Directors and VPs whose very jobs, and their millions of dollars in salary, and their image as successful managers, rely on successful hiring choices.

It's definitely not hard to imagine such people being biased toward whiteboard. It's also not hard to imagine them hiring outside firms to conduct studies and collect data.

Speaking of bias, there's a lot of it around here toward the idea that whiteboarding is ineffective.

"it's not hard to imagine that A" does not mean that A is happening. It doesn't even mean that P(A) is high.

Your first paragraph also goes directly against what you are trying to prove. If their success relies on good hiring, then they would pick the best methods. If they haven't, they wouldn't be successful and would be replaced.

What a load of twaddle .

If you can find where I have said that anyting proves anything else, then I will certainly retract it. The only people talking about proof are those setting up unreachable goalposts.

If their success relies on good hiring, then they would pick the best methods. If they haven't, they wouldn't be successful and would be replaced.

That's faulty reasoning. Successful hiring choices do not necessarily depend on having used the most ideal hiring practice. Past success does not mean things cannot be made better.

What a load of twaddle

I know this topic makes people emotional, but how about we keep it civil?

I do apologise. For a moment I thought I was talking to Alasdair. Having now checked your name properly, everything you wrote previously is seen in a new light and my post is the twaddle in this instance.

Agreed that things can always improve.

Circular reasoning isn't data, though.

"The procedures at companies X, Y and Z are correct because their operations require their procedures to be correct" sounds entirely accurate, but doesn't prove that the procedures are correct (or optimal, which is another question not covered by your argument: the status quo can be sufficient but not optimal)

That wasn't my argument. It's more like: these companies have almost infinite resources, and it's in their best interest to get it right.

It's of course not proof, but it's something.

This is a massive, unwarranted assumption, large companies do plenty of things that _make no sense whatsoever_ en masse.

It's weird seeing people put giant bureaucracies on a pedestal.

Unless the giant whiteboarding companies are also hiring people who fail the whiteboard interviews so they can see to what extent (or not) success in whiteboarding correlates with good employee, I'm unconvinced.

I completely agree that having candidates solve trivia, puzzles, riddles, and brainteasers on a whiteboard is an extremely poor method of evaluation. Outstanding developers can mentally freeze when asked to solve even fairly trivial problems in front of a critical audience. Having candidates use a whiteboard to illustrate and explain details of projects or problems that they have previously worked is far more productive. You then drill them within their familiar context regarding their design choices and present them with what-if scenarios that might have changed their approach. It is more realistic and it helps put candidates at ease so you can better evaluate their thought processes, enthusiasm, and practices. I cannot recall a real-world situation where a developer had to solve a detailed problem in front of a critical audience. In front of a critical audience, you either know the answer or you say when you can have the answer.

I've been a professional developer for over 20 years and I've never been asked to do anything on a whiteboard at an interview. I guess I've done at least 20 interviews in that time (but I can't really remember). Maybe I was just very lucky. It's just as well as I have really shitty handwriting.

I wonder if the right thing to do is to simply give interviewees a choice between whiteboard interviews and take home tests. I seem to be in a minority, but I personally prefer whiteboard interviews over take home tests, but I can easily understand why many people prefer take home.

To be honest, I wonder how much take home is for your benefit rather than the company's.

Hiring is extremely time-consuming and a big motivator for me to adopt take home problems as part of our process would be that it saves time for people who would otherwise be involved in interviews.

However, we're at a point where we're little enough known - and therefore don't have much cachet as a desirable place to work - that I'd prefer to invest the time in speaking with someone rather than send them a test.

It's all rather cold-blooded, which is unfortunate, but it's also the reality of hiring and having to deal with large numbers of applicants relative to the size of your team.

I think you're right. It all comes down to the person involved. There's no silver bullet but I do think it makes sense to give people more choice.

From the article linked on the github site:

> "While the path to becoming a software engineer used to involve going to college and majoring in computer science, now candidates for engineering jobs also include autodidacts who taught themselves how to code and graduates of coding bootcamps, which teach web development fundamentals in a shortened period of time. This means non-traditional candidates can get a foothold in the industry without following a traditional path — but it doesn’t matter if they can’t get hired because of a fixation on memorizing trivia."

So now a computer science education is "trivia" and a one-month web development bootcamp is equivalent?

One way that a takehome can align well with a business is when it selects for people who are relatively strong at "introvert" activities.

Some of our work requires high-bandwidth face-to-face collaboration, with ideas and decisions needed immediately, but a lot of our work is a natural fit for being able to go off and think through a problem by oneself (for perhaps the bulk of it; there's still interaction).

A takehome seems to favor someone good at the think-through part. (Although a takehome doesn't fully exercise someone strong at this bulk part who also has a sense of when to, say, bounce it off someone else, or ask more questions, or get feedback at that point, or call in an intense group brainstorming.)

(Of course, some people can do, say, pair-programming all day, and it energizes them, and that's great. Others, who we might roughly label "introverts", would find all-day pair programming taxing, or distracting with social awarenesses, or have a sense at times that they'd be better off thinking at their own pace or in their own directions. Both kinds have merits, and probably the organization wants some of both. My experience is that a mix of them works on a team, even with some near the extremes, though the most extreme pair types presumably need a mate to function.)

if you find an interview in front of a whiteboard to be a high pressure situation where it is difficult to communicate... maybe that is the problem and something to work on.

it really is the case, then you are unsuitable for work in a lot of roles... aside from that being able to communicate under pressure is extremely valuable everywhere.

on the other hand... plenty of roles don't need this. sitting behind your desk doing code is usually pretty different to anything you come across in interviews :I

Are whiteboard interviews so bad that it justifies selecting companies against it?

It may not be the most pleasant or effective interview technique but just as candidates don't need to be perfect to be hired, neither are companies. It is not a red flag, not even a yellow flag. Just a minor annoyance in the recruiting process.

And while it may affect your chances of getting hired, out of arbitrary criteria, it is is at least one you can do something about relatively easily.

I've written a script to allow me to filter the list, using the Functional Perl libraries. Maybe someone will translate it to JS?


If you want to run it:

    sudo apt-get install libfunction-parameters-perl libterm-readline-gnu-perl libpadwalker-perl
    git clone https://github.com/poteto/hiring-without-whiteboards
    git clone https://github.com/pflanze/functional-perl
    functional-perl/examples/hiring-without-whiteboards --help
    functional-perl/examples/hiring-without-whiteboards hiring-without-whiteboards/
E.g. to search for companies that offer remote jobs but not also jobs in London, UK:

    $cs->filter(fun($r) { $r->remote and not $r->locations->any(fun($l) { $l=~ /\bUK\b/ and $l=~ /london/i }) })->show_items
Disclosure: I'm the author of the Functional Perl libraries.

If a take home assignment takes more than 2-3 hrs, or is one of those “spend as much time as you like”, you’re in a not great situation. The mgr likely doesn’t know exactly what he’s looking for, or likely doesn’t care too much about employee welfare.

If you find yourself here, stand up for yourself. Say you have a number of interviews going on and that you are happy to do a 2-3 hr assignment (the same as an on-site interview).

I work at Netflix and we most definitely do white board coding interviews. At larger companies interview approaches will vary by teams and orgs.

There are many comments in this thread about whiteboard vs take-home programming challenges. That's a false dichotomy. What I would really like to see is an interview where I am allowed to code on a computer (at the interview) instead of a whiteboard. I would like to be able to write real code, and test it while I'm coding, as I normally do when programming.

Yeah, this has started becoming the norm at a lot of startups - coding on computer + design on whiteboard, and I think it works really well.

"Take home" challenges are excellent - they give an opportunity to create a common platform for discussion that every party feels comfortable with.

As for time investment, it's worth to dedicate 4-6 hours of your life to make sure the next few years of your employment are good for both parties.

It is not whiteboard that is a problem, but pressure of being evaluated by a random dude. It's like dancing naked. Whiteboard is a complimentary tool that should be used for visualization and demonstration, that's it!

Also, it takes years of experience and a great emotional intelligence in order to be able to conclude anything not obvious about a person after 1 - 1.5 hours of f2f communication. Let's face it - most of us are not there.

The best way is to simulate a real-case dynamics of whatever the job requires, for as long as possible, and give both parties chance to behave in a natural way.

All sounds great when you interview for 1 position at a time, but how does this scale if I interview for 4-5 companies in my job search? Considering every take home probably also has a full day interview afterwards, that's a lot of time investment.

As a company looking for people, do you want to have your 6 hour take home project to happen after the candidate has an offer? As a candidate, are you really going to spend another 6 hours, if you have an offer in hand?

It's your choice to interview for 4-5 positions, moreover, you will have those interviews whatsoever, so it can't be an argument :) Most chances you are applying for a high paying job and do that once in 2-3 years on average, aren't you ready to invest a week of intense effort for that? If not, you could choose to apply to a FAANG and spend 2-3 weeks studying craking the code interview-style books. How much time do you think is reasonable to invest for candidate and a company to make a decision? As a company I don't see a point in giving home excercise after an offer, but why are you asking? I will spend 12 hoirs if I consider a company better than one that offerer.

I didn't get in details, what kind of CS question should be eliminated in "non-whiteboard" interviews. However, I would definitely ask at least basics of algorithms, their analysis, and data structures. For example, in my carrier, I saw enough getter methods (e.g. getCustomers) which looks from outside simple/fast but internally do linear search on each invocation. It especially "nice", if you have a piece of code which iterates over multiple collections in nested loops on UI thread..

I am proud to say my company has a phone screen coding question 100% relevant to the day-to-day work you do. And also all our coding / whiteboarding / behavioral questions are geared to answer if you know how to handle challenges that daily life in the company will bring, and what sort of person you are.

To come up with the right questions was a difficult effort. We definitely avoid algo / puzzle questions like the plague, and the technical stuff we ask is more of a discussion than a quiz.

So yeah, it is important to look for the right signals.

In at least 20 interviews over the years I've never had a white board interview, I assume that's mostly a west coast/SV/startup thing.

> I assume that's mostly a west coast/SV/startup thing.

I guess they feel like they are gathering hard data to back up their hiring decisions—except humans don't choose their allies that way.

It's a technocratic smokescreen.

If you don't mind me asking: How much do you get paid, and what sort of interesting problems at scale do you get to work on?

The salary I make and the interesting stuff I get to work on is worth the song and dance I've got to perform every few years, in my opinion.

I wasn't making any claims about which is better, or even which I prefer, just an observation that I've never seen East Coast established companies do any whiteboarding.

Mm'kay, let me rephrase the question:

What kind of companies were the 20 places you interviewed with, and what were the typical salaries they were offering?

Laptop tests aren’t great either. Are you at your best on a dinky little screen, goofy keyboard, and with the clock ticking? I’m guessing not.

This is a great list, but I think it's more interesting than just "doesn't do whiteboard job interviews" - I like that each company has a quick breakdown of their hiring process, which is even more useful. There's a lot more people doing take home projects than I thought!

If whiteboard job interviews with clever algorithm problems are so bad, how is it that successful companies like Amazon and Google do it and they are both hugely successful?

What is considered a teaser? I’ve done the Leetcode style questions and most don’t feel like “gotchas” to me...

I've interviewed engineers on computer science problems on a whiteboard and those who did great turned out to do great on the actual job.

That's a one way implication. It is possible there are people who do poorly on coding interviews but great on the job.

Whiteboard coding is simply a quick test that has few false positives in my experience (around 40 interviews).

many assumptions, few facts

There are few facts to make the case in either direction, so the anecdotes are valuable.

Of course it's a bit of a shame that the one comment not subject to HN groupthink is [predictably] all the way at the bottom of the page.

I'd love examples of respectful, positive ways to decline a whiteboard question.

I recently read 'Developer Hegemony' and remember a section where the author advised politely declining and suggesting that you may know some other (implied lesser) programmers who might be willing to jump through the arbitrary hoops.

Fun in theory. In my opinion this approach will work about as well as the old "if we all stop paying our taxes they can't come after all of us" idea.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact