No. Competitive programming is a sport with its own rules, and most working engineers never compete. Disliking contests tells you about contests, not about engineering. Build the problem-solving foundations you actually need, then judge your fit by building real software.
What people tell me
I like technology. I enjoy building small websites, fixing my friends' laptops, reading about how apps work and trying new tools. But my classmates are obsessed with competitive programming and contest ratings, and every time I join a contest I freeze, feel slow and end up ranked near the bottom. People around me say that if you are not good at contests you will never be a good software engineer. I am starting to wonder whether I chose the wrong field.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Competitive programming is one narrow sport inside computer science, not a test of whether you can do the job.
- You still need solid fundamentals: data structures, complexity and clear problem solving at a normal pace.
- Judge your fit by building real things end to end, not by contest ratings.
- Pick a steady problem-solving routine without the stopwatch, and keep it alongside project work.
- If you enjoy making things work for people, that is the core of the job.
What contests actually measure
Competitive programming rewards a specific set of skills: recognising a known pattern quickly, implementing it without bugs under a timer, and doing all of that alone with no tools, no documentation and no colleagues. It is a genuine skill and some people love it. I respect it.
But very little of a working engineer's week looks like that. In a normal week on my teams, people spend their time understanding requirements, reading existing code, designing small changes, reviewing each other's work, debugging something odd in production, writing tests and talking to other people about trade-offs. Speed under a stopwatch almost never decides whether someone is good at the job. Clarity, reliability and judgement do.
So when someone tells me they hate contests, my first reaction is not worry. It is curiosity about what they do enjoy.
Separate three things people blur together
| Thing | What it is | Do you need it? |
|---|---|---|
| Competitive programming | Timed contests, ratings, tricky puzzles | Optional. Useful for some, irrelevant for many |
| Problem-solving fundamentals | Arrays, hash maps, trees, graphs, complexity, breaking a problem down | Yes. Every engineer needs these |
| Building software | Turning a real need into working, maintainable code | Yes. This is the job |
The mistake is treating the first row as the gate to the other two. It is not. You can be average at contests and excellent at the second and third rows. Plenty of the strongest engineers I have worked with have never opened a contest site.
Do not use this as a reason to skip fundamentals
Here is the honest part. Some people who say they hate competitive programming actually hate being stuck on any problem at all, and they use the dislike as a reason to avoid data structures entirely. That will hurt you later, both in technical rounds and in real work, where choosing the wrong structure makes a feature slow or fragile.
The fix is to practise problem solving without the parts that make contests miserable:
- Remove the timer. Give yourself 30 to 45 minutes per problem, then read a good solution and understand why it works.
- Learn patterns, not problems. Two pointers, sliding window, hashing, BFS and DFS, binary search, simple dynamic programming. A handful of patterns covers most of what you meet.
- Explain your solution out loud or in writing. This is closer to real engineering than typing fast.
- Keep it small and regular. Four or five problems a week, every week, beats a weekend binge before a deadline.
Test your fit the right way
If you want to know whether software engineering suits you, run a better experiment than a contest. Spend four weeks building one small but real thing, something a friend, a society or a family member would actually use. A booking form, an expense tracker, a small inventory tool.
Then ask yourself honestly:
- Did I enjoy the moment it worked for someone else?
- When something broke, did I want to find out why, even if it was frustrating?
- Did I find myself thinking about it when I was not at the laptop?
If the answers are mostly yes, you have your answer, whatever your contest rating says.
Where your interest might point
People who like technology but not puzzles often thrive in areas where the work is about systems, users and reliability:
- Web and mobile development, where the feedback loop is visual and fast.
- Backend and APIs, where the challenge is correctness, data and scale.
- Cloud, DevOps and platform work, where you make other engineers productive.
- Security and IT operations, where curiosity about how things break is a strength.
- Data engineering, where the problems are about moving and shaping data reliably.
None of these require contest ratings. All of them require fundamentals and the patience to finish things.
Dealing with the classmates
Your classmates are not wrong to enjoy contests, and they are not wrong that it helps with some hiring processes. They are wrong that it is the only path. You do not need to argue with them. You need a plan of your own that you can point to: a problem-solving routine at your own pace, one or two projects that work, and a clear idea of which kind of role you want first.
When the comparison bites, remind yourself that you are not competing in their sport. You are training for a different one.
If you are still stuck
Read How do I start DSA when I cannot solve problems and never know which approach to use? for a gentle problem-solving routine, then Fifteen problem shapes and the move that solves each and How to start your career as a software engineer. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- Fifteen Problem Shapes and the Move That Solves EachThe usual way to learn algorithms is to work through a long list of problems and hope something generalises, which leaves most people with a hundred solutions memorised and no idea what to do with the hundred and first. There are perhaps a dozen shapes of problem, each with a move that usually works. Fifteen of those shapes and how to recognise them.
- How to Start Your Career as a Software EngineerA practical route into the first software engineering job: pick one language and stop shopping, build things too big for a tutorial, learn the five fundamentals you cannot skip, get your code in front of a human, and apply earlier than you feel ready. Includes a twelve month shape to work to and an honest read on what the current entry level market has changed.
- The Fundamentals Worth Learning as a Software EngineerFrameworks are the fastest moving and least valuable part of what you know. This is the layer underneath: how a computer runs your code, data structures as trade offs, complexity at conversational depth, storage, networks, concurrency, version control, testing as a design tool, and the two skills engineers skip that decide how far they get.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.