Here’s the uncomfortable truth: it doesn’t matter that whiteboard coding tests / LC don’t measure a lot of things a dev needs to do day to day. They are the currently known most economical filter to hire *at scale*. I’m talking when you hire 100 devs per year (or 1,000 ) Hiring is done by people who are devs themselves and you want to keep a similar bar between different parts of the org. Yes, tasks that simulate day-to-day work give better signal. But they require far larger investment and it’s problematic when the question leaks. (When you do more than 20-30 interviews with the same question, expect it to leak and be googleable when people search for what your hiring process is). With algorithmic questions it makes no difference if it leaks, given companies have a question bank in the hundreds! A nice side effect for large companies is they self select for people who are willing to put up with BS things: aka spend considerable amount of time to do something mostly pointless (prepare for these algo interviews), just because it’s how things work and what it takes to get the job. Those who refuse to do this would likely not be a fit for these environments where these interviews are not the first or last things that are process you follow… just because. And make no mistake: these places screen for soft skills, teamwork etc. Those are done via recruiter screen, hiring manager interviews, to some extent architecture and bar raiser. The coding / algorithm interview is usually 1 or 2 out of 5-6 interviews. And the coding part is usually the most trivial to pass (for anyone putting in the effort to prep - see the point on putting up with mostly pointless stuff the job asks for) The problem is not that Big Tech uses these hiring processes (it makes perfect sense for them!) It’s when small companies hiring 5-10 ppl per year copy it, without thinking. More on how to build a sensible hiring process without blindly copying this: newsletter.pragmaticengineer…