How I went from newbie to Software Engineer in 9 months while working full time

In this post, I’ll share how I went from zero(ish) to a six-figure software engineering job offer in nine months while working full time and being self-taught.

Whenever I would start reading a success story, I would immediately look to find the author’s background, hoping it would match mine. I never found someone who had the same background as I did, and most likely mine won’t match yours exactly.

Nonetheless, I hope that my story inspires others and acts as a valuable data point that can be added to your success story dataset.

Full Disclosure

I took a Visual Basic for Applications (VBA) course in high school (nine years ago). In my freshman engineering course (seven years ago), I learned some C, Python, Matlab, and Labview. I graduated from a good university with a chemical engineering degree and a good GPA (three years ago). I hadn’t done any programming outside of school, in high school or college, until I decided I wanted to learn last year.

After college, I got a job as a Process Engineer at a refinery. I worked there until I changed careers into Software Engineering.

Why I wanted to change careers

I enjoyed solving technical problems, but I knew I wanted to get into the business/startup world at some point. I always kept the thought of an MBA in the back of my mind, but every time I looked at the price tag of the top schools, my interest waned.

On May 27th, 2017 I found myself googling about MBAs again, and somehow I stumbled upon software engineering. It seemed like a perfect fit.

Software engineers are in increasing demand, salaries are great, and it’s the perfect industry from which to get into the startup world without needing a ton of initial capital. All you need is a computer, and your opportunities are limitless (kind of).

In no other engineering discipline can you just have an idea, start building it, show it to users, and iterate with little capital and low barrier to entry. In chemical engineering, you essentially need a running plant or a lot of money to design a plant if you had an idea for a new product.

I had heard of people quitting their jobs and attending a bootcamp, but the more I read about it online, the more I realized that you can totally learn it all on your own if you are committed and focused.

You might argue that you are losing out on the networking and career advice provided by a bootcamp. This can be true, but I was fortunate in that I was living in the Bay Area which allowed me to attend several meetups, so I networked that way.

Besides, the worst case was that I’d realize that I couldn’t do it on my own, and then I would quit my job to attend a bootcamp.

The Goal

Photo by Robert Baker on Unsplash

You need to have a goal. Especially if you are trying to learn while working full-time. It is easy to let your learning drag on and on if you don’t have any external pressure pushing you. So you need to create internal pressure. Your goal should be simple and quantitative. You should do enough research to come up with a reasonable goal. Mine was the following:

Get a software engineering job within one year with the same or better salary than I am making right now.

The Plan

Photo by Glenn Carstens-Peters on Unsplash

Once you have a goal, you need a plan to help you get there. This is where you consume as many success stories as you can. None of them will match your exact situation, but you can take some advice from each one. I developed (and iterated on) my plan using resources such as the learnprogramming subreddit, the freeCodeCamp forum, and Medium.

On May 27, 2017 I decided I was going to make the coding plunge, and I dove in head first. That day I decided to start putting in no more than 40 hours per week at my job, so that I had time to code after work and on the weekends. Luckily for you, I did a pretty good job of documenting my progress.

My plan, through many iterations, ended up looking something like this:

1. Take an Intro to CS course to get a solid base understanding of core CS concepts
2. Follow freeCodeCamp until I can build portfolio-level full stack web apps on my own
3. Refactor to clean up the code, add testing, focus on advanced concepts
4. Contribute to open source
5. Prepare for job interviews

To start, my plan was simple. At the time, I thought I was going to follow Google’s Technical Guide, so I started with their recommended introductory course, Udacity CS101.

Month 0 - Udacity CS101, Harvard CS50

The high of making this big decision gave me a ton of energy. I would start coding as soon as I got home from work and wouldn’t stop until I went to bed. And then again all weekend. Udacity CS101 tracked completion percentage, which was a big motivator for me. I logged my completion percentage every day after coding. I finished the first 75% in 10 days. The last 25% was heavy in recursion, and it was a bit tougher for me. All in all, it took me 20 days to finish Udacity CS101.

