How to Interview a Software Developer: Practical Exercises That Show Real Skill

Software development has been around for decades, yet many organizations still struggle with one basic challenge: knowing whether a developer can really code before they hire them. Managers often leave it to a senior engineer to "have a chat", or they trust the résumé: if the candidate stayed more than a year at a well-known company, the thinking goes, they can’t be much of a risk.

A résumé tells you where someone worked. It doesn’t tell you what happens when their code doesn’t work. The most reliable way we’ve found to find out is a practical interview: give the candidate real code and watch how they work with it.

This guide is for hiring managers, engineering leads and senior developers who interview developers themselves. If you’re choosing a development company rather than hiring an individual, see how to vet software developers when everyone uses AI.

Step 1: Prepare the exercises before the interview

If you’re hiring someone who can really code, make the interview about writing and understanding code. Prepare a few short programs, or code snippets, in advance: some that don’t compile, some with logical errors, and some that work but contain bad design or coding practices. Have them open in the IDE before the candidate joins, so the time is spent in interviewing and not in setting up in front of the candidate.

Use the same language, framework, and tools the candidate would use on the job. For web developers, that often includes browser developer tools. For desktop, mobile, or backend developers, use the IDEs, debuggers, and supporting tools commonly used in that environment.

Step 2: Evaluate how they handle compile errors

Give the candidate a program with a few compile errors and ask them to build it and explain the errors they see. You do not necessarily need them to fix every issue. What matters is how they approach the problem.

Pay attention to:

• Which error they investigate first
• Whether they can distinguish root-cause errors from secondary errors
• How they interpret compiler messages
• Whether they form and test a hypothesis before making changes
• How clearly they explain their thinking

An experienced developer will often recognize patterns quickly and focus on the error most likely causing the others, rather than attempting to fix every message one at a time.

Step 3: Evaluate debugging skills

Hands-on practice is what you’re really hiring for, and the best test of practice is debugging. Prepare a few small programs with logical errors. Ask the candidate: "This should do X, but it does Y. How would you find out why?"

You’ll learn quickly how much debugging they’ve done. Pay attention to how they approach the problem, not just whether they reach the answer.

Look for:

• Breakpoints: do they use them, and where do they put them?
• Watch variables: do they inspect values while stepping through, or only add print statements?
• Immediate window or console: do they evaluate expressions while paused, in the Visual Studio Immediate Window, the VS Code Debug Console or the browser console?

If that goes well and the candidate is senior, go deeper:

• Open the Debug menu and ask which options they’ve used and what they know about the others.
• Ask whether they’ve used Attach to Process in Visual Studio, or attached a debugger to a running service. Familiarity with advanced debugging techniques often shows experience troubleshooting production systems and complex applications.
• Discuss how they would debug a Windows service, a background job or a multi-threaded application. You’re asking for their approach and opinions here, not one fixed answer.

For web developers: the browser’s developer tools

Open the developer tools in Chrome, Edge or Firefox and ask which panels the candidate uses and when they’re useful: Elements, Console, Sources (breakpoints in JavaScript), Network, Application (storage and cookies), Performance. Nobody is expected to know every option, but the more they know, the more confident you can be about how they’ll work.

A good practical question: "This page calls the same API twice when the user clicks Save. How would you find out why?" The Network panel answers it in a minute for someone who uses it every day.

Step 4: Good practice vs bad practice

Prepare code that compiles and runs but has something wrong with it, and ask the candidate what they’d change. You’ll get many different answers, and each tells you something about how they think. Two examples in C#:

Sample 1

try
{
    DoSomething();
}
catch (Exception ex)
{
    throw ex;
}

What a good answer covers: throw ex; resets the stack trace, so the log no longer shows where the error really happened. Use throw; to rethrow, or wrap the original in a new exception with more information. And if the catch block adds nothing, it shouldn’t be there at all.

Sample 2

static void Main()
{
    var service = new MyService();
    var x = new MyObject();
    x = service.GetX();
    PrintX(x);
}

What a good answer covers: the new MyObject() is created and immediately thrown away, because x is replaced on the next line. It’s harmless here, but it shows whether the candidate understands what a variable holds. A strong candidate may also ask what happens if GetX() returns null.

You can build more samples like these from the problems you find in your own code reviews.

Step 5: Review a pull request

If you want to evaluate more, or you skipped some of the steps above, ask the candidate to review a pull request. Pick a few PRs from a real project with a good amount of change, and ask: "If you were reviewing this, what would you comment on, and what would you let go?"

