If you are already a subscriber, jump ahead to the good stuff! But if someone forwarded you this email, they probably love It Depends and think you would too! 

Subscribe now!
#46: Competitive programming is useless

You can listen to this episode on SpotifyGoogle, or Apple

Hello Everyone!

Welcome to the 46th episode of It Depends. Hope everyone is doing well and staying. Today we are going to talk about competitive programming, and then it is the best of the internet as usual.

Competitive programming is useless

This post is a rant. I know that this is not true of every company and or every engineering student. But it is widespread enough in my experience that I find it worth ranting about.


Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless. Unfortunately, companies and students are both headed in that direction at the moment instead of looking for engineers with broad interests.

From competency to fetish

Competitive programming started out as a good thing. When I was in college, there was no leetcode or equivalent websites. I think GSoC had just started out and only the “rockstar” programmers used to participate in that. Or maybe this was just the situation in my college – I don’t know. By and large, my class got by without writing much code, much less code of the type one might encounter in a real job. I and a few others who genuinely enjoyed programming ended up doing a variety of projects on our own and learning things that way.

The leetcodes and geeksforgeeks of the world filled a critical gap between textbooks and hands-on exercise. They provided a convenient place to see the kinds of questions asked in interviews and practice solving them. And then something went wrong. With growing access to these questions, interviewers started asking harder and harder questions in the coding rounds in college (and generally <5 years exp.) interviews. The expectation for these rounds is currently, IMO, meaningless. We left competency behind and are now well into fetish-land.

As a response, college students now pursue competitive programming obsessively to stay on top. In this weird arms race against prospective hires, companies keep asking harder and harder questions in a misguided attempt to raise the bar. The students respond by doing nothing else but solve every single available question on every single competitive programming website.

The junior engineer interviewing process, as it exists today, has a systemic problem. It doesn’t matter how high newbies are above a certain bar of logical, coding, and algorithmic competence – it is all the same. This is a classic case of a metric being gamed. A premium is placed on being able to solve super complex data structures questions. To meet this unnecessarily high benchmark, college students do whatever it takes. If the question had instead been “can this person become a great engineer in our company”, perhaps the outcomes might have been different?

Being able to solve typical data structures, algorithms problems is a signal in the larger interview process. By lowering the unduly high bar on DS type questions, organizations can make room for students to exercise their curiosity and develop their passions for something unique to them – their favourite technology, their favourite tech stack, their favourite industry. This will help them find people that can be trained, are self-motivated, and have an actual interest in technology beyond a gamified version of it.

A diluted signal

Now all this would be fine if this would help people become infinitely better programmers (it doesn’t) or at least distinguish themselves from the pack. But there is no indication that this is the case.

Students with 37 million zillion stars on coding ninjas, extra-super-advanced level on leetcode, or uber-coding-lord status on codeforces regularly fail the interview process because EVERYONE around them is at that same level! And in the pursuit of that level, they have ignored a lot of other fundamentals they should have learned or things they could have explored and tried out on their own. When asked what kind of technologies they find interesting, several students have told me over the last few years that they are only excited by competitive programming and have no other interest in software engineering or technology as such.

I can understand students from lower rung colleges following this strategy. Assuming for a minute that students from lesser tier colleges are less smart (possibly untrue but again a discussion for another day), the better students can distinguish themselves from their peers by extreme achievements in competitive programming. But at the better colleges, everyone is doing the exact same thing, and as a result, there is no benefit for anyone.

It is again the responsibility of the organizations to call this out and focus on other aspects of being an engineer. At least on other academic subjects if nothing else. But almost always, the first interview round is a super-hard data structures challenge which lesser mortals can’t get through. So later rounds are always evaluating people who are competitive programming biased. This funnel will never allow a different breed of software engineers to pass through.

It is an accepted idea in the industry that employee performance appraisals are subjective. Most companies make only superficial attempts at making them objective because different employees contribute in different ways. This subjectivity/uncertainty is part of evaluating anyone for any role. Unfortunately, we have reduced the fresher interview process to a computing game. This is not good for anyone, and the sooner we stop it, the quicker we might be able to find good engineers instead of human-like robots.

From the internet

  1. Aline Guisky describes how her team built an event-driven architecture to clean up noisy machine learning labels.
  2. Matt Ricard has a funny but all too relatable take on the evolution of configuration. This got me thinking about how domain models evolve, so stay tuned for more on that.
  3. Adventures in rolling-my-own-open-source: the storj.io team wanted a lightweight version of gRPC, so they made DRPC!
  4. Ole Rydland has a lovely introduction to socio-technical architecture. This is a great place to start before you move on to the heavier stuff.

That’s all for this week folks. Have a great weekend!


If you love reading It Depends, consider supporting it on Patreon, Gumroad, or Buymeacoffee

Modify your subscription    |    View online