What makes a senior software engineer

Published on

I've realised that job titles can mean completely different things in different companies. A senior in a tiny start up is completely different than a senior in FAANG, and again they're different than a senior in a big enterprise. But anyway, this is what I think makes a good senior engineer.

Years of experience

I cannot see how anyone should have senior in their title without quite a few years (5+) of experience. Even the best engineers just can't have enough real world experience in just a couple of years. (This doesn't stop some companies handing out the senior title).

Years of experience (especially at the same company) means:

  • engineers have designed & implemented solutions, and then seen how successful or not they were a few years later.
  • engineers with many years of experience will have used various design patterns - and quickly realise when sometimes they're really not suitable
  • engineers saw how companies grow (especially with # of engineers), and how the architecture that works for small companies (with a few engineers working ont he code) does not scale well once you have lots of people and lots of teams working on the same codebase.
  • have seen trends come and go. Juniors can often read something written on http://dev.to or a blog on medium.com (which are often written by inexperienced engineers) and think that they've come across the next big thing. But these trends come and go, and after a few years you start to notice what to filter out.

They mostly work solo - but can help others and help the team move along faster

Most software engineers at a senior level are individual contributors. (The next levels, e.g. staff engineer will have less of this). But its critical that senior engineers don't focus just on working solo.

I don't think an engineer can be a good senior engineer if they have no interest in helping others out. They should also strive to always be improving the quality of code or practises.

Deep understanding of a programming language

A senior engineer should know a programming language to a very deep level. They should also be able to easily know how to Google when faced with an issue in a language, and know how to find the answer quickly.

Part of this also means knowing how to write clean code.

To me, clean code means easy to understand, bug free, tested, and easy to maintain/make changes in future.

Dirty/unclean code means hard to understand, might have bugs, not tested, and a nightmare to make even small changes to.

Know SQL

This one is unlike most others. Most others are quite generic attributes to have. Some companies might not use SQL, but I don't think you can get to senior level without knowing SQL. Its a pretty useful thing to know. And most (I'd guess over 50%) modern tech startups use postgres, mysql or sqlite, so its going to be useful at some stage.

Know regex

I'm surprised when I speak to a senior+ engineer who struggles to write basic regex. Just learn it once, its pretty easy.

Know about security issues

Another thing that suprises me is when senior+ engineers introduce basic security issues. There is a lot to cover here, so I won't even begin to list them...

Understand / experience with APIs

Maybe this is a bit skewed towards engineers working at places such as SaaS companies. But I think API experience is very important...

  • definitely know RESTful APIs, how they should be designed
  • understand oAuth, understand different ways of authenticating
  • understand rate limits, how to design systems that can handle these
  • think about soap (not as popular now, and not fun to work with), graphql (very popular now)

Be reliable

One of the best things about working with decent engineers (of any level) is when they're reliable and do good work. It is not fun working with engineers who say they will do something but have a reputation of skipping doing the actual work

Fun to work with

This isn't really an attribute of a senior engineer, but working with people that are fun to work with (which really just means not being an asshole) makes working on the team so much more nicer.

Good PRs

  • Knows how to create good PRs. Small PRs, well tested, good descriptions, good commits
  • Knows how to do good PR reviews. Find bugs, knows when to leave comments requesting changes and when its fine to just hit approve (maybe with some optional comments)

Know design patterns (and when not to use them)

  • Design patterns seemed to be something talked about more years ago, and seems to be talked about less lately. Going too religiously following design patterns can result in very hard to maintain code. But senior engineers should be very aware of the main design patterns (and have experience implementing and using them)
  • Also very critical to know when not to use them!

Be continually learning about software engineering

  • learns new languages
  • learns new frameworks
  • learns new design patterns
  • understands how internals of frameworks work (e.g. for a FE engineer, they should have a good understanding of how React or Vue works under the hood)

Share knowledge

  • Senior engineers should try and level up other engineers (more junior and more senior)
  • This can be in PR comments, via weekly team updates etc.

Be able to give presentations

  • Probably not always requried for senior positions, but should be able to give presentations.
  • To both technical (e.g. other engineers) and non technical stakeholders

Be able to make decisions

  • When faced with a few options in how to implement something, seniors should be able to sum up the pros/cons and make decisions. When unable to, they should be able to easily discuss it with others (more senior) and come up with a decision.

Be able to raise issues and question others

  • When planning out features or discussing problems, senior engineers should be expected to bring up questions and other approaches.

Come up with alternatives

  • I think one of the best things seniors can do is not implement the first idea that is presented. Its always better to come up with other ideas (even if the original was the best)

Be good at problem solving

  • A lot of software engineering is problem solving. Seniors should know how to figure out solutions to problems

Be able to debug issues when things break

  • And on a similar note, they should also know how to debug issues.
  • This includes experience using debugging tools

Be able to resolve performance issues (and hopefully spot them before they become an issue)

  • can make reasonable compromises when it comes to scalability and performance

Be pretty good at system designs

  • I think system design interviews only make sense at senior+ positions
  • senior engineers should have a good understanding of cloud providers such as AWS or GCP, and know how the popular services work.
  • Have a good idea how to organise a new application, using different services, how to handle large traffic, how and when to cache etc

Be able to be given specs, and question them and work out if the end user will use the feature like you code it for

Know how to present proposals to stakeholders, and know how to speak to stakeholders

Take responsibility when things go wrong

Share team wins, don't blame others

Not take things personally, and see it just as work. No ego, doesn't get angry when specs change

Be able to interview candidates

Hopefully have a passion for programming

Can self manage projects, and can help manage projects involving others

Able to estimate work

Care about their work, and always try to improve things

Want to code in the right way (not just hack things together) - but also be pragmatic and know when to cut corners

Knows when to ignore DRY, and realise its better to write dead simple code that is easy to maintain

Knows how to test, knows the different ways of testing (unit, integration, e2e. Also things like visual regression testing, api contract testing), and when they're worth using

Knows some basics of devops/cicd (docker, github actions etc)

Knows how to release software (especially when there are complex deployments)

Understand when (and how) to deal with tech debt in an app

Experience with monolyths vs microservices (nice to have at senior level!)