Given an array of intervals where intervals[i] = [starti, endi], merge all overlapping intervals, and return an array of the non-overlapping intervals that cover all the intervals in the input.
🪞 Reflections
This problem felt pretty easy.
I realized mid-problem that I’d need to track the maximum endpoint while iterating
The one logic error (< vs <=) was a careless error. I didn’t find it with the one test I selected, as it didn’t come up in that problem.
Imagine that when you put one of them to cover the other, some nodes of the two trees are overlapped while the others are not. You need to merge the two trees into a new binary tree. The merge rule is that if two nodes overlap, then sum node values up as the new value of the merged node. Otherwise, the NOT null node will be used as the node of the new tree.
Return the merged tree.
Note: The merging process must start from the root nodes of both trees.
🪞 Reflections
Even though this problem is labeled Easy, I panicked a bit when first approaching it, as I haven’t spent a lot of time working on trees.
Initially, I was trying to solve the problem iteratively. When I realized there was a natural recursive solution, I regained a lot of confidence, as that solution very simple.
I keep missing opportunities to use recursion during the planning phase. Occasionally, I realize this during the implementation, which can save me from floundering with a complicated iterative solution. I should practice recognizing when a recursive solution will be natural during the planning phase to save time and avoid changing plans mid-problem.
Changing plans mid problem resulted in using incorrect variable names. This is another common consequence of making a change mid-solution.
Also, during a mock interview yesterday, I noticed the existence of a recursive solution in the middle of floundering with an iterative solution. While I pointed this out, my interviewer asked me to continue with the iterative solution anyway. 2 possible conclusions from this scenario: 1. If I identify the recursive solution earlier, I may not be blocked from changing course to use it mid-implementation; 2. Some interviewers may hold a bias against recursion, so I may need to practice iterative solutions for times when I’m explicitly asked not to use recursion.
I’m still not keeping my planning phase near 2 minutes. In this case, I think that’s because I wasn’t confident with my approach, so felt the need to plan more carefully. While that may be the right thing to do in this scenario, it’s also worth considering how to avoid this scenario.
< 18 minutes total isn’t bad, and I’m happy with my solution.
Practicing writing the iterative version felt valuable. I like my more or less mechanical approach of thinking about stack frames to convert a recursive function into an iterative one.
That said, in the iterative version, I didn’t catch several bugs during manual testing. This isn’t great. Conclusions: try to identify when I can use recursion during planning. Use recursion when possible. Continue practicing iterative solutions for the scenario where recursion is explicitly barred.