Debunking Tech Careers
Do Frontend Engineers push pixels all day? What the heck is DevOps?
You’ve probably heard terms like Frontend, Backend, and Product/Project Manager thrown around all the time. You may have even heard of DevOps Engineering or Growth Engineering. What do all these job titles actually mean? What does your day-to-day look like in each of these roles?
Do Frontend Engineers just push buttons 2 pixels to the right all day?
There are so many different career paths in tech, which can be a blessing and a curse at the same time. While each role has its own unique pros, it can be really overwhelming to unravel all these different positions and figure out what suits you best. In this post, we’ll be explaining some common roles in tech to help you find the right role based on your interests!
Frontend Engineering
Frontend engineers develop the part of the application that users see and interact with — typically this would be in the form of a website. They collaborate closely with designers to build the user interfaces that the final customer uses. They’re also frequently thinking about efficient state management, combining local application logic with data fetched from remote APIs.
Why Frontend Engineering?
If you enjoy creating value for customers and thinking from a user-centric point of view, Frontend Engineering is for you! You get instant visual feedback and can see the impact of your work right away.
Is it true that Frontend Engineers just push pixels all day?
Not at all! While Frontend Engineers should have a strong eye for design, you’ll typically spend most of your time managing state, fetching data, and writing comprehensive test cases!
Backend Engineering
Contrary to Frontend Engineering, Backend Engineers are generally responsible for building the application logic that users don’t see, often referred to as logic on the server. What this “logic” actually entails varies depending on the size and organizational structure of your company. For example, you might work on building microservices, data pipelining, database wrangling, or automation and scripting.
If you enjoy thinking algorithmically rather than from a user-centric approach, then Backend Engineering might be for you!
A typical day as a Backend Engineer
In general, you’ll pick up tickets to work on each week, collaborating with your team as you think about how you’ll approach each problem. You’ll typically have standups with your team each morning to get a pulse of what your teammates are working on, and retrospective meetings every few weeks to identify areas where your team can improve.
Is it true that you can work at 5 “backend” jobs and have done drastically different things each time?
Very much so! Two main factors contribute to what type of work you might be doing. One is the size of the company — for example, at a smaller company you’ll be expected to take on a wide range of skills, while at a larger company you’ll have a chance to hone your skills in a specific area!
The other main factor is the job description itself: read the job title and description closely, as they might describe what technologies you might use or what your team does! For example, some roles might list using Python and Flask to build an API, while others focus on databases or scalable systems. If a particular concept interests you more, you may want to look for jobs that specifically cater to those areas!
Full Stack Engineering
Full Stack Engineering is essentially the combination of Frontend and Backend Engineering. You work with both the client-side and the server-side of the application. Your projects can involve owning a project and building end-to-end features from the ground up. It can usually look like building the backend, managing database calls, creating the frontend, and sometimes working directly with designers.
Why Full Stack Engineering?
If you are unsure what you like yet, Full Stack Engineering is a great way to understand what you want because you get a taste of the whole stack before deciding to focus on one side or another. It helps you to not only understand how each part of the system works, but also how they work TOGETHER. You get a range of experiences with this role!
Do Full Stack Engineers suffer from being a “jack of all trades, master of none”?
Knowing one language does not necessarily mean you’ll be weaker at another language. At the same time, having exposure to the full breadth of technologies helps you understand what type of development you enjoy the most! More often than not, people will prefer some tools more than others — some folks prefer backend, while others may prefer frontend or infrastructure.
This does not mean you are a jack of all trades, since you can hone your skills more in the area you enjoy, while still carrying your knowledge of the rest of the stack with you.
Product Management
As a Product Manager, you’re responsible for being the voice of the customer when it comes to deciding what is getting built, and when, so it’s critical that you have a clear understanding of what your users’ needs and pain points are. To get that information, you may spend your time pouring through user feedback, doing user and market research, speaking directly with customers, and meeting with internal stakeholders (customer support, customer success, business, sales, etc.).
You’ll work cross-functionally to create a product roadmap and define the most important features to prioritize for your product based on the needs of the customer, business, as well as your own intuition and market understanding!
What does a typical day look like as a PM?
What your typical day looks like depends largely on what stage of the project(s) you’re working on is at, but you can count on regularly collaborating with business leaders to align on product strategy and vision, engineers to discuss tradeoffs and feasibility, as well as designers to work through workflows and usability. As a PM gains seniority, much of these practices still stay the same, however, the scope of the problems to solve become more ambiguous and yield higher impact on the overall business.
Are product managers people managers?
No, product managers are not people managers. It’s useful to use the analogy of a sports team manager — the person does whatever it takes to ensure the team operates effectively. This does not mean managing what people are doing on a day-to-day basis, but rather by doing research, identifying opportunities, and condensing feedback to ensure everyone on the product team — designers, developers, business analysts — have everything they need to work effectively.
UI/UX Design
UI stands for user interface design, and focuses on the visual aspects while UX stands for user experience, and encompasses the broader realm of interaction design & user research. The main goal of UI/UX Designers is to design how the interface, which the users interact with, will look like.
What is a typical process for UI/UX?
A UI/UX Designer works closely with engineers and product managers. The day-to-day varies based on your project and the phase of a project. A typical day might include iterating on your mockups using tools such as Figma, Sketch, or Invision. You are in charge of presenting to stakeholders/clients, conducting user interviews/usability testing, and working with your design team to ideate, wireframe, and receive feedback.
Comparing Product and UI/UX design
Product design and UI/UX design are often used interchangeably. The main difference is that product design is more from a business approach, and can be more broad than UI/UX.
Do you have to be good at art to be good at UI/UX design?
Definitely not. A lot of UI/UX is about problem solving. Even though some people come from a more visual background, every designer is different and it is valuable to also be strong in user research or making design decisions. You will be working with other designers so everyone will bring their strengths to the table. If you work at a bigger companies, there may also be existing design system so you can leverage that to create visually strong designs.
Growth Engineering
As a Growth Engineer, your mission is to improve user acquisition, conversion, and retention. There is not a specific part or stack you will work on. Your work can range from notifications, feature improvements through experiments, new-user onboarding, and building an experimentation framework.
Why Growth Engineering?
This is great if your interest is in marketing, engineering, and company growth. If you like a fast-paced environment and want to apply your engineering skills to grow the company, then Growth Engineering is for you. You are able to see the results of your work right away and get validation of the work you do.
Here’s a personal anecdote from one of the Growth Engineers we spoke to:
At one company I worked at, I was sending out email and notification campaigns to 50+ million users, driving a significant part of the revenue. In another co-op, I worked on unifying the login flow so that users can get onboarded quicker.
The best part about the job is being able to see results within days. To this day, I am most proud of one of my growth projects where we saw a 100% increase in Daily Active Users and a 300% increase in click rate for iOS.
Do growth engineers write way less code?
This can be possible, but you can also write way more code. The point of Growth Engineering is that it’s not about how many lines of program you write. What’s more important is bringing users to your platform and driving business results at the end of the day!
If this role sounds like it can fluctuate a ton, that’s because it is! A huge part of Growth Engineering is experimentation, as “growth” will vary from company to company — if change is something you like, then Growth Engineering might be something you want to check out!
Infrastructure Engineering (DevOps/Site Reliability Engineering)
Infrastructure Engineering is also commonly known as DevOps or Site Reliability Engineering. Its exact definition/scope strong defined, but at a high-level, it is “the foundation that the rest of engineering relies on: storage systems, compute platforms, networking, CI/CD pipelines, developer tools.”
In general, infrastructure engineers have a similar background to Backend Engineers but focus on different domains. Traditional back-end engineers tend to build product features and application software, whereas infrastructure engineers tend to build systems/tooling to support the reliability and scalability of application software.
In other words, your work is even more “behind the scenes” than a Backend Engineer: Backend Engineers typically are focused on application-specific logic, while Infrastructure Engineers build out the infrastructure so that your application can actually run in the first place and scale out to hundreds of millions of users!
How do I know if Infrastructure Engineering is for me?
If you resonate with any of the following prompts, definitely consider looking more into Infrastructure Engineering!
- Have prior experience in a developer role (e.g. front-end or back-end) and want to try something new, as well as broaden your skill-set
- Enjoy troubleshooting complex systems and/or find debugging exciting
- Comfortable with your work being “behind the scenes” (not directly visible in the product/related to the core business of a company)
- Find yourself writing scripts to automate a manual task or improve the efficiency of a process
Is it true that you have to wake up in the middle of the night if your application stops working?
It’s true that full-time Infrastructure Engineers go “on-call”, as they are the folks responsible for ensuring the application is up and running. However, this rarely happens, as your role in the first place is to prevent these outages from happening in the first place by ensuring services can automatically heal and recover. Additionally, if you’re an intern, you’ll typically never be on-call.
Security Engineering
In some sense, Security Engineering is a specific type of Backend Engineering. Security Engineering focuses on building secure software solutions: that might mean separating sensitive information into a new database, adding certificates and certificate rotation to your application, writing key management and secret management software, preventing malicious attacks, etc.
Subcategories of Security Engineering
There are a lot of subfields and jobs under the big umbrella of Security Engineering. One is penetration testing, which is finding bugs and loopholes in an application that need to be fixed. Another is incident response, which is a part of corporate security that responds to breaches or other incidents. Security Engineers are always in high demand. Although getting into the field as junior developers may be difficult at first, having an interest in security is a good start.
Typical tasks and tools
A day can start with checking a couple of platforms for bugs and tasks. Some daily tasks include monitoring logs, programming rules and alerts to look for suspicious activity, configuring permissions in AWS, and generally maintaining system health.
Some common tools you may use are: Datadog, AWS, Terraform, Ruby, Python.
Do I need to code well to be a Security Engineer?
You may still write code on a daily basis, so it is definitely an asset! However, you can expect to write less code than a typical Backend Engineer.
Data Science
Data science, in simple terms, is an interdisciplinary field that combines domain knowledge, statistics, and computer science to extract insights and knowledge from data. This can involve conducting deep dives, visualizing the data, building models, etc. — the goal is to use the data to add business value. In the industry, the roles and responsibilities that come with being a data scientist vary based on the organization and are very project-dependent.
A day in the life of a Data Scientist
The day-to-day really varies, but typically it can involve completing some ad-hoc data investigations, researching and experimenting with ways to improve models, and validating your results. The applications may vary between companies; however, the skills you build are extremely transferable. An internship experience in the field is a really helpful way to learn whether this is a strong fit for you!
Do you have to be good at math to be a good data scientist?
Yes, a lot of math you learn actually helps with being good with data science. For example, concepts in linear algebra like vectors and matrices map to arrays and tables in data science. Calculus and combinatorics can help you optimize an algorithm. Probability and statistics are essential in building data models. Computational math can help with understanding the computational capabilities of big data. Many math skills are very transferrable when your work with data and help you understand the problems you face. Don’t skip math class if you’re interested in data science!
Mobile Engineering
Mobile Engineering can be really similar to Frontend Engineering, except that you develop mobile applications rather than web applications. Since most of the time you’ll be building software that people interact with, you’ll spend a lot of time building UI components and working with design teams. You’ll review code and work with team members, investigate libraries or develop tools in-house, and most excitingly, build apps!
Tools and frameworks for Mobile Engineering
iOS: Swift (Objective-C)
Android: Java, Kotlin
Both: React Native, Flutter
What’s great about Mobile Development
What’s great is the immediate impact that your work has. When you push a new feature or change, you can open the app and say “Hey, I did that!”.
Additionally, Mobile Development can sometimes be considered a more “niche” field, with a higher barrier to entry because of the specific languages and technologies required to develop mobile apps. If you’re interested in mobile apps, this is great news for you as Mobile Engineers are almost always in high demand!
Should all mobile developers know how to write BOTH Android and iOS apps?
You don’t need to know both. Usually, big companies will have dedicated teams to tackle Android and iOS separately. In smaller companies, if there are not dedicated teams for the two platforms, you will likely write in a single language to target both. The high-level ideas of iOS and Android are not too different, and once you are familiar with one, it’s not too hard to connect the dots and transition into the other.
So Many Choices!
We hope this was helpful in giving you a better understanding of some common career options in tech. All the different options can be very overwhelming at first, but just know that there’s something for you based on your personal interests and strengths!
Where do I start?
If you’re interested in exploring any of these careers, you might find yourself asking, where do I start? Finding a Mentor within the field you’re interested in is a great first step.
Each term at the University of Waterloo, Tech+ UW runs a Mentorship Program for anyone wanting to further develop their skills and break into the tech industry. Gain 1:1 support from upper-year Mentors and receive feedback on side projects and portfolios, as well as help with your resume and interview skills!
To keep up to date when Tech+’s Mentorship Program applications open each term, click here to sign up for our mailing list or follow us on social media.
