Software Engineer screening interview questions

What a good software engineer screen should establish

• Hands-on ownership of real production code
• Ability to explain technical decisions and trade-offs
• Debugging approach and comfort with ambiguity
• Collaboration with product, design, and other engineers
• Alignment between the candidate's stack and yours

The questions, and what to listen for

1. 01

   Walk me through a project you shipped recently. What was your specific contribution?

   Listen for: Concrete personal ownership ('I designed the API, I wrote the migration') rather than 'we' throughout.

2. 02

   Tell me about a technical decision you made that you would make differently today.

   Listen for: Honest reflection, understanding of the trade-off, and what they learned.

3. 03

   Describe the hardest bug you have debugged. How did you find it?

   Listen for: A systematic approach: reproducing, narrowing scope, forming hypotheses, using logs or tooling.

4. 04

   How do you decide when code is good enough to ship?

   Listen for: Awareness of tests, code review, risk, and business context; not perfectionism or recklessness.

5. 05

   Explain a system you worked on to me as if I were a product manager.

   Listen for: Clear communication without jargon; adjusts to the audience.

6. 06

   What does your ideal code review process look like?

   Listen for: Values feedback, keeps reviews small, separates style from substance.

7. 07

   Tell me about a time you disagreed with a technical direction. What happened?

   Listen for: Argues with data and respect, commits once a decision is made.

8. 08

   How have you handled a production incident or outage?

   Listen for: Calm triage, communication with stakeholders, and a blameless post-mortem mindset.

9. 09

   Which parts of our stack are you strongest in, and where would you need to ramp up?

   Listen for: Self-awareness and an honest map of strengths and gaps.

10. 10

    How do you keep your skills current?

    Listen for: Specific, recent examples rather than generic 'I read blogs.'

11. 11

    What are you looking for in your next role?

    Listen for: Motivations that match what the role actually offers.

12. 12

    What questions do you have about the team or the codebase?

    Listen for: Curiosity about how the team works, quality, and product impact.

Red flags

• Cannot describe their own contribution separately from the team's
• Blames previous teams or managers for every failure
• No examples of shipping to real users
• Dismisses testing, reviews, or documentation as unnecessary