Status: 7 years of experience in two small companies
Location: Remote
Date: April, 2021

Interview Process

Phone screen (1 hour), 3 medium problems. The interviewer was clearly not interested at the beginning and he was playing with his phone after asking the coding problem while I was coding. I solved them fast enough that the interview debated at the end whether or not to give me a 4th problem and he decided not to and just use some remaining time talking about different variations/optimizations. How would you solve this non-recursively? What if we know the input is sorted? I was pretty sure that I would pass at this point.

Onsite has 3 coding rounds, 1 system design, and 1 behavior round, with 1 hour each, and 1-hour break in the middle. A total of 6 hours. Details below:

Round 1

2 medium coding problems. I wrote about 200 lines of code during this round. The problems are not hard, but speed is definitely very important here. Again, the interviewer is playing with her phone in between and I had to repeat things at times. Not very good interview experience here. But I get that it must be boring if you see candidates implemented this over and over again.

Round 2

A lot of standard behavior questions that you can find online around disagreements, tight deadlines, impactful projects, failures, learnings, etc. It was a relaxing conversation for me since I have been reflecting on my own work for weeks before the interview.

Round 3

Two medium coding problems. But my brain does not remember any more details somehow. The only thing that I remember is that he didn't play with his phone which I highly appreciate.

Round 4

System design. I was very nervous before this round. I knew it had the highest uncertainty. But I found the problem easy since I thought about a few similar problems before. I've talked about load balancing, sampling, databases, distributed message queue, socket connections, caching, capacity planning. The interviewer didn't ask for many follow-up problems. He said he would let me drive the conversation at the beginning of the interview. And that was what I did. I talked a lot about all the different areas that I was familiar with. I was probably talking 90% of the time during this round if not more.

Round 5

Two medium coding problems. We spent a lot of time testing my second problem since it was binary search and it wasn't particularly easy to validate that and I did have bugs. But it was the end of the day, and my brain was numb. I knew I finished 2 problems so I didn't try to rush it. And I knew this interviewer was less experience (according to the recruiter) so I was very patient with him too.

Preparation/Suggestions

It is important to know coding well and fast. I prepare them by always putting the problem that I see under a category. I find it helps a lot to identify the optimal solution quickly. Here are the categories that I have:

• array + string
• binary search
• 2D matrix
• bit operation
• data structure design
• dynamic programming or memorization
• greedy
• hash map or hash set
• linked list
• math
• min-max optimization
• monotonic
• NP problems
• ordered map
• priority queue (heap)
• recursive
  • DFS
  • BFS
  • tree
  • graph
  • back tracking
• sliding window
• soring
• stack
• two pointers

It may not be a perfect categorization and there are sometimes overlaps. But this is what works for me.

System design can be prepared too. But it is just less structured. I watched endless hours of videos and also I have been thinking about all the systems over and over. I think those help. Also, it is important to be familiar with all the different topics around system design. Just as an example, a load balancer is not sth that I would ever have to deal with at work. But I need to know about them for the interview. Web socket is another example that I would not have to think about since it just doesn't fit the business need for my current company. I think that may be why system design felt so complicated and intimidating since you'll never know what you'll get asked. And more likely than not, the problem is not sth that you are working with day-to-day. Therefore, I think it is important to put in the time to prepare for them too.

Systen design is everywhere. To name a few: a bank, a two-player chess game, multi-player game, Twitter, messenger, slack, mint.com, YouTube, Dropbox, Google Translate, Movie/Flight/Hotel Booking System, ... If you add "Design" in front of the any of these names, it becomes a interview question. It can also be smaller, focusing on just a feature. For example, how do you design rate limitter, live ranking, trending search, video update, etc. For these, they can become system design questions like "How do you design XXX for XXX". For example, "How do you design live ranking for leetcode?". Things to think about more for any systems: How do you scale this to 1 billion users? How do handle spiky traffic? For each box that you draw, how do you handle failure? Follow up questions are always around these.

Finally, be very serious about your current work. Not only it is your responsibility, but it helps in behavior questions. Other interview questions are not related to your current work, but behavior questions are all about your work experience (current or past). And what's more, it is very important for leveling, which sets the band for your compensation. All in all, try to build great products, handle conflicts properly, communicate well with your peers, help them and mentor them if you have the chance, learn from your mistakes and improve, ...

Best of luck!

Edit:

Sorry, I made a mistake on the durations. The screening interview was actually 45 minutes. Same as the virtual onsites, each round was 45 minutes with a 15 minutes buffer.

But I often ended up using 5 - 10 minutes extra in asking various reverse questions to the interviewer at the end. That would be another advice, always come prepare to ask some questions to the interviewer. Sometimes it is a way for the interviewer to tell whether you are interested in working there or not. On the other hand, it is an opportunity for you to learn more about the company that you might be potentially working for in the next 4 - 5 years. If you are lucky enough to have multiple offers at hands, these information will all help you make a better decisions for yourself. Here are some questions I used:

• which team are you on?
• what's the most exciting project that you shipped in the last year?
• what projects are plan for the rest of the year?
• how many people are working remote?
• how roadmap is defined? how is work created and assigned?
• is there product managers, designers, or data scientists in your team?
• how do you meansure success in the team?
• how often do you collaborate with other teams?
• what's the process like to switch teams?
• what is the oncall schedule like?
• what's the tech stack?
• what do you like the most working at X (and dislike the most)?
• ...