Software Engineer Career

Updated: 2018-12-19

Ignore The Titles

This is the first advice for you: titles are meaningless.

Some companies(like Microsoft) have so many levels, so that you can feel your career progression every one year or two; some companies(like Oracle) have titles so bloated that almost everybody is a "principle"; on the other hand some companies(like Facebook) hide the levels and call everybody "Software Engineer"("all engineers are created equal"?)

Tracks

Though all software engineers code, they may have different focus areas or specialties.

Product Development

You may work on front-end, back-end, full stack, or mobile. The main focus is to develop products/features. It can be exciting to see people are using and loving your product, but can also be frustrating to feel "I'm just implementing the business logic", or "just translating designer's sketch to code".

Besides coding, "product sense" and "empathy for your users" are also critical for this type of roles, unless you want to blindly follow and totally rely on your PM, and be the junior software engineer forever.

Infrastructure

This is not that related to business logic, your work is not measured by earnings or user churn rate or other business metrics, but more by system performance metrics like latency, throughput, and 99.999% reliability. It required more hardcore computer science knowledge, especially about distributed systems.

Machine Learning / Data Scientist

"Data Scientist" is an over used term. In some companies they are building machine learning models; however in some companies they are more like "data analyst", defining metrics, creating queries and dashboard, and model training is done by software engineers(called Ranking/Algorithm/ML Engineer).

Testing

Focus on testing.

DevOps

The key to DevOps are monitoring and automation

SRE: Site Reliability Engineer

A term coined by Google. One big part of SRE's job is oncall. Normally software engineer will be oncall when the product is newly launched, then it will be transferred to SRE.

Google explains the relationship of SRE and DevOps as:

class SRE implements DevOps

meaning DevOps is the "interface", the set of best practices, while SRE is a concrete "class", or job title that follow those best practices. However as a class may implement more than one interface, SRE is not limited to DevOps

Google's SRE book

Towards "Senior" / Tech Lead

You will reach a point where you stop just implementing someone else's idea or spec, you start to spend more time exploring new directions, scoping new projects, and making larger impacts. Then you will be a "Senior" software engineer, whatever the title is.

Besides hardening your technical skills, these soft skills will become more and more important: communication, collaboration, problem solving, empathy, handle responsibility and failure, curiosity and keep learning.

Tech is not easy, but people are always harder.

IC or Manager

At some point you need to make a decision, whether to stay as an individual contributor or to be a people manager.

Individual Contributor

If you enjoy technical challenges and do not want to "manage" people, most companies have this IC ladder for you.

Very senior IC can be called "Architect", but that normally means "didn't code anything in the past 10+ years." And some companies have "Fellows", for people who made very high impact and at VP's pay grade.

But inevitably, as you become more senior, you will spend less time coding, but more time working with other team members or other teams discussing longer terms and bigger pictures.

People Manager

If you enjoy having 8 to 10 meetings per day, doing 1:1s every week, and performance review/calibration every quarter or half, or you simply hate coding, then you should be a people manager.

The career path is clearer than IC's, from first line manager to second line, then director, VP Engineering, until CTO or CIO. What's the job of CTO? Here's a good quote:

(@jimbojsb:) CTO’s Prayer: God, grant me engineers to build the things I can’t buy, budget to buy the things I can’t build, and the wisdom to know the difference