Earlier quoted context omitted.
And yet, they still persist on presenting leetcode riddles that have very little relevance to the job being interviewed for. If they were hurting that much for devs, you'd think they might lower the bar a little by not requiring a years study of leetcode.
The riddle-like questions are trash, I agree. Any question that requires you to already know a slightly more arcane data structure or algorithm, or involves just regurgitating some algorithmic trick, or similar, really just gives you signal of "did this person already know the question beforehand?", and nothing else. Not asking those types of questions, and instead asking a more straightforward programming question w…
There's definitely a difference between hiring Sr. vs. Jr. programmers. When it comes to Sr, the best place I ever worked had a pretty great process:
1. Phone interview that was 100% identical for all candidates. It was basically a "take me through your work history, answering these 5 questions for each job." It worked wonderfully and gave a really good indication of what the person learned at each position and how they were able to apply that knowledge at the next job. And, if there was some obvious red flag at each step (e.g. "all my bosses have been jerks"). It also had the benefit of being more fair. I don't know how many places I've worked where if person A conducted the phone interview it was a shoe-in, and if person B did it was impossible to get through.
2. While doing #1, make a mental note of a couple things along they way they worked on (esp. if they seemed proud of them) and then - in a follow-up interview with a couple programmers on the call - really dig in deep on the technical details. Ask questions. You'll learn rapidly if they actually did the work and understand the problem or simply worked on it w/o understanding. What were the major challenges? What would they change now if they could go back? And here it's awesome if you get someone who can give answers that aren't always technical things (e.g. "I wish I knew early on how best to deal with X").
3. At this point, you're ready for an on-site and have already proven to yourself and the team "this person can code and solve problems." What's left is any final details you want to be sure of. Any odd personality quirks that won't work for the culture the company is going for? Let non-technical people they'd have to interface with interview them.
The best we ever came up w/ for Jr people was a test with some basic college class stuff like big-O and for problems 1-3 would you prefer linked list, hash table, or tree and why? And then try and do #1 and #2 above, but using their college classes/team projects as work experience. But that didn't always work out all that well.