Last post I addressed some of the problems with many of the common engineering interviewing practices found in today’s tech scene and introduced a philosophy of interviewing that focuses on the outcome and product we expect from our hires instead of simply performing a skill assessment for how they use specific tools. This week I want to dive into some specifics of how we as engineering interviewers can instead evaluate the outcome and product with an example problem, and how to ask our questions in ways that show a candidate’s overall cognitive process.
I’ve been interviewing and hiring for Software Engineering roles for most of my career. There’s always been concerns about candidates “cheating” their way through interviews. “I think this candidate is using google”, “This candidate seemed to already have known the questions we were asking”, and similar accusations have been common refrains at hiring huddles for as long as I can remember.
Making sure we as engineering managers and engineering leaders are fairly and accurately evaluating the qualifications for a candidate is essential to building functional engineering teams, and removing or detecting usage of interview assistance tools is a natural initial response after you catch your first candidate cheating their way through an interview. But this begins a forever game of cat and mouse with each side escalating the detection and stealth capabilities respectively until at some point we just give up and return to the days of flying candidates into an office, and interviewing them on a company laptop.
This site is mostly just a collection of thoughts on topics I feel strongly enough on in the moment to write about. Anything from useful tech tips I don’t want to forgot, rants about consumerism culture’s contributions to the decline of practical creativity, or my recent adventures in my home shop.