Software Engineer

A software engineer builds and maintains the systems other people depend on. On a given day that means reading code you didn't write, deciding how a feature should be shaped before typing anything, writing the implementation, reviewing a teammate's pull request, and getting paged when the thing you shipped behaves differently at 3 a.m. under real traffic than it did on your laptop. The title covers an enormous band — the same two words describe someone maintaining insurance claims processing in Java and someone writing inference servers in Rust — but the core loop is constant: take an ambiguous problem, turn it into a precise specification, encode that specification so a machine executes it reliably, then own what happens next.

"Software engineer" is the umbrella the narrower titles sit under. A frontend developer, backend developer, full-stack developer, and mobile developer are all software engineers with a smaller surface area; at most large companies those are literally the same job ladder with a specialization noted in the req. The roles genuinely distinct from it sit adjacent in the pipeline. A DevOps engineer owns how code gets deployed and stays up rather than what it does. A data engineer owns the movement and shape of data rather than application behavior. A machine learning engineer owns training and serving models. The boundary that actually matters in practice is who gets paged: if your name is on the on-call rotation for a service, you are the engineer for it.

Here is the honest version of the AI question. The routine tier of this job has already been eaten. Writing a CRUD endpoint from a clear spec, converting a mockup into markup, translating a function between languages, drafting a first-pass test suite — Claude, Copilot, and Cursor do all of that competently, and that is precisely the work that used to fill a junior engineer's first year. What has not been eaten is the work that requires holding a whole system in your head: deciding what to build, debugging a failure that spans three services with incomplete logs, judging whether a generated solution is actually correct rather than merely plausible, and carrying a design that has to survive four years of changing requirements. Compensation data reflects the split exactly — senior pay held, entry-level hiring got materially harder. The fastest path forward is to skip the tier that got automated: learn to review and correct machine output rather than to produce the same output slower.

The people who last in this job like being wrong in public and fixing it quickly. You need real tolerance for sitting with a problem you do not yet understand, and comfort with the fact that most of your hours go to reading and reasoning rather than typing. It suits you badly if you want work with a finished state — software is never done, and maintenance is most of the total lifetime cost. It suits you badly if you want to avoid writing, because design docs, incident write-ups, and review comments are a large share of a senior engineer's real output. A computer science degree helps at the résumé screen and for the algorithms interview, but it is not a licensing gate. A large share of working engineers arrived via bootcamps, adjacent technical jobs, or self-teaching plus a public record of shipped things.