> hard to truly tease out quality during interviews
I'm not sure I agree here. I doubt most interviewers have actually given much thought to what they are actually trying to look for in a potential candidate. The widespread practice of over-focusing on algorithmic whiteboard questions is a symptom.
There's got to be better processes in assessing candidates' qualities beyond solving algorithmic puzzles (which perhaps is 5% of a software engineer's job at best).
I dunno, I’ve conducted about 100 dev interviews over the years. Have tried various combinations of whiteboarding, architecture/design questions, take home problems, talking about past projects/experience, and sitting down together with the interviewee and pair coding on bugs or small features. I don’t know that any approach was clearly more effective than another, and for all of them I think the ability of myself and other interviewers to predict performance at the company was decent, but far from excellent. The clearest signal is probably a super enthusiastic referral (from a highly trustworthy source), but it’s rare to be able to get that.
It’s just really tough to figure out in 2-3 hours how someone is going to perform in a given role over the next few years. Interviewing is an inexact art, not an exact science, and it’s very much my experience that companies compensate for this by favouring false negatives (not hiring possibly strong candidates) over false positives (hiring weak candidates).
I'm not sure I agree here. I doubt most interviewers have actually given much thought to what they are actually trying to look for in a potential candidate. The widespread practice of over-focusing on algorithmic whiteboard questions is a symptom.
There's got to be better processes in assessing candidates' qualities beyond solving algorithmic puzzles (which perhaps is 5% of a software engineer's job at best).