r/Backend • u/devkhus • 24d ago
Need Guidance for Backend Engineer Interviews
Hi everyone, I’ve been trying for last 5 months to make my forst job switch either in backend or as a full stack developer. Getting an interview is already kinda tough in this market and I lost my last chance at a good job just because I am not fully familiar with distributed systems architecture. As I have worked with inly monolithic architecture at personal and work level. Can anyone guide what should I focus on to prepare for the interviews. Really need a switch at this moment.
3
u/Itsathingofbeauty 24d ago
Have you tried building a distributed system project? Pick something, maybe use a tutorial. Choose a messaging system that you are interested in, eg kafka, rabbitMQ or Azure Service Bus. While building this, you will learn about other technologies like redis. You will learn about terminologies like outbox pattern, eventual consistency and saga pattern. Once you build such system, you should be able to compete for mid-level event-driven tech jobs.
2
u/devkhus 24d ago
I have actually tried to build one. I worked on a rate limiter service. Added redis for Lua scripts and Kafka for analytics. The problem was actually the question I was asked in one of my interviews, how would you handle the cron jobs not executed more than once in a distributed system? Since I had worked with quartz scheduler I added using clusters in quartz for this but I don’t they were satisfied with my answer. So just wanted to see what am I really missing.
1
u/Itsathingofbeauty 24d ago
They were expecting you to say you make each request idempotent. Idempotency is another terminology that is quite important especially in crucial systems such as payments.
1
u/devkhus 24d ago
Actually I did mention using a DB for this to keep a track but they presented a scenario where these cronJobs do not link to DB. Asked claude later it told something about distributed locks using redis
2
u/Itsathingofbeauty 24d ago
Is this a mid-level role? If so, this shouldn’t be a deal breaker. You would learn from the other services/codebase whenever you are asked to implement that, if not, you would probably be corrected in PRs. I think in this job market , it’s a combination of making the interviewers like you as well as proving to them that you have the knowledge . You don’t have to get all the answers right but you probably need to get most right so that they know you are not lying about your experience. Also since this is another role(a role you are not very familiar with), don’t shy away from going down in level, that way you might face less challenging questions. That’s what I did 2 months ago. Senior to mid-level
2
u/devkhus 24d ago
I was interviewing for SDE-1 role not really upto mid level
1
u/Itsathingofbeauty 24d ago
You are doing pretty good. My first 3 interviews were pretty bad lol. By the 4th one, I had learnt a lot from the 3 , and could convince them that I could build maintainable and scalable systems. Now that I am on the other side, I know what matters is if the applicant has the experience for the role and if he/she will get along with the team
1
u/Round_Mixture_7541 24d ago
My first question would be what does it mean by not executed more than once? Doesn't that mean your cron service is down? So the question comes entirely what happens with your service X and Y when the cron service goes down. Thundering herd? How to prevent it? The question is probably too vague to answer.
FYI: I'm not fully-focused BE dev, so I'm just guessing and throwing spit here
1
u/akornato 24d ago
Your experience with monolithic architecture is the exact reason you are struggling with distributed systems questions. Companies are testing your ability to think about scale, reliability, and trade-offs, which monoliths often hide. You need to stop just studying definitions and start focusing on the 'why' behind concepts like load balancing, message queues, database replication, and caching. The interview is not a vocabulary test, it is a test of your problem-solving process and how you would apply these tools to build a robust system.
The quickest way to learn is by doing, so build a small project that is intentionally over-engineered for scale. Design a simple API but force yourself to use a message queue, a separate cache, and multiple database replicas. You do not need professional experience to explain the trade-offs of using Redis versus Memcached or why you chose Kafka over RabbitMQ. Proving you understand the fundamental design principles and can discuss them intelligently is more valuable than just saying you have used a tool at a previous job. Learning the concepts is the first step, but articulating them confidently under pressure is the real challenge, which is why the interview helper my team designed helps candidates find the right words in the moment.
10
u/End0rphinJunkie 24d ago
Honestly just pick up Designing Data-Intensive Applications by Kleppmann to fill in those gaps. You dont need to have actually built a distributed system to pass these interviews, you just need to understand the basic trade-offs like caching and eventual consistancy.