Hello,
Wanted to give back to community. I was given the opportunity to do a L4/L5 loop. 1 System Design, 1 coding, 2 coding system design, 1 googleyness.
-
System Design Round #1
- Q: Design Google Docs
- Started off with requirements, use cases, customers
- Asked a lot about who was using it, how they were using it, etc
- Got all of the REQUIRED features: functional. All the non-functional that we needed to address. Spent a lot of time here trying to figure out exactly what we were doing.
- Talked about workflow from user's perspective and our perspective
- Began with how it would look from customer side, how the workflow would be utilized, how the data (user interaction) would look like
- Talked about what about from our end. What would happen when the user opened up the document, what would that look like in our backend
- High-level design
- Talked about our required APIs that we might need and what they would initially look like
- Talked about what our DB should look like (very high-level). What we SHOULD be storing and what were some of the trade-offs for choosing this particular design
- Talked about some levels of bottle-necks. Are we okay with it? How do we improve if we're not okay with this?
- Low-level design
- Spent well over 15-20 minutes talking about just the database. We dove into every single table for the SQL side of things (how do we know each document belongs to this user, how do we know we can allow this user to access the document vs that user). We talked about chunk-ing (breaking up) the document into manageable pieces so that we don't overload the servers with crazy changes. We also talked a lot about how we wanted to store the chunks of the files (debated between NOSQL vs SQL). How do we rebuild this when the user is grabbing the document for the first time? How do we update the DB while more than 1 user is updating the document?
- We spent some time about the APIs, but they were pretty happy with just some of the high-level design of it.
- We also spent the remaining time talking about concurrency since we have a lot of users that can access 1 document and all change it at the same time. How do we know the sequential order of it? How do we want to handle bringing that "real-time" data of changes to all of the users watching another user updating the doc? Should it be near-instant? Is that feasible?
- Overall: Felt okay. Struggled a bit with deeper systems design knowledge. Interviewer seemed like they had "better" things to do or were being "prestigious" about this. Every time I asked a question, they would not really answer it. Kept saying, "that this is your interview and you should be able to design this system".
- If I had to score myself: 3/5
-
Pure Coding Round
- Q: https://leetcode.com/discuss/interview-question/382955/airbnb-phone-screen-find-strings-that-differ-by-1-character
- Something similar to this.
- Spent the first 3-5 minutes clarifying all the inputs, what was needed/wanted, and edge cases/inputs that we should consider.
- Began discussing the brute force. Interviewer asked me to reduce it.
- Began discussing some potential solutions. Got stuck at this part for a bit. I was trying really hard to get the Trie method going, but they wanted me to think simpler. Ended up thinking about pre-processing all strings with a "special" character to replace the actual character since we only needed to see if there was a difference of 1.
- Overall: Felt okay. Definitely was able to solve the solution, but it did take about 1-2 hints (don't remember exactly). Interviewer was being collaborative, so definitely enjoyed the round.
- If I had to score myself: 3.5/5
-
Coding System Design #1
- Q: Design a Restaurant Waitlist that can perform 4-5 functions that was given.
- Overall: I felt great about this round. Felt like the interviewer was really collaborating to get this problem solved.
- If I had to score myself: 4/5
-
Coding System Design #2
- Q: Design a Customer Agent System that can schedule the next customer, resolve the customer's ask (run given customer function
f), and if full, give the customer a waiting time. Each Agent operates at different time (finishes a customer's request differently). However, if the number of customers exceeds the number of agents, let the customer know how long until the next agent is available.
- Follow-Up: How do we handle if an agent needs to take a break? Or if an agent got interrupted halfway with a customer's request? (this is basically resembling servers that go down in prod)
- Overall: Felt good. Definitely solved it utilizing the approach. Follow-up was more of a discussion. Interviewer was awesome to work with. Friendly and was collaborative.
- If I had to score myself: 4/5
-
Googleyness
- A lot of behaviour questions. Not just tell me about a time, but a lot of follow-ups to see if you were bsing the answers.
- A lot of back and forth conversations, rather than just Q&A.
- Overall: Felt pretty good, interviewer was friendly and kept the conversation going. Definitely think that some of my answers could've been prepared more.
- If I had to score myself: 3.75/5
Google's interviewing process is a lot different than the other tech companies I've interviewed for. A lot of the questions are variations, but not straight from LC. They really stressed that I collaborated and communicated with them rather than just regurgitate algorithms, which was super refreshing. Besides the 1st interviewer, I felt like everyone was actually trying to gauge my skillset for L4/L5. They all asked really great questions to help challenge my answers/designs.
Overall, I don't know. I felt good in some rounds, okay in others. I know that Google demands a lot of strong hires to even be considered. I'm just going to keep my expectations low. Good luck!
UPDATED RESULTS: Passed both HC. Team matching over the next couple of weeks is what I am hearing