Tech Roles Decoded: A Recruiter's Plain-English Guide

Most recruiters screening for tech roles have felt the same quiet dread: a candidate mentions something like "distributed tracing" or "event-driven architecture" and you nod along, hoping your follow-up question doesn't expose the gap. The discomfort is real, and it's worth naming. But the fix isn't learning to code. It's learning to ask better questions - and knowing what you're actually trying to find out when you ask them.

This guide is for talent acquisition professionals who work with technical roles and want to move beyond surface-level screening. It won't turn you into a software engineer. It will help you explain tech roles clearly to hiring managers, ask questions that surface genuine competence, and stop letting jargon slow down good hiring decisions.

Understanding the Tech Role Landscape

Before you can explain tech roles for talent acquisition purposes, it helps to group them by what they actually touch rather than by the titles on job boards.

There are broadly three territories. First, there's backend and infrastructure - the work that runs unseen. Databases, servers, APIs, the systems that make applications function even when no one's looking at them. Second, there's frontend and user-facing work - the interfaces people click, scroll, and type into. If a user can see it or touch it, someone in this territory probably built it. Third, there's data and analytics - the work that captures what's happening, cleans it up, and turns it into something a business can act on. These three territories overlap in practice, and some roles sit across two of them, but they're a useful mental map.

The bigger problem isn't the categories - it's that job titles lie. "Senior Engineer" at a 12-person startup means something different from "Senior Engineer" at a company with 3,000 engineers and eight layers of management. Consider two candidates: both have five years of experience and the same title on their CV. One spent those years as the only technical person at a small product company, making every architectural decision alone. The other worked on a single feature within a large team where every significant decision went through committee. Neither is better. But they're not interchangeable, and "Senior Engineer" tells you nothing about which problem they'd actually solve for you.

Rather than memorising a list of fifteen job titles, try grouping by function. Roles that write code. Roles that design systems. Roles that move and shape data. Roles that keep systems running. These groupings hold across companies in a way that titles often don't.

Why Tech Roles Feel So Opaque to Recruiters

Technical professionals use domain language because they live in it every day. It's not gatekeeping - it's the same reason a GP talks about "contraindications" rather than "things that make the medication dangerous." The vocabulary is precise and efficient inside the domain. It just doesn't translate without effort.

Picture this: you ask a candidate about their experience with APIs. They say, "Oh yes, I've built and consumed several REST APIs, mostly working with JSON payloads, and I've done some GraphQL work too." You've got a sentence that contains four terms you'd need to look up and no clear picture of whether this person is good at their job. That gap - between what they said and what it means for the role - is where most recruiter screening goes wrong. Not because you asked the wrong person. Because you asked the wrong kind of question.

The speed of change in tech makes this harder. Roles that existed five years ago may have split, merged, or disappeared. "DevOps Engineer" is a good example - it emerged as a bridge between software development and infrastructure operations, but what it means varies enormously by company. At some organisations it's become "Platform Engineer" or "Site Reliability Engineer," with meaningfully different scopes. When you see a title you haven't encountered before, assume it needs investigation rather than assumption.

Specialisation also creates islands. A frontend engineer and a backend engineer on the same team may genuinely struggle to explain each other's work to you - not because either is poor at communication, but because their daily tools and concerns have almost no overlap. When you're screening across a team's worth of roles, you're essentially crossing between different professional languages each time.

Ask About the Output, Not the Tool

The most practical shift a recruiter can make is to stop asking about tools and start asking about outcomes. "How many years of Python?" tells you almost nothing useful. "Tell me about the last thing you built that users actually used - what did it do, and how do you know it worked?" tells you whether this person connects their work to real outcomes, whether they think about users, and whether they can explain their own work clearly.

Walk through a real screening moment. A backend engineer mentions they spent time "optimising queries." Most recruiters let that pass. Instead, follow it: what was slow, and how slow? How did you measure the problem before you started? What did you try first? How did you know it was fixed? These questions don't require you to know anything about database optimisation. They reveal whether the candidate has a systematic approach to problems or whether they're describing work they were adjacent to.

A few output-focused questions worth keeping in your toolkit, by role type:

• Frontend: "Describe a time a user couldn't do something they needed to do. How did you find out about it, and what did you change?"

