Writing code has always been the easy part of a software engineering job.
This has always been true, but it’s becoming more and more true as AI-based tools transform software engineering.
This also means that now, more than ever, trying to vet software engineering job candidates by their ability to sort a list or solve coding challenges or whatnot – coding challenges from leet code to whiteboards – are becoming even more useless than they were before.
Even before this wave of AI-powered software engineering, I didn’t use or trust traditional methods for vetting software engineers.
Some of this is my own biases. I not only taught at a coding bootcamp for two years, but I’m also a self-taught developer with an English major and a generic college degree.
I’ve also never landed a job that used one of these tests in the interview process. But I’ve had a twenty-year career in software development and been part of IPOs, acquisitions, and freelance consulting.
My bootcamp instructor experience reinforced my belief that anyone can write code. Watching folks go from learning what a variable is to landing software engineering jobs and building apps from scratch will do that to you.
And, thanks to today’s AI tools, this is more true than ever. Stories and worries abound about engineering candidates faking their way through traditional coding challenges with AI tools – with some designed specifically for this purpose.
This is why I believe that we should screen for the hard parts of software engineering instead:
- Can you understand and explain code?
- Can you explain why a code choice was made?
- Can you defend your choices if need be (and not be an asshole about it)?
- Can you translate business context into functioning code?
- Can you take feedback?
- Can you forecast future problems or issues?
- Can you work through ambiguity?
Basically, all the human and squishy parts of software engineering in a startup environment.
These questions are the things I wanted to try to vet with engineering candidates at my startup – not if they could sort a list of if they know O-notation.
I also knew from years of working with junior engineers and my own work experience that candidates are frequently fighting private battles with anxiety. I wanted to give them familiar ground to fight that battle on.
And that’s why I landed on an interview tactic I called “Show and Tell.”
I loved it then, and I highly recommend it to those hiring software engineers in this accelerating world of AI coding help.
How it works
- Ask the candidate to bring code to the interview. This can be code they love, code they hate, code they have lying around. Even code some AI spit out if they’re feeling frisky. But code they know and are ready to talk about.
- Talk about that code. This is your opportunity to check for their understanding of code, and their ability to explain the rationale behind their decisions. It can also give you an opportunity to see how they react to feedback and collaboration.
There is no Step 3.
A bit more about Step 2, though:
You can standardize this as much as you like, with a rubric and standard lines of inquiry or just wing it and go with vibes.
Either way, having an idea ahead of time of the skills or working styles you’re wanting to validate will go a long way and help you to guide the conversation.
One other possible advantage to this technique that I’ve successfully used in past roles is to combine this show and tell with the team interview – essentially get the whole team together in a room, and after the intros and standard questions, open up the show and tell.
Tradeoffs and considerations
Notably, this approach works best with folks who have code to show.
If you’re hiring for folks in closed source ecosystems they might only have work code to share from places they no longer work. This code might not be available for them to share, or might be covered by an NDA.
It rewards folks with open source code, side projects, and generally non-work code.
It is also less of a “test” than other techniques … there is no pass/fail standard and instead introduces a lot of squishiness.
As mentioned earlier, you can alleviate a lot of this by introducing a rubric and clear interview objectives, but it’ll never be as simple as “the tests pass.”
Final thoughts
I have found this technique to be highly effective at discovering how well a developer will work in a team environment.
In fact, when I’ve gotten into trouble in hiring is when I’ve overruled the results of this step in favor of a rosy prior work history.
Essentially, code is worthless unless it can be understood and explained, and people are always the hard part of working in software engineering.
It doesn’t matter how skilled a developer is if they don’t take feedback well, can’t explain their code, or blindly let AI take the wheel – just like copy pasta before.
Code is the least important part of software development, and your vetting process should instead vet the parts that actually matter – how we work with one another to get stuff done.