Nate

Growing as a Java Engineer in a Full-Stack World

Tue, 10 Mar 2026 00:00:00 GMT

Starting in the Java Ecosystem

My foundation is Java — Spring Boot, JPA, Maven, the whole stack. There's something grounding about an ecosystem that's been production-tested for decades. You don't wonder if the library you're using will be deprecated next quarter. The type system is strict, the patterns are well-documented, and the tooling is mature in a way that reflects years of real-world pressure-testing.

But Java can also feel heavy when you're trying to move fast. Spinning up a Spring Boot project to test an idea is overhead. The ceremony around configuration, annotations, and dependency injection is worth it at scale, but it adds drag when you're building a side project on a weekend and just want to see if something works.

Why I Started Reaching for TypeScript

The first time I built a frontend for one of my own projects, I used React because that's what everyone was using. Then I discovered TypeScript, and something felt immediately familiar — a strict type system, interfaces, generics. It mapped cleanly onto how I already thought about code from my Java background, just with dramatically less ceremony.

The difference is velocity. A Next.js project with TypeScript and Tailwind can go from idea to deployed in a weekend. That speed changed what I was willing to try. I started building more because the cost of starting was lower, and building more is how you actually get better.

How Both Worlds Inform Each Other

The Java mindset makes me a more deliberate TypeScript developer. I think about interfaces before implementations. I default to separating concerns. I'm suspicious of magic and prefer explicit configuration when the stakes are high.

The TypeScript mindset has made me more pragmatic in Java. I question ceremony where it doesn't add value. I reach for simpler solutions first. I think about the developer experience of the API I'm building, not just whether it's technically correct. Each ecosystem has filed down rough edges in how I approach the other.

Where My Stack Is Going

I'm not abandoning Java — it's where I do my most serious backend work, and the ecosystem isn't going anywhere. But I see my future as genuinely full-stack: Java for the systems that need reliability and scale, TypeScript for the interfaces and tools and side projects where speed is the constraint.

The engineers I respect most aren't language loyalists. They're pragmatists who know when to use what. That's the goal — not expertise in a single tool, but the judgment to reach for the right one.

What 6 Months of the NeetCode Grind Actually Taught Me

Thu, 15 Jan 2026 00:00:00 GMT

Why I Started

I'd been putting it off for months. Everyone in the dev community talks about LeetCode like it's some rite of passage, and I kept telling myself I'd get to it after finishing the current project. Then I found NeetCode's roadmap — a curated list of 150 problems that map to real patterns — and something clicked. I started the grind not because I had interviews lined up, but because I wanted to close the gap between the code I write at work and the code I knew I should be capable of writing.

The Patterns That Actually Clicked

The first few weeks were humbling. I'd spend 45 minutes on an "easy" problem, eventually look at the solution, and feel like I'd never seen this language before. But somewhere around week three, sliding window started to make sense. Then two pointers. Then I hit the trees section and everything slowed down again.

What changed things was tracking the pattern, not the problem. Instead of asking "how do I solve this," I started asking "which pattern does this problem smell like?" A problem with a shrinking and growing range? Sliding window. Two arrays to compare element by element? Two pointers or a hash map. Once I started categorizing before coding, my solve rate went up noticeably and problems stopped feeling like puzzles dropped from nowhere.

What Daily Practice Taught Me About Discipline

The grind is less about intelligence and more about consistency. Doing one problem a day feels slow. Doing one problem a day for six months is 180+ problems and a muscle memory for pattern recognition that you simply cannot shortcut your way to. The discipline I built from this carries into everything else — the side projects I finish instead of abandon, the documentation I actually write instead of defer.

I also learned to be comfortable being stuck. That sounds small. But as a developer who prefers building to debugging, sitting with a problem for 20 minutes without progress used to feel like failure. Now it just feels like process. That reframe alone has made me a calmer engineer.

What I'd Do Differently

Less time re-solving problems I already understand. There's a temptation to go back and polish solutions to problems you've already beaten, but that time is better spent on the next category you haven't touched. I'd also start the dynamic programming section earlier — I avoided it because it felt abstract, but it's one of the most pattern-able sections once you commit to it.

If you're thinking about starting, use NeetCode's roadmap and don't grind random problems. The structure is the point.

How Building Side Projects Changed the Way I Interview

Fri, 20 Feb 2026 00:00:00 GMT

The Gap Between Prep and Real Building

There's a version of interview prep that's entirely theoretical. You memorize system design frameworks, practice behavioral questions, and grind through mocks until your answers sound rehearsed. I did some of that. But the thing that actually changed how I showed up in interviews was building Bookmarked — a full-stack app that saves tweets directly to a Notion database through a Telegram bot.

Building something real surfaces problems you'd never encounter in a mock. What do you do when the Telegram webhook and the Notion API have different rate limits? How do you handle a failed sync without losing the user's data? These aren't questions you can answer from a framework. You have to build through them.

What Bookmarked Taught Me About System Design

Before I built Bookmarked, I could talk about message queues in the abstract. After building it, I understood why you'd want one — because synchronous API chaining is a liability when one service is slower than another. I ended up with a simple retry mechanism instead of a full queue, which was the right call for the scale, but I understood the tradeoff I was making and could articulate it precisely.

That kind of reasoning — knowing what problem a pattern solves and when it's overkill — is exactly what interviewers probe for in system design rounds. It's hard to fake if you haven't built anything real.

How Having Real Projects Changed the Interview Dynamic

The moment I started walking interviewers through Bookmarked instead of a to-do app, the conversations got more interesting. Engineers asked follow-up questions. They pushed back on architecture choices. One interviewer spent twenty minutes on the Telegram webhook flow because he'd built something similar and wanted to compare notes.

That's a completely different dynamic than reciting answers. Real projects invite real conversation, and real conversation is where you actually demonstrate what you know rather than what you've memorized.

What Recruiters Actually Want to Hear

They want to see that you've hit real walls and made real decisions. Not that you've followed a tutorial to completion, but that you encountered a problem, weighed your options, and chose one with a reason. The "why" is everything. A mediocre technical decision with clear reasoning reads better than a perfect decision with no explanation.

Build something you actually use. The specificity of a real problem, and the authenticity of having genuinely solved it, comes through in a way that polish alone can't replicate.