One Job Title, Five Different Roles: Why Technical Hiring Starts With Role Definition

"We need a Security Engineer."

It sounds like a clear hiring requirement.

It often isn't.

Depending on the company, that one title could describe an Application Security Engineer, a Cloud Security Engineer, a Detection and Response Engineer, a technically strong GRC professional, or the person expected to own the entire security function because there is no team yet.

The same problem is showing up across technology hiring.

"We need an AI Engineer" could mean someone who builds and evaluates RAG systems, someone who works on model fine-tuning, an engineer who builds agentic workflows, or a software engineer integrating AI APIs into an existing product.

These are not interchangeable roles.

They need different technical depth, different experience, different interview questions and often completely different career backgrounds.

Yet companies frequently begin the hiring process with the same broad job title.

That creates a problem long before the first resume arrives.

The Technical Hiring Problem Often Starts Before the Search

When a technical role is poorly defined, the hiring funnel can look healthy on paper.

Applications come in. Recruiters find candidates. Search results are full. The hiring manager has plenty of resumes to review.

But the quality of the funnel is misleading.

Many of the candidates may be good at what they do. They simply may not be good at the specific problem the company needs solved.

That distinction matters.

The problem is not necessarily a shortage of talent.

It can be a shortage of role clarity.

This matters even more in technical hiring because technology roles are becoming increasingly specialized.

Security is no longer one discipline. AI engineering is not one discipline either. Cloud engineering, data, software engineering and platform roles have all developed into increasingly distinct areas of expertise.

The title alone often doesn't tell you enough.

Why "Security Engineer" Can Mean Five Different Jobs

Consider a company that opens a position called Security Engineer.

What exactly will this person own?

1. Application Security

The person may work closely with software engineering teams to find and fix vulnerabilities in applications and development workflows. The role could involve:

• Application security
• Secure software development
• Code analysis
• Threat modeling
• Vulnerability management
• Security testing
• Developer security enablement

This is a very different role from someone responsible for monitoring security events.

2. Cloud Security

Another company may use "Security Engineer" for someone responsible for securing cloud infrastructure. That could involve:

• Cloud security architecture
• Identity and access management
• Infrastructure security
• Cloud configuration
• Security controls
• Container or workload security
• Cloud monitoring

The candidate profile changes considerably.

3. Detection & Response

A third organization may actually be looking for someone who builds and improves its detection and response capability. That could mean:

• Security monitoring
• Detection engineering
• Incident response
• Threat detection
• Security operations
• SIEM environments
• Automation

Security hiring data reflects how loose the titles have become. CyberSN's 2026 cybersecurity jobs report, which tracks US security job postings, counts demand by the work a posting asks for rather than the title on the listing, because, in its own words, job titles are noisy.

The title is evolving. That makes the underlying job definition even more important.

4. GRC With a Technical Edge

A fourth company could be looking for someone working across governance, risk and compliance, but with enough technical understanding to engage deeply with engineering and security teams. That could involve:

• Security governance
• Risk assessment
• Compliance
• Controls
• Audit readiness
• Security frameworks
• Technical risk

Again, "Security Engineer" doesn't communicate enough.

5. "Own Everything"

And sometimes the requirement is simply: "We need someone to own security."

There is no security team yet. There is no established security function. There may not even be a clear boundary between security engineering, governance, incident response and architecture.

That is not a Security Engineer role in the same sense as the four examples above. It is closer to building a security function.

The hiring strategy should be completely different.

The Same Problem Exists With "AI Engineer"

AI is making this problem even more visible.

"AI Engineer" has become a broad label for several different types of work. Depending on the company, the role might focus on:

• RAG and retrieval
• LLM evaluation and application reliability
• Agentic workflows and tool use
• Model fine-tuning
• Integrating AI capabilities into an existing software product

Read a handful of current AI engineering job postings and the variation is obvious. Some describe engineers working on agentic pipelines, retrieval infrastructure, vector databases, evaluation and production systems. Others focus on building retrieval and LLM systems directly into products.

These candidates may all have "AI Engineer" somewhere in their experience.

But their actual capabilities can be very different.

That is why a search based mainly on the job title can produce an impressive-looking but poorly matched candidate pool.

A Good Candidate Can Still Be the Wrong Candidate

This is one of the most important distinctions in technical recruitment. A candidate can be:

• highly experienced
• technically strong
• well qualified
• working at a respected company
• excellent in interviews

and still be wrong for the role.

Why?

Because hiring is not about finding the best candidate in the abstract. It is about finding the person whose capabilities match the problem the organization needs solved.

A Cloud Security Engineer may be an excellent security professional. That does not make them the right person to build an AppSec program.

An ML Engineer may have deep experience training models. That does not automatically make them the right person to build a production RAG application.

A GRC professional may understand security frameworks exceptionally well. That does not mean they should be expected to build detection pipelines.

That distinction becomes particularly important when technical job titles are broad.

The Three Questions to Ask Before Opening a Technical Role

Before searching for candidates, the hiring manager and talent team should answer three questions.

1. What Problem Will This Person Own?

Not: what are their responsibilities?

Instead: what problem are we hiring this person to solve?

This pulls the conversation away from generic job-description language.

For example, instead of "Responsible for cloud security and security best practices," ask: "What cloud security problem is currently creating risk for the organization?"

