QA, security, staff, principal, tech lead: what do these engineering titles mean?

QA, security, staff, principal, tech lead: what do these engineering titles mean?

QA and security are two more disciplines, like the ones in who works on a software team, and the rest of these titles measure something different: how far up the seniority ladder someone sits. The disciplines covered so far run horizontally. Frontend, backend, mobile, and infrastructure divide the work by what part of the product it touches. Seniority runs vertically, over all of them. A junior backend engineer and a principal backend engineer work in the same discipline at very different scopes.

This lesson covers the two remaining disciplines first, then the vertical axis: what seniority measures, what staff and principal mean, and how tech lead, architect, and engineering manager differ. The module overview shows where each piece fits.

What does a QA engineer do?

A QA engineer owns how a product gets tested. QA stands for quality assurance, and the name dates from an era when the job was mostly manual: a tester clicked through every screen before a release, following a written script, hunting for bugs. That version of the job still exists, and it matters most for products where a mistake is expensive, like banking or medical software.

At most software companies today, the work has shifted to code. Modern QA engineers write automated tests, programs that check the product on every change, and they build and maintain the systems that run those tests. Titles like "test automation engineer" or "SDET" (software development engineer in test) name this version of the role. It is programming work, and a person in it reads and writes code every day.

The useful mental split is manual versus automated. A resume that says "wrote test plans and executed regression testing" describes the manual tradition. One that says "built the test automation framework" describes an engineer whose product happens to be tests. Both are real QA, and they draw on different skills.

Why do some companies have no QA team?

Those companies have moved testing responsibility onto the developers themselves. Each developer writes the automated tests for their own work, and the CI/CD pipeline runs every test on every change before it can reach production. Why software is never finished covered the machinery. The staffing consequence is that a separate testing team becomes optional.

This is a deliberate choice about where responsibility sits. Many well-run companies, including most startups and several of the largest tech companies, ship this way. Quality lives in the tests developers write and in code review, rather than in a downstream team that checks the work.

What does a security engineer do?

A security engineer protects a company's systems and data. The discipline splits along a line this module has already drawn. One part faces infrastructure: locking down the servers, networks, and cloud accounts that keep the product alive. The other part, called application security or AppSec, faces the code the team writes. An AppSec engineer reviews new code for ways it can be attacked, runs tools that scan for known weaknesses, and works with developers to fix what turns up.

Two more specialties appear on reqs. A penetration tester, or pentester, attacks the company's own systems on purpose to find holes before a real attacker does. Compliance-focused security work gets a company through audits like SOC 2, the certificate enterprise customers demand before they will buy.

Security engineers usually arrive from somewhere else. Backend and infrastructure work are the common origins, because attacking a system well requires understanding how it was built. A security resume that opens with several years of ordinary development is the normal shape of the career.

What does seniority actually measure?

Seniority measures scope of ownership. A seniority level names how large a piece of the work someone is trusted to own without supervision. A junior engineer owns tasks: a well-defined ticket, with a senior nearby to unblock them. A mid-level engineer owns features end to end. A senior engineer owns systems: they design the solution, weigh the tradeoffs, and answer for the result over time.

Years of experience correlate loosely with all of this, and titles map to it unevenly across companies. Large companies pin titles to internal level numbers, like L3 through L7 at Google, with written expectations for each. Small companies hand out titles far more freely. The same word on two resumes can describe two very different scopes, which is why decoding what "senior" means at one specific company is its own lesson later in the path, in the intake station.

The reliable signal is in the verbs. "Fixed", "implemented", and "contributed to" describe task scope. "Designed", "owned", and "led the migration of" describe system scope, whatever title sits at the top of the page.

What is a staff engineer, and what is a principal engineer?

Staff and principal are the levels above senior on the individual contributor track, usually shortened to IC: the track for engineers who keep building rather than moving into management. A staff engineer operates at the scope of several teams or one large system. They set technical direction, make the decisions that are expensive to reverse, and unblock other engineers. Much of the output is influence: design documents, code reviews that teach, and the quiet work of stopping bad ideas early. A principal engineer does the same at the scope of a whole organization or company.

The existence of these levels is the point. Engineering careers fork after senior. One branch manages people and the other keeps building at ever larger scope, and companies with a full ladder pay the two branches at the same levels. A staff engineer at a large tech company earns what a manager of managers earns. Moving to management is a change of job, and people move in both directions across a career.

What is an architect?

An architect makes the high-level structural decisions for a system: which parts exist, how they talk to each other, and which technologies they are built on. The name borrows deliberately from buildings. An architect draws the load-bearing structure before anyone pours concrete, because those decisions are the expensive ones to change later.

Whether it is a job title depends on the company. Large enterprises, banks, and consultancies often employ formal "solutions architects" or "enterprise architects" who design systems that other engineers then build. Most product tech companies skip the separate title and fold the work into staff and principal engineers, on the view that the person designing a system should stay close to the code.

The word also appears as a verb, and "architected" on a resume is a scope claim: this person is saying they made the structural decisions. A later lesson in the candidate-call station covers what sits behind that claim.

What is the difference between a tech lead and an engineering manager?

A tech lead coordinates the technical work of one team, and an engineering manager is responsible for its people. The tech lead, often written TL, decides how the team's sprint of work gets divided, reviews designs, and stays hands-on in the codebase. At most companies it is a hat rather than a level: a senior engineer wears it for a while, and it can rotate. The manager owns hiring, career growth, performance, and the health of the team, and at many companies writes little or no code.

The two roles pair on one team, and the seam between them varies. Some companies combine them into a tech lead manager, or TLM. On a resume, "tech lead" signals a senior engineer trusted to coordinate others while remaining an IC. "Engineering manager" signals someone who crossed the fork. A candidate who held both at different times has seen the fork from both sides, which is a common and healthy career shape.