Most people become software developers through one of four routes: a computer science or related degree, teaching themselves, a bootcamp, or moving sideways from a nearby job such as QA, IT support or data analysis. All four can work, but none of them gets you hired on its own. What gets you hired is evidence that you can build, debug and ship software with other people.
This guide covers each route honestly, what employers check at each stage of hiring, the kind of portfolio that changes a recruiter's mind, and what the first job is really like.
Pay and outlook for software developers
Software developers are one of the largest professional occupations in US tech. The Bureau of Labor Statistics counts about 1.7 million software developer jobs in 2025, with a median annual wage of $135,980 in May 2025. The lowest 10 percent earned less than $82,460 and the highest 10 percent earned more than $214,670.
The BLS projects employment of software developers, quality assurance analysts and testers to grow 10 percent from 2025 to 2035, with about 106,100 openings a year on average. Many of those openings come from people leaving the occupation or retiring, not only from new positions.
The neighboring occupations tell you something about where the work is heading:
| Occupation (BLS title) | Median pay, May 2025 | Projected change, 2025 to 2035 |
|---|---|---|
| Software developers | $135,980 | +10% |
| Software QA analysts and testers | $104,300 | +6% |
| Web developers | $92,650 | +4% |
| Computer programmers | $100,390 | -7% |
The contrast between developers and computer programmers is the useful part. The BLS expects programming work to keep being automated, including with AI, and expects some higher-skilled programming tasks to shift to software developers. In plain terms: the job of turning someone else's specification into code is shrinking, while the job of deciding what to build, designing it and owning it in production is growing. Aim your preparation at the second job.
A median is a midpoint across the whole workforce, including people with 20 years of experience. Your first offer will depend heavily on employer type, location and industry. Among the top-employing industries the BLS lists, software publishers paid the highest median for developers, at $164,550.
The four routes, compared
The BLS describes a bachelor's degree in computer and information technology or a related field, such as engineering or mathematics, as the typical entry requirement, and notes that some employers prefer a master's. In practice, plenty of working developers took a different path. The question is what each route gives you and what it leaves out.
| Route | What it gives you | Where it falls short |
|---|---|---|
| Degree (CS or related) | Fundamentals, access to internships and campus recruiting, a credential that clears résumé filters | Four years and real cost; coursework rarely teaches working in a large existing codebase |
| Self-taught | Low cash cost, full flexibility, proof of self-direction | No structure, no external signal, hardest route to get past a résumé screen |
| Bootcamp | Structure, pace, a cohort and some career support | Short; quality varies a lot between programs; graduates often have similar-looking portfolios |
| Adjacent role first | A salary while you learn, domain knowledge, internal transfer options and references | Depends on an employer willing to let you move; can take a year or more |
Degree
If you are 18 to 22 and can afford it, a degree is still the lowest-risk path. The value is less in any single course and more in the internships it gives you access to. Internships are the clearest bridge into a first developer job, and the BLS specifically mentions them as a way students gain experience. If you are in a degree program now, treat landing an internship before your final year as the main goal.
Related degrees (math, physics, electrical engineering, statistics) work too, as long as you add serious programming on top.
Self-taught
Teaching yourself works for people who can finish things without external pressure. The risk is not learning to code; free material for that is plentiful. The risk is spending a year learning and then having nothing a hiring manager can evaluate. If you go this way, set a public output target from week one: a deployed project, a merged open source pull request, a written explanation of something you built.
Bootcamp
A bootcamp buys you structure and speed, not a job. Before paying, ask for outcome numbers and how they are defined: what counts as "placed," over what time window, and whether teaching assistant jobs at the bootcamp itself are included. Ask to talk to graduates from the last two cohorts, not ones the school picks. If a program will not answer clearly, that is your answer.
Adjacent role first
This is the most underrated route. People move into development from software QA, technical support at a software company, IT support, systems administration and data analysis. The advantage is simple: an internal hiring manager already knows your work and how you behave on a team, which removes most of the risk a stranger's résumé carries.
If you take an adjacent job, pick one where you are close to the code. A QA role on a product team, where you read code, write automated tests and file precise bug reports, gets you much closer than a help desk role with no contact with engineering. Tell your manager early that you want to move into development, and start doing small pieces of developer work (test automation, internal scripts, small bug fixes) with permission.
What employers screen for
Hiring for junior developers usually runs through three filters. Each one tests something different.
The résumé screen. A recruiter or applicant tracking system checks whether you match the posting. A degree, a past internship or a relevant job title clears this filter fastest. Without those, you need specific project lines that use the posting's own language ("built a REST API in Python with PostgreSQL, deployed on AWS") and links that work.
The technical screen. This is a coding exercise, a take-home project or a live session. It checks fundamentals: data structures, basic algorithmic thinking, reading and changing unfamiliar code, writing tests, SQL, Git, and how HTTP and web APIs work. Interviewers watch how you reason when you are stuck as closely as whether you finish.
The team interview. Here they are asking whether they want to work with you. Can you explain a technical decision and its trade-offs? Do you ask clarifying questions before writing code? Can you take feedback on your code without getting defensive?
AI coding assistants are now a normal part of many developers' toolkits. Use them while you learn, but make sure you can explain and modify every line you submit, because anything in your portfolio or take-home is fair game in an interview.
A portfolio that actually helps
Most junior portfolios fail for the same reason: they show that the candidate followed tutorials. A hiring manager has seen hundreds of to-do apps, weather apps and movie search apps built from the same video course. They prove almost nothing.
What helps:
- Two or three finished projects, not fifteen half-finished ones. One solid project with a real user beats a long list of repositories.
- Something someone actually uses. A tool for a club, a small business, your current employer or yourself that solves a real problem. Real users create real bugs, and fixing them is what the job is.
- Deployed and running. A live URL, plus instructions to run it locally. If it cannot be run, it cannot be evaluated.
- A README that explains decisions. What the project does, why you chose the stack, what you would change, known limitations.
- Tests and a sensible commit history. These show working habits, which is what a team is hiring.
- One merged contribution to an open source project. Even a small fix proves you can read someone else's codebase, follow their conventions and get a change through review.
What to skip: certificates of completion from online courses (fine for your own learning, weak as evidence), a dozen languages listed at "beginner" level, and elaborate portfolio websites. A plain page with three good project links is enough.
What the first job is really like
The first year is mostly reading code rather than writing it. You will fix bugs, add small features to systems other people designed, write tests, review pull requests and learn the deployment process. The BLS duty list for developers reflects this: alongside design, it includes software maintenance, testing and documenting systems for future upgrades.
A few things that matter more than new developers expect:
- Mentorship beats a small pay difference. A team that reviews your code carefully will make you better faster than a slightly higher salary at a team that leaves you alone.
- Asking good questions is a skill. Spend a reasonable amount of time trying first, then ask with specifics: what you tried, what you expected, what happened.
- Production is where you learn. Seeing how your code behaves under real traffic, how incidents are handled and how releases go wrong teaches things no course covers.
Expect the job search itself to take longer than the learning felt like it should. Junior roles get many applicants. Referrals, internal moves and direct contact with hiring managers convert far better than cold applications, so spend part of every week on people, not only on job boards.
Where it leads
The BLS lists project management specialists and computer and information systems managers as common advancement paths. Many developers stay technical instead, moving toward senior and staff engineering roles, or specializing in areas such as security, infrastructure or data. A developer who has worked in production systems also has a short step into information security or data science if those interest them later.
The next step this month
Pick your route based on your real constraints: time, money and whether you have a job you can grow out of. Then build one small project that a real person uses, deploy it, write a README that explains your decisions, and ask a working developer to review the code. That single loop, repeated two or three times, is the core of most successful career changes into software.