From CSE Backbencher to SDE at a Top Startup — No CP, No DSA Grind

Let me describe the type of ECE student I was for my first two years at NIT Trichy. I attended lectures. I passed exams. I was not in any competitive programming club. I had not solved more than fifteen Leetcode problems by the end of second year. I had a GitHub with three half-finished projects that I had started, gotten to 60% completion, and abandoned when a course deadline interrupted the flow.

By fourth year I had a job at a well-known B2B startup in Bengaluru that I am genuinely excited about. Here is what happened in between, and why I think the conventional campus placement wisdom about grinding DSA was, at least for me, the wrong path.

The Projects Strategy

I decided in my third year to finish things. This sounds trivially obvious and is actually quite hard. I committed to completing one project per semester, end to end, including deployment, documentation, and at least ten real users who were not my friends. This constraint — real users, not friends — is the most important part. My friends will use anything I build out of loyalty. Strangers will use it only if it actually works and solves something.

The projects: a local food ordering system for PGs in Trichy (about 60 users at peak), a simple expense splitting tool for hostel common expenses (used by three hostels), and a student-alumni mentorship matching tool for NIT Trichy that I built in coordination with the alumni cell and that got 200 signups in its first week. Each project had a real problem, a real user base, and metrics I could speak to.

How the Interviews Actually Went

I interviewed at six companies. Three of them started with DSA rounds, which I cleared at a moderate level — not brilliantly, but competently enough. Two skipped DSA almost entirely and spent the interview asking me about my projects in depth: how I handled edge cases, how I would scale if the user base grew 10x, what I would do differently if I were building it today. These two companies were where I performed best by a significant margin.

The offer I accepted was from a company that spent 40 minutes of a 60-minute interview on the mentorship tool. The CTO asked me why I had used a particular matching algorithm. I explained. He asked what the limitations were. I explained those too. He asked what I would have done with more time. I had an answer because I had thought about this. This is the advantage of deep project work over breadth of problem-solving: you know your domain.

I am not saying do not do DSA. I am saying: if you have built real things and you can speak about them with depth and honesty, including about what broke and why, that is a differentiator in hiring that is underused by most candidates I know.