Recruiting good software developers is hard. A resume can look strong, a technical test can look neat, and still the interview may not show whether the person can work well with your team.
At HDWEBSOFT, we treat developer interviews as a conversation, not an exam. We still check technical skills carefully, but we also pay close attention to how candidates explain, ask questions, receive hints, and turn a vague problem into a practical solution. That matters whether we are building a custom software development team or supporting a client through an extended engineering model.
In this post, I’ll share the interview approach we use when hiring software engineers. It is written mainly for technical interviewers, but HR specialists, team leads, and founders can also use it to understand what a good software developer interview should reveal.
I also recommend reading Chuck Groom’s Software Engineer’s Guide to Interviewing Software Engineers and Developer Job Interview Questions. Both share useful perspectives on making interviews more effective and more respectful.
The audience
This article is most useful for technical interviewers who can run a practical discussion with candidates. Some examples may be difficult for non-technical readers, but the core idea is simple: a good interview should reveal how a developer thinks, communicates, and grows.
Define your criteria first
Before asking questions, define what you want to evaluate. Each company has its own hiring criteria, but in our experience the most important ones are:
- Communication: Can the candidate explain clearly, ask useful questions, and work with others?
- Actual level: What can the candidate do right now?
- Potential: What can the candidate become next month, next year, and in the next five or ten years?
For HDWEBSOFT, communication is the first criterion. We work as an offshore software development company with clients in different countries, so even a strong developer will struggle if they cannot communicate clearly.
Start with an open, calm approach
Before starting the technical part, we make the interview atmosphere clear. We tell candidates something like this:
Don’t panic. Nobody knows everything. The purpose of this interview is not to prove that you know every answer. We want to see whether we can collaborate, think through problems together, and find good solutions.
This simple message helps candidates relax. It also sets the right expectation: we are not only testing memory; we are observing how they work.
Check communication throughout the interview
The best way to interview software developers is to evaluate communication during the whole interview, not as a separate section.
Communication appears when candidates describe a past project, clarify requirements, explain a technical decision, or admit what they do not know. These moments are often more valuable than a perfect textbook answer.
Can they explain what they have done before?
One useful question is asking candidates to describe a project they have worked on. For example:
- What is your favorite project?
- Who used the product, and what value did it bring them?
- What were the most important technical points in that project?
- What was your real contribution?
The expected answer is not a long speech with every technical detail. A good answer is short, clear, and focused on the important points.
This helps us evaluate two things:
- Can the candidate understand a project as a whole?
- Can the candidate pick out the key points instead of getting lost in details?
If a developer has no clear feeling about what they built, it is hard to trust that they truly understood the work. Developers who can summarize a past project well usually have better potential to understand future projects too.
Can they turn an explanation into technical specifications?
Another useful interview method is to give candidates a small requirement and work with them toward a solution. The difficulty should match the candidate’s level and experience.
The goal is not always to see whether they know the answer immediately. Sometimes the better signal is whether they can ask good questions, understand hints, and adjust their thinking.
Below are a few examples.
Example 1: A simple question for a fresher
Question: It is now 1 AM in New York. What time is it in Vietnam?
If the candidate cannot answer immediately, I allow them to ask questions. A good question might be: “What is the time zone of New York?”
If they do not know the formula, I can explain that Vietnam is UTC+7 and New York has its own time zone depending on the date. Then I observe whether they can use that explanation to calculate the answer.
The point is not geography. The point is whether they can ask meaningful questions and use new information.
Example 2: Combining the question with a common algorithm
Question: I have a sorted array with 1,000 items. I want to check whether a value exists in that array. In the worst case of binary search, how many checks are needed?
If the candidate forgets binary search, I explain how it works. If they can follow the explanation and calculate the answer, that is still a good sign.
This question tests more than memory. It tests whether they can understand a concept quickly and apply it.
Example 3: For a PHP developer, backend developer, or full-stack developer
Question: Forget PHP Session for a moment. If you had to write your own library to do the same job, what would you build?
This question can be difficult even for PHP developers with a few years of experience. If they are unsure, I explain how PHP Session works and see whether they can reason from there.
Many developers work mainly with high-level frameworks such as CakePHP, Laravel, Symfony, or similar tools. That is fine, but sometimes it makes them underestimate important fundamentals. This question helps reveal whether they understand what happens under the framework, which is especially important when you need to hire PHP developers for a long-running product.
Example 4: For a full-stack developer
Question: How would you build a normal e-commerce shopping cart and checkout flow?
If the candidate handles the basic flow well, I extend the question: Suppose a product has a limited inventory count. How would you make sure the purchased quantity never exceeds that limit?
This is a good topic when evaluating candidates for backend-heavy work. A junior developer may talk about basic cart behavior. A stronger developer may discuss validation, transactions, locking, race conditions, payment status, and order rollback. If your project depends on those decisions, it may be worth working with experienced backend developers.
How they explore the problem tells us a lot about their real level.
Example 5: A less common but interesting technical problem
Question: I have an admin page with a list of products. When one user opens a product edit page, how can we make sure no one else can edit the same product at the same time?
This is mainly about resource locking. Some candidates can answer directly. If not, I guide them back to a more familiar case: user registration, where the system must prevent two users from being created with the same email at the same time.
Then I ask: “Can a similar practice be applied here?”
This question is useful because it shows whether candidates can transfer knowledge from one problem to another.
What these questions reveal
From the examples above, the interview usually leads to two situations:
- The candidate answers fluently because they already understand the topic well.
- The candidate does not know the answer immediately, so we work through it together.
The second case is often more interesting. During that process, we can see whether the candidate asks useful questions, understands clarification, reasons logically, and moves toward a solution.
This allows us to evaluate several things at the same time:
- Communication: Can they ask and explain clearly?
- Actual level: What kind of problems have they already handled?
- Potential: Can they become a problem-solver, or do they only handle repetitive tasks?
That is why scenario-based discussion is one of the best approaches to interviewing software developers. It compresses many signals into one conversation.
Check the candidate’s actual level
I will not spend too much time on this part because many technical question lists already exist. Java has its own common questions. So do .NET, Python, iOS, Android, React Native, Node.js, React, Vue, JavaScript, CSS, and many other areas. For product teams, this often connects directly with the type of software development services they need.
Those questions are still useful. You need to know whether the candidate can do the job today. But a list of framework questions should not be the whole interview.
Use them to check the candidate’s current technical level, then use practical scenarios to understand how they think. For quality-focused roles, include questions around testing strategy and automation testing services, not only coding syntax.
Check the candidate’s potential
Actual level matters, but potential matters even more. If actual level has a weight of 1, potential may have a weight of 10.
Why? Because software development changes quickly. A developer who only knows today’s tool may stop growing. A developer with strong fundamentals, curiosity, and problem-solving ability can keep improving for years.
Better education can help, but it is not everything
A good software developer does not always come from a famous university. Many excellent engineers are self-taught or come from ordinary schools.
Still, a strong education can provide a better foundation. It may not create a visible advantage today, but in the long run, a solid foundation can help a developer learn faster and go further.
Stronger background knowledge means stronger potential
Education is only one signal. Background knowledge is more important. We value candidates who understand fundamentals deeply.
Data structures and algorithms
For fundamentals, data structures and algorithms are still important.
Many application developers focus only on high-level application development: Java Spring, .NET Framework, Node.js, Python, PHP, React, Vue, and so on. That is understandable because those are the tools used every day.
However, developers who understand data structures and algorithms usually have a stronger base for problem-solving, performance thinking, and system design.
Programming techniques
Basic programming techniques are also important. At HDWEBSOFT, we expect developers to understand clean code practices and SOLID principles, not only to repeat their definitions.
OOP, design patterns, and UML
Most developers say they use object-oriented programming. But it is still difficult to find developers with truly solid OOP thinking.
Many people can explain abstraction, inheritance, and polymorphism. Fewer people can point to a line of their own code and explain which principle it expresses.
I am also impressed when a developer has mastered several design patterns and knows when not to use them. Design patterns are not just recipes. They are a shared language for understanding structure, intent, and other people’s code.
Conclusion: the best way to interview software developers
So, what is the best way to interview software developers?
There is no single magic question. A good interview combines different types of questions. Use technical questions to check actual skill. Use fundamental questions to check background. Use practical scenarios to check communication, problem-solving, adaptability, and potential.
At HDWEBSOFT, this approach helps us hire engineers who can contribute now and grow with future challenges. It also makes the interview more human: less like a test, more like a real working conversation.