• Backend: "Tell me about a system you built that had to handle more load than you expected. What broke, and what did you do?"

• Data: "Walk me through a piece of analysis that changed a decision someone actually made. What was the decision, and what did you find?"

• Infrastructure: "Describe a time something went down when it shouldn't have. What was your role in fixing it, and what did you change afterwards?"

None of these questions require you to understand the technical answer in detail. They require the candidate to tell a coherent story about their own work - which is exactly the skill you need to assess.

Map the Role to Your Company's Real Problem

Most hiring for technical roles starts in the wrong place. A hiring manager hands you a job description that lists eight technologies and three years of experience in each. You post the role, screen for the keywords, and wonder why the candidates who make it through still feel like a mismatch.

Try reversing the process. Before you open the job spec, ask: what is broken? What can't the team do right now that they need to be able to do? Who will fix it, and what does fixing it look like in six months? The answers to those questions are your actual filter.

There's a meaningful difference between "we need a Senior Engineer" and "we need someone who has spent at least two years on reliability problems in a high-traffic system, because our platform is falling over under load and we don't have anyone who's solved that kind of problem before." The first is a label. The second is a filter. It also makes your screening questions obvious - you know exactly what experiences to probe for.

A template worth using when you sit down with a hiring manager before a search: "Our problem is [specific thing that's broken or missing]. We need someone who has [specific experience that solves it]. We'll know they're right when [observable signal in the interview process]." If a hiring manager can't fill in the first blank, the role isn't ready to be opened yet.

Build a Personal Glossary as You Go

Every recruiter who works in tech consistently should be keeping a running document of terms they encounter - not an exhaustive technical dictionary, but a personal reference built from real conversations. Each entry: the term, a plain-English explanation of what it means, and a note about which role types tend to use it.

Something like: "Microservices - a way of building software where different parts of the application run separately and talk to each other, rather than everything running as one big system. Mentioned by: backend engineers, platform engineers, architects. Why it matters: teams using microservices often need people who can work across multiple codebases and understand how services depend on each other."

You can build this glossary without ever sounding uninformed in a conversation. When a candidate uses a term you've encountered but want to confirm you're understanding correctly, you can say: "I want to make sure I've got this right - when you say you work with microservices, you mean [your plain-English version]?" Most candidates find this flattering, not condescending. It shows you're paying attention.

There's one more move worth making with hiring managers: ask them to annotate their job specs. Not just "what skills do we need" but "why does this skill matter, and what problem does it solve for us." A requirement that says "experience with Kubernetes" means little. A requirement that says "experience with Kubernetes because we're moving from a single-server setup to containerised infrastructure and whoever joins will be part of that migration" is a narrative. Narratives are easier to screen for.

When to Bring in a Technical Screener

There's a limit to what recruiter screening can honestly assess in technical roles, and it's worth naming that limit clearly rather than papering over it. You can evaluate communication. You can assess whether someone's experience plausibly matches the problem you're solving. You can probe for coherent thinking and self-awareness. You cannot reliably assess whether someone's code is good, whether their architectural decisions hold up under scrutiny, or whether their claimed depth in a technology is real.

Some situations call for escalating earlier than usual. If the role is highly specialised and you're finding it hard to distinguish between strong and weak candidates based on experience alone, bring in a technical screener before you're deep into a process. If a hiring manager has been vague about what they actually need - and your problem-mapping conversation hasn't produced clarity - a short conversation between a senior engineer and a candidate can surface misalignment faster than another round of recruiter screening.

The lightest version of this: a 20-minute conversation between the candidate and a senior engineer on the team, framed simply as "walk me through something you built" and "what would you do differently now." It doesn't need to be a formal technical interview. It just needs to be a knowledgeable person listening to how the candidate talks about their own work. That's usually enough to confirm or question what your screening found.

When to Seek Support

If you're working in an organisation that hires technical roles consistently and you don't have a technical screener available, that's a structural gap worth raising - not as a complaint, but as a hiring risk. Misaligned technical hires are expensive and slow to surface. A small investment in a lightweight technical review step, even informally through an existing engineer, tends to pay for itself quickly.

You don't need to become technical to hire technical people well. You need good questions, honest conversations with hiring managers, and the judgment to know when to bring someone else into the room. Those are things you can build over time - one role, one glossary entry, one follow-up question at a time.