Software engineer
What did the candidate own while they were with you, and how did it turn out?
A specific piece of work, their personal contribution and an outcome the referee observed directly.
Run a fair, structured reference call. Choose a role, ask job-related questions and record what the referee actually said, in notes you can copy and download.
Choose the role and the referee's relationship to the candidate, then adapt the questions to the vacancy.
Reference questions for software engineers: what they owned, the quality of their work, how they collaborated and how they responded to feedback. Adapt the set to the vacancy before you call.
Managers can speak to scope, autonomy and growth. Ask for first-hand examples with dates; be careful with overall judgements of character.
6 core questions · 2 alternatives · 4 evidence themes
Work through the sections in order: verify the basics, ask the questions, then summarise the themes.
Explain who you are, which role and company the candidate applied to, and what you will do with the notes. Record only job-related information.
Tell the referee who you are, the role applied for and how the notes will be used. Ask only job-related questions and follow the rules that apply where you operate.
Confirm the facts first: the referee's relationship to the candidate, the role and the dates. Ask about the work itself afterwards.
Which dates did the candidate work there, and does that match the CV?
What was their title, and which team or function were they part of?
What were they responsible for in practice?
How did you work together, how closely, and during which period?
Ask the same core questions for every candidate for this vacancy. Use alternatives to replace a less relevant question, and keep notes factual.
1.What did the candidate own while they were with you, and how did it turn out?
Listen for: A specific piece of work, their personal contribution and an outcome the referee observed directly.
Follow-up questions
Point to explore: Match the answer to the CV's dates and scope; first-hand detail suggests direct observation.
Theme: Delivery and ownership
2.Where was the quality of their work strongest, and where did it need review?
Listen for: Concrete strengths and at least one honest limitation, with examples.
Follow-up questions
Point to explore: A referee who cannot name a limitation may be giving a courtesy answer; ask for a specific example.
Theme: Work quality
3.How did they work with the people around them — teammates, other teams, stakeholders?
Listen for: Behaviours in reviews, planning or incidents, not general praise.
Follow-up questions
Point to explore: Ask how close the referee was to that collaboration; second-hand praise carries less weight.
Theme: Collaboration
4.How did they respond to feedback or direction?
Listen for: An example where they changed approach after feedback, and how they pushed back when they disagreed.
Follow-up questions
Point to explore: Ask for the most recent example; dated examples are easier to verify.
Theme: Response to feedback
5.How much supervision did they need, and how did that change over time?
Listen for: Growth towards autonomy that the referee observed during their own period working with them.
Follow-up questions
Point to explore: Growth claims should stay within the period the referee actually saw.
Theme: Delivery and ownership
6.Would you choose to work with them again — why or why not?
Listen for: A direct answer with reasoning, and how recent their collaboration was.
Follow-up questions
Point to explore: Hesitation is a fact to record, not a verdict; note the words used.
Theme: Collaboration
7.Which technical strengths did they show beyond the day-to-day basics?Alternative question
Listen for: Depth in specific tools or domains, with examples of hard problems.
Follow-up questions
Point to explore: Match claimed depth against the vacancy's actual requirements.
Theme: Work quality
8.How did they communicate status, risks and delays?Alternative question
Listen for: Examples of early, clear communication rather than late surprises.
Follow-up questions
Point to explore: Incidents and delays show communication better than routine updates.
Theme: Collaboration
Pull together what the referee said for each theme, in their words where possible. A declined question is a fact to record, not a rating.
What the candidate actually owned and delivered, and how independently they worked.
Questions 1, 5.
The standard of their code and technical decisions, including where work needed review.
Questions 2, 7.
How they worked with teammates, other teams and stakeholders.
Questions 3, 6, 8.
How they received direction and what changed as a result.
Questions 4.
Export the complete call notes with verification items and questions, or the summary alone with themes and your recommendation. Both include blank candidate, referee and date fields.
Notes are kept only while this page is open. Copy or download them before leaving or reloading. Changing role or relationship keeps a separate draft.
Help candidates prepare, too. A role.so candidate pack brings the role, company and hiring process together before the interview stage.
Explore a candidate packGood reference questions ask the referee for facts about the actual work. These examples show how the focus changes by role. Open the tool above for the full question set, follow-ups and points to explore.
What did the candidate own while they were with you, and how did it turn out?
A specific piece of work, their personal contribution and an outcome the referee observed directly.
How did they decide what the team worked on next?
Trade-offs with an explicit rationale, not personal preference.
What roles did they recruit for, and what happened with those hires?
Volumes, role types and what became of the hires, as far as the referee knows.
Where did their opportunities actually come from?
Self-sourced versus inbound or marketing-generated, with habits you can picture.
What were their main responsibilities, and which did they own outright?
Their real scope, not the job title — what they decided versus what they executed.
A reference check collects facts about past work from someone who observed it. Its value depends on asking job-related questions and recording answers accurately.
Illustrative note for an experienced software engineer.
A reference check is a conversation with someone who observed a candidate's work — usually a former manager or colleague. Its purpose is to verify facts about past work and collect evidence that helps you decide what to explore next. It is one input among several, not a verdict on its own.
Start with the facts: how the referee knows the candidate, their role, team and dates. Then ask job-related questions about the work itself — what the candidate owned, how the work turned out, how they collaborated and how they responded to feedback. Record answers as facts, with dates and examples, rather than overall impressions.
A former manager can speak to scope, autonomy and growth; a peer sees day-to-day collaboration; a direct report can describe leadership. One manager and one colleague is a common starting point. Agree with the candidate who to contact, and confirm how closely each referee actually worked with them.
Keep every question about the work. Questions about health, family, beliefs or personal circumstances are off-topic in most contexts, and the rules that apply vary by location. Ask only what you would need to know for this vacancy, and check the rules where you operate before calling.
It is specific and checkable: a piece of work, the candidate's part in it, a date and an outcome — including honest limitations. For example: “She owned the reporting API migration. It shipped in April, two sprints late; she flagged the delay early and reprioritised with the team lead.” Vague praise without examples tells you little.
Yes. Copy notes and Download notes include the verification items, the questions with your notes, the summary themes and your recommendation. The download is an editable text file you can paste into your own document. It is not an Excel or PDF download.
Agree with the candidate who to contact and what may be shared before you call. Practice and legal requirements differ by location, so check the rules that apply where you hire. Telling referees who you are and how the notes will be used is good practice everywhere.
These role.so reference templates follow fair-hiring practice: questions about the work, consistent core sets and answers recorded in the referee's own words. They are starting points to adapt to a vacancy, not validated assessments. Check the rules that apply in your location before contacting referees.