There is a lot to be said for the entirety of your question, but i'll try to focus on this since it stood out to me (plus the interest of time): >System design

There is a lot to be said for the entirety of your question, but i'll try to focus on this since it stood out to me (plus the interest of time): >System design rounds require me to solve problems that the top engineers in the world spend months on. One question I was asked was "How do you make sure that a celebrity's tweet reaches all of her followers in less than 3 seconds?". I had no idea, I have never handled that kinda scale. In fact most of my work experience is kinda vanilla and boring, so I generally have nothing much to draw on or much to talk about. System Design rounds are going to be difficult. The idea isn't to give a correct, complete answer. It's to see how well you can reason about a hazy problem based on your current knowledge. Bram Cohen who wrote BitTorrent has this to say: "My suggestion for learning software architecture is to practice. Obviously you can't practice it by doing hundreds of projects, because each one of them takes too long, but you can easily design a hundred architectures for problems which only exist on paper, and where you strive to just get the solution to work on paper. Start by modifying the requirements of a problem you're working on. What if the amount of bandwidth or CPU was a hundredth what it currently is? What if it were a thousand times? A million? What if you had a thousand times as much data? A million? A billion? What if the users were untrusted and you had to either prevent them from damaging the system or have a means of fixing things when they did? It doesn't matter if these scenarios are totally unrealistic, what matters is that they're different and that when you try to find architectures for handling them you take the inputs just as seriously as if you were about to start writing a system with those requirements for work. Try to find as many different approaches as you can, and come up with scenarios in which the stranger ones would be better." [1] Secondly, "vanilla and boring" is a moving target. That question up there would for the most part be vanilla to senior backend developers, a little more than trivia and a waste of time. You cannot say "I never handled that kinda scale". This is the wrong mindset to apply to any sort of problem solving. Start with what you know and get to the point where you have a list of knowns and unknowns. And for heavens sake, you have a massively powerful search engine. "Writing scalable systems" should be a query in your head right after you think "I don't know how to scale". Talk about your vanilla and boring work. If you think it would make you feel better, focus on how it impacted the customers or whoever. It's perfectly fine to work on non-world changing things. Lastly: >I'll preface this by saying this field has never been my passion, just a profession I like. Probably a healthy mindset, considering the amount of people in this field who chose it as a means of escapism from the hardships of every day life and convinced themselves in the process of coping with trauma that it's a passion. Passion isn't a requirement for good work, but some time spent learning the tech and being analytical in thinking about problems goes a long way. And to answer your Q, ideally you should only quit if you don't like the day to day work and related reasons. Interviews don't represent this at all. It's mostly idiots on an ego trip. [1] https://bramcohen.livejournal.com/4563.html https://bramcohen.livejournal.com/4563.html