I’m trying to hire a Lead Backend Engineer for our team of 15, and the usual ways of evaluating candidates don’t feel reliable anymore. We developed an enterprise saas and need to expand as we grow and the struggle is real for me as the project owner/exec who oversees everything. I have asked my team for referrals but seems everybody has an angle of who they want to bring in.
AI has flattened the signal:
- resumes all look polished
- technical answers sound perfect
- take-homes are easy to outsource
- GitHub isn’t representative for most engineers
I’m not trying to filter for trivia or clever algorithms. I’m trying to figure out who has actually dealt with real production problems—messy data, weird bugs, performance bottlenecks, half-rewritten systems, tradeoffs under pressure, etc.
Here’s what I’m struggling with:
System design interviews feel too “textbook.”
People give confident, generic answers that don’t reflect real constraints.Asking about past projects is hit or miss.
Strong engineers go deep; others stay vague. AI is getting better at sounding deep.Code tests don’t show judgment.
They show whether someone can complete tasks, not whether they can lead or review code.
What I want to understand is simple:
- How do they reason about tradeoffs?
- How do they review imperfect code?
- How do they debug something when logs are useless?
- How do they push back when a solution is bad?
- These are the parts of the job that are hardest to fake—and hardest to measure.
So I’m asking the dev.to community:
If you've hired senior engineers recently, what actually worked for you?
What interview formats or signals helped you separate real experience from polished answers?
I’d appreciate any advice from people who’ve been on either side of this.
Top comments (3)
Some thoughts
System design interviews: pick a ticket you've just completed and use that as the design scenario because you've just lived it. One thing I cannot over stress is go with the applicant's flow. I've been interviewed by companies that got frustrated when I wasn't solving it their way, and I was hired by a company that rolled with my punches :)
Asking about past projects is hit or miss: it is. Just pick something that you feel is important that you don't introduce to your current team. Is there a culture or a trait you want to avoid? Maybe spar with AI to give you some ideas.
Code tests don’t show judgment: absolutely worthless now. My take is to pair with them showing you how they slice a problem up using AI. To see how someone is prompting will give you massive insight into whether they are just winging it, or actually collaborating with the tool. In other words, don't try to design a test to eliminate the AI. Absolutely include it and make them work for it! :) An engineer will reveal their value by their prompts in ways a coding test can't.
How do they review imperfect code?: It's you second day on the job. You've got AI and a couple of repos and a bug ticket. What you gonna do?
How do they debug something when logs are useless?: Maybe a better scenario is how to you make logs not useless in the first place. Here's a function that is not surfacing logs. What are we doing wrong and how can we improve it?
How do they push back when a solution is bad?: Don't ask them that question. Give them a bad solution and see how they push back :)
Does that help?
Thank you for the advice. Much appreciated.
Oh, I forgot. Something that annoyed me as an interviewee in the technical interviews was where there was an abstract function or similar to talk about. I'd always preface the interview by saying "I'm going to treat this like a Sprint Refinement meeting", and so I'd ask very specific questions about making the task clear and executable. Almost every time there was a hand-wavy "you don't need to worry about that" response. Now, that actually told me more about how they operate than it told them about me :)
So my advice would be to you to wrap the technical interview around whatever ceremonies you already have in your teams and watch how the interview reacts to that, and what questions they ask, and maybe they'll actually get to do some code (but don't worry too much about that).
Hope that helps a bit too.