What do you expect from a Principal Software Engineer?

Alexey Tsitkin
3 min readApr 6, 2020

--

My team is currently hiring, and I got asked this question by a candidate the other week, and thought it might be a good topic for discussion.

This role might also be called Staff engineer/Tech Lead/Architect or even Senior Software Engineer in different companies, based on size of the company, organizational structure and company culture.

Obviously this person needs to be Smart and able to Get things done.
But this is usually pretty vague, and hard to test for (we try though 😄).

Also, unlike entry or mid-level engineering positions, I would expect this person to hit the ground running, and would be highly productive within a month or so, which requires a certain level of technical knowledge and experience.

So what technical experience are we looking for?

Coding:

This is the simplest one - you need to have experience writing production-grade code.

This usually means using some sort of language/framework combination like Java/Spring, Scala/Play, Python/Django etc.

It doesn’t really matter what actual language you used - a good developer could usually get a grip of a new language in a few weeks.
But it is imperative to have written code running in a decent scale production environment.

Data stores:

We will likely not ask you how the Trigram index in PostgreSQL works, or how do you create a transaction in DynamoDB.

What you do need to understand is what would be good use cases for RDBMS, NoSQL, in-memory cache etc.
Preferably you used several different ones, at scale, to know the difference.

These are questions we face on a daily basis, each time we develop a new micro-service, for example.

Cloud:

It doesn’t really matter if you used AWS, Azure or GCP - the concepts are very similar in all of them.

But what’s important here, is to understand (at least in high-level), what set of services the cloud provides for you, and what are the possible pitfalls (e.g. cost).

Containers:

Unless you have some specialized use-case, or you have been living in a cave for the past 5 years or so, there’s really no reason not to use containers for deploying your services.

You don’t have to be a Kubernetes expert, but you do need to understand what are the benefits containers provide, how does Docker work on some basic level, and how does it fit in your CI/CD pipeline.

Monitoring:

Last, but definitely not least!

You need to be able to explain in detail how did you monitor your code in production.

If you didn’t do that, it usually means one of two things:
1. Someone else did it for you
2. Your system wasn’t really used on a reasonable scale

Again, the specific tool doesn’t really matter here (Grafana, Prometheus, DataDog to name a few), but when you ship code to production, you need to understand how the code behaves there (as usually, you might be in for some surprises).

Bonus: Open-source!

It’s pretty clear that not everyone has the time to make significant contributions on their personal time.
But what we’re looking for is a person who knows when it is a good time to look for an open-source library, and what criteria to use when deciding whether this library can be used in a production system?
When would be a good time to fork an open source project? And when would it be worth contributing code back?

Of course, putting the technical aspect aside, it’s incredibly common that candidates tumble on the non-technical stuff, like preparing your resume, or being able to explain the things you did. But that would be a topic for one of my next posts.

Thoughts?
What is your organization looking for in senior engineers?

Note: this post does not represent in any way my company’s views, but rather my own technical perspective.

--

--

Alexey Tsitkin

Software engineering enthusiast (back end and big data). Engineering Manager @barracuda. https://www.linkedin.com/in/alexeyt/