After running the full hiring pipeline at SOLID Code — CV screening, technical interviews, take-homes, onboarding — I've learned that the things that predict performance are rarely the things that show up on a CV.
Years of experience is a proxy, not a signal. I've interviewed engineers with seven years of experience who couldn't explain why they made the architectural decisions they did, and junior engineers two years in who had clearly spent those two years thinking deeply about the problems they were solving. The number matters less than what someone did with the time.
The Question I Always Ask
Tell me about a technical decision you made that you'd make differently now. This question does a lot of work. It filters out people who've never reflected on their work. It surfaces how someone thinks about trade-offs. And it tells you a lot about their intellectual honesty — whether they can separate their ego from their code.
The best answers I've heard aren't about dramatic failures. They're about small decisions — a service boundary that turned out to be wrong, a technology choice that seemed right at the time, a design that worked but that the candidate now understands more deeply. The willingness to say 'I was wrong and here's why' is a strong signal.
What Ruins An Interview
Candidates who can only answer questions about technologies they've used, not questions about why they used them. Working with a technology for three years without ever questioning its constraints isn't three years of experience — it's one year repeated three times.
Candidates who frame every past challenge as someone else's fault. Projects fail, codebases get messy, teams make bad calls. Someone who has never owned part of that failure hasn't been paying attention.
Candidates who can't say 'I don't know.' Confidence is good. Pretending to know things you don't is a liability on a team where architectural decisions have real consequences.
What I've Learned To Value
Communication over brilliance. An engineer who can clearly explain what they built, why they built it that way, and what they'd change is more valuable than one who produces clever solutions that nobody else can reason about. Code is read far more than it's written. The same is true of architecture.
Curiosity that goes one level deeper. Not someone who read a blog post about CQRS and now wants to use it everywhere — but someone who asks why the pattern exists, what problem it's solving, and whether that problem applies here. That extra question is what separates engineers who grow from engineers who collect technologies.
Ownership instinct. The engineers who have made the biggest impact on the teams I've led are the ones who didn't wait to be asked. They saw a problem, assessed it, raised it, and proposed something. Not loudly — quietly, systematically. That instinct can't be taught easily. It can be nurtured if it's already there.