The backend engineer roadmap

What does a senior backend engineer need to know?

I would argue that a good backend engineer needs to know… everything? I started the sentence thinking that I would write “a lot” but ended up writing “everything” because it’s true. You need to know pretty much all there is to know about software development, and it is also good if you know about business requirements, team management, culture enablement… well, you get the point.

So I started from the assumption that it is impossible to know all there is to know considering we have limited time to learn. Then the next question is: what are the essentials a senior backend engineer needs to know?

I do not have a good answer to this question but at the same time I think the thought process behind searching for the answer is still worth discussing.

I tend to think of three main areas:

1 - People - this includes skills like communication, team work, understanding how to handle different interactions with other people and related stuff.

2 - Tech - the main point of this article.

3 - Product - skills like understanding the big picture of your company, understanding how to improve OKRs, suggest improvements that are aligned with company and all that.

The areas aren’t completely separated from each other (which might mean that I need a better way of thinking about this). Usually when people talk about what is needed to be a backend engineer, the conversation revolves around the tech part. But it’s important to point out that tech isn’t everything.

That said, let’s talk about tech =X

I mean, we’ll cover the other areas in the future. But the point is that the tech part is a hard cut. If you don’t have the tech knowledge, you don’t get the position and that’s that. Once you have the tech part covered, you’ll be able to get in and meet a bunch of people that also have the tech part covered. And the thing that will move you forward isn’t learning more tech. Of course learning more will help, but the biggest impact a senior engineer can have won’t be an improvement of 0.01% in the execution speed of some method. It’s more likely that the impact will come from identifying a improvement in a process that involves multiple systems, bring this to the table, convince the stakeholders that this change should be a priority and managing the people to get it done.

It’s kind of obvious if you think about it, but nevertheless it’s important to point out.

Aaaanyways, the main point of this article is to reflect in the entrance barrier.

The way I see, a senior backend engineer needs to have a high level understanding of the whole flow he’s supporting. That is:

1. Gateway

2. Proxy

3. Front end

4. Reverse proxy

5. Backend

6. Database

How deep should I go into each topic?

As deep as possible, of course. Which means not too deep if you try to understand everything about everything. That’s why I usually argue that you don’t necessarily need to know everything in detail, but at least a high level understanding of each of these components is important. Some first-hand experience with them is also cool.

And I would say that at least 2 of them you need to have a deeper understanding. I’m personally experienced with backend and database. And I have to say that most of the knowledge came with real scenarios experience. I also believe that creating your own systems that simulate real life scenarios is already great. If you implement your own blockchain for example, even just for fun in a local setup, I firmly believe that you’ll be able to leverage that knowledge in a real life scenario. The only kind of knowledge I’m not a fan is the purely conceptual one. I don’t know how to explain it exactly, but reading about a topic without creating something real for yourself, even if just a local test scenario, doesn’t provide the same level of understanding. At least that’s my personal take.

For an example of how deep I would go in the topic of databases, I would make sure to cover all the basics, the SQL and NoSQL databases, all main concepts like indexing, partitioning, sharding. And finally, I would pick one specific Database Management System to learn in more detail. I know a lot about PostgreSQL so I would try to understand at least some of the underlying works, like for example how the sharding is implemented using Foreign Data Wrapper.

Which strategy is the best to learn all this?

The one that works for you, of course. I’d say to keep a few things in mind:

1. A lot of the backend engineer knowledge is procedural, which means that the best way to learn it is by putting it into practice as soon as possible. (Leaving a reference here of some good content on improving how you can learn by Justing Sung.)

2. It’s impossible to know everything about everything. Have a clear goal of how deep you want to go in a topic and stick to it.

3. Make sure you are comfortable with what you know. If for some reason you covered everything you wanted in a topic, but still feel like you don’t really know anything about that topic, revisit it with a different approach. Probably putting what you learned into practice in your local environment will help you get the confidence you need.