As a former director of engineering, that lesson always stuck with me. When hiring engineers, I never cared much about what college candidates went to, or what companies they worked for, or how they whiteboarded. The thing I looked for were signals that would indicate this person would not fit in with the team culture, take a long time on tickets compared to peers, ignore clean code or performance, etc. If you are optimizing for that, then Automattic has one of the best hiring processes around. You do the interview async, and then you have a 6 week contract to work on tickets (based on actual past tickets). I went through the process and hated the work and the company, and they also thought I focused too much on the code and not the customer. A perfect outcome in my opinion. A standard interview process might have resulted in an offer and my acceptance.
I interviewed with vscode and they had a 2 day process. Granted theirs was not a calibrated interview. They would choose random vscode tickets. I was given one that I could only test on a windows machine (at that time I did not have a windows machine). It felt a bit biased.
1) white board interviews are good for brainstorming, terrible for writing code in
2) Coding questions consider whether candidate can write code, ask more details about the problem space, iterate possible ways to solve a problem and list their tradeoffs.
3) Talk to the references
A lot of times it is not about the candidate, it is how well you onboard and mentor them.