Introduction

If you're new to the world of software, it's easy to get overwhelmed by the career possibilities. You can choose to focus on software engineering, big data, machine learning, and more. Within these areas, there are many different roles, each filling different functions and requiring different skills. It's hard to know what's out there, what's possible, and what you might enjoy.

Recently there's been a lot of interest in the data and ML part of the software space in particular. Early career folks who ask me about roles are often surprised to learn that there are more options than just being a data scientist or a machine learning engineer! This is especially true if you're interested in the challenges that come from data generally, which are relevant to software roles across the spectrum.

Software is complicated, and no matter what type of software you're working on, there are many different types of work required to get things done. Even at companies that focus on data and machine learning (ML), there are roles that only involve some data or ML knowledge, and even roles that don't involve it at all! Therefore, talking about the roles in data and ML in particular ends up including most of the roles in software in general.

Since I've been working in the field for a few years now, I want to share what I've learned and help you make an informed decision about your career path. I will be focusing on "technical" roles in this post, since it's about software-related careers, but tech companies also have roles in management, product, sales, design, and other areas.

Update (May 2024): I've updated this post to separate some broader roles into more specific focuses common in industry. I've also tried to simplify and clarify the core content, reducing the length and cutting the fluff.

Disclaimers

This post is aimed at people entering the world of software, regardless of their other prior experience. As a result, some of the roles I'll be discussing are not entry-level, but may be accessible to readers with relevant experience.

This post will be full of generalisations. This is because roles, titles, responsibilities, and skills vary widely between companies. Additionally, the lines are fuzzy and continually changing. It's hard to essentialise which roles even exist. Roles are even impacted by which other roles exist at a company!

This is just a general overview of how I personally have seen roles differentiated in the industry. I'm drawing on my experience, coworkers' and friends' experiences, and job postings I've seen. However, I am still biased by my perspective.

For the sake of this post, I've also chosen to use some uncommon titles. This serves primarily to distinguish between different focuses within a broader role, e.g. "backend product engineer" vs "backend scalability engineer". However, I've also listed common title keywords for each role.

Use this post as a starting point so you know what to research further. I want to show you what's possible but not widely known; I'm not claiming to tell you what's universally true.

My experience

I know what you're thinking: "Who are you to tell me about all these different software roles?" You've got me, I'm not a vampire. I haven't lived for a thousand years, and I haven't worked in every role I'll be discussing. However, I have worked in a few different roles in this space, and through those experiences, I've also worked with many other roles.

I started my career as an end-to-end data product engineer, where I covered the whole data stack: data collection, data cleaning and transformation, software development, dashboarding, and data science. I then moved into more typical data engineering, which was really more of an analytics engineering role, where I worked with other developers such as data scientists.

Next I took a hard pivot into backend engineering at a foundation model company, where I worked on the core product. It was a small startup at the time, so I ended up collaborating with not only other product engineers, but also infrastructure engineers and folks from across the modelling side of the company.

Finally, I'm now working as a data platform engineer at an ML-powered drug discovery company, where I build and maintain the data infrastructure. And on top of that, I've spent time broadening my understanding of other roles through reading, online courses, and side projects.

Update (June 2025): I now work as a backend engineer at a small startup again. This time, my main focus has been on systems, which I'll discuss in more detail later. I'd been wanting to work on systems for a while, but I didn't view it as distinct from platforms until I started my last role. So if you read this post, it might save you from making a similar wrong turn!

Domains

There are a variety of roles in the software field, each of which has a unique focus and skillset. I like to categorise them into five domains, or areas of work: insights, models, products, platforms, and systems. Roles in the same domain share similar high-level deliverables and/or problem statements, but perform different work. This may mean collaborating together on shared projects, or simply solving similar problems towards different end goals.

You can think of these domains as different "teams" or "departments" within a company, although in practice, they may not be organised this way. In particular, roles in the "platforms" and "systems" domains are often colocated with the other roles they support, rather than being their own centralised teams. These are also not hard divisions; some roles can cross boundaries between domains.

Insights

Imagine that you own a business in any tech-related industry. It could be anything from an international video streaming service to a small business with an e-commerce site.

