If there’s one thing I’ve learned about myself, it’s that I rarely do things the “normal” way. While everyone else was busy racking up points in the Accelerated Reading program with the usual suspects—Magic Tree House, Diary of a Wimpy Kid, Harry Potter—I was more interested in hacking my way through Deus Ex Machina: Human Evolution or setting my alarm for 4 a.m. to catch Cowboy Bebop reruns. I’ve always had a knack for finding my own path, especially when the standard route just didn’t make sense to me.

Let’s rewind a bit. In elementary school, my reading scores were so low that my teachers wanted to hold me back a year. The school had this AR program where you had to rack up points by reading certain books. Magic Tree House? Diary of a Wimpy Kid? Harry Potter? Sorry, not for me. I wanted something with a little more edge. My teacher, probably at her wit’s end, finally just let me loose in the library. “Pick anything,” she said. I came back with a Tom Clancy novel—four reading levels above where I was “supposed” to be. Political intrigue, shadow governments, the threat of World War III. Now that was a story. By the time they scrapped the AR program, I had one of the highest point totals in the school.

Fast forward to high school, and I was the kid who set his alarm for 4 a.m. just to watch anime that wasn’t even meant for my age group. I’d do my homework while the rest of the house slept, then make sure everyone else was up for school and work. I guess you could say I’ve always been a little… unconventional.

When I started college in 2012, I was working 40 hours a week and going to school full-time. At first, I tried to do it all—show up to every class, ace every test, be the model student. Spoiler: I was burning out fast. So I did what I do best—I changed my approach. I mapped out the labs, test days, and project deadlines, and focused my energy there. Suddenly, my grades improved and I actually had time to sleep. Who knew?

So when it came time to break into tech, I knew the “traditional” path wasn’t for me. I wasn’t about to take on more debt for a CS degree, and bootcamps felt like a stress marathon. I figured, if I could teach myself how to survive college and work, I could teach myself to code. I just needed a plan, some mentors, and a place where I could learn from my mistakes.

Here’s how I mapped it out (with a little help from Disney’s funniest meme-worthy character):

• Get a job—any job—in a tech company.
• Find a mentor who actually knows what they’re doing.
• Learn to code, then learn to program, then learn to build real applications.
• Build a resume with actual projects, not just certificates.

Rolling the Dice: Getting My Foot in the Door

My first “tech” job? Office worker at a healthcare/pharma tech company in my hometown. The company helped doctors and patients with prescription authorizations, and let’s just say, a lot of those authorizations failed because of missing data. (I’ll skip the interview story, but let’s just say I rolled a Nat 20 on my persuasion check.)

The real challenge was moving from the call center to anything even remotely related to software. Meanwhile, I was teaching myself Java (my first language), then Python, and figuring out Django. I was basically building my own curriculum, one Google search at a time.

Then, I got picked for a test group at work. We were supposed to try a new workflow for prior authorizations—call the pharmacy first, not the insurance company. By the end of the quarter, I was leading the project, reporting to leadership, learning SQL, and even suggesting ways to improve our workflow. Not bad for a guy who started out answering phones.

Mentorship: The Game Changer

Enter Dan, my mentor. If it wasn’t for him, I probably would’ve stalled out after the test group project. The company had this stretch program for aspiring software engineers. Most people went back to their day jobs, but a few of us got a shot at an apprenticeship. Dan’s advice? Stop doing tutorials. Stop just reading textbooks.

Write code, write code badly. Figure out why it’s bad. Write it again, but better. So I did. I built a web scraper, a D&D manager, and a bunch of other projects in Python. When it came time to apply for the program, I knew the competition would be tough. Three interviews, three teams, three different sets of expectations. The program was new, so every interview was a little different, but they all wanted to see if you could actually build something.

Facing My Weaknesses: The Front-End Challenge

The first interview? Full-stack team, but with a front-end focus—specifically Vue.js. At that point, my front-end experience was basically “I know what a button looks like.” I’d spent most of my time on backend projects, so JavaScript frameworks and dynamic UIs were a whole new world.

They gave me some sample code to review and asked me questions about it. I could walk through the code and explain what it was doing, but when they asked about my own experience or real-world front-end projects, I didn’t have much to say. I realized pretty quickly that while I could reason through code, I didn’t have the hands-on experience that comes from actually building and debugging front-end apps.

