Practical Programming

I don't like Leet code and I hate grinding them. My problem with it is how rigid, boring, and dry theory-driven it is, which most of the time does not correlate with the day-to-day work of SWE. So what if we have an alternative that is a bit more practicality driven? Per title, I want to share my alternative to LC for both interview prep and technical growth

The concept

The high level is simple: Building projects.

I start with something I am personally interested in, whether I find it cool, a minor inconvenience, or maybe prototyping a concept that might be worth a startup. For me, this step is to build up the gratification and incentive to commit to a project. I recall some folks were struggling with selecting ideas that you can tie with their area of focus. For me, I found the most breakthrough usually come from outside of my own comfort zone (take this with a grain of salt though)

As always, the devil is in the details.

There are certain “north stars” that I follow to get the most out of things I work on:

Model before execution: “I came up with 100% idea, prototype 80% then maintain 10%” - Me on GitHub. Coming up with an idea is relatively easy, and so is writing code, well, spaghetti code, which yields minimal learning. A large portion of my old projects suffered from this, and now I refuse to look back at them, no matter how cool the result was. I find it so important to strategize, even just in the form of day dreaming.
Iteration over perfectionism: This is more of a mindset acceptance. Not to say you should gloss over quality but sometimes, suboptimal is ok. If it really matters, I would go back and fix it later, usually with a clearer mind (or better tools are available)
Depth and patience over result: intentionally a bit conflicting with my previous point, just so you realize there will always be tension and trade-off. The point of this is to allow me to sit and soak in the problem. If it doesn't work then why. If there is an existing solution can I replicate it? What's the gap?
Overkill is encouraged: I like to imagine my project and code will be used by millions of people. Is my code understandable? Can it scale? Can I stop malicious intent? In reality, none of my projects get to hundreds but the thought exercises is worth the implementation
Failing is learning: kinda given, but just another way of saying don't stop doing things. If I was not able to build a feature, I now learn why it is hard and at least one way it doesn't work.
Retrospectives: I reflect back on my development early and often. The hope is the next one should be better than the previous, whether in quality, experience, etc

The Example

I started my first project back in 2010 (7th -8th grade) but did not conceptualize these purposes until way later in college. Some of my highlighted projects (see attached picture) includes a retro game player, voice assistant module, smart mirrors, VR-enabled RC car, and most recently, an over-engineered personal website application.

I was quite surprised when I started taking them seriously with my a-layer-deeper approach. Turns out lots of CS were just hiding in plain sight: organizing images with different aspect ratio into a nice square? That's the partitioning problem. Highly connected data causing high delay in retrieving them? Graph database, graph traversal concept. One time I was dealing with streams and came up with an idea to sacrifice accuracy to save sacrifice speed. I then learned this was a common approach and CS was not just space-time trade-off but space-time-accuracy trade off (Redis Hyperloglog did this for years)

The Pros

I touched on it a little bit above but here are the bullet points:

You naturally accumulate competency and whatever you learn always stays in the back of your mind for a long time
You gain the ability to solve any problem incrementally, especially unfamiliar and ambiguous ones
Cool portfolio && cool stories
It is always more fun and exciting to solve these problems as they are important to you

The Cons

Probably takes longer than traditional LC training
Not quantifiable: some projects can leap you to the moon while others feel like just doing what you are told with tutorials
Sometimes you don't know if it is just difficult or unsolvable to get to an optimal solution

Wrap it up

I recently encountered a few folks that love to determine your/one's level of competency by the amount of LC you/he did, which is what motivates me to put this together. I think my main point is there are many parts to get to where you want to be technically, whether for interview practice or to grow as an engineer in general. This was my way and I wanted to share but I hope you will take a look at this and other input to develop your own 😅