How do you make decisions about your business? Do you just go with your gut and guess about everything? Even if you have a superhuman intuition, that won't scale across all the decision makers in your company, and all the decisions that need to be made.

Insights teams support data-driven decision-making, taking the guesswork out of business decisions. They do this by first gathering and maintaining data for analytics purposes. Then they analyse and interpret the data to derive insights. Finally, they surface these insights to inform business decisions.

Analytics Engineer

The primary goal of analytics engineers is to provide clean, reliable data from all relevant sources. Without data, there is nothing to draw insights from or to train models on. Therefore, analytics engineers enable both insights and models teams to worry less about the data and more about what they can do with it.

Similarly, analytics engineers may be stakeholders for data platform engineers, who build the systems that analytics engineers use to gather and transform data. In smaller companies, this work is often combined into a single "data engineer" role.

Responsibilities:

Manage and organise analytics datastores.
Build pipelines to transport and transform data.
Ensure data accuracy and reliability.

Sample projects:

Build a pipeline to ingest, process, and store data from multiple sources for downstream analytics.
Create views which connect, aggregate, and summarise data for business users.
Maintain data catalogue entries to ensure that data is discoverable and understandable.

Title keywords: analytics, data, ETL, ELT, pipelines, modelling, warehouse

Data Analyst

Organisations can collect all the data they want, but it's only valuable if they can derive insights from it. That's where data analysts come in.

Data analysts often work with business stakeholders to understand their needs and then use data to answer their questions. They are sometimes described as "data storytellers" because they identify and communicate the narratives that are hidden within data.

Although data scientists generally have a broader skillset than data analysts, it's not inherently a more senior role. It's very possible to have a successful career as a data analyst without becoming a data scientist. However, it's typically easier to get an entry-level job as a data analyst than a data scientist.

Responsibilities:

Discover, process, connect, analyse, and visualise data.
Present insights and trends to provide visibility and inform business decisions.

Sample projects:

Analyse customer journeys and purchasing patterns to improve marketing strategies.
Conduct A/B tests to evaluate the effect of a website redesign on user engagement and conversion rates.
Create dashboards aimed at executives to track key performance indicators (KPIs) and business metrics.

Title keywords: data, analyst, business intelligence, business, product, growth

Data Scientist

Similar to data analysts, data scientists work with data to derive insights. However, data scientists focus more on statistical techniques and machine learning algorithms, and less on visualisation and business understanding.

There is some overlap between data scientist and ML scientist skillsets, and some companies use the titles interchangeably.

Responsibilities:

Apply statistical techniques and classical machine learning algorithms to identify patterns in datasets.
Apply predictive analytics to forecast future behaviour or reason about the unknown.
Present insights and trends to provide visibility and inform business decisions.

Sample projects:

Segment customers by behaviour to improve marketing strategies.
Classify user feedback by sentiment to track overall satisfaction.
Forecast inventory needs based on seasonal trends and historical sales data.

Title keywords: data, scientist, analyst, computational, statistician, quantitative, predictive, modeller

Models

Machine learning (ML) is all the rage these days. Large language models (LLMs) in particular have captured the world's imagination and are proving to have real value.

But ML is about more than just user-facing chat and image generation tools. It has a wide range of applications within companies, whether it's supporting ML-powered applications, improving user experience more subtly, or just increasing operational efficiency.

Models teams create and support these in-house ML models and services. They design and train models, then productionise and integrate them. These models are usually, but not always, deep learning models.

Models teams are often distinct from insights teams due to having different goals. Machine learning models can also be used for insight generation, and data scientists sometimes build models as well. However, models built by a dedicated models team are often viewed as products or services, and the goal is to improve them for downstream usage.

Machine Learning Scientist

Machine learning scientists focus on research and experimentation. For example, they might experiment with different model architectures to see which one performs best. This role is typically only found at companies that build their own models from scratch and have a deep incentive to innovate at the bleeding edge.

Responsibilities:

Research and advance the state of the art in machine learning theory.
Experiment with novel architectures, optimisation methods, and other approaches.
Evaluate model accuracy, potentially with human feedback.

Sample projects:

Determine how to optimally balance different datasets and reduce bias for model training.
Develop a model for generating high quality synthetic training data.
Evaluate model safety and robustness by testing against adversarial examples.

