Where can my career go?

These are mostly the same job with a fancier-sounding word. 'Engineer' sometimes hints at more focus on design and scale, but many companies use the two words to mean the same thing. Don't overthink it.

This is about how much guidance you need, not just years on the job. Junior means you're still learning the ropes and asking questions. Senior means you handle unclear problems alone, and help others do the same.

Frontend is the part people see and click: buttons, pages, layout. Backend is the engine they don't see: saving data, logins, and the heavy lifting. Full-stack means you do a bit of both.

These are just abbreviations. SDE stands for Software Development Engineer, and SWE stands for Software Engineer. Different companies pick different letters for the same 'person who builds software' role.

These are older, more casual words for someone who writes code. They mean the same thing as developer or engineer — you'll just see them less on modern job titles.

An architect designs the big-picture structure — how systems fit together — more than writing day-to-day code. An engineer builds and maintains things. Architect is usually a senior specialty, not a separate career.

A Tech Lead still codes and makes technical decisions for a team. An Engineering Manager focuses on people: growth, hiring, and one-on-one check-ins. A manager usually codes much less, or not at all.

Staff is a step above Senior on the IC (individual contributor) track. A Senior engineer handles hard problems alone. A Staff engineer influences multiple teams and projects at once, without becoming a manager.

IC stands for Individual Contributor: you grow by getting better at the craft itself. Manager means you grow by helping other people do their best work. Both are valid, well-paid paths. Neither is a demotion or a promotion over the other.

DevOps is a broad culture and role focused on automating how code gets built, tested, and deployed. SRE (Site Reliability Engineer) is a related but more specific job focused on keeping systems up, and recovering fast when they go down. Many companies use the two titles almost interchangeably.

A Data Analyst explains what already happened, using charts and reports. A Data Scientist builds statistical models to predict what might happen next. An ML Engineer takes those models and turns them into real software that runs in production.

QA stands for Quality Assurance — testing software, often by hand, to find bugs before users do. SDET stands for Software Development Engineer in Test — a QA role that also writes code, building automated tests instead of only running them by hand.

This is someone who sets up and manages the servers, storage, and networking an app runs on — but inside a provider's data center (like AWS, Azure, or GCP), instead of physical hardware you own yourself. Think of it as the plumbing an app needs to exist.

A contractor is hired for a project or a fixed period, usually without standard benefits, and can work with several clients at once. Full-time means you're a permanent employee of one company, usually with benefits like health insurance and paid leave.

Lead usually means you guide a specific team or project day-to-day. Principal is a more senior, individual-contributor title, with influence across many teams. It's about depth of impact, not managing people.

This is a newer title for someone who owns a feature end-to-end: talking to users, writing the code, and shipping it, instead of only handling one narrow layer. It overlaps a lot with 'full-stack,' just with more focus on product thinking.

No. Plenty of working engineers are self-taught or came from bootcamps, and many good teams hire on skills, not diplomas. That said, be honest: a degree can make a first job easier to land in some countries and companies, and a few — like big-name firms, or certain visas — still ask for one. Either way, what gets you hired is real projects you can show, and problems you can solve.

It's a rough shorthand for 'how much have you actually done,' not a stopwatch. Someone who built and shipped real things for two focused years can be ahead of someone who coasted for five. Job ads that say '3+ years' are usually describing a level of skill, not a strict rule. If you can do the work, it's often worth applying anyway.

Because there's no industry-wide rulebook. Every company invents its own titles and levels, so 'Software Engineer II' at one place might equal 'Senior' at another. Titles also vary by country. Focus on what the job actually involves — the day-to-day work and the skills — more than the label on it.

At a startup, you usually wear many hats, ship fast, and work with less structure. That's great for learning broadly, but it often means more chaos and risk. At a big company, you go deeper on one area, with more support, mentorship, and process. That's steadier, but slower-moving. Neither is 'better' — they suit different people at different times, and it's normal to switch between them.

