In 2015 Max Howell, who wrote Homebrew, tweeted about his Google rejection: 90% of their engineers used his software, but he couldn't invert a binary tree on a whiteboard, so no. We all shared it and laughed, and then most of us went back to running the same interviews.
I like algorithms, and I've written a whole run of posts on two pointers. I still think most technical interviews measure the wrong thing, and I suspect most interviewers know it too.
The LeetCode round
The job ad says "build and maintain our customer dashboard." The interview says "find the longest palindromic substring in O(n) time, you have 40 minutes, talk while you type." Linear time on that one means Manacher's algorithm, and nearly everyone who knows it learned it from a LeetCode editorial rather than at work.
How well you do mostly depends on how many evenings you've spent on LeetCode lately. That tells the interviewer who had free time last month. It doesn't tell them who can debug a flaky integration or push back on a bad spec, which is what the dashboard job needs. The people who'd be best at that job, the ones with kids or a current job they're busy being good at, are usually the ones who haven't had the evenings.
I understand why companies keep doing it. When you're hiring at scale you need a test that hundreds of interviewers can run the same way, and a puzzle with a known answer is easy to standardise and easy to grade. Easy to grade isn't the same as measuring the job, though. And now that a model can solve the puzzle faster than either person in the room, the round increasingly measures who's willing to keep one open in another window.
The take-home that's actually a sprint
"Should take about two hours" usually means a weekend. The brief is vague, nobody tells you the bar, and you know the other candidates are polishing theirs, so you keep polishing yours. Then the rejection comes back as one line with no feedback, and you've done a weekend of unpaid work for what was basically a lottery.
The loop that never ends
Recruiter screen, hiring manager, technical, system design, "values," a second technical because one interviewer was off sick, then a chat with the VP. That's six to eight weeks, easily, and good candidates tend to take another offer somewhere around round four.
More rounds don't make the hire safer. They spread the decision across so many people that nobody ends up owning it.
What I'd do instead
I'd test the job itself. Give the candidate a small, real-ish codebase with a bug and a feature request, and pair with them on it. An hour of watching someone read code they've never seen tells you more than a day of whiteboards.
If there's a take-home, be honest about how long it takes. Over two hours, pay for it. If you won't pay for it, cut it down.
I'd keep the whole thing to three rounds over two weeks: the pairing session, a design conversation, and meeting the team. Then decide. If you still can't, the problem is your rubric, not the candidate.
And I'd always send feedback, even if it's two sentences. It costs you nothing, and it's the only part of the process the candidate can use afterwards.
Interviewing is hard, and I haven't figured it out either. But "the big companies do it this way" isn't a hiring strategy. It's cosplay.