While I was taking Udacity CS101, I had started reading the learnprogramming subreddit quite heavily. I read that it was important for self-taught developers looking to make a career change to be active online. I decided to make new Twitter, Reddit, Stack Overflow, Medium, and Quora accounts using my full name, so that I could build up an online presence.

Also, I decided to stop reading distracting media like Instagram, Facebook, and non-programming subreddits. I would only check my phone for programming-related news and posts. This was crucial in making sure that I was finding out about the best learning paths and learning resources. It was because of this that I found out about Harvard CS50 on edX.

I was originally content with just doing one intro course, but everyone seemed to recommend Harvard CS50, so I decided to dive into that next. CS students at other schools had taken this course and said they learned more in CS50 than a year or two at their university studying CS. The general consensus was that the course was difficult but worth it. By the end of Month 0, I had completed the first 5 lectures and homework assignments.

Month 1 - Harvard CS50, Linux, 1st Meetup, freeCodeCamp

I completed CS50 about halfway into the month. I’m not going to comment too much on my experience with CS50, because I wrote an in-depth post about my experience here.

TLDR: It’s a great course, I highly recommend it. David Malan is an excellent lecturer, and there are a ton of resources to help you get through it. You start in C, move on to Python, and then finish with web development. It is very dense, and there is a lot of material, but I think it is well worth it.

After CS50, I decided to set up my XPS 15 to dual boot Windows and Ubuntu. That was a frustrating weekend. I messed up my partitions and almost bricked my laptop. I was close to chucking my laptop and getting a new one.

I slowly weaned myself off of Windows and eventually was solely using Ubuntu. I wanted to force myself to get comfortable with the command line which I think worked to some degree, but I still have a long ways to go.

I started 100 days of code to make sure I stayed focused and coded every day. It is important to document your progress. If you are making progress every day, it won’t seem like much but when you look back a month or several months, you will realize that you have actually made quite a bit of progress which motivates you to keep going.

I knew that networking would make or break me, so I mustered up the courage to go to my first coding meetup. I had never gone to any meetup let alone a coding meetup. I was so nervous that after driving there, parking, and walking to the door, I almost turned around and went home.

It helped that it was the first meetup for the group. I quickly realized that there was no reason to be nervous. No one knew each other, no one was judgmental, and everyone was eager to learn. This was the beginning of a meetup-spree. I ended up attending over 50 meetups in 9 months.

I’m glad that I started going to meetups early. Most people only started to attend meetups when they were looking for a job, but at that point it is almost too late. There are so many reasons to start early. To name a few:

1. Developing relationships takes a long time. Starting early means that you have connections who can vouch for you when looking for a job later
2. Talking about programming with strangers is a great way to prepare for interviews
3. You can learn new frameworks, tools, and learning resources from people who are ahead of you. This can influence your future learning plan.

There was some uncertainty at this time in my coding journey. This was about when I needed to decide what kind of software developer I wanted to be.

Ultimately, I chose web development because it seemed like there was high demand and also a lot of online resources. Once I had that figured out, I needed to figure out what to do next. Some people recommended that at this stage I should think about web apps I wanted to build and then get going. Some people recommended The Odin Project or freeCodeCamp.

The guy that was running the weekly meetup I was attending knew Ruby and wanted to do projects with Ruby. This was a big reason why I made the decision to go all in on The Odin Project.

And then two days later I ditched that idea.

That is one of the downsides of going the self-taught route. One minute you think you know what path you should take, but then the next day you wonder if that was the right move.

I read that Ruby was falling out of favor, and I proved this by searching for Ruby vs JavaScript jobs, so I ended up starting freeCodeCamp. The one thing that bothered me about freeCodeCamp was that they came up with the project ideas, so every camper does the same projects. This concerned me at first because I wanted to stand out to recruiters. However, I ended up loving freeCodeCamp, and now I highly recommend it. For more details on my experience and recommendations regarding freeCodeCamp, check out my writeup here.

Month 2 — YDKJS, freeCodeCamp Front End, React

I started reading You Don’t Know JavaScript, because everyone recommended it to supplement freeCodeCamp. I had to re-read several sections as it is pretty dense, but it’s a perfect resource to learn lexical scope, closures, promises, and all parts of JavaScript that you hear about and want to learn but never do because they seem difficult.

