The most persistent misconception about software engineering is that the job is essentially solitary coding — a developer alone at a screen, translating requirements into working programmes through pure technical work. This image is accurate for perhaps a third of the actual job at most companies, and an even smaller fraction at senior levels. The rest involves code review, system design discussions, debugging production incidents at 2am, explaining technical tradeoffs in product planning meetings, mentoring colleagues, writing documentation, and navigating the organisational dynamics of large engineering organisations.
This gap between the perception and the reality matters for two groups. Aspiring software engineers need an accurate picture of what they are actually signing up for — including both the genuinely interesting parts (system design, technically challenging problems, building things used by millions of people) and the unglamorous but unavoidable parts (on-call rotations, meetings, legacy code). Managers and non-engineers working alongside software teams need to understand what engineers are actually doing when they are not visibly writing code, because misunderstanding this creates unrealistic expectations, poor planning, and friction.
This guide covers the full scope of software engineering work — day-to-day responsibilities, the level system at major technology companies (with salary data), the frontend/backend/fullstack distinction, career progression from L3 to L7+, and what getting started in the field actually requires. The numbers come from verified sources including Levels.fyi, Bureau of Labor Statistics data, and published compensation surveys.
The economic significance of software engineering is hard to overstate. Stripe's Developer Coefficient research report (2019) estimated that software developers contribute $300 billion annually to the US economy's GDP growth, and that companies with the strongest engineering talent grow revenue 4.9 times faster than competitors. The Bureau of Labor Statistics projects 26% employment growth for software developers through 2032 — roughly five times the average across all occupations. For career planners, these are exceptional structural tailwinds.
"Programming is not about typing code. It's about thinking." — Leslie Lamport, Turing Award winner and creator of LaTeX
Key Definitions
System design: The process of defining the architecture of a software system — how components fit together, how data flows, how the system handles load, failure, and scale. System design is a core senior engineering skill and a primary focus of technical interviews at major companies.
Code review: The practice of having peers examine code changes before they are merged into the main codebase. Reviews catch bugs, enforce coding standards, and transfer knowledge. Most engineering teams require at least one reviewer approval before merging.
On-call rotation: A schedule by which engineers take turns being the first responder to production incidents outside business hours. On-call engineers carry a pager (now typically a phone alert through PagerDuty or similar) and are responsible for triaging and resolving alerts that cannot wait until morning.
Technical debt: The accumulated cost of previous shortcut decisions in a codebase. Code written quickly to meet a deadline is often harder to maintain, extend, and debug than code written carefully — the "debt" is the future work required to address those shortcuts.
Continuous integration / continuous deployment (CI/CD): Automated pipelines that build, test, and deploy code changes. Engineers commit code to a repository; the CI/CD system automatically runs tests and, if they pass, deploys the change to production. Managing and improving these pipelines is a real part of engineering work.
SRE (Site Reliability Engineering): A discipline pioneered at Google that applies software engineering principles to operations and reliability problems. SREs write code to automate operational tasks, define and monitor service level objectives (SLOs), and manage the engineering infrastructure that keeps production systems reliable.
RFC (Request for Comments) / Design Document: A written technical proposal describing a planned system change or new system. Engineers write RFCs to communicate proposed designs, gather feedback, and create a record of architectural decisions. At senior levels, writing and reviewing RFCs is a primary work product.
Postmortem: A written analysis of a production incident, documenting what happened, why it happened, what was done to resolve it, and what changes will prevent recurrence. Postmortems are a cornerstone of engineering learning culture and are written without blame — the goal is systemic improvement, not individual accountability.
What a Software Engineer Does: The Real Day-to-Day
An engineer's day at a mid-to-large technology company typically divides across five types of activity, in varying proportions depending on seniority and role.
Writing Code
New code — implementing features, building services, writing scripts — is what most people imagine when they think of software engineering work. At junior levels, this occupies perhaps 50-60% of working time. At senior and staff levels, it can drop to 20-30% as coordination, design, and review work expands.
Writing code well requires more than knowing language syntax. It involves understanding the codebase's existing patterns and conventions, writing tests that cover meaningful cases, handling edge cases and error conditions, considering how the change affects performance and reliability, and writing code that colleagues can read and maintain rather than just code that works.
DeMarco and Lister's Peopleware (1987, revised 2013) documented that interruptions have a disproportionate cost in software development: resuming productive coding flow after an interruption takes an average of 23 minutes. This finding has shaped how thoughtful engineering organizations design their workdays — protecting focused coding time while also ensuring that communication requirements are met.
Code Review
Most engineering teams require changes to be reviewed by one or more peers before merging. Code review is not simply rubber-stamping. Good reviewers check correctness, security, test coverage, performance implications, consistency with architectural patterns, and readability. Senior engineers often spend 1-2 hours per day reviewing colleagues' code — time that does not produce code output but is critical to overall team quality and knowledge sharing.
Fowler's Refactoring (2018) describes code review as one of the highest-leverage activities in software development: catching a design flaw in review costs minutes; catching it after deployment to production can cost days or weeks. Studies of the Chrome browser codebase conducted by Google researchers found that code review catches approximately 26% of all bugs in the software, more than any other quality mechanism including testing.
The social dimension of code review matters as much as the technical dimension. Reviews that are consistently critical without being constructive, or that focus on personal style preferences rather than genuine issues, damage team morale and slow delivery. Google's engineering culture documentation explicitly trains reviewers on respectful code review practices — a recognition that the human dynamics of review are as important as the technical outcomes.
System Design and Architecture
As engineers progress, they spend increasing time thinking about how systems should be structured rather than how individual pieces of code should be written. System design involves questions like: how should this service communicate with others (REST, gRPC, event streams)? How will the system handle 10x current load? What happens when this dependency is unavailable? How do we make this observable when things go wrong?
At staff engineer level and above, system design is the dominant technical work. This involves writing design documents (RFCs), presenting proposals for peer feedback, and guiding implementation decisions across multiple teams.
Bass, Clements, and Kazman's Software Architecture in Practice (4th edition, 2021) describes the fundamental tradeoffs that all distributed system architects must navigate: the CAP theorem (Consistency, Availability, Partition tolerance — you can have at most two), the cost of synchronous versus asynchronous communication, and the engineering cost of premature optimization. Senior engineers who can reason clearly about these tradeoffs — and explain them to non-technical stakeholders — are disproportionately valuable.
Debugging and Incident Response
Software breaks. Bugs escape to production; services go down; performance degrades under load. Debugging is a genuine skill — the ability to form hypotheses, examine logs and metrics, isolate variables, and identify root causes in large systems. Some engineers find this genuinely engaging; others find it stressful. All of them must be able to do it.
On-call rotations ensure that someone is accountable for responding to production incidents around the clock. Being on-call means being reachable 24/7 for a rotation period (typically one week per month in well-run organisations) and accepting that some on-call periods will be quiet while others will involve multiple middle-of-the-night incidents.
Google's Site Reliability Engineering book (2016) describes the target of 50% toil-free on-call: engineers should spend no more than 50% of their on-call time on reactive work (responding to incidents), with the remainder directed at eliminating the root causes of recurring incidents through engineering. This principle — that on-call burden should decrease over time as engineers automate and fix root causes — distinguishes mature engineering organizations from those where on-call is perpetually overwhelming.
Meetings and Communication
Software engineering at product companies involves significant meeting load: daily standups (15-30 minutes of status updates and blocker identification), sprint planning (setting work goals for the coming two weeks), design reviews (discussing technical proposals), product planning (working with PMs and designers on upcoming features), and one-on-ones with managers and mentors. Studies of engineering time use place meetings at 20-35% of total work time for mid-level engineers and higher for senior and staff engineers.
Written communication matters as much as meeting participation. Design documents, postmortem write-ups, technical guides, and comment threads in code reviews collectively constitute a large volume of engineering writing that directly affects team knowledge and decision quality. Larson (2019) in An Elegant Puzzle argues that senior engineers' primary leverage comes not from the code they write but from the documents they produce — specs, postmortems, and design documents that scale their thinking across many people and long time periods.
The Level System: L3 to L7+ at Major Technology Companies
Large technology companies use levelling systems to standardise career progression and compensation benchmarking. Google's system is widely referenced because it is publicly discussed and companies often benchmark against it.
L3 (Entry Level / New Graduate): Can implement defined tasks with limited guidance. Learning the codebase, tools, and team processes. Expected to ask for help frequently and deliver assigned work accurately.
L4 (Software Engineer II / Confident Individual Contributor): Works independently on well-scoped features. Contributes to code reviews. Identifies and resolves bugs. Makes reasonable technical decisions within established patterns.
L5 (Senior Software Engineer): Leads features or small projects end-to-end. Makes significant technical decisions. Mentors junior engineers. Begins influencing the broader technical direction of the team. The modal level for experienced engineers at major companies.
L6 (Staff Software Engineer): Drives technical direction across multiple teams or a major component. Identifies problems that teams are not seeing, proposes and drives cross-cutting improvements. Writing and reviewing design documents that affect significant parts of the system.
L7 (Senior Staff / Principal Software Engineer): Organisation-wide technical leadership. Identified with the company's most technically significant systems. Shapes how engineering is practised. Very rare — fewer than 2% of engineers at major companies reach this level.
L8+ (Distinguished Engineer / Fellow): Industry-wide recognition. Fewer than a dozen at Google or Meta. Considered among the most technically accomplished people in the field.
What Differentiates L5 from L6
The transition from senior engineer (L5) to staff engineer (L6) is one of the most significant career inflection points in software engineering. Will Larson, in Staff Engineer: Leadership Beyond the Management Track (2021), identifies four archetypes of staff engineer work: the Tech Lead (coordinating a team's technical direction), the Architect (designing large systems), the Solver (tackling the company's most ambiguous technical problems), and the Right Hand (extending the reach of an executive).
Common failure modes for L5 engineers attempting to advance: continuing to optimize for individual coding output rather than team output; failing to develop the written communication skills required to influence at scale; and not developing the organizational awareness required to identify which problems are worth solving at the cross-team level.
Salary by Level (United States, Total Compensation including Equity, 2024)
Data from Levels.fyi, aggregating self-reported compensation at major technology companies.
| Level | Meta | Amazon | Industry Average | |
|---|---|---|---|---|
| L3 / Entry | $180,000 - $220,000 | $170,000 - $210,000 | $155,000 - $190,000 | $100,000 - $140,000 |
| L4 | $220,000 - $300,000 | $220,000 - $290,000 | $175,000 - $230,000 | $130,000 - $180,000 |
| L5 / Senior | $300,000 - $420,000 | $290,000 - $400,000 | $225,000 - $320,000 | $160,000 - $220,000 |
| L6 / Staff | $400,000 - $600,000 | $380,000 - $580,000 | $300,000 - $450,000 | $200,000 - $300,000 |
| L7 / Sr Staff | $550,000 - $900,000+ | $500,000 - $850,000+ | $400,000 - $650,000+ | $280,000 - $450,000+ |
"Industry average" reflects typical technology companies outside the FAANG tier. Startups may pay less in cash but offer equity that can be highly valuable upon a liquidity event.
Outside the United States, salaries are substantially lower. UK senior engineers average GBP 80,000-130,000. German engineers earn EUR 75,000-110,000. These gaps reflect both cost of living differences and the concentration of high-paying technology employers in US markets. The Stack Overflow Developer Survey 2024 found that US-based software engineers report median total compensation of $185,000, compared to $70,000 globally — a roughly 2.6x gap that persists even when adjusting for purchasing power.
Frontend vs Backend vs Fullstack Engineering
Frontend engineering focuses on the user-facing layer of software: browsers and mobile applications. Core technologies include HTML, CSS, and JavaScript, with modern frontends typically built using frameworks like React, Vue, or Angular. Frontend engineers care about performance (page load times, rendering efficiency), accessibility (ensuring the product works for users with disabilities), and visual correctness across browsers and screen sizes.
The accessibility dimension deserves particular emphasis. The Web Content Accessibility Guidelines (WCAG) define standards for accessible web content, and legal requirements in multiple jurisdictions (ADA in the United States, EN 301 549 in the European Union) create compliance obligations for public-facing applications. Frontend engineers who understand and implement accessibility standards are disproportionately valuable.
Backend engineering focuses on server-side systems: the APIs that serve data to frontends, the databases that store it, the services that process it, and the infrastructure that keeps everything running. Languages commonly used include Python, Java, Go, Rust, Node.js, and C++. Backend engineers care about reliability, performance under load, data consistency, and security.
The rise of distributed microservices architectures has significantly expanded what "backend engineering" encompasses. A backend engineer at a company running hundreds of microservices must understand service mesh architectures, distributed tracing, API design patterns, message queues, and the failure modes specific to distributed systems — a substantially broader skillset than the monolithic application backend of a decade ago.
Fullstack engineering describes engineers who work competently across both layers. True fullstack proficiency — meaning real depth in both frontend and backend — is less common than the title suggests. Most "fullstack" engineers have a primary orientation and functional competence in the other area. Fullstack roles are more common at startups and smaller companies where resource constraints require individuals to span the entire stack.
Specialisations within these categories include:
Mobile engineering (iOS, Android): Building native applications for Apple and Android platforms. Swift and Kotlin are the primary languages for native development; React Native and Flutter enable cross-platform development from a single codebase. Mobile engineers deal with device fragmentation, limited compute resources, and app store submission processes that have no equivalent in web development.
Platform engineering / Developer productivity: Building the internal infrastructure and tooling that other engineers use — CI/CD pipelines, developer portals, internal APIs, shared libraries. A growing specialisation as companies recognize that the productivity of their engineering organization is itself a product to be engineered.
Site Reliability Engineering (SRE): Focused on production reliability, observability, and the elimination of operational toil through automation. Pioneered at Google, where it is a fully developed career track. SREs write software to improve reliability rather than building user-facing features.
Data engineering: Building the pipelines, data warehouses, and infrastructure that support analytical and machine learning work. Increasingly close to data science in tooling (Python, Spark, dbt) but primarily focused on the reliability and scalability of data infrastructure rather than analytical work.
Engineering Culture: What Actually Differentiates Great Teams
The technical skills of software engineering are learnable from books, courses, and practice. What is harder to teach — and what distinguishes exceptional engineering teams from average ones — is culture.
Atlassian's 2023 Teamwork State of the Industry report found that engineers at high-performing teams spend 17% more time in collaborative activities (pair programming, design reviews, mentoring) than those at lower-performing teams, and report 46% higher satisfaction with their work. The correlation between collaboration culture and engineering output quality is well-established.
Psychological safety — the belief that team members will not be punished for speaking up with questions, concerns, or mistakes — was identified by Google's Project Aristotle research (2015) as the single most important factor differentiating high-performing from low-performing engineering teams, ahead of team composition, individual skill, or process. Engineers who feel psychologically safe raise problems earlier, take calculated technical risks, and learn faster from failures.
"If you want to build a ship, don't drum up people to collect wood and assign them tasks and work, but rather teach them to long for the endless immensity of the sea." — Antoine de Saint-Exupery, commonly cited in engineering leadership contexts regarding intrinsic motivation
Blameless postmortems are a cultural practice that operationalizes psychological safety in the context of production incidents. Rather than finding who made a mistake and holding them responsible, blameless postmortems ask what systemic conditions allowed the mistake to occur — inadequate testing, unclear runbooks, insufficient monitoring — and address those conditions. John Allspaw at Etsy popularized this approach and documented its impact on incident recovery times and engineering trust.
The Technical Interview: What to Expect
The software engineering technical interview at major technology companies has a distinctive format that is worth understanding whether you are preparing to interview or trying to understand why engineers spend time on "LeetCode problems."
Coding interviews (algorithm and data structure problems): Candidates are given a programming problem and asked to solve it in 30-45 minutes while explaining their reasoning aloud. Problems are drawn from classic computer science topics: arrays and strings, trees and graphs, dynamic programming, sorting and searching. The stated goal is to assess analytical thinking and problem-solving process; the practical effect is that preparation for these interviews requires significant specific practice.
System design interviews: Candidates are asked to design a system (e.g., "design a URL shortener," "design Twitter's news feed," "design a distributed key-value store") and explain their architectural choices over 45-60 minutes. This tests understanding of distributed systems, scalability, and tradeoff reasoning. System design interviews are more open-ended than coding interviews and reward breadth of knowledge.
Behavioural interviews: Past-experience questions assessing collaboration, conflict resolution, impact, and leadership. At Amazon, these are structured around the company's Leadership Principles and use the STAR format (Situation, Task, Action, Result).
The disconnect between interview skills and job performance is well-documented and frequently criticized. LeetCode proficiency does not predict software engineering effectiveness, and many strong engineers perform poorly on algorithmic interviews through lack of specific preparation. However, the major technology companies have maintained this format because it provides consistent evaluation at scale, even if it is imperfect.
The Management Track vs the Individual Contributor Track
After reaching senior engineer level (L5), software engineers face a career fork: the management track (leading people) or the individual contributor (IC) track (deepening technical leadership while remaining a practitioner).
Both tracks lead to high compensation and organizational impact. The management track leads to engineering manager, director of engineering, VP of engineering, and CTO. The IC track leads to staff engineer, principal engineer, distinguished engineer, and fellow.
The choice is often framed as a personality question — are you a people person or a technical person? — but Larson (2021) argues this framing is misleading. Both tracks require strong communication, organizational awareness, and the ability to drive outcomes through people rather than purely through individual work. The genuine distinction is whether you want your daily work to be oriented around technical problems (IC track) or organizational and people problems (management track).
Many companies expect senior ICs to develop "technical leadership without management" skills — influencing technical direction through writing and persuasion rather than through authority. This is a genuine skill that requires development; technical depth alone does not produce organizational influence.
How to Become a Software Engineer
Computer science degree: The traditional path provides strong foundations in algorithms, data structures, computer architecture, operating systems, and software design that remain relevant throughout a career. A CS degree from a strong university facilitates entry to FAANG-tier companies through campus recruiting. Approximately 60% of software engineers at major technology companies have a CS or related engineering degree, according to the Stack Overflow Developer Survey 2024.
Bootcamp: Intensive programmes of 12-26 weeks teach practical web development skills and help graduates build portfolios. Bootcamp graduates regularly land roles at technology companies, though typically not at FAANG level without additional preparation. Outcomes vary significantly by programme quality and individual effort. Course Report's 2023 Bootcamp Outcomes Report found a median starting salary of $70,000 for bootcamp graduates who found employment, significantly below the FAANG entry level but competitive for smaller companies.
Self-taught: Many professional engineers are self-taught, particularly in frontend and web development. Free resources (freeCodeCamp, The Odin Project, MIT OpenCourseWare) combined with consistent project building and community participation are viable paths. Getting the first job without a degree or bootcamp credential requires a strong portfolio and network. The Stack Overflow Developer Survey 2024 found that 35% of professional developers are substantially self-taught.
Technical interview preparation — in particular, practising algorithms and data structures problems on platforms like LeetCode — is essentially mandatory for entry into major technology companies, regardless of how you learned to program. Neetcode.io and AlgoExpert are commonly used structured preparation platforms.
The Impact of AI Coding Tools
The introduction of AI coding assistants — GitHub Copilot, Cursor, and similar tools — has materially changed software engineering workflows. GitHub's 2023 productivity study found that developers using Copilot completed coding tasks 55% faster than those who did not, and reported higher job satisfaction due to spending less time on boilerplate code.
The implications for the field are actively debated. Some predictions of mass displacement have not materialized; instead, AI tools appear to be changing the distribution of work: reducing time on routine implementation while increasing the proportion of time spent on design, architecture, and code review (which requires judgment that current AI tools cannot replace). The most likely near-term effect is that AI coding tools raise the productivity ceiling for experienced engineers significantly while lowering the barrier to entry for routine tasks — shifting what distinguishes strong engineers from average ones toward judgment, communication, and system design.
"AI will not replace software engineers. Software engineers who use AI will replace software engineers who don't." — A widely circulated framing in the engineering community, attributed to various sources but reflecting a broad consensus as of 2024.
Practical Takeaways
The engineers who advance fastest are typically not the ones who write code most quickly — they are the ones who communicate clearly, make thoughtful decisions about tradeoffs, help their colleagues succeed, and understand enough about the business context to work on what actually matters. Technical skill is necessary but not sufficient at L5 and above.
On-call rotations, code reviews, and design documents are not interruptions to the real work of engineering — they are the real work. Treating them as second-class to coding output is a misunderstanding of where engineering value is actually generated at scale.
The dual career ladder (management vs IC) means that people who love technical work are not forced into management to advance. But staying on the IC track at senior levels requires developing influence skills — writing, teaching, and organizational navigation — that are not emphasized in most programming education.
References
- Larson, W. "An Elegant Puzzle: Systems of Engineering Management." Stripe Press, 2019.
- Larson, W. "Staff Engineer: Leadership Beyond the Management Track." Independently published, 2021.
- Levels.fyi. "Software Engineer Salary Data by Level." Levels.fyi, accessed 2024.
- Bureau of Labor Statistics. "Occupational Outlook Handbook: Software Developers." BLS.gov, 2023-24 edition.
- Fowler, M. "Refactoring: Improving the Design of Existing Code." Addison-Wesley, 2nd edition, 2018.
- Google. "Site Reliability Engineering: How Google Runs Production Systems." O'Reilly Media, 2016.
- McConnell, S. "Code Complete: A Practical Handbook of Software Construction." Microsoft Press, 2nd edition, 2004.
- DeMarco, T., & Lister, T. "Peopleware: Productive Projects and Teams." Dorset House, 3rd edition, 2013.
- Bass, L., Clements, P., & Kazman, R. "Software Architecture in Practice." Addison-Wesley, 4th edition, 2021.
- Stripe. "The Developer Coefficient: Software Engineering and the GDP." Stripe research report, 2019.
- Evans, E. "Domain-Driven Design." Addison-Wesley, 2003.
- Stack Overflow. "Developer Survey." Stack Overflow, 2024.
- GitHub. "The Impact of GitHub Copilot on Developer Productivity and Happiness." GitHub research report, 2023.
- Google. "Project Aristotle: Understanding Team Effectiveness." re:Work, Google, 2015.
- Atlassian. "Teamwork State of the Industry 2023." Atlassian, 2023.
- Allspaw, J. "Blameless PostMortems and a Just Culture." Code as Craft blog, Etsy, 2012.
- Course Report. "2023 Coding Bootcamp Outcomes and Demographics Study." Course Report, 2023.
- Lamport, L. "Turing Award Lecture: The Computer Science of Concurrency: The Early Years." Communications of the ACM, 2015.
Frequently Asked Questions
What does a software engineer actually do beyond writing code?
Code writing typically accounts for only 30-50% of a software engineer's time. The rest involves code review, system design, debugging production issues, attending planning meetings, writing documentation, mentoring colleagues, and participating in on-call rotations. Senior engineers spend progressively more time on architecture and cross-team coordination.
What is the difference between L3, L4, and L5 engineers at FAANG companies?
At Google, Meta, and similar companies, L3 is entry-level (new graduate), L4 is a confident independent contributor, L5 is a senior engineer who leads projects and mentors others, L6 is a staff engineer setting technical direction across multiple teams, and L7+ is principal or distinguished engineer with org-wide or company-wide impact.
What is the difference between frontend, backend, and fullstack engineers?
Frontend engineers build what users see and interact with — browsers, mobile apps, and UI components. Backend engineers build server-side logic, APIs, databases, and infrastructure. Fullstack engineers work across both. In practice, most engineers specialise with some fluency in adjacent areas, rather than being equally expert in all.
How much do software engineers earn at FAANG companies?
At Google, Meta, Amazon, Apple, and Netflix, L3 engineers earn \(150,000-\)200,000 in total compensation including equity and bonus. L4 earns \(200,000-\)280,000. L5 earns \(280,000-\)400,000. L6 staff engineers can earn \(400,000-\)600,000. These figures are significantly above industry average and reflect Silicon Valley market rates.
Do software engineers need a computer science degree?
A CS degree is not strictly required. Many working engineers entered through bootcamps, self-study, or adjacent degrees in maths or physics. However, a CS degree provides strong foundations in algorithms, data structures, and systems that remain relevant for technical interviews at top companies and for senior system design work.
