Why I built Nudge

If you've spent real time grinding LeetCode, you know the moment. You've read the problem two or three times. You have a rough idea of what data structure might be involved. You write something, it's wrong, you delete it, you write something else, also wrong. Ten minutes pass. Then twenty. Then thirty.

At that point you're basically choosing between two bad options.

Option one: keep staring. Maybe it clicks if you give it more time. Sometimes it genuinely does. But more often you're not making progress anymore, you're just re-reading the same few lines of your last attempt, hoping the ninth read reveals what the first eight didn't.

Option two: give up and go watch someone solve it. This feels like the responsible move. You're not wasting time, you're "learning." And a good walkthrough does explain the solution well. You follow the logic, it makes sense, you can see why each step works.

Then you close the tab, open a similar problem two days later, and you've got nothing. You remember that you watched a video. You don't remember the reasoning.

It took me a while to actually understand this, not just notice it. It's not that solution videos are bad, or that the people making them explain badly. It's that watching someone else reason through a problem and reasoning through it yourself use different muscles, and only one of those is the muscle an interview actually tests.

When you watch a solution, you're doing recognition: you see a state transition or a two-pointer trick, and you agree it makes sense, the way you'd agree a chess move makes sense once someone points at the board and explains it. Recognition is real, and it isn't nothing. But recall is a different task. An interviewer doesn't hand you a finished idea and ask if it's correct. They ask you to build it from an empty editor while they watch.

That gap is exactly where I kept getting caught. I'd watch a DP solution, follow every line, feel confident I understood it, and then sit down in front of a structurally similar problem a couple of days later and freeze at the exact same spot I always froze: figuring out the state and the transition. I'd never actually practiced that part. I'd only practiced agreeing with someone else's version of it.

So the thing I actually wanted wasn't a solution, and it wasn't nothing either. It was a real middle option: something that would get me moving again without doing the stuck part for me.

That sounds simple until you try to build it. A hint that's too vague ("think about what data structure would fit here") isn't really a hint, it's just a more encouraging way of restating that you're stuck. You already knew you needed a data structure; you didn't know which one, or why. On the other end, a hint that's too specific is just the solution wearing a disguise. Spell out exactly what to store in the hashmap and you haven't nudged someone toward the insight, you've handed it to them and asked them to type it out.

The useful zone in between is narrower than either of those, and it has to be specific to where someone is actually stuck in that attempt, not to the problem in general. If you've correctly figured out you need a hashmap but you're stuck on what to use as the key, a general hint about hashmaps is useless. You're already past that part. It needs to land on the actual gap. That ended up being most of what building this was: not writing good hints in the abstract, but figuring out where in a given attempt someone is actually stuck, so the hint can meet them there instead of restating the general area.

In practice, that meant a handful of concrete decisions. Nudge sits next to the problem as a side panel, and it's built to ask before it tells, so when you ask for help, its first move is usually a question back, meant to surface what you've already figured out before it gives you anything. You can pull your actual editor code into the conversation with @code, so it's reasoning about the code you're genuinely stuck on rather than a hypothetical version of the problem. It also pays attention to how long you've actually been on a problem, because a hint at minute two of barely reading it should look different from a hint at minute thirty after three failed approaches. And where there's an inline hint sitting next to your code, it's aimed at the specific line or gap you're stuck on, not a general tip about the topic.

None of that is complicated technology. It's mostly just discipline about not answering the question you weren't asked.

None of this started as a company idea. I built it because I was the one grinding LeetCode, this was the tool I wanted while I did it, and it didn't exist. The earliest version existed because it was faster to build a rough version of the thing I wanted than to keep doing without it.

By the time I started building the first version, I'd already worked through more than 100 problems on my own, and I still couldn't reliably solve new ones under pressure. That gap cost me real interviews, more than I'd like to admit. It wasn't that I didn't understand the concepts. It was that understanding a concept and being able to produce it from scratch, live, while someone's watching, are two different skills, and I'd only ever practiced the first one.

I don't think that's a particularly dramatic story, and I'm a little suspicious of any version of this page that tries to make it sound like one. It's a fairly ordinary thing, a student getting annoyed at a specific, recurring frustration and building something to fix it for himself. The only reason it's now something other people use is that the frustration wasn't unique to me.

I still think the best version of practicing for these interviews is the slow, uncomfortable one, where you sit with a problem long enough that the solution actually becomes yours, not something you borrowed for twenty minutes. I just don't think "slow and uncomfortable" needs to mean "stuck with no way forward."

If you're grinding technical interviews too, I hope this helps you the way I wanted it to help me, not by making the problem easier than it is, but by keeping you from getting stuck in a way that doesn't teach you anything.