A Senior Software Engineer vacancy asks for Java, Python, Kubernetes, Terraform and AWS. The responsibilities include application development, architecture, performance optimisation, production support and collaboration across engineering teams.
Nothing particularly unusual. Every requirement might be legitimate, and the organisation may genuinely need someone comfortable working across all those areas.
What’s less obvious is the problem this person is being hired to solve.
Is the priority developing new functionality, modernising an ageing architecture, improving deployment reliability or taking ownership of production systems? A senior backend engineer and an experienced platform engineer could read the same description and reach very different conclusions about the role. Both interpretations might be reasonable.
This is a familiar problem in software engineering, although we don’t often discuss it in the context of recruitment.
A job description is effectively a set of requirements. It describes an organisational need, establishes expected capabilities and responsibilities, and provides a basis for evaluating whether someone can fulfil them. Yet a description can be detailed, technically accurate and still leave its most important requirement unclear: what the organisation actually needs the person to accomplish.
Plenty of requirements, not always enough clarity
Technical roles are difficult to describe precisely. Responsibilities overlap, teams operate differently, and job titles are rarely standardised across organisations. A Software Engineer in one company may spend most of their time building application functionality, while someone with the same title elsewhere concentrates on infrastructure, architecture or operational reliability.
There is nothing inherently wrong with multidisciplinary roles. Smaller teams often need people who can cover several areas, and larger organisations increasingly rely on collaboration across established functional boundaries.
The difficulty arises when a description lists everything someone could be responsible for without explaining which responsibilities matter most.
Consider a QA Manager vacancy where most responsibilities concern designing and maintaining automation frameworks, with little mention of quality leadership, test strategy or coordination. The organisation may genuinely need an automation-focused technical leader. But someone experienced in QA management could reasonably understand the title to imply a different distribution of responsibilities.
A Release Manager vacancy might similarly concentrate on CI/CD configuration, deployment scripting and infrastructure. Those activities can be part of release management, depending on how responsibilities are distributed. What remains unclear is whether the person is expected to engineer deployment pipelines, coordinate releases, manage readiness and risk, or own some combination of these.
Neither description necessarily contains an incorrect requirement. The ambiguity lies in what the requirements collectively describe.
This can happen quite naturally, even in established organisations. A previous job description is reused, new technologies are added, responsibilities evolve, and different stakeholders contribute expectations. Over time, the document may become a reasonably accurate inventory of activities without clearly representing the current hiring priority.
An established role title doesn’t necessarily mean the business need behind it has remained unchanged.
Sometimes the organisation is still working out exactly how a role should develop. That uncertainty is legitimate, particularly during restructuring or when establishing a new function. A description can acknowledge an evolving mandate while remaining clear about the immediate priorities. Presenting every potential responsibility as equally important provides considerably less useful information.
When the technology list becomes the requirement
One consequence of poorly prioritised role definitions is an excessive emphasis on particular tools and technologies.
Technical recruitment naturally involves technology-specific qualifications. Organisations have existing stacks, established workflows and practical constraints. Familiarity with their systems can be valuable.
However, especially for senior professionals, experience solving a problem is often more meaningful than experience using one particular product to solve it.
Take test management. Someone who has spent years developing test strategies, managing coverage and traceability, coordinating execution and reporting quality evidence through Jira, Zephyr and TestRail already understands the discipline.
If the hiring organisation uses Azure DevOps, that professional will need to learn its particular workflows and configuration. But their expertise in test management doesn’t disappear because the interface changes.
Making several years of Azure DevOps experience an absolute requirement could exclude someone whose broader expertise is highly relevant to the organisation’s needs.
A similar distinction exists in software engineering.
An experienced automation engineer with a Java and Selenium background may have substantial knowledge of automation architecture, maintainability, test reliability, CI/CD integration and execution performance. Moving to a TypeScript/Playwright environment requires learning new language and framework behaviour, including differences in asynchronous execution and tooling.
That learning has a cost. It is also a different challenge from learning how to design reliable automation in the first place.
For an experienced professional, the ability to recognise recurring engineering problems, evaluate tradeoffs and apply established principles across different technologies is part of what makes that experience valuable.
There are reasonable exceptions. Maintaining a specialised legacy system may demand substantial knowledge of an uncommon programming language. Engineering software used in power-grid control systems may require domain expertise involving operational safety, industry standards and failure modes that cannot be treated as ordinary application-development concerns.
Even then, relevant experience may extend beyond an exact technology or industry match.
The distinction is whether a requirement is essential to performing the work, or simply describes the environment in which that work currently happens.
In requirements engineering, we regularly challenge specifications that prescribe a solution before adequately establishing the underlying need. Technical hiring deserves similar scrutiny.
A company needing better deployment reliability may have good reasons to value Kubernetes expertise. But if the position primarily concerns diagnosing reliability problems, improving application behaviour and coordinating with an existing platform team, insisting on extensive Terraform experience may be unnecessarily restrictive.
The organisation’s actual priorities should determine which expertise is essential. The technology inventory shouldn’t determine the role by default.
The recruitment consequences are shared
A job description is often the first substantial information a candidate receives about a position. When priorities are unclear, applicants have to infer them from the title, the responsibilities and the listed qualifications.
Some relevant professionals may decide not to apply because they lack experience with a particular technology, even when they have extensive experience with the underlying problem. Others may apply believing the position emphasises work that turns out to be secondary.
Neither situation necessarily reflects poor judgement. Candidates can only evaluate the opportunity described to them.
For employers, that same ambiguity may affect which candidates enter the process and how their experience is evaluated. Recruiters and hiring managers may spend time screening against requirements that only partially capture what the team needs. Differences in expectations may emerge during interviews, sometimes after considerable effort on both sides.
There is research supporting the broader observation that how requirements are presented influences applicant behaviour.
In Words Matter: Experimental Evidence from Job Applications, Lisa Abraham, Johannes Hallermeier and Alison Stein examined alternative versions of more than 600 corporate job advertisements at Uber. Removing optional and excessive qualifications increased applications by approximately 7%.
The result is interesting, although it shouldn’t be interpreted as evidence that fewer requirements automatically attract better candidates. The composition of the applicant pool changed in more complicated ways. What the experiment establishes is that people respond to the qualifications employers choose to publish.
A 2025 field experiment by Larissa Fuchs and colleagues examined how emphasising career advancement or flexibility in advertisements affected applications to a technology company. Highlighting career opportunities attracted additional well-qualified applicants and led to more interview invitations for entry-level positions. Emphasising flexibility also increased applications, but with limited evidence of attracting better-matched candidates.
These findings concern different aspects of recruitment, and the latter study’s results should not be generalised to senior technical positions. Nevertheless, they demonstrate that the information employers emphasise influences who responds, and that attracting more candidates is not necessarily the same as attracting more suitable ones.
Clearer descriptions might produce fewer applications if candidates can identify an unsuitable position earlier. They might also attract experienced professionals who would otherwise exclude themselves because of unnecessary technical requirements.
The more useful objective is informed self-selection: candidates recognising where their expertise is relevant, and employers receiving applications based on a realistic understanding of the work.
That alignment also matters after recruitment. Jean Phillips’ 1998 meta-analysis of 40 studies on realistic job previews found associations with outcomes including higher job performance and lower employee turnover. A realistic job preview is broader than a written vacancy, so the findings cannot be attributed to job descriptions alone. They do, however, support the importance of communicating expectations accurately.
There is also a difference between improving the written requirements and changing how candidates are assessed.
A 2024 study by the Burning Glass Institute and Harvard Business School found that approximately 45% of the organisations studied that removed degree requirements from job postings showed no meaningful subsequent change in actual hiring behaviour.
The study concerned academic qualifications, not technical tools. Still, the implication is relevant: removing a requirement from a description accomplishes little if the selection process continues to enforce it.
A vacancy might welcome transferable engineering expertise, yet the initial screening still rejects candidates who lack three years of experience with a specific framework. In that case, the published description and the actual evaluation criteria are communicating different expectations.
Applying a little requirements thinking
Return to the Senior Software Engineer vacancy from the beginning.
The organisation could add several more paragraphs detailing technologies, responsibilities and desirable experience. Or it could clarify its immediate need.
For example:
Our immediate priority is improving the reliability of several Java-based services. This engineer will lead application-level improvements, investigate recurring production issues and work with our platform team on deployment-related changes. The platform team retains ownership of shared Kubernetes infrastructure and Terraform configuration. We’re primarily looking for experience diagnosing production problems and improving software reliability across complex systems.
This doesn’t remove the technical requirements or make the role less demanding. It clarifies which expertise matters most, how responsibilities are distributed and what the person is expected to contribute.
If the organisation actually needs someone to design and maintain the underlying infrastructure, the description should say that instead.
Neither version is inherently preferable. What matters is whether it accurately describes the position being filled.
Requirements thinking also helps distinguish activities from accountability. Someone may participate in deployment activities without owning the deployment platform. A technical lead may contribute to architectural decisions without having final authority over them. A release manager may consolidate readiness evidence and coordinate decisions while risk acceptance remains with accountable business or technical owners.
Those boundaries matter when candidates evaluate the role, and when the organisation later evaluates their performance.
Success expectations deserve similar attention. A long list of responsibilities may say little about what meaningful progress would look like after three or six months. The organisation doesn’t need to predict every deliverable, but identifying the most important problems the new employee should help address provides useful context for both hiring and onboarding.
Finally, requirements benefit from validation.
A brief review involving the hiring manager, relevant technical stakeholders and the recruiter may reveal that different participants understand the same requirement differently. It may also expose essential capabilities that were left implicit, or qualifications that have remained on the list simply because they appeared in an earlier version.
This needn’t become an elaborate approval process. The purpose is to establish a shared understanding before asking candidates to interpret the description themselves.
Technical organisations already use requirements reviews to identify ambiguity, conflicting expectations, unnecessary constraints and missing ownership. A job description may be a different kind of artefact, but it is subject to many of the same problems.
Applying some of that discipline before publishing a vacancy seems a reasonable extension of a practice we already consider important in engineering.