Roles in an engineering team

Written Explanation

Roles, not job titles

A role describes what someone is responsible for. A job title is the label on a business card. A person titled "Software Engineer" might do frontend work on Monday, backend work on Tuesday, and QA-style checking on Friday. Conversely, two people with the title "Backend Engineer" at different companies may have very different duties. Use the roles below as a map, and expect that real teams smudge the borders.

Frontend engineer: what the user sees

The frontend is the part of an application that runs where the user is: in a web browser or inside a mobile app. In the browser, frontend code is written in the languages the browser understands (HTML, CSS, and JavaScript, covered by the MDN web documentation). A frontend engineer builds the screens, buttons, forms, and layout, makes them work on different devices and sizes, and sends requests to the backend when data is needed.

Typical concerns: Does the page look right on a phone? Is it fast to load? Can someone who uses a screen reader use it? Does it show a helpful message when the backend is slow?

You first met the idea in the module on software: a website's frontend and its backend are not the same thing. The frontend asks, the backend answers.

Backend engineer: the hidden service, data, and rules

The backend is the part that runs on servers. It receives requests from frontends (and sometimes from other services), applies the business rules, stores and retrieves data, and sends back responses. It is the role this entire course prepares you for.

Typical concerns: Is this request allowed? Is the price calculated correctly? Is the data stored safely and kept consistent? Does the service stay fast when many requests arrive? If the data is wrong, who gets hurt?

A good backend engineer needs to be careful, because many people and programs depend on the service, and mistakes in rules or data can be costly.

Full-stack engineer: both sides

A full-stack engineer works on both the frontend and the backend of the same product. "Stack" means the layers of technology that make up an application, from what the user sees down to where the data is stored. Full-stack engineers are common in small teams, where one person owns a feature from the screen to the database.

Full-stack does not necessarily mean "expert in everything". Many full-stack engineers are stronger on one side. The value is that they can follow a feature across the layers and understand the other side's needs.

QA: finding problems before users do

QA stands for quality assurance. QA engineers (sometimes called testers) check that the software does what the requirements say, and look for the cases nobody thought of: strange inputs, unusual sequences of actions, many users at once. They may test by hand, write automated tests (programs that check the software), or help the team design a test strategy.

Many modern teams have the developers write tests for their own code too, with QA engineers focusing on harder questions: what should we test, what is risky, and how do we know the product is good enough to release? In some teams there is no dedicated QA role and everyone shares the testing work.

QA is not the "last line of defense" that excuses everyone else from care. The best result is a team where quality is built in from the requirements stage on.

DevOps: automating the road to release

The word DevOps joins "development" and "operations". Microsoft's documentation describes it as a way of bringing development, operations, and related roles together through shared culture, practices, and tools. Because DevOps is both a culture and a set of practices, you will see it used in two ways:

• As a way of working, in which developers and operations people collaborate and share responsibility across the life of the software.
• As a job role, usually called DevOps engineer: the person who builds and maintains the automatic systems that build, test, and release software, and the infrastructure it runs on.

The automatic route from "a developer saves a change" to "the change is checked and available to users" is often called a pipeline. Setting up pipelines is a typical DevOps task. Continuous integration (CI) is one practice you will meet: team members merge their changes into the shared code often, and each merge triggers an automatic build and set of tests, so that mistakes surface in minutes instead of weeks.

SRE: keeping production reliable

SRE stands for site reliability engineering. The idea, described in Google's SRE book, is to hire software engineers to run production services, and to have them build software that automates operations work instead of doing it all by hand. An SRE team typically cares about how available the service is, how fast it responds, how changes are rolled out, how it is monitored, what happens in an emergency, and whether there is enough capacity for the demand.

The book also describes a useful shared measure, the error budget: a chosen amount of allowed unreliability, based on how reliable the service needs to be. While there is budget left, the team can release new things boldly. When it runs out, the team slows down and focuses on reliability. This turns a typical argument ("ship faster" versus "keep it stable") into a measurable agreement.

DevOps versus SRE in one sentence: DevOps is mainly about developers and operations working together and automating the path to release; SRE is a specific approach to running production using software engineering. They overlap a great deal. Many companies use one word for what others call the other, or have one team doing both. Do not worry about getting an exact line; focus on the responsibility each name points to.

Architect: how the big pieces fit

An architect decides, or leads the decisions about, how the large pieces of a system fit together: what the main parts are, how they talk to each other, where data lives, what rules the whole system follows, and which trade-offs to accept (cost, speed, safety, simplicity). Architects look at a longer time horizon and a wider area than a single feature.

Architect work appears at several levels: a senior backend engineer may make architecture decisions for a service, while larger organizations have people whose main job is architecture across many teams (the career map in lesson 4 returns to this). In a good team, architects explain their decisions and stay close to the code, rather than handing down a drawing and disappearing.

The roles at a glance

How the roles hand work to each other

A feature does not belong to one role. It moves, and often loops back. A simplified picture:

Architect/team design -> Frontend + Backend build -> Review -> QA + automatic tests
        -> DevOps pipeline releases -> SRE/operations team runs and watches
        -> feedback and problems return to the team for the next change

In words: the design says what the pieces will be. The frontend and backend engineers build their parts and agree on how they talk (what the request looks like and what comes back). Teammates review the code. QA and automatic tests check it. The pipeline that DevOps maintains builds and releases it. The people who run production watch it, and what they see feeds back into the next piece of work. Lesson 3 follows this path step by step.

Two things to notice:

1. The handoffs are conversations, not walls. If the backend changes how its answers look and does not tell the frontend, the screen breaks. Teams reduce this by agreeing on the shape of requests and responses early, and by testing them.
2. The arrows go both ways. QA sends bugs back to the builders. SRE sends reliability findings back to developers. The architect hears from builders that a design is too hard to implement.

Who to ask?

Matching a problem to a role is a good test of understanding:

• "The login button overlaps the logo on a phone." Frontend.
• "The service answers 'price: -5'." Backend (the rule is wrong), perhaps with QA to add a test for it.
• "Deploying takes two hours of manual steps." DevOps.
• "The service has been failing every Monday morning." SRE/operations with the backend team.
• "Should the orders and payments live in one service or two?" Architecture, with the backend team.

In practice you ask the team, and you find out who is best placed. But knowing the map tells you which questions to bring.

Where do you start?

This course follows the backend role. But a backend engineer constantly touches the neighbors: reading frontend requirements, writing tests, understanding the pipeline, and being involved in operating the service. At work you do not need to be an expert in the other roles. You need to know what they need from you, and to speak enough of their language to collaborate.