No. Titles, typical timelines, salaries, and even which roles exist all vary a lot by country and city. The levels and 'years' shown here are a general guide from the global tech industry. Treat them as a rough map, and check what's normal where you actually plan to work.

This is one of the first engineers at a startup, often hired right after the founders. You build the first version of the product across the whole stack, with almost no structure to lean on. The trade-off is real: you usually get more equity (a share of the company) in return for more risk, longer hours, and less certainty. It's less a fixed 'level' and more a stage — as the company grows, founding engineers often become Staff engineers or leaders, or move on to the next early-stage company.

These are the senior individual-contributor (IC) levels above Senior — you keep building and influencing, without becoming a people manager. Roughly: Staff influences several teams, Principal shapes a whole area, Distinguished shapes the company's technology, and Fellow is the rarest of all. Each step up is much rarer than the last, and many companies stop at Staff or Principal. Treat the top ones as a bonus, not a target you must hit.

A fractional CTO is a senior tech leader who works part-time, often across several small companies at once. An interim CTO is a temporary one, filling the seat until a permanent hire is found. Both are common at startups that need experienced leadership but can't yet justify a full-time executive.

These overlap a lot and the lines are blurry. DevOps focuses on automating how code is built, tested, and deployed. SRE (Site Reliability Engineer) focuses on keeping systems up and recovering fast when they break. A Platform Engineer builds internal tools and 'paved paths' so other engineers can ship easily — more like building a product for developers. Many companies mix these titles freely.

A Software Architect designs the internal structure of a system — how the code and services fit together. A Solutions Architect is usually customer-facing: they design how a product or set of technologies solves a specific client's problem, often during a sale or a big rollout. One looks inward at the codebase; the other looks outward at the customer.

Both are engineers who work directly with customers. A Sales (or Solutions) Engineer supports the sales process with demos, technical answers, and proof-of-concept integrations. A Forward-Deployed Engineer goes further and embeds with a customer to build custom solutions on top of the product, inside their real systems. You need coding skills and people skills for both.

Most companies number their engineering levels, but there's no shared standard, so the numbers mean different things in different places. Loosely: the first working level is entry/junior, the next is mid, and the one after is senior — for example L3/L4/L5 at one company, or SDE I/II/III at another. The exact numbers differ, so ask what a given level actually means rather than assuming it matches another company's.

This is a hybrid that sits between design and frontend. You build polished, pixel-accurate interfaces, design systems (shared, reusable UI pieces), and prototypes. You care about how something looks and feels as much as how the code works — a good fit if you like both design and coding.

This is a security role focused on the app and its code itself, rather than networks or servers. An AppSec engineer reviews code for weak spots, helps developers write safer code, and sets up tools that catch security bugs before they ship. It's a specialty within the broader security field.

These overlap heavily and are often the same work. 'Web Developer' usually points specifically at building websites and web apps. 'Software Engineer' is a broader term that can include web, but also mobile, desktop, and systems that never touch a browser. The 'engineer' label sometimes carries a hint of more pay or scope, but that's about connotation, not a hard rule.

All three work outside a normal full-time job, but the flavor differs. A freelancer usually takes on smaller, hands-on project work, often for several clients. A contractor is typically hired to fill a role for a fixed period, working much like an employee but without permanent status. A consultant is usually brought in for their expertise and advice, sometimes charging more for guidance than for building. The words get used loosely and overlap.

This is someone who runs or heavily contributes to an open-source project — reviewing changes, fixing bugs, and guiding its direction. It can be a paid job, a volunteer role, or a side project, and it counts as real, visible experience. Many people land jobs partly on the strength of open-source work anyone can go and see.

These are the upper rungs of the management track, and each covers more ground than the last. A Director leads several teams through the managers under them. A VP of Engineering sets direction for a large part of engineering and turns company goals into plans. A CTO (Chief Technology Officer) owns the company's overall technology direction. These seats are few by nature — usually only one CTO.

