What does a hiring manager mean by "distributed systems" and "migrating off the monolith"?

What does a hiring manager mean by "distributed systems" and "migrating off the monolith"?

When a hiring manager says "distributed systems" or "migrating off the monolith," they are describing the shape of their software and the project the hire will join, and both phrases decode into concrete, searchable work. Distributed systems names a category of engineering problem. Migrating off the monolith names a specific project: taking a large application apart while it keeps running. Each phrase narrows who the team needs, and this lesson decodes them one at a time, along with the words that travel with them: microservices, monorepo, re-platforming, greenfield, and brownfield.

These phrases sound like jargon because they are, but the jargon is precise. A hiring manager who uses them is handing over real information about the codebase, the project, and the profile that fits.

What is a distributed system?

A distributed system is software whose work is spread across many machines that coordinate over a network. One server handles logins, another holds the database, a dozen more process payments, and they all talk to each other constantly. Nearly every product running in the cloud is distributed to some degree.

Spreading work across machines creates problems a single machine never has. A machine can fail while the others keep running, so the system has to notice and recover. Two machines can hold different versions of the same data for a moment, so the system has to reconcile them. Messages between machines take time and sometimes vanish, so every conversation needs a plan for silence. The engineering discipline of handling these failures well is what "distributed systems" means as a skill.

On a req, "strong in distributed systems" usually points to backend engineers who have built or operated software spread across many machines, most often at meaningful scale. The phrase covers a wide range, so the specific problems the team is fighting, slow responses, data getting out of sync, outages during traffic spikes, narrow the profile far more than the phrase itself does.

What is a monolith?

A monolith is an application built, tested, and released as one large piece. All the code lives together, and every deploy ships the whole thing at once. The name borrows from the Greek for "single stone," and the image is accurate: one solid block.

The word often arrives with an apologetic tone, and that tone is worth ignoring. A monolith is a normal design, and for many products it is the right one. It is simpler to build, simpler to test, and simpler to run, because everything is in one place. Many large, successful companies run monoliths on purpose and defend the choice publicly. A team describing its monolith is describing a codebase where one change can touch anything, which means the work rewards engineers who read unfamiliar code well and hold a big system in their head.

What are microservices?

Microservices are the opposite design: the application is split into many small services, each owning one job, each built and released on its own. One service handles accounts, another handles billing, another handles search. Teams own their services and ship them independently, without waiting on each other.

The split solves real problems. Fifty engineers editing one monolith step on each other, and a bug in one corner can delay everyone's release. With microservices, each team moves at its own pace. The cost is that the application becomes a distributed system by construction: every boundary between services is a network call through an API, and every network call can fail. Microservices trade coordination complexity between people for operational complexity between machines.

For hiring, a microservices shop tends to want engineers comfortable with service boundaries, API design, and production debugging across many moving parts. The developers on why tools carry so much weight have opinions about this trade, and a candidate who has lived both designs can say what each one costs.

Is a monorepo the same as a monolith?

No, and the two get confused constantly because both start with "mono." A monorepo is one repository that holds many projects. A monolith is one application that ships as a single piece. The monorepo is about where code is stored. The monolith is about how code is released.

The combinations all exist in the wild. Google famously keeps almost all its code in one enormous monorepo while running thousands of separate services. A startup can keep its monolith in one repo, or scatter microservices across fifty repos, or gather those same microservices into one monorepo. A candidate who says "we moved to a monorepo" is describing a code-organization project. A candidate who says "we broke up the monolith" is describing an architecture project. Those are different kinds of work done by different kinds of engineers, and hearing the difference on a call is exactly the fluency this module builds.

What does "migrating off the monolith" involve?

Migrating off the monolith means splitting a large single application into separate services while customers keep using it. The system cannot go down for the rewrite. Engineers carve off one piece at a time, stand it up as its own service, route real traffic to it, watch it under load, and only then move to the next piece. Teams compare it to changing an airplane's engines mid-flight, and the comparison is fair.

Projects like this run for quarters or years, and they reward a specific temperament: patience, care around live systems, and comfort with old code the original authors have left behind. The engineer spends more time reading and untangling than writing something new. A hiring manager who says this phrase in an intake has told you the daily reality of the job, and it looks very different from the daily reality of building a new product.

What does re-platforming mean?

Re-platforming is the broader version of the same move: rebuilding a product on a new technical foundation. Moving from a company's own machines into the cloud, changing the core tech stack, or replacing a system the company outgrew all count. Migrating off the monolith is one kind of re-platforming.

The word signals a project with a before and an after, a live system on one side and a target on the other, and a long careful middle. The load-bearing skill is rarely the destination technology, which an experienced engineer picks up quickly. It is the migration itself: moving data without losing it, running old and new side by side, and cutting over without customers noticing. Candidates who have done one carry the scars and mention them.

What does the project's shape say about the person it needs?

Each phrase in this lesson maps to a profile. "Distributed systems" points to backend engineers who have operated software across many machines and can talk about failures they have handled. "Migrating off the monolith" points to engineers who have changed live systems slowly and safely, often in older codebases. "Moving to microservices" points to people who have drawn service boundaries and lived with the results. "Re-platforming" points to people who have run a long migration end to end.

The phrases also say what the job is like. A migration job is careful, incremental, and heavy on reading existing code. A scaling job is diagnostic, measuring where a system strains and reinforcing it. Which one the hiring manager describes tells you which candidates will light up at the description and which will quietly pass, and that fit question belongs in the intake, well before sorting requirements into real and copied.

What is greenfield work, and what is brownfield work?

Greenfield work builds something new from an empty repository: no users yet, no old decisions to honor, every choice open. The name comes from construction, where a greenfield site is an untouched field. Brownfield work changes a system that already exists and has customers depending on it, the way a brownfield construction site already has buildings and pipes to work around. Everything in this lesson about migrations is brownfield.

Most engineering jobs are brownfield, because most companies already have a product. Yet job descriptions lean greenfield in their language, all "build" and "create" and "from the ground up," because building sounds better than maintaining. When the description says greenfield and the rest of the req describes a ten-year-old codebase, the intake is the place to reconcile them. Some excellent engineers prefer brownfield work and say so: they like real constraints, real users, and the puzzle of improving a thing that cannot stop running. A hiring manager who is honest about which kind of work this is will get candidates who wanted exactly that.