I finished the front-end section of freeCodeCamp. The checklist format and estimated completion time helped motivate me to finish quickly. I was also itching to move on to the next section and learn React. However, this also meant that my projects had minimal styling. I did whatever it took to fulfill the user stories and nothing more.

In hindsight, maybe I should have focused on making the projects more appealing. Perhaps, this would have helped me learn CSS more deeply.

The next step was learning React, and I was pretty pumped.

I had heard so much about it, and I was ready to fit in with the cool kids. However, I was a little hesitant given the licensing issues at the time. I’m really glad that is no longer an issue. Learning React was difficult for me. I wasn’t aware of any good tutorials then (but it seems like there are a ton now).

I tried reading the docs and following along with Facebook’s Tic-Tac-Toe tutorial, but I didn’t quite understand all of it. I was told if that wasn’t working for me, then it meant I didn’t understand JavaScript enough. So then I went back to reading You Don’t Know JavaScript, but again that was too dense for me.

Month 3 - freeCodeCamp React, CodeClub, Starting freeCodeCamp Back End

Ultimately, I just decided I would work my way through the freeCodeCamp React projects to see how it went. That code was ugly, but it did help me understand React a little better.

That meetup I had been attending weekly decided that they were going to build projects with full stack JavaScript instead of Ruby, and they decided that the first project would be to build a website for the meetup group, CodeClub.Social.

I developed cards using React and Meetup API allowing the user to sign up for the next three meetups from our website. It was a little difficult for me to take a quick break from freeCodeCamp to do this, but it was an opportunity I couldn’t pass up. I was happy to be working on a project with a small group of people. It also helped me learn Git and Github.

Before the month was over, I started working on the back end section of freeCodeCamp.

Month 4 - Finished freeCodeCamp Back End, Yeggle

I worked through all of the API projects in freeCodeCamp, but I started deviating from freeCodeCamp at the Image Search Abstraction Layer project.

I was itching to make full stack web applications, so as soon as I saw the title of this project, I had an idea for my own project. I would make a node app that would store random imgur URLs in a database, and then make a front end that would output a user-specified number of those random images. What everyone says is true: you work harder and have more success when you are working on a project that was your own idea.

Once I got it to work, I was very proud of myself. It was ugly and clunky, but it worked.

As I was working through freeCodeCamp, I was learning about what projects would be within my capabilities. I was running regularly at the time, so I would come up with ideas on my runs and write them down when I got home. That way I would have a list of project ideas when I was ready.

I finally felt ready to start making my own useful and polished full-stack web apps to share with users and put on my portfolio. I was so ready to get started.

When looking for a new restaurant, I always found myself opening Yelp to check reviews, and then opening Maps to check their reviews. What if I made an app that compared both side by side?

So I made Yeggle. I used Node/Express/React along with the Google Maps and Yelp APIs. There were a couple obstacles I didn’t think I would be able to overcome, but in the end I finished and I was very proud of my app. Then I posted it to Reddit, and no one cared. That was a bit of a bummer, but I didn’t let it get me down.

Month 5 - StockIT

I didn’t get quite as much done this month, as I started it off with a two week vacation to Japan and Thailand!

But I did start and complete my next project. I kept reading about how difficult it was to get a job as a self-taught developer, so I thought I needed to do something unique. I remembered a game where a Dow Jones stock graph started trending, and you had one opportunity to buy and one opportunity to sell, and the goal was to beat the market. The purpose of the game was to show you how difficult it was to beat the market.

My idea was to make a game similar to that, but instead of the market, you would be playing against a machine learning algorithm. So I created StockIT.

I took a video tutorial on Pandas and Scikit Learn that covered multiple machine learning techniques. I originally wanted to do some cool deep learning techniques, but I realized that took massive datasets and more time than I wanted to spend.

Instead, I stuck to a simple linear regression model. I thought that would be the hard part, but it wasn’t. Getting D3 to jive with React was the hard part. Both libraries wanted to control the DOM. There were some other libraries that helped to join the two, but I felt they were too bloated. I ended up using D3 to generate the SVGs and React to handle the DOM which worked out quite well for me.