These sound alike but are different jobs. A Product Manager (PM) owns the 'what' and 'why': they decide what to build and why it matters, usually without writing the code. A Product Engineer builds it, and cares a lot about the product and its users while doing so. They work closely together, but one mainly decides and the other mainly builds.

An intern is a student on a short, often paid work placement — usually a summer — to learn and try the job before finishing school. A 'new grad' role is a real, full-time first job aimed at people who just finished a degree or program. Internships are temporary and about learning; new-grad roles are permanent and about starting your career.

A Product Manager (PM) owns the 'why' and 'what': the strategy, the user problems, and which direction the product should go. A Product Owner (PO) is often a specific Scrum role focused on the 'how and when' of building it — owning the backlog and making sure the team builds the right things in the right order. At many companies the two heavily overlap, and one person does both; at others they're separate jobs. It varies a lot by company.

The three PMs, and they're genuinely different. A Product Manager decides what to build and why, based on users and business goals. A Project Manager makes sure one specific project ships on time and on budget — they own the plan, not the product direction. A Program Manager coordinates many related projects or teams toward a bigger goal. Roughly: product owns the 'what', project owns the 'when', program owns the 'how it all fits together'.

These sound the same but point in opposite directions. QA (Quality Assurance) is about preventing bugs — building quality into how the software is made, through good process and testing early. QC (Quality Control) is about catching them — checking the finished product to find defects before it ships. QA asks 'are we building it right?'; QC asks 'did this come out right?' In everyday tech jobs, 'QA' is often used loosely to cover both.

These titles overlap a lot and companies use them loosely. 'Tester' or 'QA Tester' usually points at hands-on testing: running through the app and reporting bugs. 'QA Analyst' often leans toward planning what to test and analyzing quality, still mostly by hand. 'QA Engineer' sometimes hints at more technical work, including writing automated tests. But the lines are blurry — always read what the job actually involves rather than trusting the label.

These are two ways to run a project. Waterfall plans everything up front, then builds it in order — design, then build, then test — like following a fixed blueprint. Agile builds a little at a time, shows it, gets feedback, and adjusts as it goes. Waterfall suits work where the requirements really won't change; Agile suits the common case where you learn what's actually needed as you go.

Both are Agile ways of working, but they're organised differently. Scrum works in fixed time-boxes called sprints (often two weeks), with set roles and regular meetings. Kanban has no sprints — work flows continuously across a board, and the team limits how many things are in progress at once so nothing piles up. Scrum adds rhythm and structure; Kanban is lighter and focuses on smooth flow. Some teams blend the two.

XP is an Agile approach that's heavy on engineering practices, not just meetings. Its habits include pair programming (two people working at one screen), test-driven development (writing the test before the code), and continuous integration (merging and testing small changes often, instead of one big merge later). The goal is to keep the code healthy enough to change safely and often. Teams often borrow XP's technical practices even when they use Scrum for the rest.

A Scrum Master is a servant and facilitator: they help the team work well, run the meetings, and clear blockers, but they don't own the plan or tell people what to do. A Project Manager owns the project's scope, budget, and timeline, and is accountable for delivering it on schedule. One helps the team help themselves; the other drives a plan to a deadline. Some companies blur the two into one role.

A Scrum Master usually helps one team with its day-to-day ways of working. An Agile Coach works broader — across several teams, and often with managers and leaders — to change how a whole part of the organisation thinks and works. It's usually a more senior step: less about running one team's ceremonies, more about shifting habits and mindsets at a larger scale.

These are Scrum's four regular meetings, and each has a clear purpose. Sprint planning: agree what the team will build next. Daily standup: a short daily sync to spot blockers early, not a status report to a boss. Sprint review: show the finished work and gather feedback. Retrospective: the team reflects on how to work better next time. Kept short and useful they help; run out of habit with no purpose, they become the meetings people dread.