Perhaps the answer is: "We are moving 70% of our infrastructure to the cloud and need someone to establish the security architecture, controls and monitoring model."

Now the role becomes much clearer.

2. What Does Success Look Like in the First 90 Days?

A job description can contain twenty responsibilities and still fail to explain what success means. The first 90 days are often a better test.

Ask: if we hire the right person today, what should be different 90 days from now?

For a Cloud Security role, that might mean:

• establishing an initial cloud security baseline
• identifying critical gaps
• prioritizing remediation
• implementing key controls
• creating visibility across the cloud environment

For an AI Engineer, it might mean:

• taking an existing prototype into production
• improving retrieval quality
• establishing evaluation criteria
• reducing latency
• improving reliability
• integrating the system with an existing product

Now the recruiter knows what to look for.

More importantly, the candidate knows what they are actually being hired to accomplish.

Skills-based hiring guidance increasingly recommends tying required capabilities to observable outcomes rather than relying mainly on titles, credentials or years of experience. AIHR's practical guide to skills-based hiring, for example, advises rewriting job descriptions around skills and measurable outcomes.

3. What Can We Teach, and What Has to Walk In on Day One?

Not every skill needs to be a hiring filter.

This is where many technical job descriptions become unnecessarily restrictive. A hiring manager may list:

• 10 tools
• 5 certifications
• 3 programming languages
• 8 platforms
• 7 years of experience

and call all of them "must-have".

But are they really?

The better questions are: which capabilities are essential on day one, and which skills can a strong candidate reasonably learn?

For example, if the actual requirement is deep cloud security architecture, familiarity with one specific cloud security tool may be learnable. If the requirement is building detection systems at scale, hands-on detection engineering experience may not be.

Separating essential capability from learnable knowledge makes the hiring brief sharper and often expands the relevant talent pool without lowering the bar. LinkedIn's research on skills-based hiring found that a skills-based approach could widen talent pools by 6.1x globally.

From Job Description to Hiring Brief

A conventional technical job description often starts with the title and works down. A better hiring brief starts with the problem.

That is a meaningful shift. It also improves the screening process.

The question becomes more precise. So does the search.

Why Clearer Roles Usually Produce Better Candidate Pools

The objective of a hiring process is not to generate the maximum number of applications. It is to generate enough relevant candidates to make a confident decision.

When a role is vague, recruiters compensate by searching more broadly. That can increase volume while reducing relevance.

A clearer brief does the opposite. It narrows the search around the capabilities that actually matter.

This is one reason skills-based hiring is increasingly focused on observable capabilities, structured evaluation and outcome-based job descriptions.

The result is not necessarily more candidates. It can be fewer candidates who make more sense.

And that is usually a better hiring funnel.

Where AI Helps in Technical Recruitment

Once the role is clearly defined, AI becomes extremely useful. AI can help recruitment teams:

• map role requirements
• identify related skills
• expand title variations
• structure screening criteria
• surface potentially relevant profiles
• identify gaps in a hiring brief
• generate role-specific interview questions
• compare candidate evidence against defined requirements

This can significantly reduce the mechanical work involved in searching and screening.

But there is an important boundary.

If the hiring manager says "Find me a Security Engineer," AI can find thousands of people associated with security engineering.

It cannot know whether the organization actually needs AppSec, Cloud Security, Detection & Response, GRC or a first security hire unless someone provides that context.

That context comes from the business.

The Human Conversation That Saves the Most Time

The most valuable part of technical recruitment may happen before a single candidate is searched. It is the conversation between the hiring manager and the talent team.

Ask:

• What problem are we solving?
• What does success look like?
• What must this person already know?
• What can we teach?
• What decisions will they own?
• What will they actually be doing every week?
• Who will they work with?
• What happens if we hire the wrong profile?

These questions turn a job title into a hiring strategy.

And that is where technology can then do its best work.

Technical Hiring Is Moving From Titles to Capability

Job titles will always matter. They help candidates search. They help companies organize teams. They create a common language.

But titles are becoming less reliable as a complete description of technical capability. That is particularly true in fast-moving areas such as AI, cybersecurity, cloud and data. The same title can represent very different work across different companies.

The future of technical hiring therefore needs a second layer beneath the title:

That is the question that makes sourcing better. It makes screening better. It makes interviewing better. And ultimately, it makes hiring decisions better.

A Simple Framework for Hiring Technical Talent

Before opening your next technical role, define these five things.

01. The Problem

What business or technical problem will this person own?

02. The Scope

What will they actually be responsible for?

03. The Outcomes

What should they accomplish in the first 90 days?

04. The Capabilities

What must they already know or be able to do?

05. The Evidence

What experience, work or behavior would prove those capabilities?

Only then should the search begin.

Because the quality of a technical search is heavily influenced by the quality of the requirement behind it.

Final Thought

A vague job description does not just create a sourcing problem. It creates a signal problem.

When the requirement is unclear, the market sends back every reasonable interpretation of the title. That means more profiles. More screening. More interviews. More disagreement.

And often, more time spent discovering what the company actually needed in the first place.

The answer is not always a better search algorithm. Sometimes it is a better question at the beginning.

Once that is clear, the title becomes easier to define. The search becomes narrower. The candidates become more relevant. And the hiring decision becomes much easier to defend.