I am going to start with a number most people will not say out loud.
1,200 applications.
That is how many jobs I applied to over 3 to 4 months trying to switch from a service-based company to a product-based one. I had spreadsheets, saved searches, and browser tabs I kept telling myself I would close tomorrow. Some nights I was applying at 11pm just to hit my self-imposed daily quota.
Out of 1,200, I got around 10 interview calls. Out of 10, I got 4 offers.
The applications got me in the room. What happened inside the room is what this post is actually about.
The One Thing That Followed Me Into Every Interview
At my previous company I worked on a lot of things, but one project came up in literally every single interview.
We had a Python module that parsed ASAM MDF files. Binary log files from vehicles and sensors, often gigabytes in size. The parser was painfully slow. Around 8 minutes to load a single file. The kind of slow where you start it, go get lunch, and hope it is done when you come back.
I rewrote it in Rust. Load time dropped from 8 minutes to 12 seconds. 40x improvement on GB-scale files.
Every interviewer stopped me the moment I mentioned it. The questions were real engineering questions, not generic resume stuff.
"Why Rust over Go or C++?"
"How did you profile the bottleneck first?"
"What was your testing strategy when rewriting something this critical?"
"What would you do differently now?"
I would spend 20 to 30 minutes just on this one project. Not because they were grilling me. Because it was a genuine conversation between two people who cared about the problem.
Here is why it worked: I had lived with it. I hit walls in the rewrite that took days to figure out. The context, the wrong turns, the eventual solution were all stored in my head. When a follow-up question came, the answer was just there.
You cannot fake that. A first follow-up question exposes a tutorial project immediately. Real work under real constraints creates a depth that no amount of prep can replicate.
Side Projects: The Idea Matters More Than the Code
Two side projects that got genuine reactions from interviewers:
- FreeShare - Share files locally without cables or cloud uploads, just two devices on the same network.
- NotePage - A browser scratchpad with no login, no account. Open, type, share the URL.
Neither is technically complex. A senior developer could build both in a weekend. Interviewers were still surprised by them, not because of the code but because of the idea and how I talked about it.
When I described FreeShare I did not say "it is a file sharing app." I told the actual story. The frustrating afternoon where every option for moving a file felt ridiculous. The first version that almost worked. The moment it finally clicked. People who tried it and what they said.
That story has a shape. It is interesting to listen to.
Most developers build side projects to pad a resume and it shows. Another todo app, another weather dashboard, another tutorial clone. Nothing wrong with it for learning, but in an interview you want something you can talk about like a person, not something you are reading off a bullet point.
A todo app with no story is just a todo app.
Public Presence Is Free and Almost Nobody Bothers
I write on dev.to and keep my GitHub reasonably active. I mentioned both in interviews and things I did not expect happened.
One interviewer was scrolling through my GitHub mid-call and stopped at a repo I had almost forgotten about. Another had read one of my posts before we even spoke.
I am not saying build a personal brand. I am saying most developers have nothing publicly visible. No repos worth looking at, no writing, nothing. The bar for standing out here is genuinely low because almost nobody bothers.
A consistent GitHub history does not need to be perfect. It just needs to show that you actually code outside of work. A few blog posts show you can explain technical ideas clearly. Both of these are signals interviewers notice even when they do not say so explicitly.
You do not need to go viral. You just need to exist publicly and be consistent.
The Risky Trick I Used In Coding Rounds
This one is controversial. Fair warning.
During coding interviews I would sometimes make a small intentional mistake. Not a logic error. Something tiny. A variable name that does not match. An edge case I "forgot" briefly. Then I would catch it myself, out loud, fix it in 10 seconds, and keep going.
Why? Because debugging under pressure is a real skill and most interviews never test it. If you write perfect code silently and it works, the interviewer learns you can solve that specific problem. If you catch your own mistake mid-explanation, you are showing how your brain works when things go wrong. That is more valuable information.
The rule is simple though: this only works after you have already made a strong impression. I only did this late in interviews after the project discussion had gone well. If you are already struggling and you add a visible mistake on top, it makes things worse.
It worked for me across multiple interviews. I have not seen anyone else write about it.
The DSA Situation, Honestly
I am not great at DSA. I practiced enough to not embarrass myself. Medium-level problems, common patterns, just enough to stay in the conversation.
What actually moved the needle in coding rounds was never being silent.
When I write code in an interview I talk constantly. I explain why I am choosing an approach before I write it. I mention complexity. I say out loud when I am unsure about something and then work through it while talking. If I am stuck I say I am stuck and start reasoning from what I do know.
Interviewers are not just checking if you get the right answer. They are also asking themselves whether they want to work with you. Silent candidates who eventually produce correct code are hard to read. Candidates who think out loud are a known quantity. You can picture working with them.
The gap you can close by communicating well during a coding round is bigger than most people realize. Especially if you are not going to be the best algorithmic problem solver in the room.
What Actually Got Me the Offers
The 1,200 applications were necessary. The DSA practice was necessary. But neither of those converted interviews into offers.
What did it was having things I could talk about for 30 minutes without running out. A Rust rewrite I genuinely lived through. Side projects born from real frustration. Two years of public writing and code that showed I had been at this consistently.
When someone asks about something you truly built and care about, you do not prepare an answer. The answer is just there.
You cannot shortcut that. You can only start building it now so the material exists whenever your job search comes.
Work on things you can defend. The rest follows.
Writing this because I spent a lot of time during my search wishing someone had written it for me. If you are in the middle of a switch or planning one, drop it in the comments.