Engineering and data
A first interview with an engineer should answer three questions. Did this person really build what’s on their résumé? Can they think through a problem out loud? Do they make sensible trade-offs, giving up one thing to get another? It doesn’t replace your technical interview. It tells you who should get one.
The AI asks follow-up questions that go past a rehearsed summary, into details only someone who did the work would know.
What to look for
The questions
Ask them in order. Listen for real details: what happened, what the candidate did, and how it ended.
Strong answer
Explains the problem before the tools, separates their own part from the team’s, and names one decision and what it cost.
Weak answer
Lists technologies, says “we” all the way through, and can’t say what they did themselves.
Strong answer
Made a guess about the cause, then narrowed it down with logs, a reliable way to make the bug happen, or by testing older versions one by one. Found the root cause and changed something so it couldn’t happen again.
Weak answer
“I found it eventually”, or the fix was a restart and they never learned the cause.
Strong answer
Names the limit they were working under, like a deadline or a small team, says what they gave up, and looks back on it honestly.
Weak answer
Always picked the most complex option, or can’t name a single trade-off they’ve made.
Strong answer
Stopped the damage first, by going back to the last working version or switching the feature off. Kept people informed, then found the cause and wrote up what would change.
Weak answer
Blames the testers or another team, or spent the hour hunting the bug while users were still stuck.
Strong answer
Asks about time zones, how many users there are, and what happens when an email fails to send. Then breaks it into parts: storing each user’s schedule, a background job that sends the emails, retrying failures, and alerts when something goes wrong.
Weak answer
Jumps straight to a specific tool without asking anything, or can’t break the problem into pieces.
Strong answer
Argued with reasons, stayed open to being wrong, and can tell a real problem from a personal preference that’s worth letting go.
Weak answer
Always gives in to avoid friction, or tells it as a story about winning.
Strong answer
Tests the parts where a failure is most likely or would cost the most, and gives an example of something they chose not to test, and why.
Weak answer
“I test every line”, or “we never had time for tests”, with no view of their own.
Strong answer
Names a specific idea or practice and describes code they wrote differently because of it.
Weak answer
Names a new tool they’ve read about but can’t say what changed in their work.
Before the interview
Short form questions the candidate answers before the interview. You read the answers next to the interview. They aren’t scored.
Listen for
Avoid
Use this in LessRounds
Paste the questions into a scripted interview, where the AI reads each question word for word. Add the skills from the scorecard, then share one link. Every software engineer candidate gets the same questions. You get a score for each skill, with the candidate’s own words that explain it.
No. It checks whether someone can think through real work and explain their decisions. It doesn’t check whether their code meets your standard. Use it to decide who gets your take-home task, or a session writing code alongside one of your engineers.
Listen for how big the work was and how many people it involved. Senior engineers talk about why a problem was worth solving, what they chose not to build, and how they got others on board. Mid-level engineers tend to describe the building work itself.
Start with 100 free credits, enough for about 20 interviews. No credit card or sales call needed.