This time when I shared it with Reddit, everyone loved it!

Turns out, just like VCs, redditors are all about that machine learning. All the love from Reddit was a big confidence boost. People were playing my game and enjoying it!

Month 6 - jobSort(), Job Hunt Prep

After StockIT, I rolled right into my next personal project. I wanted to make a job board that aggregated the smaller tech-focused job listing websites such as Stack Overflow, Github, and Hacker News. To add my own unique spin to it, I decided to have it sort based on the technologies the user wanted in a job and how badly they wanted each of them.

For example, let’s say I was looking for a job that was looking for someone who knew JavaScript, React, and/or Python, and I really wanted to work with JavaScript and React but I didn’t care so much about Python. Then I could give JavaScript a 3, React a 3, and maybe Python a 1. The listings would then sort accordingly.

I ran into various obstacles with this project and had to change course a couple times, but I ended up with a product I was happy with. My final tech stack was React/Node/Express/MySQL. I posted the project to the cscareerquestions subreddit and got 650 views before it was taken down because they don’t allow personal projects.

The “final” product is here, and if you’re interested in knowing more about my struggles and refactors, check out my post here.

Because of my issues, jobSort() took up a decent portion of the month. I ended up getting coffee with a friend I had met at my first meetup, and he advised me to start applying for jobs now. I read all over the place that everyone says they waited too long to apply. Also, whenever I saw a post asking when to apply, the top comment was always “now.”

In my head, I was going to work my way through my structured plan to build up my portfolio with personal projects, and then work on open source contributions, and then prepare for interviews, and finally start applying to jobs. This friend convinced me to ditch that plan and start applying. So this month I made a portfolio and a resume. The following month I would start applying.

Month 7 - Testing, Job Hunting

This month I focused on touching up my projects and applying to jobs. I also wanted to learn testing and Redux.

I added flexbox to CodeClub.Social to make it responsive. I improved the mobile UX on jobSort(). I added testing to jobSort() with mocha/chai/enzyme which was difficult to set up, easy to get started, and then difficult to get 100% coverage.

By the end of the month, I had applied to 63 jobs. I viewed this as a self-assessment. Was my portfolio/resume good enough? If so, what did I need to work on to prepare for interviews? At first, I applied with Hacker News: Who is Hiring, and Indeed.

On Hacker News, I used jobSort() to determine which listings to apply for. On Indeed, I tried non-software companies to see if I could even get a call or an interview anywhere.

At first, I was applying quickly and not personalizing my resume/cover letter. Then, I decided to personalize my cover letter and resume, and then try to send an email to someone from the company. This method was clearly better than the shotgun approach.

I received five calls that month — two from recruiting companies and three from software companies that included:

• a contracting DevOps/testing role at a dotcom company
• a series B food analytics company, and
• a fairly large and successful startup that was recently purchased by a major corporation

I made it past the HR screen in two of these, but none of them yielded an onsite interview. I was pretty happy with the three calls, and I learned a lot from them.

Everyone mentioned online that junior developers aren’t expected to know that much from the start, they just need to be passionate and excited to learn. So I thought, easy. I am passionate and excited to learn. What I learned from these calls, however, was that nobody was looking for a junior developer. They expect you to know what you’re doing from day one.

These calls taught me that I needed to

• be good enough to add value from day one
• be confident enough to convince them that I can add value from day one

Month 8 - Night Shift, Redux, Open Source, Onsite Interview

I started this month working the night shift for a 40 day stretch at my full time job - 6 days a week, 12 hours a day, 5PM to 5AM. Ugh.

I knew I wouldn’t be able to get as much done this month, but I had a goal and I wanted to meet it, so I couldn’t take a month off.

I refactored jobSort() to use Redux which was surprisingly not as difficult as I thought it would be. I listened to a lot of podcasts about it and read blogposts about it, and it never quite made sense to me until I started using it.

I really like the flow of data with Redux. It’s interesting now seeing people complain about Redux. I don’t think I’m qualified to spout off my opinions strongly, but I do like the reducer pattern.

This was supposed to be the month of open source for me. I was going to make my first open source contribution, and it would be a great contribution to a fantastic library. I was going to contribute to React!

Everyone said it was a difficult codebase to read let alone contribute to. But I needed to stand out, I needed to be unique. I knew that my contribution wouldn’t be significant, but I still wanted to do it nonetheless.

I would start by reading the docs all the way through and then pouring through the codebase. Watch every issue, every PR. Reading through the React docs in full was a great exercise, and I’m glad I did it. But I quickly realized that the issue with contributing to React is that there just aren’t that many “good first issues,” and they get snatched up quickly.

At one of the meetups I attended, Anthony Ng recommended that I try out Downshift, an autocomplete library by Kent C. Dodds. This was a gamechanger. It was right in my wheelhouse. The right difficulty, right amount of issues to help with, not too many collaborators, super helpful maintainer, clean well-tested code. On top of all that, it was a perfect solution to some issues I was having with my jobSort() application.

About halfway through the month, I received an email from one of the companies I applied to in the previous month. They set up an initial phone screen, and then a technical phone screen. The technologies they were looking for were exactly what I had learned - React, Redux, and D3. I mostly just talked about my projects and why I made certain decisions. After this, they asked me to come onsite for an interview. My first onsite interview!

I hadn’t prepared for interviews at all, so I went into it with the expectation that I wouldn’t get the job, but I would gain valuable interviewing experience. I also was running on three hours of sleep since I was still working the night shift which didn’t help. Luckily, the technical portion wasn’t whiteboarding, just a one-hour pair programming session. It was a fairly straightforward challenge, but I was very nervous.

At first, I was worried about making sure I knew everything without looking it up. When I realized that I wasn’t going to finish the challenge, I realized that I needed to stop worrying what the interviewer thought of me and just google/stack overflow to find answers. I didn’t end up finishing, and I thought I failed miserably.

Since I thought I failed the pair programming, I felt relaxed for the rest of the interview. Ultimately, I left the interview with my chin up. Worst case I got some valuable interviewing experience, and best case I got my first job offer.

Month 9 - Job Offer

I ended up receiving my first job offer 9 months and 7 days after that first day when I decided I was going to dive head first into programming with the intent of changing careers. I felt confident given that I received an offer after my first onsite interview, but at the same time, if I didn’t take the offer, what if this was the only offer I would receive for several months? I ended up taking the offer, and I am happy with my decision. I wanted to get paid to code!

Advice

Up to this point, I have mostly shared my story with some advice sprinkled in. Chances are if you’re reading this, you either are thinking about changing careers or are in the middle of learning to code with the intent of changing careers. I hope that the advice below will help you develop a plan or stick with your current plan and reach your goal.

1. Find out what motivates you and use it to your advantage. For me, it was checklists, documenting my progress, and interacting with various programming communities. If you are not motivated to reach your goal, then nothing else matters because you won’t finish.
2. Make goals and meet them. I would argue that you should have monthly goals and maybe even daily goals. Monthly goals to make sure you are on track to meet your main goal, and daily goals to make sure that you actually make daily progress. One strategy that worked for me was to make my daily goals the night before. That way, you can’t do unproductive work all day and feel like you made progress when you really didn’t. It forces you to compare your daily accomplishments with your daily goals.
3. Go to meetups way before you think you are ready. Going to meetups can feel scary, but as I mentioned above. But, in general everyone is nice and willing to help. You might find people that aren’t interested in talking with you, but they are the minority and no one will be judgmental. Also, everyone loves to give advice (like I’m doing right now).
4. Contribute to open source way before you think you are ready. When you first start programming, Github seems like this scary place that you never want to go to. It is actually very welcoming to beginners and is a great place to see good code and get your own code reviewed. If you’re still not convinced, check out my post, Why you should contribute to open source right now.
5. Start applying way before you think you are ready. This one was tough for me because I thought I was different. I thought I didn’t need to test the market to get a feel for what to work on. I thought I would know when I would be ready to apply. I’m telling you right now. You will not know when to apply. So you might as well start now. You shouldn’t go crazy and apply to 300 companies before you learn for loops. But you should know that the best way to know what you need to learn is by applying and testing the market.

Now get back out there and code!