ShareChat | SDE2 | Bangalore | REJECT

Round 1: Online Assessment

My interview process for the SDE2 role at ShareChat in Bangalore started with an Online Assessment. This was a Hackerearth-based test with 3 coding questions, lasting 90 minutes. I found this to be the toughest OA I've ever taken. I don't recall the exact problems, but they involved concepts like TreeMap/Binary Search, Graph problems, and 2D DP on a tree. I scored 210/250 in this round and was invited for the first virtual onsite interview.

Round 2: Virtual Onsite 2 (DSA)

This round began with a brief introduction. I was given two questions:

1. A medium-hard Tree-based DP question, which wasn't available on LeetCode or GFG. I struggled a bit initially, but the interviewer was very polite and provided a hint that helped me solve it.
2. An easy-medium question: Design a data structure with O(1) add/delete/getRandom(). I had previously solved this LeetCode problem (Insert Delete GetRandom O(1)), so I explained my approach and coded it efficiently.

I wasn't required to run the code on an IDE but was expected to dry run sample test cases for both problems. An hour after this interview, I received a call confirming I had cleared it, and the LLD round was scheduled.

Round 3: Virtual Onsite 2 (LLD (apparently))

This round was incredibly frustrating and made me lose confidence in the process. The interviewer was 10 minutes late, didn't turn on their camera, and surprisingly, posed a High-Level Design (HLD) problem instead of the communicated Low-Level Design (LLD). When I pointed this out, I was met with the response, "How does it matter, are you not prepared for HLD?".

Throughout the discussion, the interviewer seemed uninterested, requiring me to repeatedly call out "hello hello" when asking questions or seeking feedback. The core question posed was: "How will you add/remove servers without downtime?".

I immediately thought of consistent hashing and began explaining the concept, using draw.io to illustrate the ring structure, redundant/virtual servers, and k hash functions. To my disbelief, the interviewer stated, "you are just throwing words at me, I do not understand why you are talking about hashing in a System Design interview?". I tried to re-explain how consistent hashing directly solves the problem of downtime during server scaling, even referencing Gaurav Sen's video as an excellent resource.

However, the interviewer abruptly ended the discussion with, "Please accept that you're wrong, do not keep repeating about hashing, I was not looking for this answer." When I asked what they were looking for, they simply said, "DB sharding." This left me utterly confused, as DB sharding didn't seem relevant to the problem of adding/removing servers without downtime. They refused to elaborate further, wished me good luck, and disconnected.

After this, the HR, who had previously been very responsive, ignored my messages and calls for a week. Eventually, I received a generic rejection email. This experience was a harsh lesson, highlighting that even thorough preparation can't account for a problematic interviewer. I've since come to terms with it, recognizing it's better not to join an organization whose representatives behave in such a manner.