Growing as an engineer

People often ask me for advice on working as a software engineer at a large tech company. They are usually surprised to hear that having not majored in Computer Science major in college, I managed to successfully transition into the role. Anticipating further questions, I figured it would be helpful for me to write down my thoughts on developing one’s engineering skills and increasing impact based on my experience at Facebook so far.

Engineering levels

Tech sector does not have an extensive hierarchy of titles. There is no fixed path from an analyst to associate, and then all the way to MD. Most techies are software engineers, data scientists, or, if they choose a managerial track, engineering managers.

Instead, there is a system of internal levels for both individual contributors and managers starting from E3 (new grads) all the way to E11 (famous example of Jeff Dean). Initially I treated it as just another corporate way of classifying people, yet over time I grew my appreciation for its accuracy in defining engineers’ growth. Improving as an engineer is not only being able to tackle larger technical problems, it is also about developing certain behaviors. When it comes to describing growth of an engineer it is also useful to think of the operating paradigm of a given person.

E3 aka new grad

Joining a larger company as a new grad is a great way to develop the software engineering muscle. One can learn best practices and well-established processes that work in industry. Compared to a startup, it is a trade-off between project ownership and building a long term technical foundation. As such it is of utmost importance to learn how to execute well on smaller assignments while getting as wide codebase exposure as possible. One is usually not penalized if a project fails to accomplish its goals as long as its executed well.

In order to maximize learning at this stage it is very important to expose oneself to demanding reviewers. The good old adage of vividly remembering only the most demanding school teachers is definitely true here too. Painful as it is to respond to your first “Request for changes” with tens of comments from a coworker, it forms a basis for improvement for the next diff. Similarly to attending a lecture where getting asked questions indicates engagement and interest of the audience, diff comments show reviewer’s care and diligence. Note that as you get better at it, you should apply the same meticulousness to other diff reviews.

Looking back on my career so far I am glad I joined Flux in San Francisco for a yearlong internship after graduation. Even though I was not that passionate about architecture, I was surrounded by amazing former Google engineers who helped me build up my foundation. I vividly remember the first very negative code review I received. My first reaction was to question every single point made by a coworker defensively effectively rejecting honest feedback. It takes time to learn to accept feedback yet it’s a necessary growth condition. I especially appreciate negative but constructive one as it provides most learning signal.

E4

Over time new grads get more and more familiar with team’s codebase. One usually develops strong expertise and ownership of one of the components on a project and, as a result, is heavily involved in its future work and direction. A necessary condition to make the jump is being self-sufficient and and able to drive changes to improve the system without being prompted to do so. One of the most important skills here is the ability to unblock oneself. It often presents a tradeoff between looking things up, trying to solve the problem on by themselves, or asking other engineers for help. It is absolutely fine to ask others for help if needed but the true skill lies in striking the right balance.

At this stage it becomes more important to understand how different components interact with each other. Based on my experience, the best way to get comfortable working with complex systems is to take an active part in being oncall. When something breaks, the in-depth knowledge of all the dependencies is critical for debugging. Again, it may sound scary to do it for the first time but willingness to learn is key here. On top of that, after each major breakage teams go over a so-called post-mortem in order to understand the root cause of a problem. Note that the goal of the oncall is to mitigate the problem while a long term fix and prevention mechanism is responsibility of the whole team.

Another aspect of further growth is being highly proactive in finding new projects and collaborations. Even though it is generally expected at higher levels to create one’s extended scope to get promoted, it also helps to make the transition to E5. After all if a new project becomes successful and promising, it makes it easier to justify further investment which often comes with an increased scope.

Looking back on my experience so far, I was lucky to essentially get assigned E4 scope due to a small size of the startup (~20–30 people) and the need to develop new features daily. I was responsible for making changes to one of the main data APIs in the backend which had to evolve to satisfy multiple levels of service for different clients. I was also part of the oncall rotation which made me learn the whole stack from cloud computing, data serving, and all the way to the continuous deployment system.

