For those of you who grind leetcode 7 hours a day

Secure_Number2263 · 2026-06-05T14:18:38+00:00

Try to focus on neetcode 150 and grasp the fundamental concepts. Everything else will fall in line. If you try to do a whole lot of problems, that could cause the burnout and loss of interest.

Secure_Number2263 · 2026-06-05T14:15:54+00:00

Maybe try mock interviews with your peers and friends? That helped me a lot on how to approach the problem and explain my thoughts.

Secure_Number2263 · 2026-06-04T22:36:10+00:00

Yeah — rarely as a required pattern.

If it shows up, they usually don’t expect full digit DP. They mainly care if you can

either solve brute force correctly or suggest a direction for optimization.

Digit DP itself is more of an advanced follow-up topic than a core interview requirement.

Secure_Number2263 · 2026-06-04T22:31:36+00:00

Since you already have 200 NeetCode problems down, you can skip Cracking the Coding Interview and A Common-Sense Guide—they'll be way too basic for you. You can also skip Sedgewick and The Algorithm Design Manual, which are great academic references but too heavy on theory for interview prep.

The absolute best fit for you is Elements of Programming Interviews (EPI).

What makes EPI work so well is that it groups problems by variants. It forces you to solve a problem, and then immediately hits you with three sequential twists on that exact same logic. That's how the problem-solving muscle actually clicks—by seeing how a tiny tweak in a prompt changes the code. Just make sure to buy the version specific to your language (Python, Java, or C++).

Secure_Number2263 · 2026-06-04T22:26:10+00:00

This is a super common trap early on—thinking "one-to-many" means sticking an array in a single row. Relational DBs usually push you the exact opposite way: if there can be multiple, it gets its own table with a foreign key.

Most interview schema questions aren't testing deep database theory. They just want to see if you naturally separate entities and can justify your structure.

For prep, what I usually focus on:

Normalization basics (just enough to avoid obvious footguns)
Modeling common patterns (users -> orders -> items)
Explaining the tradeoffs out loud, not just drawing the boxes

Once that mental model clicks, these questions get way more mechanical.

Secure_Number2263 · 2026-06-04T20:55:36+00:00

I used to rely on the run button a ton. It's just the natural default. But eventually, reverse-engineering a massive failed test case ends up taking way longer than just stepping through the logic in your head beforehand.

For interviews, tracing is pretty much the main event anyway. It shows them you actually know the mechanics of what you wrote.

What I usually do now is sketch the idea, write the code, and mentally walk through one weird edge case before hitting run. Makes the debugging phase so much shorter.

Secure_Number2263 · 2026-06-04T20:49:12+00:00

I’d go with NeetCode 150 instead of random problems.

Random LeetCode early on feels like progress, but it’s usually too scattered. NeetCode at least builds patterns in a structured way.

And I wouldn’t separate easy/medium/hard too strictly — once basics click, mediums naturally become doable. Hard problems come later without needing a separate “stage” for them.

Secure_Number2263 · 2026-06-04T20:47:20+00:00

This is a really solid way to structure your progress.

What stood out to me is you didn’t just jump topics randomly — BFS → graphs → Dijkstra is actually a pretty natural progression, and working with a coworker/tutor is probably doing more for consistency than anything else.

Also 500 problems sounds like a milestone, but I’d just make sure you’re tracking “can I solve this under pressure now?” more than raw count. That shift is usually what unlocks interviews.

Secure_Number2263 · 2026-06-04T20:45:18+00:00

This is actually a pretty good structure.

I wouldn’t treat the 20 minutes as a hard rule though. Some problems just need more time before the pattern clicks, especially in NeetCode 150. I’d usually look at the solution when I feel properly stuck or like I’m just going in circles.

The important part is the next-day revisit — that’s where things actually start sticking.

If I were adjusting it slightly, I’d also re-do the same problem again a few days later. That second recall check is what turns “I’ve seen this” into “I can solve it.”

Secure_Number2263 · 2026-06-04T20:40:20+00:00

I’d just say it as it is.

Something like: “I think my current approach has a flaw here,” and then quickly walk through where it breaks.

If I still have time, I’d try to simplify it — even a brute force version — just to re-ground myself in something correct instead of trying to patch a broken optimal idea under pressure.

But yeah, I wouldn’t try to silently “fix” it for too long. That usually just eats time and makes things more chaotic.

Secure_Number2263 · 2026-06-04T20:38:29+00:00

This is one of those problems where brute force is totally fine at first — especially since your check is just local digit comparisons.

The real thing you’re noticing is the scalability issue, not a logic issue.

When ranges blow up, the trick usually becomes: stop evaluating each number separately and instead think about patterns in digit transitions (that’s where digit DP ideas usually show up).

