Most software engineers do not need 10 years to become senior.
They need 2 years of focused work.
But most people spend those 2 years like this:
8 hours office work
2 hours scrolling
1 hour complaining about manager
1 hour comparing salary on LinkedIn
30 minutes saving system design posts
0 minutes actually building depth
Then after 5 years they wonder why they are still being treated like a mid-level engineer.
The senior engineer path is boring but simple:
- Write 2 design docs every month.
- Debug 1 real production issue deeply instead of just patching it.
- Read 1 technical book every quarter.
- Build 1 side project where you handle auth, caching, queues, retries, observability, rate limits and deployments.
- Spend 30 minutes daily understanding databases, networking, distributed systems or cloud infra.
Do this for 12 months and you will not even recognize your old self.
The difference between mid-level and senior is not age.
It is ownership.
Mid-level engineers ask, “What should I build?”
Senior engineers ask, “What problem are we really solving, what can break, who gets impacted, and how do we make this reliable?”
Hard work is tiring.
But staying average for 10 years while knowing you had more inside you is a different kind of pain.
Before going for LLD round , never forget to prepare how to :
Design a Parking Lot
Design an elevator system
Design API rate limiter
Design a logging system
Design a hotel management system
Design a movie ticket booking system
If you are trying to understand distributed systems, focus less on what and more on why, when, and how. Answering what a system does is usually the easy part. The harder one is why it behaves the way it does.
This is actually learnable, and it comes from building intuition around trade-offs and from spending hours working through that one strange bug.
And that intuition is what really matters when things break. In those moments, surface-level or theoretical knowledge is not enough. What matters is having that ability to reason from 'first principles' and apply deep practical understanding.
For example, imagine a system where requests suddenly start timing out after a new deployment. Logs look normal, dashboards seem fine, and nothing obvious is broken.
If you only know what the system does, you are stuck.
But if you understand why it behaves the way it does, you start asking better questions - did latency increase due to a hidden network hop, did retries amplify load, did a small configuration change trigger cascading failures? That is where real debugging begins.
So, when you are picking up distributed systems, spend more time asking why, when, and how.
Hope this helps.
THIS MAN SHOULD BE EVERYONE'S ROLE MODEL. PLEASE DO NOT FORGET TO MAXIMIZE YOUR HEALTH BY STAYING FIT AND ACTIVE.
IT NEEDS TO BE YOUR IDENTITY. ALL YOU HAVE TO DO IS STAY CONSISTENT.
I have 12 years of experience and working as a Principal Engineer @Atlassian and I have seen concurrency scaring the hell out of a lot of junior engineers.
It’s one of the most feared topics in system design & backend interviews — race conditions, deadlocks, thread pools… you name it.
But once you internalize these 20 must-know concepts, everything clicks.
Save this thread. Read till the end.
Your future interviews and production systems will thank you.
India is one of the largest and fastest-growing tech markets, yet users here struggle to access services due to limited payment options.
Requesting the team to integrate UPI 🇮🇳 it’s the backbone of digital payments in India and would make subscribing to Claude seamless for
After multiple senior backend interviews, I realized something.
There’re high chances of cracking the interview if you’ve actually implemented the systems, and not just read about them.
Next 10 days, implement these with the help of your favourite LLM.
1. Feature Flag System
Interfaces, rules engine, extensibility.
2. Retry + Backoff Library
Strategy pattern, pluggable policies.
3. Notification Routing System
Channels, priorities, templates.
4. Rate Limiter
Algorithms, abstractions, thread safety.
5. Circuit Breaker
States, transitions, failure thresholds.
6. Metrics Aggregator
Time windows, aggregation logic, concurrency.
7. Configuration Manager
Versioning, caching, listeners.
8. Payment Processing Flow
State machines, idempotency, validations.
9. Cache Library
Eviction policies, extensible storage.
10. Job Scheduler
Workers, queues, retries, priorities.
Check my pinned post for the resources to learn these.
If you want to achieve anything great, it needs to become your one true priority. The only thing on your mind. Nobody accidentally got rich from business. Nobody accidentally built a great physique. They were obsessed with it for multiple years until it became their default.
So you say you are a software engineer.
Have you ever downloaded actual binaries like Kafka, Postgres, ClickHouse, Elasticsearch, Redis, or something else, and tried running them locally while exploring what those bin, lib, data, and logs, etc directories contain?
And then did you understand why they expose specific ports, what exactly gets written inside the data directory, and why in that particular format?
Did you then write your own client to call their APIs and bombard the server with requests, just to observe when CPU becomes the bottleneck, when RAM starts limiting scale, and how the system degrades under pressure?
After that, did you run the same systems inside Docker or Podman and experiment with controlling memory, security and disk limits to see how resource isolation affects behavior?
Did you go one step further and install Minikube locally, to orchestrate multiple instances of your container, simulate a multi-node cluster, and understand ingress and load balancing in practice?
And then maybe, did you spin up a free AWS EC2 instance and repeat everything on a real remote machine to understand how ssh works and how distributed systems behave outside your pc?
Or is your definition of backend engineering still limited to APIs plumbing?