You can judge a software engineer well without reading code. You need a technical person to check the code for you, and a set of questions that show how the candidate thinks, explains and takes responsibility. The second part is yours to run.
Borrow technical judgment for the code
Someone qualified must look at the candidate's actual work. If you have no senior engineer on the team, ask an advisor, an investor's technical contact or a trusted freelancer to run one paid session. Give them a small, real task from your product to set, because a puzzle shows little about daily work. Ask for a written opinion with reasons, so you can compare candidates later.
Questions a non-engineer can ask
- Explain it to me. Ask them to describe the last thing they built in words a customer would understand. Engineers who understand their work well can explain it simply.
- Your own part. CVs often describe the whole project, especially in IT services. Ask what they wrote themselves, what they reviewed and what they only watched.
- Something that broke. Ask what went wrong after a release, how they found the cause and what they changed afterwards. Good engineers remember these in detail.
- Questions before starting. Describe a feature you want in two sentences and ask what they would need to know first. A careful engineer asks who will use it, how many users there are and what should happen when it fails.
- A disagreement. Ask about a decision by a manager or client that they thought was wrong, and what they did about it.
What to listen for
Listen for specifics. A candidate who did the work names tools, sizes, dates and trade-offs without being pushed. A candidate who was only near the work speaks in general terms and says "we" in every answer. Notice also whether they ask you about the product and its users. Curiosity about the business is a good sign in a small team, where an engineer often decides alone how something should behave.
Two common mistakes
The first is hiring on confidence. Fluent English and a known employer on the CV are easy to like and say little about skill. The second is letting the technical reviewer decide alone. The reviewer can tell you whether the code is good, but you still have to decide whether this person will work well with your team, your pace and your customers.
Before the next interview, pick three of the questions above and write down what a strong answer would contain. Then score each candidate against those notes on the day you meet them.