Search for a command to run...
My very personal take on whether CP is important to your career
I break (and occasionally build) apps for Android. I sometimes work on backend as well. When I'm not coding, I can most likely be found watching a TV Show, a movie, playing video games or reading a book.
Agree, 90%.
In long agent conversations, Developers often lose track of how much context has been used. Tools like Claude Code or Codex have auto-compaction built in, but they compact too late. Opus 4.8 has a mil
Bottom Sheets have become ubiquitous in Mobile design across Android and iOS. If you’re using Jetpack Compose, you’ll likely implement them using either the ModalBottomSheet or the BottomSheetScaffold. The former is more used in my experience, so fur...
A task I completed that I wouldn't have (or at least, not without putting several hours into it) without Generative AI: I use an Arch-based Linux distro called Endeavour OS. It's a great OS, but lately, I've been having this issue where my computer w...
Context Receivers are a new feature introduced in Kotlin 1.6.20. They're useful for receiving the context from the call-site when a function is called. To understand it and its utility, let's first take a look at a similar feature available in the la...
Integrating Google maps into Android apps has been somewhat of a tough nut to crack for developers. With the advent of Jetpack Compose for building native UI on Android, the Google Maps team announced a Map SDK for Compose, available here. However, i...
Before we start, I'd like to clarify where I'm coming from. I like Nikola Tesla, Guido van Rossum and Steve Wozniak. Money is important, but it's not as important as doing good engineering.
I want you to know where I'm coming from, because my opinion will be heavily influenced by my background and my goals. I want to be a good engineer, first and foremost. Money comes later.
Competitive Programming, generally shortened as CP, aka Sport Programming is as the name implies, a sport. It's like a puzzle, a mental exercise, something to tickle your brain. You're given a problem, and you have to solve that problem while facing a set of constraints like limited time, language choice and coding environment. Competitive Programming as a sport has existed for about 3+ decades, and is supported by nearly every tech company on the face of the planet.
Why do people like solving Sudoku? It engages your brain's higher functions, stimulates it, and makes the time pass. If you do it long enough you also become really good at it, and can apply the skills learned from it elsewhere in life too. Same goes for competitive programming. When you get in the habit of building solutions quickly within a set of constraints you're basically preparing yourself to do it more and more in real life, making you a better engineer and problem solver. And, if you have a good competitive programming rank, you'll probably get noticed by big tech recruiters.
Competitive Programming evolved from a sport which people used to enjoy in their downtime to something that is seen as an entrance to the Big Tech companies now. While this is true to a degree, there are other methods to get into Big Tech. One of them is to just be an excellent engineer. Make good apps, or contribute to open source.
The Software community for the most part is as divided on CP as they are on vim vs emacs. There are fighters on both side of the camp and both provide very good arguments as to why their side is correct. Generally, the points that the opposers of CP present are:
My biggest gripe with CP is probably the first point mentioned above. If you ever want to see it for yourself, look at Google's HashCode's problems. They're inspired by a real life engineering challenge that Googlers faced during their day-to-day, and your CP macro tricks won't help you solve them, at all.
Practicing solving problems is a crucial professional skill for any engineer. But, CP isn't an accurate reflection of the problems that you'll face day to day as an engineer. You'll be more concerned with the overall system and structure of the problem and your solutions will range from thousands to hundreds of thousands of lines of code. But that does not mean that you should absolutely stop solving any algorithmic challenges.
Most of the people in colleges, when they start off with problem solving, will head straight to something like Codechef and start taking the challenges. That's good. Solving those puzzles is a valuable skill, but again, it's not reflective of the kind of problem solving you'll be doing in your professional life later on. Build an app, and tackle the bugs that'll inevitably come with it, and that, in my opinion, will make you a far better engineer. Still, solving these challenges is crucial. Why? Because you most companies will give you these challenges during their interview round, and having lots of practice is a good thing.
CS is one of those fields where the interviews are generally tougher than the actual job, so it makes sense that you'd want to practice under the same constraints. But, that's where the differences between Leetcode and Codechef become even more apparent.
When you're on Codechef, solving a challenge, your target is to get an AC (Solution Accepted). You're much less concerned with how you're solving the problem, and whether you're using the correct methodology or not. On the other hand, interviews are not competitions. You'll need to design a good, readable solution that can be communicated properly to the interviewer. Leetcode will help there, since the problems are more foundational in nature, and the focus is on writing clean, structured code without constraints. In an interview you'll probably have some time limit, but even then, the environment will be much more relaxed. You'll get hints from the interviewer along the way, and communication is vital. All this gets lost when you're doing pure CP on Codechef or Codeforces.
Because I'd rather be building apps. I like building apps. Even since I played GTA:SA for the first time, I wanted to build cool apps and games, and that's what I do. That's precisely why I'm in this field, and I feel like building is a more appropriate use of my time.
We're going through campus placements right now, and the lack of practice in solving coding challenges is really apparent to me. I can get through the easier, foundational problems just fine, but when deep concepts like Dynamic Programming and Backtracking are required, I'm of no use. This hurts my chances, I know, and I'm always thinking about doing more Leetcode and solving some challenges, but then again, I can never bring myself to actually do it. Why? First, because they're difficult, and quite demotivating. Second, I am lazy. That's it. It's not like you can't build apps and solve one problem on Leetcode daily.
If you like competitive programming, good for you. You've got a bright future ahead. If you're like me, and think that sport programming is not a good fit for you, build. Keep building good apps. Contribute to open source. There are companies now that hire on the basis of take home assignments and how you tackle an engineering problems rather than having your draw an algorithm on a board.
If you want to get into Big Tech, I have some sad news for you: you'll need to do Leetcode. There's absolutely no other way around it. The way their assessments work is centerd on solving these algorithmic challenges, where they want to see how well you can design a solution to a problem. Aim to do anywhere between 1 to 3-4 problems on Leetcode daily and you'll be fine. Just keep in mind, that this is not a competition. Focus on writing clean, structured, modular code, and try explaining your solution to people. That'll help more than doing CP.
Doing sport programming boils down a lot to your personal preferences. If you find it stimulating and interesting, by all means, devote your time to it. But, don't do it just because you think it's a gateway to big tech companies. There are other ways to get in, and besides, being a good engineer is far more important in my eyes than working at MAANG. That being said, do try to solve a couple questions daily on Leetcode, but remember to build a clean, modular solution with good conventions. They'll certainly help with your technical interviews.