What I've learned from 100s of interviews with candidates at top tech companies

Yeah - those are good; I've asked variants of those and others when I've interviewed. It's interesting; you sometimes get these incredulous looks (may be a red flag), other times they look surprised but launch into describing their process, failures, places to improve, etc. Sometimes this discussion can also be a means for me as a candidate to decide if I want to work there (ie - is it a broken environment where I might become the fall guy or it will cause me heartache in the long term). Sometimes it leads to more interesting tech discussion and such.

How on earth can you think that 300k is a basic living wage in the bay. Even with insane housing prices, this is like 10x the national median wage. Knock out 1/3 for taxes and you are left with 200k per year. How are you spending the 190k per year on rent and transportation that would be needed to knock you down to typical post-expenses income levels?

>> And? By your logic, if a lawyer tells you how to handle some unfair legal situation, that lawyer is doing something wrong. Because they're profiting from something that's unfair.

Just putting things into perspective for OP. It's like Trump campaign has ties to Russia. Doesn't incriminate him automatically but I would be wary of vested interests. Just an additional data point

I'm not really suggesting much here, more identifying a problem. I suppose my question is, what are some of those bad interview processes, especially around the coding interview, and how would you address them?

To an extent, you have addressed this - in a blog post a while back, you reviewed some of the other options available to a compnay trying to hire, and none are especially compelling or necessarily preferable to a technical exam style interview.

Here's the thing, I'm not just focused on clear abuses - bad question, bullying attitudes. I think even when "well administered", the customary technical exam interview itself may in fact be harming the industry pretty seriously. I think it's sufficiently onerous, intimidating, and secretive that it may be driving away talent. And I wouldn't be at all surprised that it tends to drive away people don't feel they fit the mould of the standard Silicon Valley developer at an even higher rate.

I'm starting to think this is one of those tragedy of the commons situations where each individual firm is acting in its best interest by giving candidates rigorous technical interviews - but the aggregate result ends up deterring people form applying for new jobs or perhaps entering the field at all. Imagine if you had to re-take the bar exam every time you changed law firms - and the only people who would know if you passed was the firm evaluating your candidacy! In many ways, that's what we have in software.

I really do think this drives a lot of potentially good people from our field. You mentioned in a blog post that taking time off to do take-home projects may deter women and others with family obligations from applying - but surely that's true as well for taking off 100 hours to study for a tech exam, especially one you might not pass (and if you don't, will never know why). People might be more willing to do this if there was a better process that ensured a fair hearing, a less secretive, more transparent approach to technical exam interviews.

So, I'm asking, maybe we should step back for a moment and ask how we, as people who buy into and use technical exams, may be collectively contributing to a real malaise in our industry, one that creates a problem for everyone, but perhaps an unusually severe one for the very people we're saying we are trying to get into this field.

I certainly don't think that there's an easy answer here, but perhaps our industry really does need some outside regulation, or a professional association that can administer exams in a way that is more transparent, or at least some set of standards. For instance, perhaps non-disclosures that might mask discrimination should be illegal or unenforceable? Perhaps companies and others should be obligated to share scores and reviews of candidate coding exams?

I can see big problems there as well. But I really do think the situation, as it stands, is pretty bad.

I'm glad you asked. I have been following your blogs and posts about interviews and this is the first time I've seen you ask this. This is positive.

I do not have a bulletproof solution but I have implemented processes in my current company that filters in better (measured by performance at work) people than the average prolific whiteboard coder.

1. First, we need to establish the goal of the interview. What is our goal? The goal is find passionate candidates who will get the job done or are bring something that makes our team better. Golden State Warriors will not succeed with a team full of Stephen Curry clones. Note that the goal is not to reduce false positives but to hire the best we can get.

2. With that established, we need to interview candidates and see if they are worth it.

a. If they are a generic software engineer/just out of college/did not get a chance to do something interesting yet, what else besides coding (verified by 2 rounds of non-perfect whiteboarding) did the candidate do? We need to identify if they have the potential to do more than just toy coding

b. If they have been doing something interesting at previous jobs/school they obviously did not have time to practice coding. What were they doing? Is it relevant? Is it it interesting?

With point b, I know you get paranoid about bullshitters. I agree. Candidate b can be a bullshit artist. But, if the interviewer is capable enough, the bullshittery will not go anywhere.

In the light of above, I designed the following:

1. 2 coding rounds. It's ok to miss edge cases as long as you can fix them when prompted with decisive hints. The coding problems are also relevant problems from our own codebases and not just some random "skyline problem" ----Note that the emphasis is "OK on missing edge cases". We just want to know if you can solve the problem and translate it to code

2. System design round: Yes even for college grads. For college grads ask something trivial like how would you design a simple diff or a simple OS/compiler. For experienced folks, ask something relevant to their background. This works really well because it shows which college grad really likes exploring the world of "practical" computer science. This also helps remove bullshitters to a large extent. Linkedin has a great round on this and I really enjoyed that round because it got me engaged with the team and they got to explore sides of me that even I didn't know existed

3. "What is special about you round"...We want to know what makes you special (to compensate for lack of toy coding). Here is where a lot of really good engineers would shine. Some will give examples of a compiler they wrote, or how they applied machine learning to an unconventional area. There are no right answers and it quickly becomes a technical discussion. This round shows how insightful the candidate is. Also, this has to be a full round.....not just a 5 min chit chat thing. The reason for it to be a full round is that bullshitters run out of stuff to talk about whereas the person who was engaged in such projects will go far.

Granted some engineers aren't good communicators but whiteboarding is a bad proxy for hiding bad communication skills since a lot of engineering IS good communication. This same candidate will get hired, write design docs, give presentations, explain concepts, mentor interns, interview other candidates. This person better be a good communicator.

Is this process perfect? No. But neither is the current overweighted whiteboarding

So what does this process do? It tried to "select" the better candidate as opposed to trying to "reject" everyone in the name of reducing false positives.

Not perfect but gets me the candidates who are not just whiteboarders.

I am in the bay area and I'll be happy to walk through this process in great detail if necessary.