Title keywords: machine learning, scientist, researcher, research scientist

Machine Learning Engineer

Machine learning engineers (MLEs) focus on productionising and integrating the models that ML scientists develop. Their primary focus is on making models work in the real world, rather than research and experimentation. As a result, their skillset is focused more on practical software engineering and less on mathematics and theory.

Smaller companies may have only ML scientists or only ML engineers, with the title depending on the primary focus of the role. In this case, people in these roles may be responsible for both types of work. Smaller companies may also not have ML platform engineers, with ML engineers performing that work instead.

Responsibilities:

Build and deploy machine learning models.
Productionise and standardise research demos and code.
Integrate models within larger applications and products.

Sample projects:

Implement a recommender system to personalise each user's suggested content based on their behaviour.
Implement object detection and classification in real-time video streams for self-driving cars.
Build a pipeline to automate continuous model training and deployment as new data comes in.

Title keywords: machine learning, engineer, research engineer, applied research scientist

Products

Okay, so now we have people who make sense of data and people who build models. But to what end? Where is the data being collected, where are the insights being applied, and where are the models being used? Software companies have to make money somehow, and in most cases, this means building products for customers.

Product teams build and maintain applications and services that comprise the core product of the company. These are often user-facing applications, whether the company's users are consumers, other businesses, or internal employees. For example, Meta's core products include Facebook, Instagram, and WhatsApp.

Although products may be built around or otherwise incorporate ML models, the focus of product teams is on the user experience and the functionality of the application. They can treat the model as a black box API, whether it's an external service or built in-house.

Backend Product Engineer

User-facing applications usually have two parts: the frontend, which users interact with, and the backend, which implements the application's logic and interacts with its database. There is usually a lot of different work to do in the backend, so companies often have different roles or teams for each focus area.

Backend product engineers typically work on the type of functionality that directly supports the usage of the application, enabling it to be "productised". Their work is often more user-centric than other backend engineers, and they may work more closely with frontend engineers. Their responsibilities can vary widely depending on the company and its product.

Responsibilities:

Develop the backend for user-facing applications.
Develop services to perform work and interface with other systems.

Sample projects:

Implement user authentication and authorisation for a social platform.
Build a service which sends notifications to users when new content is available.
Implement payment processing and subscription management for a SaaS product.

Title keywords: software, backend, product, growth, API

Backend AI Engineer

With the surge in interest in AI, in particular transformer and diffusion models, many companies are building AI-driven products and services. This has created a niche for backend engineers who are familiar with the basics of AI models and tooling, and how to best integrate AI into applications. I consider these engineers to also be product-focused since their work is also often user-centric, but with a specialisation in AI features.

It's unclear whether this role will continue to exist as a distinct specialisation, whether familiarity with AI will become a common skill for backend engineers in general, or whether AI tooling will become so simple that integration will be as basic as using any other API or library. Though programming is very backend-oriented, effectively integrating AI benefits from having a "data mindset", especially when it comes to data quality and model evaluations. For now, there are plenty of companies hiring for "AI engineers".

Responsibilities:

Integrate AI models and tooling into applications.
Develop new AI-driven features and services.
Design and implement the architecture necessary to support these capabilities.

Sample projects:

Enhance existing search functionality with semantic search capabilities.
Create an AI agent which can asynchronously perform tasks on behalf of users.
Customise the application behave differently based on previous interactions with the user.

Title keywords: software, backend, AI engineer, AI product, applied AI

Backend Integrations Engineer

If you scroll down on the homepage of most software products, you'll often see a section showcasing the various other products that product works with. Customers use a lot of different products, so it's often important for them to choose products which are compatible with each other. Integrations are often a huge unlock for larger enterprise customers in particular, who are willing to spend serious money to avoid the internal engineering work, and politics that comes with securing those resources, to build their own integrations.

Compatibility can be a key differentiator when the core technology of a product is commodified or there are competitors in the space. Some products also rely on integrations to actually have value; i.e. the product's main selling point is that it enables integration between systems.

