+ 937 (div. 4) + +
+
+ ~1300 performance. Consistently finishing E, getting F occasionally.
+
+ -
+
- + B: took me way too long because I just wanted to code. Wasted 5 + minutes when I know better—patience and a formula got me + there in 30 seconds. + +
- C: submitted without rigorously checking all edge cases. +
- + D: misunderstood the problem statement twice. Polya and Zeitz both + advise to fully understand exactly what the problem statement is + asking, whether through direct analysis or examples. Then, I + messed up the brute force. However, I did notice that raw + recursion would not TLE based on the fact that each number can be + divided in only a few ways. + +
- + E: I knew a number didn't have that many divisors but the + implementation took me too long. + Pay closer attention to the constraints and just solve the + problem.. Spend a bit more time on implementation, + even if you know a way that works. Here, I knew an approach + to code but it was easily error-prone. + +
-
+ Immediately came up with the idea but was unable to express it in
+ code. This means I did not fully understand the problem, namely
+ with some core mistakes:
+
-
+
- The tree it not necessarily binary +
- + C's cannot have children, so tracking depth/available nodes to + fill per level is crucial + +
- + Coming up with the expression \(a=c+1\) (and ensuring the + input conforms to that) is a lot easier than cusotm coding + logic to ensure levels are filled out properly. The core + problem is that I lack the mathematical prowess to be certain + of what exactly I need to check after I make that assertion + and why. In this case, it means that the number of C's is + appropriate, so I never even need to check them—I + just need to make sure that the rest of the solution is valid. + +
+
+ Impatience is holding me back. Lack of discipline and focus is + holding me back. It doesn't just harm my+ranking+ problem-solving ability but it + prevents me from improving. +