I really enjoyed this article, I wish I would have read this the week before I first started interviewing people. I have 100% made some of these mistakes before.

Thankfully, when I first started, I was interviewing alongside a team of engineers more experienced than me, and I had a terrific manager that slowly brought me along (or left me out when I was out of my league) to strengthen my interviewing skillset - otherwise I would have sunk a deserving candidate at least a couple of times.

I still don't consider myself an exceptionally strong technical developer, but at least I know enough about my limits to know how to set the table effectively during an interview.

Aside from what was listed in the article, a couple of additional pieces of advice I've picked up along the way were:

1. Don't leave an interview with any suppositions that could have been clarified directly with the candidate. If you're unsure of something on their resume, ask them to clarify, even if it makes you feel a little uncomfortable (except don't ask legally protected questions, of course) 2. Seek curious people. You can teach a programming language, but you can't teach interest in the craft.

Another major problem is recruiting for something specifically, explicitly niche instead of adjacant skills that directly imply ability to learn it. Whatever gain they thought they were going to get by filtering so hard to derisk is lost many times over by lack of availability of the specific experience creating endless delays.