Backend integrations engineers are the people who build these integrations between systems. This may enable reading data from external systems, or performing actions within them. A strong intuition for effectively transforming and organising data is beneficial, because data is essentially the way every system communicates.

Responsibilities:

Integrate external systems into the product to support customer needs and business features.
Securely manage and update user credentials across a variety of authentication methods.
Build internal utilities and abstractions that simplify managing many different integrations.

Sample projects:

Build a webook processing service to ingest real-time data and events.
Develop a migration tool to help customers import their data from competitors.
Design a framework which enables users to create custom integrations.

Title keywords: software, backend, integrations, connectors, connectivity, third-party, authentication, identity

Web Frontend Engineer

Web frontend engineers work on the part of the product that users directly interact with. Specifically, they work on the user interface (UI) and user experience (UX) of web applications. This includes the layout, visual design, and interactivity of the application, as well as the performance and accessibility of the web code. Frontend engineers who design the UI and UX of mobile applications, rather than web applications, are called "mobile engineers".

Frontend engineers often work closely with designers, who decide on the look and feel of the application along with the user flows, in order to best implement the designer's vision in code. They also work closely with backend engineers, who provide the data and logic that the frontend needs to render and interact with.

Engineers who work on both the frontend and the backend are called "fullstack engineers". They are often especially sought after as early engineers or technical co-founders at small companies. This is because most (but not all) products have a significant frontend component, and it's very useful to have both frontend and backend skills in one person in early stages.

Responsibilities:

Develop the web frontend for user-facing applications.
Ensure that the web frontend is accessible, performant, and user-friendly.

Sample projects:

Build a real-time chat feature which displays messages immediately without requiring a page refresh.
Build an interactive map which allows users to explore geospatial data.
Enable the web application to work offline and sync data when reconnected.

Title keywords: software, frontend, web

Platforms

A company full of software people will generate a lot of code and build a lot of systems. You can let them run around wild, but it's likely that they will create a lot of duplicated work, inconsistent systems, and inefficient processes. This is where platform engineers come in.

Platforms teams build the systems, services, and patterns which support operations, analytics, and machine learning. They design and maintain foundational and operational infrastructure (infra), develop services for internal or external use, and build tooling and guardrails to increase developer productivity. They may focus on supporting the core products of the company, or on internal tooling. Most companies' infra is cloud-based, but some have on-premises (on-prem) or hybrid (a mix of cloud and on-prem) infra.

The goal of all platform engineers is to reduce toil in human workflows and reduce load on systems. In essence, they enable the work of the other roles we've discussed so far. Platform engineers may be part of a centralised platform team, or they may be colocated with the teams they support.

Platform engineering roles are often given "Ops" titles: DevOps Engineer, DataOps Engineer, MLOps Engineer. This is a trend that originally started with the "DevOps" title, and has since been applied to other roles. However, DevOps (and by extension, DataOps and MLOps) is a set of practices and principles that can be applied to any role, not a role in itself.

Developer Experience Engineer

Developer experience (DX) engineers typically work on enabling other engineers to build and deploy their services. Their main goal is to increase developer productivity by providing self-service tooling and automating processes.

Responsibilities:

Develop and maintain CI/CD pipelines to automate code integration and deployment.
Build and maintain development environments and workflows to reduce friction for engineering teams.
Manage and provision resources using Infrastructure as Code (IaC).

Sample projects:

Create a self-service platform which enables developers to deploy and manage their own services.
Automate IaC workflows by enabling developers to provision resources through pull requests (GitOps).
Enable developers to easily run and test their changes in a production-like environment.

Title keywords: software, infrastructure, platform, developer experience, DX, DevTools, tooling, build and release, DevOps

Data Platform Engineer

Data platform engineers specialise in data infrastructure, which is built on top of foundational infrastructure. This means that "infrastructure engineers" build the underlying systems which data platform engineers use to build their own systems. As a result, data platform engineers work more closely with insights teams than other platform engineers do.

Responsibilities:

Manage systems and infrastructure that support data workflows end-to-end.
Build integrations for data sources and sinks, simplifying data access and retrieval.
Integrate and maintain tools for data governance, workflow orchestration, data asset generation, and data quality.

Sample projects:

