Topic 3 — Understanding tech roles

Goal: Know enough about tech roles to hire for them credibly.

Lesson 3.1 — The fear of being found out

Yara's first week at Northwind Robotics, she's on a video call with Marcus Beaufort, the VP of Engineering, and he's rattling off the role he needs filled: "Senior backend, ideally someone who's run things in production, Go would be nice but Python's fine, and they have to be comfortable owning a service end to end." He pauses. "Make sense?"

It does not make sense. Yara nods anyway and writes down every word so she can decode it later.

She came from tech sales — three years as an SDR hitting quota on cold calls for software deals. She's good with people and good at targets. What she doesn't have is a single line of code in her past, and she has the specific, quiet fear that runs under a lot of new tech recruiters: the engineers are going to figure out I have no idea what they do.

Here's the reassuring part, and it's the foundation of this whole topic. A technical recruiter needs a recruiter's-level grasp of tech, not an engineer's. You will never write production code, and nobody expects you to. What you need is the landscape and the vocabulary — enough to read a job description accurately, hold a credible conversation, spot a reasonable match, and talk shop with a hiring manager like Marcus without bluffing.

Engineers don't expect you to code. They expect you to know what they do. The first builds nothing; the second builds trust.

That distinction is everything. The recruiter who says "tell me about your backend experience" and follows the answer keeps an engineer's respect. The one who asks a strong backend candidate whether they "do any Photoshop" loses it in one sentence, and word travels. You're learning a map, not a trade.

Lesson 3.2 — The engineering roles you'll actually hire for

Marcus's 35 open headcount this year are mostly engineers, so this is where Yara spends most of her map-learning. Imani Okafor, the senior recruiter mentoring her, draws it out on a whiteboard as a handful of specialties — the same word an engineer can't do without code, and a recruiter can't do without.

• Frontend — builds the part users see and click: the screens, buttons, layouts. Common stack: HTML and CSS (the structure and styling of every page), plus JavaScript, TypeScript, and a framework like React.
• Backend — builds what users don't see: the servers, the APIs, the databases, the business logic that makes the buttons actually do something. Common languages: Python, Java, Go, Node.js.
• Full-stack — does both front and back, common at smaller companies like Northwind where people wear more hats.

Here's the trap Imani makes Yara say back to her, because it's the single most common sourcing mistake on the front-vs-back line: the same language can be either side. Look at the two bullets above — JavaScript and TypeScript appear in the frontend stack, but Node.js is JavaScript running on the backend. So "JavaScript" on a resume tells you nothing about which half of the stack the person works on. You have to read the cluster around it: React, HTML, CSS → frontend; Node.js, APIs, databases → backend. The language alone never identifies the specialty — the surrounding stack does. (This is the "search by capability, not by keyword" habit Topic 5 drills; the keyword "JavaScript" is exactly the kind that lies on its own.)

• Mobile — builds the phone apps. Two camps that don't overlap much: iOS (language: Swift) and Android (language: Kotlin).
• DevOps / SRE (Site Reliability Engineering) — keeps the infrastructure running and reliable: the cloud servers, deployments, uptime. Stack you'll see: AWS, Docker, Kubernetes, Terraform.
• Data / ML — works with the data the product generates and the models built on it. Big enough that it gets its own lesson next.

Imani's one rule for Yara: a specialty is not interchangeable with another just because they're both "engineering." A React frontend role and an iOS/Swift mobile role are different jobs needing different people. Send Marcus a brilliant Android engineer for his backend req and you've wasted everyone's afternoon.

The reassurance underneath all of this: SkilsMVP has full syllabi on every one of these roles. You learn the recruiter's slice — what the role does and which words cluster around it — and go deeper on any role you're hiring heavily for.

