Discovering roles and possibilities for newcomers to the world of software, data, and ML.
2023-06-06
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.
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.
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!
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.
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.
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:
Sample projects:
Title keywords: analytics, data, ETL, ELT, pipelines, modelling, warehouse
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:
Sample projects:
Title keywords: data, analyst, business intelligence, business, product, growth
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:
Sample projects:
Title keywords: data, scientist, analyst, computational, statistician, quantitative, predictive, modeller
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 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:
Sample projects:
Title keywords: machine learning, scientist, researcher, research scientist
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:
Sample projects:
Title keywords: machine learning, engineer, research engineer, applied research scientist
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.
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:
Sample projects:
Title keywords: software, backend, product, growth, API
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:
Sample projects:
Title keywords: software, backend, AI engineer, AI product, applied AI
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:
Sample projects:
Title keywords: software, backend, integrations, connectors, connectivity, third-party, authentication, identity
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:
Sample projects:
Title keywords: software, frontend, web
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 (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:
Sample projects:
Title keywords: software, infrastructure, platform, developer experience, DX, DevTools, tooling, build and release, DevOps
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:
Sample projects:
Title keywords: software, data, infrastructure, platform, operations, DataOps, lake, lakehouse
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:
Sample projects:
Title keywords: software, machine learning, platform, infrastructure, operations, MLOps
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.
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:
Sample projects:
Title keywords: software, backend, infrastructure, scalability, scalable data, streaming, database
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:
Sample projects:
Title keywords: software, infrastructure, platform, systems, site reliability, reliability, production, operations, DevOps, performance
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:
Sample projects:
Title keywords: machine learning, systems, accelerators, model serving, inference, optimisation, performance, compiler, kernel, runtime, GPU, CUDA
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.
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.