Use this guide to interview a Software Engineer at the early-to-mid level. You are hiring for reasoning, working habits, and trajectory more than for accumulated scope — so favor questions that reveal how the candidate thinks and learns over questions with a single right answer. Pick eight to twelve per session, keep the set consistent across candidates, and score against the competencies below.

Fundamentals and problem solving

• Walk me through a recent problem you solved that you are proud of. What made it interesting?
• How do you choose a data structure? Give an example where the choice mattered for real performance.
• Explain a concept you understand deeply — caching, hashing, concurrency — as if to a new graduate.
• What happens when a browser makes an HTTP request to a server? Go as far as your knowledge takes you.
• How do you estimate whether an approach will be fast enough before building it?
• Tell me about a time complexity analysis actually changed what you built.

What good looks like: you are listening for reasoning, not recitation. Strong candidates explain trade-offs in their own words, connect theory to a concrete decision they made, and say "I don't know, but here is how I would find out" instead of bluffing when they hit the edge of their knowledge.

Coding and code quality

• What does clean code mean to you? Show me with a before-and-after example from your own work.
• How do you approach naming, and why does it matter more than it seems?
• When do you add an abstraction, and when is duplication the better choice?
• How do you keep functions and modules from growing without bound?
• What does a good commit history look like, and why should anyone care?

Systems and debugging

• A service starts returning intermittent errors. Walk me through your first fifteen minutes.
• How do you read logs effectively? What separates useful logging from noise?
• Tell me about a bug that turned out to be in code you did not write — a library or the platform. How did you prove it?
• What is a race condition? Describe one you have caused or fixed.
• How do you reproduce a bug that only happens in production?
• When you have been stuck for hours, what do you actually do?

What good looks like: strong candidates are systematic — they form hypotheses, bisect the problem space, and change one variable at a time instead of thrashing. Crucially, they know when to ask for help and arrive with a summary of what they ruled out, rather than grinding silently or escalating with no context.

Testing

• When time is limited, what do you test first, and why?
• What makes a test valuable versus noise?
• How do you catch the edge cases you did not think of? What practices help?
• Tell me about a bug that a test you had written caught later. What did that teach you?

Collaboration

• How do you handle code review feedback you disagree with?
• Tell me about a time you misunderstood requirements. How did you find out, and what changed in your process?
• How do you communicate progress when a task takes longer than estimated?
• What do you do when documentation is missing and the original author is gone?
• Describe helping a teammate at cost to your own work. How do you balance that?

Growth and motivation

• What have you learned in the last six months outside of assigned work?
• Which engineer or codebase have you learned the most from, and what specifically did you take away?
• Where do you want to be technically in three years?
• What kind of feedback is hardest for you to receive? Give an example of acting on it anyway.