You just need to ask a couple of open-ended questions about the candidate's preferred programming language and/or some technical details of a past project they've worked on to get an idea of whether they are reasonably competent or not. It shouldn't take more than 10-15 minutes to go through. The majority of rest of the meeting can consist of the candidate asking you questions and/or chit-chatting to make sure the vibes aren't off.
What you are trying to judge is whether or not they can do the job, which you can really only tell once they are actually doing the job anyways. So you pay extra attention to what they do for the first couple of days/weeks after you've hired them and if it's obvious things are not going to work out you let them go. Most places have laws that are amenable to hiring someone on an initial trial period before stronger employee protections kick in.
In general, most of the pathologies of the hiring process can be solved by treating it as a satisfier problem instead of an optimizer problem.
I would be interested to explore a "quick hire, quick fire" philosophy, but I'm not sure it would lead to overall greater satisfaction. Employers don't like to fire people and employees don't like to be fired.
Because, let's be real, not a lot of us are writing leetcode type solutions in our shitty web devs jobs where we center a div. So we need to practice, and more importantly, memorize. Companies don't want a solution, they don't even want a good solution, they want one particular solution. That requires memorization.
> It’s typically 2 medium/hard problems solved optimally in 20 minutes each with no errors if I want to beat the competition.
I have also definitely made errors in interviews, and gotten hired. If I had to guess, it is a lot more about how you handle those. (To a degree. E.g., in one question, which was a coding challenge, I could solve it, but I was pretty sure my solution was not efficient. I voiced that, voiced why my gut was thinking it could probably be better, but I didn't ever get the full solution. In another one, I was just asked for past experience; I didn't think I had much to offer, voiced what I did have. I still to this day like the question, because it was a tough question, and the person who asked it really pressed me — in a good way, in that I could see that she took her own role/work seriously — on why I thought I was qualified.)
I've also had a call where me & the interview were definitely not connecting, at all. That wasn't going to work out, so nothing was lost?
As an interviewer,
> It’s typically 2 medium/hard problems solved optimally in 20 minutes each
… add 5 min for entry pleasantries and padding, 10 for questions for you at the end, and that's an hour, which is often all the time the recruiter schedules. And honestly, that's usually enough.
I don't ask hard problems. Easy ones sift out candidates. Where I ask coding questions, the first is almost always designed around "can the candidate write a for loop?" and the second is around basic datastructure comprehension. (Can you recognize situations that require a hashtable? a queue? and apply those to the problem.) Often a parsing question. Essentially CS 201, or easier, though I do not care if you know big-oh notation.
Most interviews I've been a part of fit that MO, and I've done interviewing with startups and with FAANG-sized companies.
> each with no errors if I want to beat the competition.
It's not about beating the competition. SWE hiring IME is never zero-sum. Two phenomenal candidates are two hires.
I'm not sure if we are experiencing different processes, or we have different opinions about what kind of time / reward tradeoff is reasonable.