[_khwc]

While there are many legitimate criticism of whiteboard-style coding interviews, I have yet to see a convincing alternative that scales well to the size of big companies. Google [1][2], Facebook et al. hire thousands of engineers per year, meaning they conduct at least 10-100k interviews per year. How do you design a process that is consistent, measurable and efficient at that scale?

[1] Google gets 2 million resumes a year https://www.fastcompany.com/3044606/hit-the-ground-running/g...

[2] Headcount increased from 57,148 to 66,575 between Q2 15 and Q2 16: https://abc.xyz/investor/

[Sir_Substance]

This is what I'm starting to think of as the "sympathetic customer fallacy".

Coming up with a scalable hiring filter mechanism that doesn't belittle or frustrate the kinds of engineers are you are trying to attract is fundamentally not the problem of your hirees.

Now, maybe the top engineers will suffer through the process, in which case fine, run the whiteboard interviews. But increasingly, it seems like the real cream of the crop are saying "companies that run these kinds of interviews are too rigid for me to be willing to work for them".

Complaining about it won't actually attract those engineers back, because _your_ hiring process is not _their_ problem. They don't care about your hardships, and why should they?

First impressions matter, and if their first impression of your company is that you make everyone you see jump through arbitrary hoops regardless of merit, it's not really surprising they might not want to work for you. Telling them that the hoops are needed to keep the riffraff out hardly improves your image.

Maybe you'll have to accept you'll have to hire some bad engineers in order to get the great ones, and do the filtering as a longer process.

Maybe it's not possible for a 50,000+ employee company to have a hiring process that isn't belittling.

Maybe there's a third technique others haven't worked out.

But whatever the answer, you can be damned sure that complaining the world is unfair won't actually solve the problem for you.

[friendlygrammar]

>But increasingly, it seems like the real cream of the crop are saying "companies that run these kinds of interviews are too rigid for me to be willing to work for them".

I do not believe this for a second. The real cream of the crop comes into these interviews, passes them with ease and sometimes even enjoy the process. The worst companies I've seen had low hiring standards, they let any fool join the company and then that fool will go on to interview other fools and lets them join. It's like a cancer and rejecting a few potentially good candidates is worth preventing it.

[existencebox]

Let me refute that for you then.

I have been hired at both G and MS. In my tenure at both, my connects (performance reviews) have been stellar (you'll have to take my word on that, unfortunately).

At the risk of saying something I should never associate with my professional profile, I have also been rejected at both, in combination ~5 times to the 2 I was accepted. (both prior and post my acceptances at each place).

I reasonably consider myself to be a "good engineer" in a pragmatic, "you pay me money to make your company money" sort of way, however, I would not say I pass the interview process with ease or enjoy it; and would VERY MUCH say the process puts me off interviewing for companies I know behave this way instead of just waiting for a prior coworker who trusts my output to say "hey we need someone"; those latter arrangements have historically worked out far better in the long run for me given both outcomes and ROI of time spent in the process.

While I certainly welcome that I am either a fraud or an outlier, the fact that I've heard similar stories from coworkers I see as very high end engineers allows me to assert at least that this occurs (interviews putting off good candidates) although not necessarily how much.

The fact of the matter for me, at the end of the day, is the common lament: if the interview (and when it is) even VAGUELY about what we do day to day, I will surf without blinking, with the exception of the occasional "culture fit" rejection which I've come to accept in stride, but between those rejections and the sheer volume of "I clearly don't want to be interviewing today so going to make this hellish/I expect a magic question to a problem I prepared ahead of time" that I've seen, it seems divorced from reality that such an often arbitrary and painful process wouldn't put people off it. I recently likened it to be most similar to what it used to feel like to ask out someone in middle school, when you felt somewhat clueless despite your best effort, with low chance of success and high chance of shameful failure.

[nvarsj]

The majority of people that pass these kinds of interviews are the kind of person who will study for months the various coding interview books. Do you think that sort of person correlates with the "cream of the crop"? There may be some loose association there.

[gwbas1c]

I love whiteboard questions! I've been on both sides, (given whiteboard, handled whiteboard,) and they always tell me a lot about the other person. They're also fun.

[davidcgl]

I'm not sure I understand -- who's complaining?

To be clear, I can see why big companies prefer coding interviews (it's more "consistent" when interview feedbacks are boiled down to a score), but at the same time I'm not defending it because like many have said it's not a great measure of an engineer's capability. I'm looking at the problem from the employers' point of view.

[8_hours_ago]

Give them a computer and some resources. Let them work on a problem for a few hours. Then have a discussion with them about how they approached the problem, any limitations of their implementation, and what they would do if they had more time.

I don't see how whiteboard-style coding interviews can scale any better than that approach.

[daxfohl]

The thing I don't like about whiteboard: A solid candidate that has a bug near the top of a function ends up looking sloppy because whiteboards don't have "insert". The same candidate making the same bug at the bottom of the function can just erase a closing brace and continue looking marvelous. It's very arbitrary I think.

[nitrogen]

Possible solution: leave room at the top of the whiteboard and between some lines for erasing and rewriting sections.

[daxfohl]

Another option would be to write the program in BASIC, with line numbers.

[parennoob]

> How do you design a process that is consistent, measurable and efficient at that scale?

None of these are strict requirements. Individual groups who are hiring can decide best what kind of person will make a good team member, and should be largely charged with hiring one (with some cross-team supervision to remove obvious biases).

It's humans you are hiring, not AWS instances –– a process that easily scales to large numbers (like HackerRank) should be viewed with some skepticism.

[vonmoltke]

> How do you design a process that is consistent, measurable and efficient at that scale?

I think you would be hard-pressed to demonstrate that their processes are consistent.

[davidcgl]

I'd argue they are consistent in that every candidate who made it past resume screening is given equal opportunity to partake in a well documented process. Whether or not the process itself is effective is a different question.

Sure, interviewers themselves are inconsistent (accents, prejudice, interview difficulty, etc), but that's not something that can be fully mitigated when every candidate gets a different set of interviewers.

Again, I'm not defending the practice and would just like to have a constructive discussion.