I made a lot of hiring mistakes early on.
Back in 2004, when I started interviewing candidates, I was impressed by all the wrong things. Multi-page resumes. College degrees. Long lists of certifications with acronyms. I didn’t have those credentials myself, so I assumed they mattered. I’d vouch for these candidates, recommend we hire them, and then a few months later, I’d regret it.
The work didn’t match the resume. The quality wasn’t there. The practices and patterns they followed didn’t live up to my expectations. That’s when I started noticing something: some people had 20 years of experience, but they were really just repeating year one, 20 times over. They learned something early and never revised their knowledge.
So I stopped being impressed by years of experience. And I stopped caring about certification counts.
Building a Better Interview Process
Years later, I developed a different approach. After an initial conversation, I’d send candidates two assignments to complete on their own time.
The first assignment simulated an existing small application, but I intentionally made the code messy. The instructions were simple: make the changes described in this one or two-page document. It shouldn’t take more than 30 minutes to an hour for a solid developer.
What I was looking for wasn’t whether they could complete the task. I wanted to see how they thought about solving the problem. Did they clean up the mess? Did they rename variables? Did they remove useless comments? Or did they just add their changes to the existing chaos?
I’d often ask, “If you had more time, what other changes would you have made?”
If they did well, I’d send the second assignment: work on that same application and do whatever you want with it. Introduce automated tests. Add a dependency injection container. Refactor however you see fit, as long as the features still work.
I wanted to see where they’d go with it.
Every person I hired through that process, I would still hire today. They were great to work with.
What I Was Really Looking For
At one point, I started doing more in-person interviews. I’d open the messy code, hand them the one-page document, and ask, “Where would you start?”
I wanted to see their reaction. Would they look at the code and say, “This is messy”? Would they say, “I’d probably start by renaming some variables for clarity before making changes”? Or would they just dive in and contribute to the mess?
I’d ask about automated tests. How would you handle the dependencies in this spaghetti code? How would you approach testing this?
But the technical questions weren’t the most important part.
What mattered more was whether they were coachable and whether they could teach.
When I noticed someone didn’t know something, I’d take a moment to teach them. Then I’d watch: did they get curious? Did they ask follow-up questions? What did they do with what I just shared?
And when I found something they knew that I didn’t, I’d ask them to teach me. How would they explain it? Could they make it clear?
Those are the skills that matter. Can they be coached? Can they coach others? Will they disagree with me when they see things differently? Are they open to other perspectives?
The technical stuff, you can look up. You can learn syntax. You can figure out where the curly braces go.
But being coachable and being willing to coach others? That’s harder. People call it a “soft skill,” but in many contexts, it’s actually the hard skill. Hard as in difficult.
A Tip for Job Seekers
I don’t interview people as much anymore, but I know there are others out there who think as I do.
So here’s my tip: develop those two skills.
Be coachable. Be willing to learn, to listen, to revise what you know.
Be a coach. Be able to explain what you know clearly and help others grow.
Those will take you further than any list of certifications.
I find this approach also helps when partnering with AI tools.
Leave a Reply