'Agile' started as a mindset — build a bit, get feedback, adjust — but it's often reduced to a set of rituals and tools. Be honest about 'fake agile' (also called cargo-cult agile): a team holds all the standups and sprints, yet nothing actually improves, and 'Agile' becomes a way to micromanage or track output. Real agility is about how a team learns and adapts, not how many ceremonies it performs. The word gets used to mean almost anything, so always look at how a team actually works.

These three work with data but do very different jobs. A Data Engineer builds the pipes: the systems that move, clean, and store data so it's reliable. A Data Scientist uses that data to build models that predict what might happen next. A Data Analyst explains what already happened, using charts and reports. Roughly: the engineer plumbs it, the scientist predicts with it, the analyst explains it.

A generalist knows a bit of many areas and can move between them; a specialist goes deep in one and becomes the expert. Neither is better — they fit different teams and stages. 'T-shaped' is the middle most people aim for: broad enough to work across areas (the top of the T) with real depth in one (the stem). You don't have to pick forever — many people widen or deepen over time.

This is the idea that some engineers are ten times more productive than everyone else. It's mostly a myth, and a harmful one. Real, lasting impact comes from making a whole team better — clear code, good reviews, sharing what you know — not from one hero coding alone at 2am. Chasing the '10x' label tends to reward showing off and burnout over the steady, collaborative work that actually ships good software.

On-call means taking turns being the person who gets paged when production breaks — sometimes at night or on weekends. Teams rotate it so no one carries it alone, and healthy teams keep it rare by fixing root causes and often pay or give time back for it. It's a normal part of many engineering jobs, especially in backend, DevOps, and SRE. It's fair to ask about the on-call load in an interview — how often, how noisy, and how it's compensated.

Remote means you work from anywhere, with no regular office. On-site means you're expected in the office most days. Hybrid is a mix — a few set days in, the rest at home. Each has real trade-offs: remote offers freedom and no commute but can feel isolating and needs strong writing; on-site makes mentoring and casual learning easier, which can help early in your career. Policies shift often, so check what a company actually does now, not just what a job ad says.

FAANG is an old nickname for a handful of giant US tech firms (Meta, Amazon, Apple, Netflix, Google), now used loosely for 'big-name tech'. These jobs often pay more and look good on a CV, but they're highly competitive, narrow in scope, and not automatically better for you. Plenty of great engineers build strong careers at smaller companies with more ownership and variety. Chase the work and the growth that fit you, not just the logo.

These are the everyday words of the blockchain world. Web3 is a broad label for apps built on blockchains instead of on one company's servers. A smart contract is a small program that runs on a blockchain and enforces rules automatically — often moving real money, which is why bugs are so costly. A dApp ('decentralized app') is an app whose backend logic lives in those smart contracts rather than on a normal server. It's a smaller, more hype-prone field, so learn it with clear eyes.

All three inform what gets built, but they own different things. A Business Analyst digs into what stakeholders need and turns it into clear requirements for the team. A Product Manager decides what to build and why, and owns the product's direction and priorities. A Data Analyst answers questions with data — charts and reports about what's actually happening. The BA and PM roles overlap a lot at some companies; the Data Analyst is the more distinct one.

All three 'explain things', but for different readers and goals. A Technical Writer creates the docs, guides, and references people use to actually operate a product. A Content Designer shapes the words inside the product itself — button labels, error messages, and flows — so the interface is clear. A Developer Advocate is part engineer, part communicator: they teach other developers through demos, talks, and tutorials, and carry that community's feedback back to the product team.

These describe how much digital content mixes with the real world. VR (virtual reality) replaces your view with a fully virtual world, usually through a headset. AR (augmented reality) adds digital things on top of the real world you can still see, like on a phone screen. MR (mixed reality) blends the two so virtual objects react to your real surroundings. XR ('extended reality') is the umbrella term that covers all of them.