How to Self-study to Become a Software Engineer, Part 1

I graduated college with a degree in social welfare, and a little over a year after self-studying at home, I was working as a software engineer. There’s a growing number of people today with similar stories, including many on my team at Exabeam, some of whom I’ve interviewed to prepare this article. This is part one of our two-article series discussing some tips that we felt may help guide someone looking to self-study as well.

Start with the fundamentals of computer science

The ideal engineer for any company is someone who can operate independently to squash bugs and implement features using clean code and scalable design decisions. When companies hire someone who isn’t that person, they’re hoping that they can become that person. So, the goal for anyone preparing for this career is to convince companies they have this growth potential.

The best indicator of those qualities is a strong grasp of the fundamentals. It’s a misconception that companies just want to see that you can type the right sequence of lines to do a Google-able common task. They want to see that you understand what you typed so that when the time comes, you can use it to solve uncommon tasks. And that’s what fundamentals are – understanding the building blocks and knowing how to use them to do just about anything.

It helps immensely to start at the fundamentals rather than in the middle of some thin vertical slice of a specific domain (e.g. web development). If you build on top of some concepts that you only understand 70% of but can use for your task, missing knowledge quickly compounds as you get to higher levels of abstraction. When a bug occurs three layers up and you’ve missed 30% of the understanding of each layer below, you’re stuck. Maybe Google has the answer, but you don’t even understand enough of what you’re doing to know how to phrase the question.

A guided path on a thin vertical is what boot camps do, and they sidestep this problem by having people around for you to ask questions when you get stuck due to a lack of fundamentals. But this is like putting duct tape on a structural crack. Don’t build a house with duct tape. Without strong fundamentals during interviews, you have to rely on luck that the interviewer is looking at you at just the right angle to not notice all those cracks.

Trending tools, frameworks, and libraries all change, but the fundamentals don’t. The intro class that I self-studied from UC Berkeley is based on one taught at MIT when there was only one computer for the class to share. Yet the material is essentially the same.

Here are some of the free resources I used to learn computer science fundamentals:

• UC Berkeley’s CS61A: Structure and Interpretation of Computer Programs
  • Supplementary notes
• UC Berkeley CS61B: Data Structures.

What my colleagues suggest:

• Warren, frontend software engineer: “Even though React is an amazing technology, I personally think you should at least know the ins and outs of JavaScript before learning React, since it mainly uses JavaScript.”
• Clement, front end software engineer: “One thing for sure is, I need to understand the basics of web dev which is knowing how to work with HTML, CSS and JS. It’s like I need to know how to crawl before I can walk. By understanding the fundamentals of web dev, it allows us to work with different tools with ease.”
• Albert, frontend software engineer: “Google everything: Part of how I started understanding tech in general was by reading companies’ engineering blogs and going through and Googling every word/phrase I didn’t know until I fully understood blog posts.”

Roughly, 20% theory, 75% building, 5% preparing

I just advocated for the importance of studying theory, but I don’t recommend you sink too much time into it at first. The primary goal is, again, to convince companies that you have potential — after that, you are paid, partly, to grow and learn. So finish your learning while getting paid.

My curriculum was to first learn the fundamentals of computer science, then choose a domain, learn some of the fundamentals in that domain, build things, and prepare for interviews.

At many top tech companies, the interns walking the hallways outside of summer come from schools like Northeastern and the University of Waterloo. That’s because those schools understand the importance of learning by doing, and have students spend a significant amount of time interning instead of sitting in the classroom. By the time they graduate, they usually have an advantage in getting hired over students who’ve been only focusing on their GPA.

What should you build? Ideally, it’s something that:

• Is technically challenging to prove your core skills
• Is useful to prove you can think through a product (it’s always a plus when an engineer demonstrates product sense)
• Has users, which forces you to take the project more seriously

That’s hard to do for most experienced engineers, so don’t worry if you don’t succeed — it’s just a compass point to head toward. Start with toy projects to get your feet wet, then choose some interesting extensions. I built a web app for tracking moods on a calendar, and then a “marketplace” for people to post things they wanted to give away so it doesn’t go to waste. Zero users 🎊, but I still built the app with the assumption that users would use it and thought about what users would want, and that made it very challenging. I ended up learning most of what I am now doing on the job while building those projects.

One thing I had trouble with is where to start. There are so many distinct verticals in software that I was overwhelmed. My advice is to scan job boards, see which verticals are in demand for junior engineers, do a little research on a day-in-the-life of an engineer, and pick one that interests you. If you have strong fundamentals, it won’t be hard to switch at any point. I’m a very visual learner and it was easier for me when I could see the code I was writing translate to something on the screen. I Googled, “how to build a web app” and went from there.

Make sure you leave time at the end to prepare for interviews after building your projects. Many companies these days use derived theoretical challenges, which is an esoteric field. These don’t have anything to do with what you’ll do on the job, but it helps companies standardize their interviews. It’s worth your time to learn and practice these. There are many specialized resources, the most popular being LeetCode.

What my colleagues suggest:

• Warren: “After learning the basic concepts and syntax, the best way to improve your skills is by writing more code on your own.”
• Clement: “I self-learned React and Angular 2 (it was old at that time), creating my own side project and posting it on GitHub to allow people to see what I had done.”
• Albert: “Ask yourself what is something that you’d want to exist and use it as a reason to learn about things you otherwise wouldn’t learn about.”

We looked at relearning the fundamentals and getting practical experience in this post, which I hope you found useful. In the second part of this article series, I’ll talk about mentors and how to sustain yourself for the long haul.