TL; DR:

• Does the interview represent the work?
• Are you trying to support the candidate or gatekeep the role?
• Join the livestream (or watch the recording) on Monday, September 15th, at 7:00 PM Pacific!

---

Interviewing That Actually Works

I’ve been on the interviewer side a lot lately, and it reminded me how bizarre our industry can make this process. We throw candidates into multi-round gauntlets, then judge them on puzzles they will never see again. You know, like that binary tree question you had to do or the graph theory one you were stumped on.

Meanwhile, the traits that matter at work--clarity, judgment, collaboration, and the ability to learn--get treated like extras. Some of the fundamental things that we want to see in software engineers get completely glossed over because we do this circus of ridiculous interview questions.

Here’s the approach I use now. It’s simple, human, and it maps to how we actually build software in the teams I've worked in. I was inspired to write this after interviewing candidates recently and reflecting on some of the interviews I had for my current role at Microsoft -- and you can hear more about that on Code Commute:

Start with intent and say it out loud