What does a backend engineer do all day, and is mobile a different search?

What does a backend engineer do all day, and is mobile a different search?

A backend engineer spends the day designing and changing the systems that store data, enforce rules, and answer requests, and yes, a mobile role is a different search from a web role. Those are the two facts this lesson unpacks.

An earlier lesson covered frontend, backend, and the API as parts of an application. This lesson covers them as careers. The layers of the app are also the main split in the engineering job market: most developers build their depth on one side of the API and stay there for years. The previous lesson put a whole team in the room. Here the word "engineer" splits into the disciplines a req actually names.

What does a backend engineer actually do?

A backend engineer builds and maintains the half of the product that runs on the company's computers: the servers that answer requests, the database that holds the records, and the API the frontend calls. When a payment goes through, a password gets checked, or a search returns results, that logic is backend work.

The day itself is mostly reading and reasoning. A backend engineer reads far more code than they write, because every change lands inside a system other people built. They review teammates' changes. They design how data will be stored, which is a bigger decision than it sounds: a data design gets built on for years, and changing it later means moving live records without losing any. And they investigate behavior in production, tracing why one request out of ten thousand came back slow or wrong.

The hard parts of the discipline are data design, reliability, and scale. A backend that works for a hundred users can fail at a hundred thousand, and backend engineers are the people who see that coming.

What does a frontend engineer actually do?

A frontend engineer builds the half of the product a person sees and touches: every screen, button, form, and list, usually as a web app running in the browser. They work close to the designer from the previous lesson, turning a design into a working interface, and close to the backend through its API.

The center of the job is a problem called state: everything the screen currently believes. Data is loading, then it arrives, then the user edits it, then the save fails and the edit has to survive. Keeping every part of the screen correct while all of that changes is where frontend complexity lives, and it is the problem frontend frameworks exist to manage.

Around state sit two more hard parts. Performance on real devices means the interface has to feel instant on a cheap phone with a weak signal, in every major browser. Accessibility means it has to work for people using a screen reader or a keyboard alone, which is a legal requirement in many markets and a craft in its own right.

Is one of them harder than the other?

Neither. They are different problems, and developers on each side tend to find the other side's problems foreign rather than easy.

Frontend difficulty is dominated by change and perception. The state of a screen shifts constantly, the code runs on thousands of device and browser combinations the team never touched, and the judge is a human being who notices a delay of a tenth of a second. Backend difficulty is dominated by data, failure, and scale. The code runs on machines the team controls, and the judge is reality: the numbers must be right, the system must stay up, and load can multiply overnight.

Both disciplines carry senior people with deep, compounding expertise, and they command comparable pay at comparable levels. The stack lesson covered full-stack developers, who work across both halves. That claim is common and usually leans one way, so which half a person is stronger in matters more than whether the word appears.

Is mobile a different search?

Yes. Mobile engineering means building the apps that install on a phone through the App Store or the Play Store, and it is far enough from web work to count as its own market.

The distance shows up in three places. The languages and tools are different, so years of web experience translate to a ramp rather than a running start. The platform rules are different: a mobile app runs under Apple's or Google's constraints on what software may do on their devices. And the release rules are different in a way that shapes the whole culture. A web team can ship a fix to everyone in minutes. A mobile team submits a versioned release, waits for store review, and then waits again while users update on their own schedule. A bug that reaches the store stays in the world for weeks, so mobile teams test harder and release more deliberately.

What is the difference between iOS and Android work?

They are close to two separate markets. iOS work means Swift, Apple's language, inside Apple's ecosystem: its interface conventions, its device lineup, and its App Store review process. Android work means Kotlin, Google's preferred language since 2019, across an enormous range of devices from many manufacturers, which makes device variety a daily engineering concern.

Few developers work deeply in both. The languages differ, the tools differ, and the platform knowledge that makes someone senior, the accumulated judgment about how their platform behaves, is specific to one side. A team that needs native apps on both platforms usually staffs two specialists or reaches for the approach in the next section. For a search, "mobile engineer" on a req is worth splitting into which platform the team actually means, because the two candidate pools barely overlap.

What is a native app, and what is cross-platform?

A native app is written for one platform with that platform's own tools: Swift for iOS, Kotlin for Android. Native is the default for teams that want the deepest control over performance and platform features, and it is what the platform specialists above build.

A cross-platform app shares one codebase across both platforms, built with a framework made for exactly that. React Native builds on React, so JavaScript teams can reach both app stores with the skills they already have. Flutter, Google's framework, uses a language called Dart and draws its own interface, which keeps the app identical on both platforms. Cross-platform trades some native control for one codebase and one team, and a large share of new apps make that trade.

The web app is the third option, and the reason many products never enter the app stores at all. It runs in the browser, installs nothing, updates instantly for everyone, and reaches every device at once. A common product path runs web first, cross-platform when the phone matters, native when the phone is the product. Each step along that path changes which discipline the next req names, which is why the same product can be a web search one year and a mobile search the next.