From Rusty to Ready

The take-home that told me the truth

Early in the search, one company gave me a small take-home project. They asked if I knew Blazor, Microsoft's newer web framework, roughly their answer to React. It was brand new at the time. I said I'd look into it.

I did the research, built the project in Blazor, and it all worked. Every feature. Then we sat down for the code review.

That's where it landed. The code ran fine. But going through it with someone who worked on a team every day, it was obvious my code wasn't written to the standard the industry expected now. It wasn't something other people could pick up and live in. I'd been alone so long I'd never had to write it that way.

I could keep losing interviews to that, or I could fix it.

Studying, on purpose

I'd taken one course from Code with Mosh back at my old job, on Docker, because that's how we deployed. I liked the way he taught, so when I needed to relearn things, I went back to him.

React first, because that's what I was interviewing on. Then data structures, because the coding challenges were getting harder and there were algorithms in there I hadn't touched since college. Then design patterns, because interviewers for senior roles kept asking me to explain patterns I'd been using for years without knowing their names. Then more React.

Each shift came from what the interviews were actually testing, not a fixed schedule. The plan stayed — pick a source, go deep — but the order moved when the pattern told me to.

Over the two years of the search I finished more than twenty of his courses. I'm naming him because that's what worked for me, not because anyone asked me to.

A course doesn't stick unless you use it

Here's the problem with courses: you watch, you nod, and a month later it's gone. If you don't use it, you lose it. I needed a project.

I sort of had one. Back in 2009 I'd written a little .NET Core app that generated a static HTML résumé with navigation. It had been sitting there for over a decade.

And I had a problem that needed solving. I was managing the whole search in OneNote and it was falling apart: job descriptions, contacts, which platform I'd talked to someone on, pay ranges, the conversations themselves, all scattered. The tools that would have fixed it cost money, and I was living paycheck to paycheck. Forty or fifty dollars a month, for an unknown number of months, wasn't happening.

I needed cloud experience on my résumé. I needed modern, clean code I could point to. I needed a way to track my search. One project covered all three.

So I dusted off the 2009 app and rebuilt it in Blazor, hosted on Azure, in Docker containers, with Azure DevOps for source control and pipelines. I made myself use the design patterns and the clean-code habits from the courses, because now I had somewhere to use them. When interviewers said "you don't have any cloud experience," I could point at something real.

That project became Bridani.

If you're starting from rusty

Pick one source and go deep instead of sampling ten. Study what interviews are actually testing, not what feels interesting. And build something, anything, that forces you to use it. Bonus points if it solves a problem you have right now.

Mine solved the problem of keeping sixty interviews straight. Next post: how the search actually ended.