Lesson 3.3 — The data roles people conflate (and shouldn't)

Three months in, Marcus forwards Yara a req titled "Data Scientist" and, in the body, describes someone who'll "build our data pipelines and warehouse." Yara has learned enough by now to catch it. Those are two different people.

The word "data" hides four distinct jobs, and conflating them is one of the fastest ways a recruiter sends the wrong shortlist.

• Data Analyst — answers business questions with insights and dashboards. Stack: SQL, plus BI (Business Intelligence) tools like Tableau or Power BI. Less coding, more "what is the data telling us."
• Data Scientist — builds statistical and machine-learning models to predict and classify. Stack: Python, pandas, scikit-learn, and the math behind it.
• Data Engineer — builds the pipelines and warehouses that move and store all that data so the others can use it. Stack: SQL, Spark, dbt, orchestration tools like Airflow. This is the role hiding in Marcus's mislabeled req.
• ML / AI Engineer — takes a data scientist's model and puts it into production so the live product can use it reliably. Sits between data science and software engineering.

"Data person" is not a role. Analyst, scientist, engineer, and ML engineer are four hires with four different skill sets.

Beyond engineering, Northwind hires a wider cast that Yara also sources. Product Managers decide what to build and why. UX/UI Designers decide how it works and how it looks, living mostly in Figma. QA / Test Engineers own quality and write automated tests that catch bugs before customers do. And then the non-tech side — marketing, sales, customer success — which a tech recruiter often picks up too. Yara's sales background, it turns out, makes her the obvious person to screen Northwind's next account executive.

Lesson 3.4 — Reading seniority

Devon Asante's resume lands in Yara's inbox: a backend engineer, eight years in, currently leading a small team at a logistics company. Marcus's req says "senior." Is Devon a match, over-qualified, or aiming at the wrong rung entirely?

Answering that means reading seniority — the ladder almost every engineering role sits on. The common rungs, entry to top:

• Intern / Junior — early career, works on well-defined tasks, needs review and guidance.
• Mid-level — works independently on moderate problems with little hand-holding. The workhorse rung where most shipping happens.
• Senior — takes a vague problem, figures out what to build, and carries it end to end on their own.
• Staff / Principal — very experienced, drives technical work across multiple teams; or, on the other track, Engineering Manager / Lead, who leads people rather than only code.

Seniority drives three things at once: who you target, what you can expect of them, and the salary band. Match a candidate to the wrong rung and the whole thing breaks — a junior priced and pitched as a senior, or a senior bored by a junior's scope and gone in six months.

So Devon, with eight years and team leadership? He reads as senior, edging toward staff or a lead track. He fits Marcus's senior req cleanly, and Yara also now knows to ask whether Devon wants to keep managing people or get back to hands-on building, because that fork decides which of two very different roles he's actually right for. Reading the rung, and reading where the candidate wants to go next, is core recruiting judgment.

Lesson 3.5 — The JD is a wish-list, not a checklist

Yara's instinct, early on, is to treat Marcus's job description like a grocery list: tick every box or reject. So when Devon's resume shows seven years where the JD says "8+ years required," her first move is to pass on him.

Imani stops her. That instinct, run rigidly, rejects most of the good people in the market.

A job description is a wish-list. Hiring managers pile on every skill they'd love, and almost nobody ticks every box. The recruiter's job is to separate the true must-haves, the things without which a person cannot do the job, from the nice-to-haves, the bonuses that are pleasant but optional.

For Marcus's role, the real must-have is "can own a backend service in production." The "Go preferred" line is a nice-to-have; a strong Python engineer learns Go on the job. And "8+ years"? That number is a proxy, not a law of physics. A strong candidate one year short of a stated requirement is usually worth advancing, not auto-rejecting. Over-filtering on superficial criteria — exact years, exact buzzwords — shrinks your pool to nobody.

Years of experience is a proxy for "can they do the work?" When you can check the work directly, the proxy stops mattering.

You don't set the real bar alone. You set it with the hiring manager — the intake conversation that gets its own full treatment in Topic 8. But you walk into that conversation already knowing the difference between a requirement and a wish, which is what lets you push back when Marcus's wish-list is quietly costing him Devon.

Worked example — Yara fills Marcus's backend req

Marcus drops a req on Yara: "Senior Backend Engineer. Requirements: 8+ years, Go, Kubernetes, owned services in production, bonus: warehouse/logistics domain."

Yara decodes it before she sources a single name. Specialty: backend, so she'll search Python, Java, Go, Node.js, not React or Swift. Seniority: senior — someone who owns a problem end to end, not a junior padding a resume. Must-haves: "owned a backend service in production." Everything else — Kubernetes, the warehouse domain, even "Go" and "8+ years" — is a nice-to-have or a proxy she won't enforce to the digit.

Then Devon's resume comes back: backend, Python (not Go), seven years (not eight), led a team at a logistics company. A rigid keyword reading rejects him twice — wrong language, short on years. Yara's reading advances him: he nails the real must-have, his Python-to-Go jump is trivial, the missing year is noise, and the logistics background is a bonus most candidates won't have.

She brings Devon to Marcus with one line: "Seven years, Python not Go, but he's owned production services and he knows warehouses better than anyone else in the pipe." Marcus, who started this topic skeptical of recruiters, reads it and says, "Yeah. Get him on my calendar." That sentence — the one that makes a demanding VP trust a recruiter with no coding background — is exactly what this topic was built to give you.