Contrary to popular perceptions, I’ve come to realize engineers do not exclusively work on building new products. Engineering sometimes involves designing new systems, but can also entail evolving older legacy systems, scaling products, and maintaining good hygiene by cleaning up unused modules. It’s not only about solving problems by creating new products; we also have to stretch our brains to think about how to improve and build upon products and processes that already exist.
While I’ve worked at a mix of large and small companies so far in my career, the above notion is something I saw even more upon joining LinkedIn. I was primarily drawn to the company for its high engineering bar and compassionate culture, and was excited to join the Premium Career team. The team’s primary focus is to build features to help members with their job search and provide tools to accelerate their careers. During my first year on this team, I had the opportunity to work on a number of technical challenges and user-facing products. From building a learning module, to surfacing relevant insights for job seekers, to deprecating older APIs, I had a chance to work on a variety of codebases and projects.
My growth mindset
Given the range of tasks I completed in my first year, I quickly came to define my personal growth mindset at LinkedIn: collaborate with an open mind, soak in the knowledge from everyone around me, stay focused, and ignore the noise. I soon came to realize that adopting this mindset has helped me learn and accelerate well beyond my initial expectations upon joining the company.
Working with existing code
Several times, I have had to dive into an unfamiliar codebase and quickly become productive. This requires paying a lot of attention to how systems are designed, how the code is structured, what design patterns are used, and how these patterns can be reused or leveraged in the future. While this may not seems as exciting on the surface as getting to write your own code from scratch, working in an unfamiliar codebase helps you to really stop and think critically about how code is written. Also, as a new engineer at LinkedIn, learning the common touch points on one codebase lent itself well to easily picking up other unfamiliar codebases that use the same framework.
While deprecating older APIs, I noticed how some systems were designed in a modular manner. This made it easier for me to quantify the risk and focus on confidently executing. Without this modular design, these tasks would have become far more complicated and error-prone while serving millions of customers in production. These types of projects are not the most glamorous, but adopting a growth mindset helped me embrace the opportunity to learn how to minimize risk while making significant changes to an underlying system, a lesson that will be useful throughout my career.
Shadowing experienced engineers
My mindset during the first year was to learn the domain as quickly as possible by shadowing and observing experienced engineers around me. One opportunity for learning that I discovered was to serve as an apprentice on the Data Model Review Committee. The purpose of this committee is to review APIs, tracking events, and database tables to make sure they follow our conventions, patterns, and best practices across the entire data lifecycle and between teams across the company. This gave me exposure to the breadth of features being built and provided a chance to adopt some of the learnings from these reviews into my own projects. Putting on a reviewer’s hat proved crucial in honing my craftsmanship skill and continuing raising my own quality bar.
Cross-team collaboration is key
Outside of day-to-day coding, LinkedIn engineers heavily collaborate with our product and data relevance teams to determine the direction the products should take. This involves brainstorm sessions during the early stages of the product cycle and breaking down and sequencing engineering tasks, so that we can continue to deliver value to our members. Building strong relationships with the product team gave me valuable insights about analyzing the right metrics for building a successful product. Similarly, cross-team collaboration with the data relevance team helped me understand the building blocks of personalizing the experience for a LinkedIn member. While collaboration with other teams might sound like something that will slow your engineering project down, I’ve found that in fact it makes the end product much better.
Recently, I worked on a product to help job seekers transition to a different career path. Connecting people and facilitating conversations is just the first step in this process. Working on this project gave me a chance to build a data pipeline, learn Spark, and gain exposure to the entire tech stack. While large projects can be intimidating at first, stepping back to understand the big picture and working with all the teams necessary provides a lot of clarity. Additionally, I’ve found that keeping an open mind and immediately incorporating feedback has proved to be a very effective strategy for me in terms of skill and career growth.
Having the opportunity to interact with multiple teams outside of engineering has given me a new perspective on the varying mental frameworks needed to approach a project based on team, role, and level. I’ve come to learn that everyone has their own version of a “growth mindset,” which they’ve evolved through their own experiences, and it’s by listening and learning from them that I’ve been able to grow, too.
Acknowledgements
I want to thank Laukik Watve, Vijay Ramamurthy, Joey Addona, Deepak Kumar, and Anne Trapasso for being generous with their time and giving me helpful editorial feedback.