We previously spoke with Anand Safi, Senior Engineering Manager at Mark43, about popular career paths for entry-level software engineers.
He covers the major disciplines that exist today:
- Software Engineering
- Data-Related Roles
- Support-Related Roles
- Quality Assurance
In this article, Anand breaks down common personality traits, daily activities, and common career paths for each of these technology disciplines.
Table of Contents
The conversation below has been edited for length and content.
The traits that best align with each discipline
There’s certainly overlap of key traits that can better position you for success across each of these disciplines. Nevertheless, each discipline favors certain traits over others.
Traits for all Technologists.
Patience
Any discipline that you start with is going to be an incremental development. You won’t pick it up overnight. A mistake that people often make in software engineering is spreading too thin or trying to pick up many things at once. As you navigate the developmental phase in your career, you’ll likely want to learn as much as you possibly can; however, you should pick your battles, stick to your focus areas and get really good at one particular skill to set yourself apart from other software developers.
Curiosity
From an engineering standpoint, oftentimes you are given just the requirements and the user story. From a product standpoint, you are given the designs. But if you’re curious for understanding the why or what the business is trying to solve, then it can be a lot different in terms of what your end implementation looks like. Engineers always talk about the importance of having a customer mindset and thinking from a user perspective so it’s not simply about writing code or implementing the feature. Is it technically feasible? Are there alternate ways to approach it? Being curious will allow you to ask these relevant questions.
Calmness Under Chaos
This trait is directly related to putting code out into production. There will be bugs. There might be issues. You might be a perfect engineer. However, you are human at the end of the day. Something might come up. Something might trigger a complex workflow that leads to an issue and you will need to set out fires, dealing with a war room situation, or address a P1 incident. Just be calm. Don’t give in to pressure because that is when we end up making the not-so-great decisions that make situations more dire.
Those three traits are important for all technology-related disciplines; however, there are two distinct traits that will help you best succeed in data-related roles.
Traits for Data-Related Roles.
Strong Analytical Skills
This is usually implied when discussing data-related roles because you constantly need to read between the lines. You have all of these different metrics being collected, but what do they tell you at a higher level? How can you weave a story out of these different metrics that are being collected?
One classic example is what they call funnel reporting. Say a hundred users started an app. 50 users clicked on “add a product to the cart,” 25 click the checkout button, and then only 10 place the order. These are all metrics that need to be independently analyzed, so being well-versed in data analysis is crucial.
A Questioning Attitude
To put it literally, this simply refers to having a natural skillset around asking business-level questions that you can still answer. For instance, some questions from the example that I gave may include: how much revenue are you losing on the table? How much is the average session time that the user is spending? What pages are they looking at? Is there a particular page view or screen that is causing the maximum bounce rate for users? Having a questioning attitude will help you approach any given metric presented to you from different angles.
Traits for Support Roles.
Regarding support roles, one trait is invaluable:
Strong Communication Skills
With any customer-facing role, having the interpersonal skills to communicate effectively is necessary not only for representing your company but for adequately attending to a customer pain point or question. Likewise, experts in support roles know that they must also be able to quickly and accurately communicate customer feedback to the right team at the company to solve the specific problem areas for their product.
Traits for QA Roles.
Similar to the Support Role, individuals in QA-centric roles need to consider the user perspective in their work. However, there is one important trait that is particularly useful in QA.
Out-Of-The-Box Thinking
A lot of people in each discipline will simply focus on following the happy path: “Okay. This is the requirement that I need to make work. My code satisfies that functional requirement. Now I’m done.” But as a QA, it is your out-of-the-box thinking for weaving up some complex situation that could break that code or some weird configuration of things that will lead to that weird state which the happy path implementation is not addressing. This is an important trait in most careers, but it is required in QA.
A day-in-the-life for each discipline.
Most teams nowadays are Agile in some sense. Therefore, individuals of every major discipline spend roughly 50% of their typical workdays on team rituals. Rituals encompass a myriad of events including team standups, retrospectives, and sprint-related meetings for grooming your backlog. However, the objectives of each ritual varies greatly across disciplines:
- For a software engineer, Agile rituals revolve around implementing new features, trying to maintain existing code, trying to put out a bug fix, pair programming with someone, or just refactoring part of the code.
- For a data analyst, Agile rituals could again focus on analyzing requirements, pulling some metrics, writing SQL queries, or crafting new queries to answer those top-level questions that the business or team have. For a data engineer and data scientist, there’s always work around statistical modeling, reviewing the results from your previous modeling efforts, and fine tuning the models themselves.
- For a support person, continuing to work with a customer in terms of ongoing issues or ensuring new feature rollouts are the primary goals of Agile rituals.
- For a QA engineer, Agile rituals are related to modeling a prediction and evaluating results. In general, these rituals center on designing test plans and test cases for the development work that was just completed.
These team rituals typically take up half of the day. The other half could be around things that naturally come up or just recurring things. There are questions. There is Slack time. There are opportunities to learn new skills and work on things that you like to do. There are breaks in between when you might be pulled into something ad hoc.
If you are working an 8-hour day, you will spend 4-5 hours of heads-down individual contributor work and spend the other 3-4 hours conversing, communicating, collaborating, dealing with things that come up, and a little bit of learning and development. In all of this, you have to remember to take breaks!
The common career paths for each discipline.
In today’s world, there are two main tracks for each discipline. You can either follow the dedicated individual contributor progression track or instead travel down the dedicated management and leadership track. Each track has merit; there is no right or wrong choice. The traditional thinking was that each path would lead to a manager role but that is not necessarily the case anymore:
Software Engineering
After choosing between working in the frontend, backend, or full stack, you will work as a junior engineer for 1-3 years before becoming a mid-level engineer. There is no title for a mid-level engineer; therefore, companies may list mid-level roles as “software engineer” or “individual contributor level 2” or “level 3.” After spending another 1-2 years as a mid-level engineer, you will likely become a senior software engineer or “individual contributor level 4.”
While many choose to remain senior software engineers, the most natural next step is to become a tech lead. Tech leads usually involve making some sort of architectural decision, collaborating with the larger team, and being able to speak about the decisions and choices that you made with your close collaborative stakeholders. This tech lead point is a critical juncture where you could continue on the individual contributor track or instead go into the management and leadership track.
- The IC Track:
Tech leads who desire to remain on the individual contributor track have three higher roles to work toward: Staff Engineer, Principal Engineer, and Fellow. Fellow is the highest possible title on the IC track.
- The Management and Leadership Track:
Tech leads interested in management have five higher roles to work toward: Engineering Manager, Senior Engineering Manager, Director of Engineering, VP of Engineering, and Head of Engineering.
Data-Related Roles
The main career paths in the data discipline are much simpler than software engineering. Whether you start as a data analyst, data engineer, or data scientist, the next step is to become a senior data analyst, a senior data engineer, and a senior data scientist respectively. After 1-2 years in senior roles, you become a lead.
Support-Related Roles
Companies may offer unique career tracks for support roles within the company. However, most support roles follow the same career track as IC roles for software engineering.
Quality Assurance
The potential career paths in QA are the most diverse of the four disciplines. At the beginning, you choose to either start as a quality engineer, a quality analyst, or an automation engineer. If you are still interested in QA, you can continue to become QA leads, QA managers, or senior automation engineers. However, quality engineering folks often find themselves interested in software development after spending a few years in QA. These individuals usually make a unilateral move into the software engineering tracks or seek continued education to better prepare themselves for this potential career change.