The answer will mix facts and opinions. Opinions cover spacing, naming conventions, indentation, comments and readability. Every candidate should have them, even if they differ from yours. The facts are what separate experienced developers. Strong candidates often spot:

• Error handling: empty catch blocks, throw ex;, exceptions that are swallowed or never logged.
• Security: user input that isn’t validated, SQL built by string concatenation, secrets in the code.
• Performance: a query inside a loop, an API called more than once for one user action, data loaded that’s never used.
• Maintainability: hard-coded values and folder paths that belong in configuration, the same code copied in several places, file paths joined with + instead of Path.Combine.
• Resources and data: disposable objects not wrapped in using, inserts and updates that aren’t in a transaction or aren’t rolled back on error.
• Testing gaps: a change with no test, or a test that can’t fail.
• Unnecessary complexity: an abstraction nobody needs yet, or ten lines where two would do.
• Warnings: code that builds, but with compiler warnings nobody has looked at.

These are among the things our own reviewers check before code is merged.

Step 6: For senior developers, discuss design decisions

Senior engineers aren’t distinguished by typing speed. They’re distinguished by technical judgment. Take an application the candidate has built, or one of yours, and ask:

• How would you scale this application?
• How would you secure it?
• What monitoring would you put in place?
• When would you split it into separate services, and when wouldn’t you?
• What would you refactor first, and why?
• If this page were slow in production, what would you look at first?

There’s rarely one right answer. Listen for trade-offs: a candidate who explains what each option costs is usually more experienced than one who has a single favourite answer for everything.

What doesn’t work on its own

• Theory tests. Many tools test theoretical knowledge. They’re useful, but they don’t give you the whole story. And someone with only practical skills who doesn’t understand why isn’t a good fit either.
• Experience and certificates. A candidate with many years and many certificates can look qualified before you’ve seen them write a line of code.
• Big-name employers. Previous employers, certifications and years of experience should be treated as indicators, not proof of capability. Practical exercises remain one of the most effective ways to evaluate technical skills.

What the exercises don’t tell you

None of these steps tests attitude or core values. A good developer isn’t always a good teammate, and a good teammate isn’t always a good developer, but your team needs both. The practical interview shows you the skills. Whether the person fits your team is still your decision, and it deserves its own conversation: how they handle feedback, how they ask for help, and how they talk about past teammates.

How we use this at SharpQuest

Every developer who works on a SharpQuest project is a SharpQuest employee. We do not subcontract software development work.

Our interview process uses variations of these exercises to evaluate practical skills such as troubleshooting, debugging, code review, and technical communication. The code review portion of the interview focuses on many of the same qualities we evaluate during peer reviews on client projects.

The goal is consistency. The skills we look for during interviews are the same skills developers use every day when reviewing code, resolving issues, collaborating with teammates, and participating in our daily stand-up.

These practices are part of how we work and how we maintain quality across custom software development projects.

Frequently asked questions

How long should a technical interview for a developer be?

About an hour is usually enough for compile errors, a debugging exercise and one bad-practice sample. Add 30 minutes for a pull request review or design discussion with senior candidates. Having the code open in the IDE before the interview saves more time than any other preparation.

Should we use take-home assignments or live exercises?

Live exercises show how a candidate works: how they read errors, use the debugger and explain their choices. A take-home assignment shows the finished result, but not how they got there. If you use one, follow it with a live session where the candidate changes and explains their own code.

What should I look for when a candidate debugs code?

Where they put the first breakpoint, whether they inspect values instead of guessing, and whether they form a theory and test it. Familiarity with advanced tools, such as attaching a debugger to a running process, often shows experience with production systems.

How do I interview a senior developer differently?

Spend less time on syntax and more on judgment: a pull request review and design questions about scaling, security, monitoring and refactoring. Listen for the trade-offs they explain, not for one right answer.

Are coding certifications a good measure of a developer?

They show what someone has studied, not how they work. Treat certifications, past employers and years of experience as indicators, and confirm them with a practical exercise.

What about candidates who use AI coding tools?

Updated 2026 Most developers now use AI tools such as ChatGPT or GitHub Copilot, and that makes a practical interview more important, not less. A working solution says little on its own; asking the candidate to change their own code and explain why it works shows whether they understand it. We wrote about what we’ve seen in how to vet software developers when everyone uses AI.

---

A résumé gets a candidate to the interview. The code they read, debug and review in the interview tells you whether to hire them. If you’ve found other ways to evaluate developers that work for your team, we’d like to hear them.

If you’d rather work with a team that’s already been through this, see our software development services or how to choose a custom software development partner. Developers who’d like to try our interview can see our open positions. And if you’re planning a project, talk to us.