Engineering and data
A first round for engineers should answer three things: did this person really build what’s on their résumé, can they reason through a problem out loud, and do they make sensible trade-offs. It doesn’t replace your technical round. It tells you who is worth one.
Follow-up questions push past the rehearsed summary to the details only someone who did the work would know.
What to screen for
The questions
Ask them in order. Listen for specifics: what happened, what they did, how it ended.
Strong answer
Explains the problem before the stack, separates their part from the team’s, and names one decision with what it cost.
Weak answer
Lists technologies, says “we” throughout, and can’t say what they personally did.
Strong answer
Describes forming a guess, narrowing it with logs, a reliable reproduction or bisecting, the root cause, and what they changed 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 constraint, like a deadline or a small team, says what they gave up, and looks back on it honestly.
Weak answer
Always picked the most sophisticated option, or can’t name a single trade-off they’ve made.
Strong answer
Stopped the damage first with a rollback or a flag, kept people informed, then found the cause and wrote up what would change.
Weak answer
Blames QA or another team, or spent the hour debugging while users stayed broken.
Strong answer
Asks about time zones, volume and what happens when a send fails, then breaks it into parts: storing schedules, a job runner, retries and monitoring.
Weak answer
Jumps to a specific library without asking anything, or can’t break the problem into pieces.
Strong answer
Argued from reasons, stayed open to being wrong, and knows the difference between a real problem and a preference worth letting go.
Weak answer
Always defers to avoid friction, or tells it as a story about winning.
Strong answer
Tests by risk and by how expensive a failure would be, and gives an example of something they chose not to test and why.
Weak answer
“I aim for full coverage”, 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 without saying what changed in their work.
Before the interview
Quick facts to read alongside the interview. They aren’t scored.
Listen for
Avoid
Use this in LessRounds
Paste the questions into a scripted interview, add the scorecard skills, and share one link. Every software engineer candidate gets the same questions, and you get a score for each skill with the quote behind it.
No. It checks whether someone can reason about real work and explain their decisions. It doesn’t check whether they write code to your standard. Use it to decide who gets your take-home or pairing session.
Listen for scope and people. Senior engineers talk about why a problem was worth solving, what they chose not to build, and how they brought others along. Mid-level engineers tend to describe the build itself.
Start with 10 free interviews a month. No card, no sales call.