Blind 75 is a list of 75 Leetcode questions that efficiently covers a large breadth of patterns that top tech companies generally look for in their coding interviews. In theory, solving these problems would expose the best number of topics and really get someone well prepared for any interview they're going to take. We all know how many Leetcode problems there are and how disorganized they can be so having this condensed list is a huge help for people looking to make the best of their study time.
My personal goal is to go through these questions to refresh the stuff I used to know and learned from college. I think it can only be a huge positive for my professional career, even if I'm not going for top tech companies. I know for a fact at my current position, having these solid fundamentals down is going to help a ton.
The only thing that's really a negative about this is how much time it's going to take. It's going to detract from all the other things, like working on this website for example. But the way I'm thinking about it is, knowing this stuff should really be a foundation to my programming. I really should know this stuff, whatever my goals may or may not be.
Some rules. Going into these problems, I'm going to try solving them blind first. If I can't solve it blindly, I'll note it down. I'm going to try figuring out an outline of the patterns I'll need to use to find the solution. I'll also look for edge cases before I attempt to solve the problem. I'm also going to try getting the problem statement digested as fast as possible and come up with a few cases. These problems are timed so I'll spend at most 30 minutes trying to solve it blindly. I'll be solving these in Python.
After getting through the problem, I think it's also important for me to go back and look for improvements.
I wanted to add a blog section to Sapling Corp as a way to communicate, but also to organize my thoughts and start a mindset of adding new features or changes to the website. The content here will be for smaller ideas that won't really need a whole journal page. I hope that it'll help me be really intentional with how I spend my time generating content on here because in the past, as other engineers often do as well, I sometimes spent way too much time optimizing small things, or working on features that shouldn't really have been worked on.
This extra layer of planning or "role-switching" will hopefully prove to be beneficial for the times to come. It's a policy I actually want to explore and write more about in the future in terms of how beneficial it is for making any work quality better.
I also leveraged this idea of role-switching when I designed the blog page. Although it's simple, I'm proud of the design I came up with. I wanted to come up with something blue and cold so that the reader gets a sense of being alert when going through this section. I also went with a monospace typeface to invoke that raw, developer feel. To achieve that effect of role-switching, I came up with the design entirely on Photoshop before working on the implementation.
To continue with this idea of role-switching, when writing future content for this page, I want to hold myself to make some guiding questions first before I write anything. It'll help come up with engaging things to write about that I might not have thought of, but also give a focus to what the blog will be about. I'll also try to leverage AI to help come up with these questions.
Hoping that this page looks completely different in a year from now!