How do I fill my knowledge gaps while interviewing?
Hello, I'm currently actively interviewing and more than once, I found myself not progressing due to some knowledge gaps on things that companies seem to expect at my level.
I worked as a backend engineer for 3 years after a coding bootcamp, mostly in product features and APIs. Distributed systems is not something I did on a daily basis.
I have struggled with system design interview questions asking about databases, concurrency, search, among other things. How can I fill those gaps to the level I can pass these interviews?
Here's what I'm going to do, and I'm looking to get advice on whether I should do, stop doing, or do something else that I didn't list.
- Stanford Databases courses (5 total): https://www.edx.org/learn/relational-databases/stanford-university-databases-relational-databases-and-sql
- Read "Understanding Distributed Systems" by Roberto Vitillo
- Practice system design interviews with a partner
Thank you for your help!
Discussion
(3 comments)- 53 months agoTech Lead @ Robinhood, Meta, Course Hero
I highly recommend you start attending the Book Club for "Designing Data-Intensive Applications" by Martin Kleppmann. Here's the next session: https://www.jointaro.com/event/taro-book-club-designing-data-intensive-applications-chapter-12-the-future-of-data-systems/
Your instinct about mocks is also correct. System design interviews are effectively behavioral interviews with a technical wrapper (it's less about getting the "right answers" and more about having an intelligent discussion about trade-offs). This sort of stuff is inherently hard to fully study for as a lot of the hiring signal comes from the flow of the conversation, not the content you gave within it.
Lastly, I have another piece of "meta-advice" here: Avoid over-indexing on failures:
- Interviewing is inherently random as there's no standardized process across companies.
- This means that you're just going to get "gotcha", one-of questions sometimes where there was really nothing you could have done to survive.
- The risk here is that you spend a bunch of time to patch up those "gotcha" holes which could have been used to bridge more fundamental gaps instead.
- It is impossible to pass every interview, so all time spent has opportunity cost. Your strategy should be to extrapolate patterns and adjust accordingly.
- Here's a story about this from my past: When I was starting my career, a company asked me super narrow Java trivia. I got blindsided by it (and then promptly rejected), so I was quite salty about it. I then spent a lot of time learning this narrow trivia with the goal of never failing this type of interview again, and it turned out to not be very useful as my future interviews didn't really cover it. This company that rejected me is now dying with their stock down 99.7% since IPO (it probably would have been terrible to start my career there).
I'm not saying this is happening to you right now - Just that you should keep an eye on it. Your strategy should be to keep track of all your interviews (I recommend having a spreadsheet) and looking for the most common areas where you're failing. If 3+ interviews got you on the same weakness, definitely shore it up.
I highly recommend these 2 as well:
- 13 months agoMid-Level Software Engineer [OP]Taro Community
Thank you Alex! Love the meta-advice. As someone new to these interviews, and without fully understanding what's a pass v. not, and given how the performance on this interview affects final results, it's been difficult to figure it out. I will join the book club if possible (still ok to join mid-book?)
- 03 months agoTech Lead @ Robinhood, Meta, Course Hero
I will join the book club if possible (still ok to join mid-book?)
Yep! We'll even be doing a rerun of "Designing Data-Intensive Applications" soon as the current run is winding down, so you can start back again at Chapter 1 🙂
