In 2022, I was promoted to Senior SDE in one of the FAANG company. Along the journey, I've received many helps from my senior co-workers and leaderships. Very often, I was doing something that a senior engineer should not do. When that happened, their guidance often helped me to get back to the right track. I feel it's time to do a retrospective to periodically remind myself that what kind of expectations do people hold on senior software engineers.
Role and Responsibility
To summarize everything in one sentence, a senior engineer is responsible for making the right technical decisions within a one pizza team.
As the baseline, you will be responsible for making system or architecture designs for the most complex projects in the team. The size of the project could vary from a few months to a few years. You are expected to make the initial design and finalize the design with relevant stakeholders including business team, senior leadership, principal engineers etc.
At the same time, you will not be limited to yourself. Your junior teammates need your help. They will frequently seek your inputs on various topics including system designs, on-call issues, best practices, or even career suggestions.
Last but not least, for all collaborations with other teams, you are, by default, the to-go person for any technical questions.
In some company, you may also assume part of the SDM role to draft engineering plan for most of the projects that your team carries.
Collaboration, Communication, Writing
A senior engineer is always expected to be accurate and precise. Their words are meant to be useful and easy-to-understand. (Yes, I am still far from there 😄)
Accuracy
As a senior engineer who is accountable for every technical thing in the team, your words are taken seriously by others. The first thing you'd like to avoid is repeatedly using non-deterministic words such as "probably", "might", "perhaps" which adds possibility and reduces accuracy in the conversation. I've seen one of the senior leadership that I previously worked with has one line in the day-1 intro: "I will not use probably when I talk. Even if I do, there's 80%+ chance that the truth is what I say". To holds high accuracy, senior engineers only share content from verified sources. If things aren't clear, they will call out that verification is needed.
Precision
This is something that many folks do not pay enough attention to. Amazon has a well-known culture of writing. Depending upon the scope, they demand a doc should be fit into either 1 page or 6 pages (check it out. In this idea, most of the low-level technical doc can be fit into one page while most of the high-level technical or business docs may need 6 pages. Why limit the number of pages? In short, it helps both the author and readers to focus on the most important things with enough efficiency in the reading and writing. Here's a real example of mine. I used to write a 3-page doc to explain one complex technical issue. In the doc, I explained how the overall system works, what's the problem in detail and how I feel the things should be changed. My skip-manager took it over and spent few days to re-write it into one page. While being amazed by how precise the new doc is, I noticed about a few key changes:
- Remove irrelevant things into the context. People often try to put a lot of things into the context section, which they feel other folks should also pay attention to. However, there are many things that either may not be relevant or the readers may already know. For instance, it's not needed to explain how Apache Spark parses a sql query while you are trying to propose an idea of perf optimization to Spark team.
- Let the data talk. People often uses large amount of words to explain or describe an issue. It's not straight forward rather not convincing. Instead, a good doc uses data to present truths. With data, it becomes easy to guide the readers to get onto the same direction.
- Have clear structure and goal. One critical thing I've learned is that writing a doc is just like telling a story or having a conversation with someone. You need to be crystal clear on what the expected outcome is. Are you trying to propose a business idea? or giving a solution to a technical issue? or even doing a KT session? By setting up a goal, it helps you to remain focused and avoid going deviated or even back-and-forth. After that, you should create a clear structure for the conversation so that the audiences can follow your lead to reach the conclusion that you want to draw.
Execution
Senior engineers hold full responsibility on delivering. They ensure that everyone in the team remains on-track to deliver high-quality products before the deadline. It often means three things:
- Frequently review the current progress against the timeline.
- Help others get unblocked if they are blocked due to technical issue or from external dependencies.
- Periodically report to key stakeholders about the progress and the upcoming things.
In the above, I've shared my view on some of the key expectations from senior engineers. These expectations are not just one-time things but rather should be constantly followed.
As this is my first post in DEV, I wish that this post sets a new start for myself. When we get promoted to senior engineer, we've not reached a terminal but rather a new gate for take-off.
"Stay Humble and Stay foolish."
Top comments (0)