Create a platform in which users can design and execute custom workflows with high resource requirements.
Implement a data catalogue which enables easy discovery and understanding of data assets and their lineage.
Design a data lake architecture for storing and processing large volumes of unstructured data.

Title keywords: software, data, infrastructure, platform, operations, DataOps, lake, lakehouse

Machine Learning Platform Engineer

ML platform engineers are similar to data platform engineers, but they focus on ML infrastructure rather than data infrastructure. They also build on top of foundational infrastructure, and they work closely with models teams to support their work. The data platform also supports the ML platform to a degree by providing the data used by the models.

Responsibilities:

Manage systems and infrastructure that support ML workflows end-to-end.
Manage model deployments, updates, and versioning.
Monitor model performance and data drift.

Sample projects:

Implement a monitoring system which sends an alert if model performance dips below minimum thresholds.
Automatically register trained models to a catalogue which enables easy comparison, sharing, and reuse of models.
Build integrations between different ML tools and platforms to reduce friction in workflows.

Title keywords: software, machine learning, platform, infrastructure, operations, MLOps

Systems

Imagine that your company has built a successful social media application which supports posts and likes. What happens when one user's posts are a million times more popular than the average user? How do you serve that popular user's posts and store who liked them? What happens if a million people suddenly start posting at the same time? How do you avoid losing new posts if the server they were sent to goes down? What about a year later when you're paying for the storage of posts nobody reads? How do you optimise cost without just deleting them?

When a product or feature is first being created, the main goal is usually to get it working and to iterate until finding product-market fit (PMF). Gaining traction comes with increased usage, meaning handling more data in both volume and velocity. Increased data can put a strain on the underlying systems, which may degrade performance or cause costs to skyrocket. You may be able to naively increase resources as much as you need to while you scale to meet demand, but you will pay for it, literally. However, the very thing that makes software businesses so disruptive is that revenue scales non-linearly with expense, i.e. 100x the revenue should result in way less than 100x the expense.

Systems teams optimise systems (you guessed it!) to handle the increased load that comes with growth. Using resources efficiently and designing more suitable systems is how you reduce cash burn and increase reliability. It can also enable new features and products which would otherwise not be technically possible or financially feasible. In some cases, the product itself may be a scalable system sold as infrastructure for other companies, such as a stream processing system or scalable database. This work requires a level of systems thinking and experience that often isn't a great fit for early career folks, but can be grown into.

Backend Scalability Engineer

How a backend system is architectured often has a huge impact on its scalability. Seemingly innocuous design decisions, or taking the approach which most quickly validates PMF, can lead to technical bottlenecks.

This creates a need for backend engineers with a data and systems focus. While backend product engineers build and improve business features, backend scalability engineers ensure that these features can grow sustainably. It's also common to specialise in particular areas of scalability, such as streaming and/or datastores.

Responsibilities:

Support data-intensive applications, ensuring that backend systems can handle large amounts of data.
Build and maintain systems which enable efficient data storage, processing, and retrieval.
Design and implement highly scalable data services, for use by other parts of the application.

Sample projects:

Implement a caching layer for a social platform to reduce database queries for popular content.
Implement a data streaming pipeline to process application events in real-time.
Build and maintain an object storage system to store and serve large media files.

Title keywords: software, backend, infrastructure, scalability, scalable data, streaming, database

Site Reliability Engineer

Site reliability engineers (SREs) work on ensuring that the company's applications and services are robust and performant. They focus on monitoring, incident response, capacity planning, and disaster recovery to maintain and improve service quality. They aim to make any application resilient to external factors, regardless of how its internal architecture is designed.

Responsibilities:

Implement and maintain monitoring and logging systems to track and alert on system performance and health.
Manage incidents, conduct post-mortems, and mitigate future issues.
Evaluate system performance under load and optimise for scale.

Sample projects:

Design and implement a canary release system to gradually roll out new features and monitor their impact on system performance.
Automate resource scaling based on real-time traffic patterns and usage metrics to optimise performance and cost-efficiency.
Implement a chaos engineering process to test the resilience of services in failure scenarios.

Title keywords: software, infrastructure, platform, systems, site reliability, reliability, production, operations, DevOps, performance

Machine Learning Systems Engineer