It was humbling, for sure. My backend skills weren’t enough to carry me through a full-stack interview—especially when the team wanted someone comfortable with Vue.js and modern JavaScript. I didn’t get negative feedback, but it was clear my lack of front-end experience was a gap.

But here’s the thing: I didn’t let it get me down. After the interview, I added JavaScript and Vue.js to my “to-learn” list. I started exploring tutorials, building small projects, and messing around with component-based development. Even though I eventually decided to focus more on backend, that experience taught me the importance of being adaptable and willing to step outside my comfort zone.

Looking back, I’m actually grateful for that interview. It showed me a weakness, but it also gave me a clear direction for growth. In tech, there’s always something new to learn—and that’s half the fun.

Finding My Groove with Ruby

The second interview was for a full-stack team using Ruby on Rails. Since I had Python experience, Ruby wasn’t a big stretch. I explained my D&D project and how I built it. I thought I was out of the running, but then another manager, Matt, reached out for an interview.

Matt focused on my motivations and how I planned to teach myself. “This program is simply a mentorship. You will be teaching yourself most of the time.”

I started with his team, working two days a week with two mentors. I began with Codecademy’s Ruby courses, then moved on to small challenges. I needed to complete a final project to be evaluated.

At first, I struggled. During pair sessions, I didn’t understand the “magic” of Ruby, which made debugging harder. My mentor was direct: “We are expecting you to perform better than this.” Some of the feedback:

Better test cases: Test the logic, think of real-world situations, invalid inputs, and unexpected code. Better debugging: Use debugging tools, not just print statements. Find the root cause, not just the symptoms. That weekend, I took a hard look at myself. I didn’t want to go back to the call center. If I was behind, I needed a plan to catch up.

That Tuesday, I called a meeting with my manager and mentors: “I’d like to change our approach. I got some feedback, and I think this is how I can not only fix my issues but actually become a better developer if we…”

My new approach:

A small project every week Write test cases for every challenge/kata Drive during pair sessions, with mentors only helping when I’m stuck I improved, but the news of my shift to backend made me think that I was still behind.

The Mastermind Challenge: My Capstone Project

For the final project, we chose the Mastermind game from The Odin Project. Requirements included:

Bot option Player vs. player mode Login screen Display previous guesses During the presentation, a bug appeared: the login screen would reappear when the user chose player vs. player, causing a loop. I didn’t realize at the time, but in the chat, I was told to just display the bot walkthrough.

I assumed everyone was troubleshooting during their presentations, so I went for it. I started by replicating another controller/integration test I’d created for player vs. player. The login information was supposed to set the session’s ID, but I realized there was some carryover from a previous test. I removed it and suddenly, the test failed. I checked the controller file—it was misconfigured. The session wasn’t being set before calling the player vs. player option, which routed back to the login page. A quick Stack Overflow search helped me set the session correctly. The login loop disappeared, and the app worked.

After the presentation, I was sent back to the call center for the rest of the week, and the program ended. I reached out to Matt for feedback and advice on my resume. For me, this experience cemented my decision: this is what I want to do, at this company or another.

Matt told me, “I probably shouldn’t tell you this yet, but that presentation was the interview. We’re hiring you as a junior on our team.”

Twelve devs in the program, three spots. In the end, I earned one of those spots and officially became a software engineer that year—four years ago.

Growth, Grit, and What Comes Next

The hardest part of my journey? Learning to communicate problems and solutions using developer vocabulary. The moment I realized I was in trouble—not meeting my mentor’s expectations—was also the moment I’m most proud of. I used introspection and persistence to improve.

My advice: Learn to code, learn to write programs, then build side projects. Stick to one language until you’re comfortable.

My current goals: I’m looking for a job I can be passionate about, where I can help others. I’m also working on a TTRPG site that allows players and GMs to play any tabletop game online.

If you’re on an unconventional path, keep going. Persistence and adaptability are your best tools. And if you ever feel lost, confused, or unsure of an answer—whether you’re behind a keyboard or just trying to figure out your next move—remember:

The process is just as important as the solution.