Adapt the template to the product, architecture, level, team boundaries, operational responsibility, and technologies actually needed.
Candidate-facing template
Replace bracketed details, remove anything that is not genuinely required, and obtain the appropriate internal approval before advertising.
Ready-to-edit job description
Copying excludes all recruiter notes below.
[Company name] is looking for a Software Engineer to build and improve [product, platform, or service]. You will work with product, design, engineering, and operational colleagues to understand problems, make appropriate technical decisions, deliver tested software, and support it responsibly in production.
Compensation and benefits: [Add the approved range and currency, equity or bonus if relevant, on-call arrangements, equipment, leave, development support, and location-dependent benefits.]
[Company name] aims to make recruitment and employment accessible and will discuss reasonable adjustments for interviews, assessments, equipment, and working arrangements in line with applicable requirements.
Apply through [application method]. Share [CV, résumé, profile, portfolio, or work examples] that explains your individual contribution, decisions, and the software outcomes most relevant to this role.
Performance expectations
Use these outcomes to replace vague activity lists with the evidence the hiring manager expects to see after the person joins.
The engineer can connect technical work to a user, operational, or organisational outcome.
Changes include proportionate tests, observability, documentation, security, and recovery considerations.
Production issues are investigated from evidence and lead to durable improvements.
Technical collaboration makes the team more capable rather than concentrating knowledge in one person.
Hiring-manager intake
Record specific answers so sourcing, screening, and interview decisions use the same definition of the role.
What product, users, architecture, and system boundaries will this engineer work within?
What level of technical and product decision authority should the person demonstrate?
Which technologies are essential on day one and which have acceptable transferable alternatives?
What are the expectations for testing, release, on-call, incidents, security, accessibility, and documentation?
How will the assessment test relevant evidence without becoming unpaid project work or trivia?
What would the person own and successfully improve during their first six months?
Evaluation criteria
Agree the criteria before interviews begin, then score examples against the same evidence standard.
Structured interview
Ask the same core questions in the same order, then use follow-ups to understand the candidate’s individual contribution.
Strong answer signal
Explains the original context, new evidence, cost of change, migration approach, communication, and learning without pretending the first choice was irrational.
Strong answer signal
Prioritises impact and safety, works from evidence, tests hypotheses, communicates clearly, and contributes to follow-up improvement.
Strong answer signal
Considers risk, behaviour, failure cost, change frequency, system boundaries, existing coverage, observability, and feedback speed.
Strong answer signal
Understands the other perspective, tests assumptions, values outcome over ownership, and shows how the decision improved.
Related titles
Common hiring mistakes
Listing the entire technology estate as mandatory without identifying the systems the engineer will actually change.
Using years of experience as a substitute for level, ownership, complexity, judgement, and impact.
Combining front-end, back-end, mobile, infrastructure, security, data, design, and support into one unrealistic individual role.
Running an assessment that rewards memorised puzzles rather than relevant problem-solving, delivery, and communication evidence.
Continue the hiring workflow
Source and review notes
O*NET: Software Developers
Reference for occupation tasks, knowledge, skills, abilities, and work activities.
ESCO: occupations and skills
Reference for internationally recognised occupation and skills terminology.
Qualifications, compensation, licences, working conditions, and equal-opportunity wording must be checked for the role and location before use.
Recruiter questions
Explain the users, product, system boundaries, level, decision scope, technologies, quality expectations, production responsibility, collaboration model, assessment, and outcomes expected.
Require only technology knowledge essential on day one. Treat comparable languages, frameworks, or platforms as transferable when the underlying engineering problems and learning expectations allow it.
Many organisations use the titles interchangeably. Where a distinction exists, Software Engineer may imply broader design, system, operational, and trade-off responsibility. Define the scope instead of relying on the title.
