You can assess those qualities through specific examples and a discussion of your project. Code quality, security and complex architecture may still require review by someone with appropriate technical expertise.
This guide explains what to ask, what to listen for and how to compare candidates without turning the conversation into a programming quiz.
Define the Work Before the Interview
A developer is easier to assess when the role is clear.
“Build our software” leaves too much open. A more useful description explains the application, responsibilities and support already available.
“We have an existing customer portal. We need someone to add a document-submission workflow, work with our backend developer and document the changes.”
Before the interview, write down:
Our guide to writing a developer brief can help prepare that information.
Start With Relevant Experience
Ask the developer to describe work similar to the responsibility you need covered.
A visually impressive website may tell you little about someone’s ability to maintain a complex backend. Equally, experience with a large platform does not establish which parts the person delivered.
“Tell Me About a Project That Relates to This Work”
Listen for a clear explanation of:
- What the application did.
- Who used it.
- Which technologies were involved.
- The developer’s responsibilities.
- Other people involved.
- A challenge they encountered.
Follow-up question:
“Which parts did you personally implement or maintain?”
A useful answer distinguishes individual contribution from the work of the wider team.
If the project is confidential, ask whether the developer can explain the approach without sharing protected details.
Explore One Example in Depth
One well-explained example can be more informative than a long list of projects.
“What Was Difficult, and How Did You Handle It?”
The difficulty could involve unclear requirements, an unreliable integration, performance or an inherited codebase.
Ask:
- How was the problem identified?
- What information did you collect?
- What options did you consider?
- Who made the decision?
- How was the result checked?
You are looking for a coherent explanation of the work.
A claim such as “I improved performance” needs context. Ask what was measured, what changed and which responsibilities belonged to the candidate.
Do not request confidential customer data or access to another client’s private systems.
Discuss Your Project Before Asking for a Price
A candidate’s questions can reveal how they approach unfamiliar work.
“What Would You Need to Know Before Estimating This?”
Relevant questions might concern:
The exact questions depend on the role. For example, someone working on an existing application may need to inspect its setup before estimating a feature reliably.
An immediate estimate is not necessarily wrong, but its assumptions should be explained. A request for investigation should also have a clear purpose.
For unfamiliar software, a scoped application technical assessment can establish what needs checking.
Ask How They Would Start
“What Would Your First Tasks Be?”
The answer should relate to your situation. For an existing application, initial work may involve reading documentation, setting up an authorised environment and understanding the affected workflow. For a new product, the developer may need to clarify users, requirements and dependencies first.
Follow-up question:
“What would we be able to review at the end of that initial stage?”
This helps turn a general approach into a proposed outcome.
Be cautious about accepting a broad rewrite recommendation before the existing application has been understood. Ask what evidence would justify that decision.
Our software project takeover page explains the questions involved in changing development teams.
Understand How Work Will Be Checked
“How Would You Test This Change?”
You do not need to name testing tools to ask about verification.
Ask the candidate to describe:
- The main user journey.
- Important failure conditions.
- Permission checks.
- Existing features that could be affected.
- Who would review the result.
- How the change would reach production.
For a document-upload feature, useful scenarios could include an unsupported file, an interrupted upload or a user trying to access another customer’s document.
A simple statement that “QA will handle it” needs clarification. Someone must own that responsibility within the engagement.
Check How They Communicate Problems
“How Do You Report a Blocker?”
Ask for a previous example. Useful reporting explains:
- What is blocked.
- What has already been investigated.
- What information or decision is needed.
- The likely effect on delivery.
- Available next steps.
Then ask:
“If you discover that an estimate needs to change, when and how would you tell us?”
You want enough information to make a decision before additional work or cost accumulates.
Communication should fit the project. A developer does not need polished sales language to provide clear, useful updates.
Clarify What They Can Own Independently
“Which Parts Can You Handle, and Where Would You Need Support?”
A role may include frontend work, backend changes, testing and deployment, but those responsibilities need confirmation.
Ask about:
A developer who identifies the limits of their experience can help you plan the team more accurately.
For work spanning the interface, backend and database, explore our full-stack developer hiring options.
Review Availability and Working Arrangements
“How Would You Work With Our Team?”
Confirm practical details such as:
- Available hours.
- Working-hour overlap.
- Meeting expectations.
- Communication channels.
- Task-management tools.
- Expected response arrangements.
- Other commitments that affect availability.
These details should be reflected in the engagement rather than left as informal assumptions.
Our developer hiring process explains how selection connects to onboarding.
Use the Same Core Questions for Each Candidate
Consistent questions make comparisons easier. Take short notes based on evidence from the conversation.
| Area | Evidence to record |
|---|---|
| Relevant experience | Comparable responsibilities and examples |
| Personal contribution | What the candidate actually delivered |
| Requirements approach | Questions asked before estimating |
| Problem-solving | A specific investigation and decision process |
| Testing | How changes and failures would be checked |
| Communication | How progress and blockers are explained |
| Independence | Responsibilities they can own and support needed |
| Availability | Whether the proposed arrangement fits |
Record unanswered questions separately.
If you use a score, write the evidence beside it. A numerical total should not conceal a missing technical requirement.
When to Involve a Technical Reviewer
A business interview cannot establish every aspect of engineering capability.
Relevant technical review may be needed to assess:
Ask an appropriately experienced reviewer to assess the areas relevant to the role.
The review should produce understandable findings and identify its limits. A generic coding test may not reflect the work your project requires.
Consider a Small Paid Assignment
A defined assignment can help assess how the candidate handles real requirements.
Choose something representative and manageable, with appropriate access and clear acceptance criteria.
Examples include:
- Implementing an approved component.
- Adding a small endpoint with relevant checks.
- Investigating a reproducible issue.
- Writing tests for an existing workflow.
- Reviewing a limited section of an application.
Agree on the fee, time, deliverables and ownership before starting.
Avoid asking several candidates to complete substantial production work without payment.
Questions That Need a Follow-Up
Some answers are incomplete rather than automatically disqualifying.
| Initial answer | Useful follow-up |
|---|---|
| “I built the whole platform” | Which parts did you implement personally? |
| “It will be easy” | What assumptions are you making? |
| “The code needs replacing” | What evidence would establish that? |
| “Everything will be tested” | Which workflows and who will check them? |
| “I can start immediately” | What hours and responsibilities can you commit to? |
| “I know that technology” | Describe a relevant feature you delivered with it |
Give candidates an opportunity to explain. Judge the resulting evidence rather than the phrase alone.
A Practical Interview Agenda
For an initial conversation, you could use:
- 1Explain the role and application.
- 2Discuss one relevant project.
- 3Clarify the candidate’s personal contribution.
- 4Ask how they would investigate your requirement.
- 5Discuss testing and review.
- 6Confirm responsibilities and availability.
- 7Record what still needs technical assessment.
The interview should leave you with a clearer view of fit and the next step.
It does not need to produce a final estimate before the candidate has access to the information required.
Discuss Your Developer Requirements
DOT IT Services helps businesses find and interview developers with relevant experience.
Tell us about your application, the skills you need and how your team wants to work.
Written by DOT IT Services.