I hear you on the ludicrous breadth of knowledge that is expected. I recently went through the interview loops of several large tech companies. This time around

I hear you on the ludicrous breadth of knowledge that is expected. I recently went through the interview loops of several large tech companies. This time around I decided to study leetcode only a little bit and to lean more into my experience during the interviews and it worked out better for me. Here's the biggest key to interviewing at senior+ level, I think. In the past, I think my tendency had been to assume that the interviewer was looking for one right answer and to try and meet them where they were. This time around, I would openly say that it depends on which context you're talking about. If someone asked me to design Twitter, for example, I could do it as a CRUD app with a web front-end, a microservice that's essentially an adapter to a SQL DB of some kind, pretty easy. So I would just say that. "If you are just starting out, this could easily represented this way and it could support you into thousands of users..." Then I would leave it on them to ask more questions about how to scale it up. I'd mention that you could carry the DB farther by using read replicas if you accept that not everything is in real time. Then we'd start to eventually talk about potential solutions for getting more realtime data like Firebase, but we'd talk about where in the stack is that really necessary or appropriate and at what scale. I found pretty good success this way, rather than starting with the most complex solution, instead starting with, basically, the simplest, and easiest to get going initially.