I have a confession.

I studied Material Science and Engineering at IIT Kanpur. Not Computer Science. Not ECE. Not even IT. Material Science — the study of metals, polymers, ceramics, and crystal structures.

And today, I write embedded software at Jaguar Land Rover. I build full-stack apps. I think about system design, data structures, and socket programming for a living.

Nobody handed me this career. I built it — one gap at a time, one panic attack at a time, one "I have no idea what I'm doing" at a time.

If you're from a non-CS background trying to break into tech, this is for you.

The Impostor That Never Leaves

Let me be real.

Three years into my software career, I still sometimes feel like a fraud. A colleague casually mentions "amortized time complexity" and I nod like I've always known, while my brain scrambles to fill in the gaps.

The thing about not having a CS degree is that you don't know what you don't know. CS graduates spent four years building a mental map of how everything connects — operating systems, compilers, networks, algorithms. They might not remember all of it, but they've seen it. They have a skeleton to hang knowledge on.

I didn't have that skeleton. I had to build mine from scratch, bone by bone.

How I Actually Learned

Here's what nobody tells you: YouTube tutorials and online courses are not enough. They give you the what but rarely the why.

I tried the popular route first. Watched videos. Did a few Coursera courses on DSA and ML. Felt good about myself for a week. Then promptly forgot 80% of it because I had no context to anchor it to.

What actually worked for me was different.

1. Learning through real problems, not syllabi

My first real CS education happened during my internship at IIT Kanpur's SURGE program. I was building a task management system and suddenly needed to understand async/await, WebSocket connections, Redis caching, and CI/CD pipelines. Not because a course told me to — but because my code wouldn't work without them.

That's when things started clicking. Necessity is a better teacher than any curriculum.

2. Going embarrassingly deep on one thing at a time

When I joined JLR and started working on embedded systems, I couldn't afford surface-level understanding. FreeRTOS doesn't forgive hand-waving. If you don't understand memory management, your system crashes. If you don't understand scheduling, your real-time constraints fail.

So I went deep. Painfully deep. One concept at a time. I didn't try to learn "all of operating systems" — I learned exactly how task scheduling works in FreeRTOS, then how memory allocation works, then how interrupts work.

Depth in one area teaches you how to go deep in any area.

3. Building things that scare me

A blockchain developer internship in Zurich. Smart contracts in Solidity. Uniswap V3 integrations. I said yes to things I had no business saying yes to — and then figured it out.

Every project I've taken on has been slightly beyond my current ability. That gap between "what I know" and "what I need to know" is where all the real learning happens.

4. Accepting that the fundamentals matter

This is the one I resisted the longest.

For a while, I told myself I didn't need to know how a compiler works or what happens inside a CPU pipeline. I'm a practical engineer, I said. I build things. Theory is for academics.

I was wrong.

The more I grow as an engineer, the more I realize that fundamentals aren't academic exercises — they're the difference between debugging for 20 minutes and debugging for 2 days. Between writing code that works and writing code that scales.

I'm now going back and learning CS from first principles. Properly. Systematically. Not because someone's making me — but because I finally understand why it matters.

What I'd Tell Myself Three Years Ago

Stop comparing your Chapter 1 to someone else's Chapter 10. CS graduates have a head start on theory. You have a head start on resilience, resourcefulness, and the ability to learn anything from nothing. Both matter.

Don't learn in order. Learn in context. You don't need to complete an entire algorithms course before building something. Build first. Hit walls. Then learn exactly what you need to climb over them.

Write code every single day. Not tutorials. Not following along. Your own code. Your own bugs. Your own solutions. That's where understanding lives.

Find your teaching style. I learn best through deep, end-to-end explanations with no gaps — followed by hands-on exercises. You might learn differently. Figure out what works for you and be unapologetic about it.

The fundamentals will call you back. You can avoid data structures, operating systems, and networking for a while. But eventually, to go from good to great, you'll need them. Start early. Start now.

The Uncomfortable Truth

Here's what I've come to accept.

I will probably always have gaps that a CS graduate doesn't. There will be moments in meetings where a concept is obvious to everyone except me. There will be terms I Google that others learned in their second year.

And that's okay.

Because I also bring something they don't — the perspective of someone who chose this path deliberately. Not because a counselor recommended it or a college seat was available. But because I fell in love with building things and refused to let a degree define what I could or couldn't do.

My degree says Material Science. My work says Software Engineer. My journey says neither defines me.

---

You don't need permission to learn computer science. You don't need a degree to be a real engineer. You just need curiosity, stubbornness, and the willingness to be bad at something long enough to become good at it.