The interview had two interviewers who came on together. They said they were hiring for different teams, so both of them figured they'd sit in and take a look.
The original problem turned out to be an exact match for one I recognized by name, word for word — but I had actually never gone through and solved it myself before.
My approach wasn't too far off: try to store the interval information, then use binary search to decide, and add/remove/query depending on the case. But because I was working it out completely from scratch in my head, what I actually wrote ended up looking pretty different from the clean version.
Compared afterward to the most optimal, most compact version I wrote with AI help — sticking closer to my own way of thinking about it (I'm not a big fan of LeetCode's Python editorial, honestly) — during the interview I had written two separate arrays, range_hi and range_lo, when really you only need one flattened array. You can also judge things more easily just by whether the returned index is even or odd.
I wasn't all that familiar with the exact behavior of bisect_left versus bisect_right, which made splitting up the possible cases and handling the edges way harder and more annoying than it needed to be. During the interview I ended up writing a bunch of complicated if/else branches just to figure out whether I should be looking at index i, or i-1, or i+1.
I also used a while loop to figure out which side's boundary needed to get deleted because of a merge, when really you just need two separate binary searches — bisect_left for the left boundary and bisect_right for the right one.
Afterward, even looking at the optimal solution's edge-case handling, it took me a good while to really follow the reasoning and understand it. It's the kind of problem where the code itself is simple, but it's really hard to fully convince yourself the logic is correct just by writing it down — kind of like some greedy problems feel — you need a genuinely clear head to cover all the cases. For me, that was the hardest part of this Hard.
Lesson learned: when you're answering in an interview, you really do need to step back and think through the overall approach first. Getting stuck deep in if/else branches built on the wrong way of splitting up the cases is deadly.
The interviewers seemed fine, though. I'm assuming I failed, since I didn't even finish writing something that actually ran and passed.
They'd mentioned at the start that they might ask two questions, so at the end I asked whether both questions would be around this same size. They said it's because someone who had already practiced this exact problem before could write it up really fast.
Discussion
Loading comments…