DSA is not useless for real jobs. Grinding 800 questions without revision is.
Where algorithms actually showed up in my work, where they never did, and why the way most people prepare is the real problem.
Contents
Every few weeks the same fight starts in my comments. One side says DSA is useless because "real jobs are CRUD". The other side says you are not an engineer if you cannot invert a binary tree on a whiteboard. Both sides are a little right and mostly loud. Let me give the boring answer with examples.
Where DSA showed up in real work
- A nightly job deduplicating 2 million customer records with
List.contains()inside a loop. 40 minutes. Switched to a HashSet: under a minute. That is O(n²) vs O(n), not "premature optimisation". - A job scheduler where low priority jobs starved forever. The fix was understanding how the priority queue ordered ties and adding an age factor.
- Searching sorted log timestamps for an incident window. Binary search over a 30 GB file using byte offsets instead of reading it line by line.
- A build tool that needed module order from dependencies. Topological sort, plus cycle detection to give a useful error instead of hanging.
Rare? Yes. Maybe a dozen times in my whole career. But each time, the person who knew the basics fixed it in an hour and the person who did not lost a week.
Where it never showed up
Segment trees with lazy propagation. Hard DP on bitmasks. I have never used these at work and I will not pretend otherwise. If your company asks those for a frontend role, the company has a problem, not you.
Why interviews use it anyway
Because it is cheap to evaluate. One interviewer, 45 minutes, a shared editor. Is it a perfect proxy for job performance? No. It is a lossy proxy that companies use because the alternatives are expensive. You can be angry about that, and you should still prepare for it, because at mass hiring scale the online assessment is DSA and you cannot talk your way past an automated test.
Tech With Tim makes the opposite case well in this video: projects and communication matter more than grinding. I agree with about 70% of it. Watch it, it is a good counterweight to people like me.
The real problem: 800 questions, zero retention
I meet students with 800 solved questions who cannot solve a small variation of a question they "did" last month. They did not learn 800 questions. They watched 800 solutions.
What actually works:
- Revise on a schedule. Solve on day 1, again on day 3, day 7, day 21. If you cannot do it on day 7 without looking, it goes back to day 1.
- Three lines of notes per question. The pattern, the key observation, the bug you made. Not the whole code.
- Tag by pattern, not by difficulty. "Sliding window, variable size" is useful. "Medium" is not.
- Stop at around 200 done properly and spend the rest of the time on mocks and one real project.
So no, DSA is not useless. Treating it like a number to grow on your profile is.
If you disagree, good, tell me where. But share the dry run, not the opinion.
Written by
Nikhil Sharan
I teach DSA and system design on YouTube (Two Pointers, 1.2M). Ex-SDE at two product companies, now teaching full time. Dry run everything. No paid course here, only free stuff and honest opinions.
Get the best of #desi_devs weekly
One email each Monday with the most useful posts. No spam; unsubscribe in one click.
Comments
Sign in to join the conversation.
Sign in to comment