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.