E5 (senior engineer)

Senior engineer is often a terminal level at tech companies meaning that engineers are not expected to grow in scope any further. Instead they can focus on growing expertise and experience in their current scope which is already a significant step up from lower levels. One of the main differentiating factors is responsibility for not only their own work but also for their team’s success.

A key mindset switch for senior engineers is from task- to process-oriented thinking where the individual outcome is not as important as its long-term implications. For example, it is not only important to fix misalignment of two cross-team systems, but also making sure that in the future we have processes in place to spot the growing disconnect sooner.

Team-level thinking may take multiple forms including setting the roadmap closely tied to achieving the goals, splitting work between engineers, and tracking progress over time to ensure their completion or shifting priorities explicitly. It may also reflect itself in taking care of overall team’s health both with respect to productivity and code quality. Being the most tenured engineer on my team currently, I realized how important it is to invest time in mentorship both directly through project work with other engineers or indirectly through diff reviews. In fact, one of the best ways to improve code quality is to lead by example by tackling the most unappealing code improvements. Other engineers would follow once it is clear that paying off technical debt is impactful too.

A crucial yet hard to do well initially aspect of that paradigm shift is realization how important delegation is for increasing one’s impact and growing the team. It may sound counterintuitive but well assigned and tailored project may increase overall team’s throughput by giving space for junior engineers to grow. At the same time, incorrect scoping or mismatch between skill sets available and project requirements usually leads to delays, frustrations but also significant time spent on direct mentoring.

E6 (staff engineer)

In general engineers at large tech companies are not expected to go beyond the terminal E5 level. Growing further hits the inflection point where guidelines and trajectories start to get blurry. People often choose to stop there in order to focus on other things happening in their lives while not having to satisfy a significantly broader scope and expectation at the E6 level and beyond.

Thanks to working at Facebook I think I have a generally good sense of what crossing that growth boundary means. In the past few weeks I gathered thoughts on becoming a Staff Engineer from more experienced coworkers. By all means, I do not know everything about it but quite a few things can be inferred from behavioral and technical expectations of the E6.

First and foremost, Staff engineers operate at the team-level rather than a large project level. Quoting my coworker, one becomes the “adult in the room” where they are expected to ensure the team is successful as a whole. The thinking changes from delivering individual impact to ensuring success of the larger effort. It is often quite easy to spot when experienced engineers “get things done” and no longer care who did what part as long as it was completed.

Another common characteristics is the ability to spot team-level inefficiencies or anticipating future blockers between workstreams of different engineers. After all, enabling cross-team projects which involve at least 5 to 10 engineers can be more impactful than delivering one killer feature slightly faster. For example, a very common case here is when multiple engineers on the team are slowed down by the same problem but none of them feels incentivized to solve. Quite often it is the case that when an experience engineer takes care of the issue, it motivates others to do the same in the future by essentially showing that solving mutual problems is impactful.

Being an E6 is not only a technical challenge but also an operational and peoples one. After all operating at the team level also involves constantly questioning whether team’s current structure or goaling is optimal. One often gets involved in recruiting, growing others, as well as helping set direction for months in advance. It is also critical to start thinking of potential external headwinds that may derail the entire effort. For example, there is significant impact to be had through derisking team’s future by identifying new opportunities for team’s tech or unblocking its main customers.

Managerial question

In industries other than tech, progressing professionally often means becoming a manager and leading larger and larger teams while being farther away from the technical work itself. Although it sounds like a cliché, in tech one can thrive and gain wide recognition by staying in the IC role indefinitely.

Looking at myself, I decided that I am not ready to start pursuing this switch yet as I realized how much I enjoy being technical while gaining wider scope. It needs to be said that big tech companies give one a lot of freedom to define one’s path. I may change my mind in the future, but I also realized that being a good IC requires developing people skills which would definitely become useful in the future.