Machine learning systems engineers focus on optimising models and their training and serving infrastructure to reduce cost and improve performance. The article 5 Types of ML Accelerators provides a brief overview of the different ways that ML systems engineers can accelerate the ML lifecycle.

This role is typically only found at companies that build very large models, have very high performance requirements, or create accelerators themselves. There may be a focus on optimising inference specifically, because that's typically the main cost driver for production models. Imagine a model which is trained for only two months, then serves millions of requests per day for two years.

Responsibilities:

Reduce computational expense by making models more efficient to train and serve.
Optimise all layers of the networking stack for machine learning, across hardware and software.

Sample projects:

Implement token streaming to incrementally process incoming and outgoing text for a large language model.
Implement data parallelism to process multiple subsets of a large dataset in parallel to accelerate model training.
Optimise a large model for edge deployment by quantising weights and reducing memory usage.

Title keywords: machine learning, systems, accelerators, model serving, inference, optimisation, performance, compiler, kernel, runtime, GPU, CUDA

The world has changed

Despite having only worked in the industry for a few years, I've seen a lot of change. Data and ML are having a "moment", and the current situation for newcomers is not the same as it was for me.

When I was looking for my first job, the vast majority of data science and ML job postings required a Master's degree or PhD, even if the degrees weren't in fields relevant to the role. There is a lot less gatekeeping in job requirements now, and more focus on actual skills. This is great for newcomers, because it means that you don't need to spend more time and money on higher education to get a job in the field.

There are also more jobs in ML now due to the ML boom, but there are fewer jobs in the overall market due to the tech crash. There is also more competition for the ML jobs that exist due to the increased interest in the field. I'm not sure how these factors balance out, but from personal experience, it's still hard for employers to find qualified candidates. You may just have to put in more work to stand out.

The quality of hosted and open-source models has leap-frogged in the past couple years across a variety of domains. This reduces opportunities for ML scientists and ML engineers, especially in smaller companies, as companies can use these models instead of building their own. However, there is still demand for applying transfer learning on top of open-source models.

Business interest in ML has increased, which increases opportunity for roles that build systems around models, open-source or not. There has been a huge boom in startups building new products and services which use ML under the hood. Additionally, business insights can't be easily replaced, so there are still many opportunities there.

Finally, ChatGPT and similar tools are making it easier to learn and work independently. I used to parse through dozens, if not hundreds, of articles to build enough understanding to answer certain questions I'd have. Now, you can just ask ChatGPT and it will give you a comprehensive answer that considers both the context of your question and your level of understanding, and it will do it faster than you can even read its response. (Seriously, if you haven't created an account yet, go do it now.) It's good for getting from 0% to 80% knowledge on a topic, but beyond that, it tends to struggle and mislead.

On the other hand, ChatGPT reduces the need for junior skillsets because intermediate+ engineers can delegate well-defined tasks to ChatGPT instead of junior engineers. However, I think ChatGPT is still a net positive because it enables junior engineers to focus on more interesting work and to learn at an unprecedented speed.

What to do?

Now that you know what's out there, how do you decide what to do? I can't make your decision for you, but I can give you some advice.

First, I suggest that you figure out what role you're most interested in. Even if you don't have the skills for it yet, you can set this role as your north star. Then you can figure out what skills you need to get there, and the path you need to take along the way.

Second, I suggest that you figure out what skills you already have. You may be surprised to find that you already have some skills that are relevant to your desired role. If not, you might instead have skills that are applicable to a different role which you can use as a stepping stone.

Personally, I believe that it's better to be working in a role that you're skilled in at a good company than the role you wanted at a terrible company. Take it from me: I missed out on a ton of career growth and compensation, only to realise that I didn't want the role that I thought I did anyway. But of course, you want to be happy with your role too, and you may be lucky to find the right role at a good company.

Finally, remember that interests change and skills are transferrable. Even if the role you take isn't totally aligned with your interests, it might be the best for your growth and future opportunities. You can potentially transfer roles within a good company too.

You might not have the skills for your desired role right now, but you can get there. I believe in you, and I'm sure that you have people in your life who believe in you too. You've got this!

If you want to build your skills and experience, I suggest that you check out my post on software projects.