21–30 of 60 posts
- Authentication: OAuth2 is probably the most widely used
- Authorization: RBAC
- Some rudimentary statistics: know how to read metrics, write metrics, etc
- Learn one RDBMS inside and out. Other database systems have their place but you’ll almost always encounter a Postgres, MySQL, MSSQL. Learn how to read EXPLAIN output, cursor based pagination, and indices.
These days most backend engineers also tend to manage data sources so understanding them is also a plus
No better way to know how to secure your code than the mindset of "Ok how would I break into this" :)
- the OSI model, DNS, TCP/UDP, TLS, and networking in general
- CPU flame graphs and other low-level performance/debugging tools
- the Knightmare devops story
- anger management
I think it's important to know about different data storage options and their trade-offs. Managing state is one of the hardest parts of backend development, particularly at scale, so an understanding of the trade-offs in databases/caches/blob-storage/queues, and when each is useful is important. I'd pay close attention to speed and "correctness". What's the consistency model of a system? Can we lose data and if so ho…
Also, I’ve had to explain this to so many other engineers, both junior and senior to me: most data is inherently relational. This next statement is a bit opinionated: 9 times out of 10 you probably want an RDBMS. I’ve seen so many attempts to shoehorn some ElasticSearch/Mongo/Neo4j/whatever database into a design because the developer wanted to work on CoolDatabaseTech. Then you’re stuck dealing with joins in CoolDatabase that it wasn’t really designed to do and frustrated at CoolDatabase’s lack of drivers in X language. Later on you’re dealing with stability and scalability issues you would never see with BattleTestedRDBMS.
The amount of capability a well designed Postgres instance can output is insane. I’ve seen a single vertically scaled Postgres instance compete with 100+ node Spark clusters on computations.
C and how to debug it. If you understand the system a layer of abstraction or two below the layer you work in, you will be able to debug deeper. Learn system calls, Various ways how to examine processes. I learnt a lot of this back in the day by completing war games on a site called digital evolution (dievo). Those are antiquated now but still a really fun way to learn it.
sounds very niche from an employability PoV.
It might be niche, but it can also be a differentiator--even if I'm not the fastest coder or the best architect I have these other skills that make me valuable at critical times. That's worth something anywhere.
And it's not even knowledge of C or C++, or syscalls or whatever: it's just basic "use a debugger" (not merely pantomime the commands, but understand what's going on) skills that can be the real game changer.
C and how to debug it. If you understand the system a layer of abstraction or two below the layer you work in, you will be able to debug deeper. Learn system calls, Various ways how to examine processes. I learnt a lot of this back in the day by completing war games on a site called digital evolution (dievo). Those are antiquated now but still a really fun way to learn it.
sounds very niche from an employability PoV.
But if you do so, then I must ask: what are you doing on this site? What can you possibly get out of it?
C and how to debug it. If you understand the system a layer of abstraction or two below the layer you work in, you will be able to debug deeper. Learn system calls, Various ways how to examine processes. I learnt a lot of this back in the day by completing war games on a site called digital evolution (dievo). Those are antiquated now but still a really fun way to learn it.