Most write-ups about self-taught engineering paths stop at the first job. The first job is the hard one in some ways and the easy one in others, and the arc that compounds (junior to mid-level to senior) is where the interesting decisions live. I want to write down the 36-month version, with all three loops in detail, because the bets I made in year one paid out in year three in ways I would not have predicted, and the bets I did not make in year one would have cost me the senior role in year three. I want to make those bets legible.
The quick version: I left a non-engineering career (technical project management at a manufacturing company) at age 32, spent ten months in dedicated self-study, landed a junior backend role at a 200-person startup at month 12, transferred to a mid-level role at the same company at month 22, and was hired into a senior role at a different mid-size company (around 800 engineers) at month 36. The compounding rate over those three years was higher than most external observers think is possible. It was not a lottery. The bets are describable.
Year zero: the ten-month self-study window
I took a sabbatical from work and spent ten months on focused self-study. The structure was deliberate. I want to describe it because it shaped what was available to me in the year-one loop.
Months one through three: programming fundamentals. Python first, JavaScript second, with a single algorithms textbook I worked through cover-to-cover. I built three small projects (a CLI tool, a web scraper, a Flask web app) and pushed them to public GitHub. The projects were not impressive. The fact that I had committed to building them, finished them, and was willing to be evaluated on them was the artifact.
Months four through six: web stack and one framework deep. I picked Django because the documentation is a high-quality teaching artifact and the framework is opinionated enough that you learn the tradeoffs by hitting them. I built one larger project: a multi-tenant SaaS app with authentication, role-based access, payments via Stripe test mode, and a small admin dashboard. The project was about 4,000 lines of code. I deployed it on a small VPS so I had to handle the operational layer (TLS certs, deployment, basic logging, a cron job).
Months seven through nine: data structures, algorithms, and one specific technical depth. I picked databases as my depth area. I read a database textbook, did the standard course on database internals, and rebuilt a small key-value store from scratch in Python. The KV store project taught me more than the textbook did. I had specific opinions about LSM trees versus B-trees and could defend them, which is a thing junior candidates rarely have.
Month ten: interview prep and applications. About 80 algorithm problems on a popular practice site, with a partner critiquing me on each one. Forty-five applications across the spectrum (junior at FAANG, junior at scale-ups, junior at startups). The application phase was the part I had under-estimated in cost. Each application is a 30-to-60-minute exercise (resume tailoring, cover note, sometimes an application questionnaire), and 45 of them is a full week of work.
Year one loop: the junior role
The loop that converted was at a 200-person backend-tooling startup. I want to walk through it because the round that swung the offer was not the round I expected.
The loop was four rounds:
The round that swung the offer was R4, specifically the deep-dive on the take-home. I had built the ETL pipeline using a streaming approach (with backpressure handling) instead of the batch approach the prompt had implicitly suggested. The tech lead asked me why. I had a real answer. I had assumed (correctly) that the production version of this pipeline would face memory pressure on large input files, and the streaming approach handled the memory pressure cleanly. The tech lead pushed me on the tradeoff (streaming is more code, the batch version would be 30 lines, mine was 110). I had a defensible answer: the 80 lines of difference was where the operational properties lived (the streaming version had progress reporting, partial-failure recovery, and a graceful-shutdown handler, which the batch version did not). The tech lead, in the debrief, said: "That round flipped you from a hire to a strong-hire because the answer demonstrated production thinking, which most junior candidates do not have."
The specific bet from year zero that paid out in this round was the database-depth project. The KV store project had taught me to think about operational properties of code (what happens when you run out of memory, what happens when the process is killed mid-write, what does recovery look like). That thinking transferred directly to the take-home critique. Without the KV store project, I would have written the 30-line batch version, defended it adequately, and converted at lean-hire instead of strong-hire. The compounding from year zero into year one was the depth bet.
Year two: the mid-level transfer
I was hired as a junior. My title was "Software Engineer" without a level qualifier, but the comp band was junior. The team had four engineers, two senior and one mid-level besides me. The work was end-to-end: I owned a service in production within four months, was on-call within six, and was leading small projects (defined as "this is your project, the senior engineers will review the design") within nine months.
The mid-level transfer happened at month 22, ten months after I joined. The mechanism was the company's engineering ladder review, which happened twice a year. I was not on the ladder review by default at month 18 (the first review I was eligible for) because the ladder review required nominations from your manager and a peer review packet. My manager, who I had built a working relationship with, did not nominate me for the month-18 review. Her phrasing, paraphrased: "You are operating at high-junior. You are not yet operating at mid-level. The gap is small but real and I do not want to put you up for review against a bar you are not yet hitting."
I asked her what the gap was. Her answer was specific: the projects I had led so far were well-scoped projects where the success criteria were clear from day one. The mid-level bar at this company required leading a project where the success criteria were not clear from day one, where I had to do the work of defining the criteria with stakeholders before the technical work started. She offered to find me a project of that shape, with the explicit framing that it was a stretch project and might fail.
The project she found was a deprecation: an old internal tool that several teams used in different ways, where the deprecation required talking to each team, understanding their use case, and either migrating them to a replacement or convincing them to drop the dependency. The technical work was small. The relationship and definition work was large.
I ran the project for four months. Two of the four teams migrated cleanly. One team negotiated a replacement that was different from the one I had originally scoped. The fourth team pushed back hard and we ended up keeping the old tool running for that team with a sunset commitment from a senior engineer on a different team. The project was successful in that it shipped, partial in that the original scope had been negotiated, and educational in that I had owned the definition work for the first time.
My manager nominated me for the month-22 ladder review. The review packet included the deprecation project as the lead artifact. I was promoted to mid-level. The compensation adjustment was small (junior-to-mid at this company was a 12% comp bump). The signal was the title and the bar I had committed to operating at.
Year three: the external senior role
The senior role at the new company came from a deliberate external search at month 30. I had a specific reason for searching externally rather than waiting for an internal senior promotion: the senior bar at my current company was high enough that the next promotion would take another 18 to 24 months, and the external market for senior backend engineers in my technical-depth area was active. The math of staying versus searching favored searching.
The external loop was at a mid-size data company, around 800 engineers. Five rounds:
The round that I had not seen before was R5. The bar-raiser round at this company was a peer from a different team whose job was to grade against the cross-org senior bar (not the team-specific bar). The format was a 30-minute deep-dive on a project I had led, followed by a 30-minute discussion of a hypothetical scenario the bar-raiser picked.
The project I picked was the deprecation from year two. This was a deliberate choice. I had a database-internals project from year zero, the KV store, that I could have picked. I had a couple of clean technical projects from my mid-level work that I could have picked. I picked the deprecation because the bar-raiser was grading on senior-shape, and the senior shape at this scale of company was not pure technical depth. It was the ability to navigate ambiguity, run a project where the scope is contested, and ship a partial-success outcome cleanly.
The bar-raiser pushed me on the project for the full 30 minutes. They drilled into the team that pushed back, what I had tried, what had not worked, what the eventual compromise was, and how I had documented the compromise so the next person who had to revisit the decision would have context. I had answers for all of these because I had lived the project. The bar-raiser, in the debrief, said: "That round was strong-hire on senior-shape. The technical depth came through in the design round. The senior-shape came through in the deprecation discussion."
The specific bet from year two that paid out in this round was the choice to take the deprecation project rather than holding out for a clean technical project. At the time, I had been worried that the deprecation project would not be a strong artifact. In year three, it was the strongest artifact in my packet.
What compounded and what did not
Three bets compounded across the three years, and one did not.
The depth bet from year zero (the KV store project) paid out in the year-one loop and again, in a different way, in the year-three system-design round. The depth bet specifically was: pick one technical area, go deep enough that you have defensible opinions, accept that the time cost will not pay off in any specific job application but will be available for any application where the topic comes up.
The operational-thinking bet from year one (the streaming take-home) paid out repeatedly across the next two years. It was the difference between code-that-works and code-that-can-be-on-call-supported. The bet was: when you are doing any substantive piece of code, ask what would happen if it were running in production with real users, and answer the question before you ship.
The ambiguity bet from year two (the deprecation) paid out in the year-three bar-raiser round. The bet was: when your manager offers you a project that is ill-defined and might fail, take it. The clean projects produce clean wins. The ambiguous projects produce stories.
The bet that did not compound was a side bet I made in year one to write technical blog posts. I wrote eight posts in year one, mostly tutorial-style explainers on Django patterns. The posts produced no measurable benefit in either the year-two transfer or the year-three loop. No interviewer brought them up. They did not surface in any recruiter conversation I had. The time spent on them (about 30 hours over the year) would have been better spent on the depth bet, which did compound.
A note for the candidate at month four
The path I am describing took 36 months. Most of the value was concentrated in three or four bets that I made in moments that did not feel like turning points at the time. The depth bet (year zero) felt like a luxury. The operational thinking bet (year one) felt like over-engineering. The ambiguity bet (year two) felt like a stretch project I might fail. None of them felt, in the moment, like the bet that would compound. They were the ones that did. The ones that felt obviously right (the volume of practice problems, the conference talks, the blog posts) compounded less or not at all.
If you are in month four of a self-taught path, the move that is most likely to compound is one that, today, does not feel like the urgent thing to spend your time on. Pick one technical depth. Build a real artifact in it. The artifact will be available to you, in slightly different shapes, in every loop you sit for the next decade.