How I Became an Engineer Without a CS Degree
I graduated with a Finance degree and became a founding engineer at a YC startup. Heres what the self-taught path actually looks like.
How I Became an Engineer Without a CS Degree
I graduated from the University of Illinois Urbana-Champaign with a degree in Finance from Gies College of Business.
Now I'm a Founding Engineer at Origami, a YC-backed startup building AI agents.
There was no bootcamp. No CS degree. No traditional path. Here's what actually happened.
The Starting Point
Before Origami, I was building websites for $700. Freelance work for small businesses. It was good for learning, terrible for ambition.
But it gave me something invaluable: proof that I could learn technical things on my own. Every website I built was a problem I'd never solved before. Every bug I fixed was a concept I'd never encountered.
The gap between "freelance web developer" and "startup engineer" felt massive. But the skillset gap was actually smaller than I thought. The real gap was in environment and expectations.
What Self-Taught Actually Means
Self-taught doesn't mean you learn alone. It means you learn without a formal curriculum.
Here's what my "curriculum" actually looked like:
Building real things for real people. Client work forced me to ship. You can't half-learn something when someone is paying you for a deadline.
Working alongside people better than me. At Origami, I was surrounded by engineers who had years of experience I didn't. I learned more in my first month than in a year of solo study.
Going deep on one stack. Instead of dabbling in everything, I went deep on TypeScript, Next.js, and the AI tooling ecosystem. Depth beats breadth when you're self-taught.
Reading code more than tutorials. Tutorials teach you how someone else solves problems. Reading production code teaches you how problems get solved in the real world.
The 6-Month Deep Dive
When I joined Origami, I made a bet: I'd go deep on engineering for 6 months, even if it meant not contributing to other areas of the business immediately.
This was uncomfortable. There were other things I could have done — GTM work, content, sales calls — where I'd have shown value faster. Engineering was the slower payoff.
But I took a longer view. Engineering is something I want to do for the rest of my life. That's a life optimization function, not a one-year optimization function.
The results didn't show up in month 1 or month 3. But by month 6, I was building internal tools, shipping features, and eventually building the AI agents that became core to our product.
What You Actually Need to Know
If you're thinking about the self-taught path, here's what matters more than you think:
- Git and version control. Not glamorous. Absolutely essential.
- How to read error messages. Seriously. 80% of debugging is reading the error message carefully.
- How to ask good questions. Whether it's to a senior engineer or to ChatGPT, the quality of your questions determines the quality of your learning.
- How to ship. Perfectionism is the enemy of the self-taught developer. Ship something ugly, get feedback, improve.
And here's what matters less than you think:
- Which language you start with. They're all tools. Pick one and go deep.
- Your educational background. Nobody at Origami cares that I studied Finance. They care about what I can build.
- How long it takes. The timeline is irrelevant. The trajectory is everything.
The Honest Part
There were moments of intense imposter syndrome. Sitting in code reviews with people who had CS degrees from top schools and thinking, "I don't belong here."
But imposter syndrome fades when you start shipping. You can't argue with working code.
And I want to be honest about the gaps too. Being self-taught means there are real things I'm still closing:
- Testing discipline — I know test cases matter, but the sustained habit isn't there yet. Big unlock ahead.
- Observability — Sentry exists in my projects, but systematic logging, metrics, and traces across everything I build? Not yet.
- Concurrency & queues — Rate-limits, exponential backoff, idempotency keys. I've hit these problems in production with multi-agent runs but haven't mastered them.
- Fundamentals — Operating systems, distributed systems, networking. I'm building on abstractions I don't fully understand yet. Every time I learn what's underneath, my debugging ability jumps.
The pattern I've noticed: acknowledging what you don't know is what lets you close the gap faster. Pretending you know everything is what keeps you stuck.
The self-taught path isn't easier than the traditional path. It's just different. You trade structure for speed and credentials for proof-of-work.
If you're considering it: start building something today. Not tomorrow. Today. The path becomes clear once you're walking it.