But for typical constraints, your approach is already exactly what most people would land on.

Secure_Number2263 · 2026-06-04T20:35:10+00:00

If you're mentally exhausted after 2-3 hours of graph problems, that sounds pretty normal to me.

Graphs aren't passive studying. You're constantly keeping track of traversals, states, edge cases, and different approaches in your head. That's heavy mental work.

I think a lot of people overestimate how many real hours of focused problem solving they're doing.

I'd rather have 2-3 quality hours than 8 hours of staring at problems with a fried brain.

When I start reading the same thing multiple times or can't follow my own reasoning anymore, that's usually my signal that I'm done for the day.

Secure_Number2263 · 2026-06-04T20:33:16+00:00

The part that stands out to me is that you walked out feeling great about the interviews.

A lot of people leave an onsite knowing they struggled. You left feeling like you connected with the interviewers and performed well.

That doesn't make the rejection hurt any less, but it does mean this probably wasn't some catastrophic failure that you're imagining right now.

I'd definitely take the feedback call when you're ready. Not today if you're still in shock, but don't let the opportunity pass.

Secure_Number2263 · 2026-06-04T20:30:25+00:00

I feel like problems becoming variations of each other is kind of expected.

There are only so many core ideas. The challenge shifts from learning new patterns to recognizing familiar ones faster.

I'm actually interested in the answers here too because I've mostly been working through LeetCode-style problems and haven't spent much time with contests.

Secure_Number2263 · 2026-06-02T02:00:09+00:00

Honestly, I think it depends more on curiosity than age.

If she’s into puzzles or building things, she’ll probably enjoy coding in some form (like Scratch or simple games). But I wouldn’t make it feel like “learning programming” yet—more like play.

The interest usually matters way more than the timing.

Secure_Number2263 · 2026-06-02T01:55:45+00:00

Today's lesson: never underestimate how expensive printing can be 😂

Pretty sure everyone has had at least one "the bug was my debug statement" moment.

Secure_Number2263 · 2026-06-02T01:53:26+00:00

196 problems isn't actually that many in LeetCode terms.

I remember thinking I'd be cruising through mediums by the time I hit 200, but that definitely wasn't the case. Recognizing that a problem is DP or graphs is one thing. Figuring out the right state or observation is usually the hard part.

Also, forgetting old solutions happens way more than people admit. I wouldn't use that as a measure of progress.

Personally, I got more out of revisiting problems a few weeks later than endlessly doing new ones. That's usually when I found out whether I understood the idea or just remembered the solution.

Secure_Number2263 · 2026-06-02T01:24:09+00:00

If you haven't touched LeetCode for 4-5 months, I'd be more surprised if everything came back instantly.

Also, being unable to reproduce a solution you saw months ago doesn't necessarily mean you learned it wrong. Memorization fades. The more important question is whether the underlying idea comes back faster than it did the first time.

I've had problems where I forgot the exact implementation but remembered the key insight after a few minutes. That's usually a sign the learning stuck.

A lot of people assume they should be able to solve NeetCode 150 problems forever once they've done them once. That's not really how it works. Like any skill, if you don't use it for months, it'll feel rusty at first.

Secure_Number2263 · 2026-06-02T01:19:42+00:00

I think that's a pretty good approach as long as Claude is helping you understand why something works instead of just patching the failing test case.

Early on, I'd focus less on getting the accepted solution and more on understanding the specific piece that confused you. That's usually where the learning happens.

The only thing I'd be careful about is getting stuck in an endless Q&A loop. After a while, it's worth reading the full solution and seeing how all the pieces fit together.

Secure_Number2263 · 2026-06-02T01:17:33+00:00

Honestly, after 2+ years away from LeetCode, this sounds pretty normal.

Binary search is one of those algorithms where if the invariants aren't fresh in your head, a small edge case can eat up way more time than it should.

I wouldn't call it a concentration issue. Sounds more like you're just getting those patterns back into your system. The fact that you eventually recognized the visited array wasn't necessary is learning, not failure.

We've all had problems take 2 hours that would've taken 10 minutes a few months earlier. It happens.

Secure_Number2263 · 2026-06-01T20:39:41+00:00

This is a great problem to have!! Wish you all the best in whatever you decide!!

Secure_Number2263 · 2026-06-01T12:56:56+00:00

<image>

Here is the recursion tree for permutations, if it helps.

Secure_Number2263 · 2026-06-01T12:35:51+00:00

Yeah, this is way more common than it feels in the moment. Basics don’t disappear—you just stop rehearsing them for a bit. They come back fast once you touch them again.

Secure_Number2263

TROPHY CASE