The recruiter assured me that they will get back to me in 5 working days regarding the offer. On the 4th day, the recruiter called me and said that they won’t be making an SDE-III offer and if I’m interested they could find me an SDE-II opening which I politely refused.
Last 10~15 minutes, he asked me about a system design problem which most likely is something that he was building or already built. I didn’t like the idea of getting thrown a system design problem in the final minutes of the interview. It took at least 5 minutes to get the requirements clear enough to start putting things together. Due to lack of time, I couldn’t go deeper into one of the main use cases and I hurried into the approach I would take while the next interviewer was already on the call and waiting. If I had time I would have given him several better options but what a bummer! Seriously, who on earth designs systems in 5~10 minutes?
In the second half, he asked me a medium coding problem which was a slightly modified form of a typical DP question. I asked him lots of questions to make sure I clearly understood the problem. I was confused about whether it was a Greedy or DP, so I discussed it with the interviewer. He asked me to write the code for the greedy solution but I found a bug a bit too late and realized this was a pure DP problem! The interviewer said greedy would work for most cases and asked me what my DP code would look like. I gave a verbal explanation of how I would write the code and he was happy with that. I felt it went OK except for the last-minute realization that I took the wrong approach to the coding problem.
I applied on LinkedIn and within a few days, I received an email from the recruiter regarding a screening interview. Once I confirmed the dates, the screening round was set up with an SDE-III engineer. All the tools used during the interview were mostly in-house. The round started with a basic introduction and the interviewer quickly gave an overview of what the next 1 hour would look like. He started with a string-based coding problem that I could straightaway identify and gave a solution using the Trie data structure. I had to code up a Trie from scratch and completely solve the problem. He found some minor bugs which I could instantly fix and he was happy with the code. He then improvised the same problem to expose it as an API and asked me to scale it to handle lots of requests. We talked very high level about running multiple instances of trie as a service, load balancing and caching requests, etc. After this, he briefly touched upon some behavioral questions where he asked me about situations where I made a wrong design choice. Overall, I think did very well and I was confident that I would make it to the onsite rounds.
For coding rounds, it’s a bit unfair to ask lead-level engineers to write code to invert a binary tree or reverse a linked list when time is limited. Even when you are a junior engineer you will never face such situations. To make matters worse, you are supposed to do it on a notepad-like tool that has no autocompletion or syntax highlighting! The only way to clear these is by exhaustively practicing data structures and algorithm questions for at least a month or more on websites like leetcode, hackerrank, etc. There are a lot of debates going on around such interview practices in the developer community. I feel the emphasis should be given to how we approach the problems and the ability to think out loud.
This was my final round and it was again with an SDE-III. Again, the first 30 minutes were dedicated to behavioral questions from past projects. He asked if I needed a chance to discuss any high-impact projects which I might have missed in previous rounds. He touched upon the following scenarios: