If you are thinking of switching careers to become a software engineer, then this post is for you. There are a lot of great resources available on the internet to become a job-ready software engineer, but it can be a challenge to separate the signal from the noise. It was for me anyways. My hope is to offer some insight that I gained from my own coding journey to make your journey a bit easier. Just a reminder, these are just my opinions.
For my undergrad I attended Penn State University and earned a BS in Petroleum and Natural Gas Engineering. I think what initially appealed to me the most about the program was the high job placement rate and the potential to travel to different parts of the world. Petroleum engineers also have pretty decent salaries, so that was certainly a factor too.
By my senior year though, I wasn’t as enthusiastic about working as a petroleum engineer anymore. Mainly because I realized that while it was true that I would have the opportunity to travel a lot, I would likely be travelling to remote areas and working long hours. I decided that after I finished the program, I would try to get a job in another engineering field instead.
I had kind of a hard time with that. There were a couple of reasons. My undergrad GPA wasn’t the best — 2.72. I also wasn’t very good at interviewing (but I did get better. these books helped: Presence by Amy Cuddy and How to Win Friends & Influence People by Dale Carnegie). Also it was kind of tough in general to get interviews for non-petroleum engineering roles because I had such a specialized degree (although some of my friends were able to do it, so maybe it was just mostly my interviewing skills to blame).
During this time I was fortunate enough to have parents that allowed me to live at home. This was a tremendous help to me. While not ideal, I am certainly glad that it was an option.
I also worked a few different part-time jobs to pay off some of my student loans during this time. Additionally, in an attempt to improve my resume I took two courses at a local community college. Then I went on to pass the Fundamentals of Engineering (FE) Exam.
It was no use though. After two years of unsuccessful searching, I made the hard choice to go back to school.
While searching for work I had seen quite a few postings for industrial engineering roles. After doing some research I decided that I could see myself working as an industrial engineer. I enrolled in the Industrial and Systems Engineering (ISE) graduate program at Lehigh University.
Now to be completely honest, I did consider studying Computer Science. At the time though, I wasn’t very computer-savvy. I had also taken a C++ course in my undergrad and didn’t do so well, so I opted to study industrial engineering instead.
I remember one day when I was working a shift at the library help desk, I was having a conversation with a fellow co-worker who just so happened to also be in my program. He was talking about Big Data and he was selling it pretty well. He said that I should seriously consider taking ISE courses that could lead to me getting a career as a data scientist. He was convincing, but I wasn’t yet completely convinced.
That next semester I did an internship at Mack Trucks. While working at Mack, I started to realize just how much data gets passed around for a company of that size. I decided that I should email my friend from the library help desk and ask him more about Big Data.
The following semester, I took courses that would allow me to learn more about the data sciences. I was willing and determined to overcome my fear of programming languages. I took a Python Data Mining course, a Business Analytics course using R, and a linear algebra course that used AMPL (which is sort of a programming language).
During this semester, I had also been reading Barron’s magazine and listening to different tech podcasts (favorite being CodeNewbie). From reading Barron’s I was able to learn that there were a lot of opportunities in the technology industry, especially for software engineers. Then by listening to the CodeNewbie podcast, I was able to learn that it was very possible to get a role as a software engineer without having a Computer Science degree.
When I graduated, my mind was made up. I was determined to become a software engineer. Now I just needed to figure out how I was going to do it.
I graduated in December 2019 (side brag: I graduated with a 3.52 so I definitely redeemed myself from my undergrad years 🙂 ) and after job searching a bit I took a job as an industrial engineer at Westport Axle in March 2020. Although I just really wanted to get hired as a software engineer right after graduating, I knew that I didn’t possess the skills needed for that to be realistic.
By the way, Westport is a partner company of Mack. They assemble the axles that are used on Mack’s trucks. Just in case you were wondering.
Just want to also mention that Lehigh, Mack, and Westport were all within driving distance of my parents’ house, so I was still living at home. Not too glamorous, but a great way to save money.
At this time, I still wasn’t sure what my next steps should be. The big question for me at that point was whether I should attend a bootcamp or go the self-taught route. Or maybe even just continue with the industrial engineering career (glad I didn’t consider this as an option for too long).
The bootcamp route was tempting. In fact I had been emailing a few bootcamps and was seriously considering enrolling. A bootcamp would give me structure, a peer network, and connect me with potential employers, but it would also cost a lot of money. I already had student debt and wasn’t too enthusiastic about taking on more.
The self-taught route seemed tough though. I would be missing out on everything a bootcamp had to offer, but I would be saving money.
This article helped shape my decision a bit. I also looked up the curriculum for some bootcamps. After some googling I realized that there were courses for those topics online. I realized that I could use the bootcamps’ curriculums and create my own curriculum. It seemed like it would take some extra work, but I was willing to do that to avoid taking on more loans. I ultimately decided to go the self-taught route.
So my plan was that I was going to continue working at Westport, and would code on weekday evenings and weekends. I figured that if I saved my money for six months, it would be enough to allow me to quit, so that I wouldn’t have a 50 hour work week getting in the way of my goal of becoming a software engineer.
That’s pretty much what I did. I worked at Westport from March 2020 to August 2020 and then lived off of my savings from August 2020 to July 2021, which is when I formally accepted an offer for a software engineering position.
Here are the topics that I studied during that time.
Here are two excellent resources that cover a wide range of programming topics:
Living on a budget was necessary in order for this career switch of mine to be possible. While working at Westport I spent very little. It was also during the middle of the pandemic, so that made going out less frequently a bit more convenient.
Didn’t eat out. Didn’t go out. Saved all of my money, so I could have something to live off of when I quit. I did take a trip to California after I quit, but I guess you have to live a little bit, right?
There was one time that I almost lived beyond my means though. I almost bought a new laptop.
There seems to be a misconception that in order to be a real developer you need a fancy new laptop. At least this is something that I believed. Even while getting my masters degree I felt very self-conscious about my ten-year-old laptop. I certainly do remember some strange looks when I would pull it out of my backpack.
I honestly kind of thought that the work that software engineers do would require an incredible amount of computing power. I thought that my laptop would not be able to handle it. So I bought a new laptop for around $2k. I remember not sleeping well at all that night, and then cancelling the order the very next day. I figured I would take my chances and push my old clunker to its limits. It was also a whole lot more important for me to put that money towards my quit-my-job fund instead.
The work I did on my laptop while becoming a software engineer mainly consisted of working in Visual Studio Code, NetBeans, or doing problems on LeetCode. It turned out that my laptop was able to handle all of these tasks just fine.
When I first started working at Westport, I had about forty connections on LinkedIn. I also didn’t have a Twitter account. All of the podcasts I was listening to stressed the importance of having a strong online presence, so I definitely needed to work on this a bit. I started engaging with aspiring developers on Twitter and on LinkedIn I focused on trying to connect with engineers who were already working in the tech industry.
I will admit that at first I felt intimidated trying to connect with people I didn’t know. It wasn’t so bad once I got started though.
I would typically send a connection request along with a few sentences that explained my situation. I would be sure to ask for their advice. For the most part, the people that did connect with me were incredibly helpful. Some would even talk to me on the phone or video chat. I learned a lot through these conversations. Lots of great advice.
But to sum up all of those great conversations in two points:
- Do projects to get interviews
- Know data structures and algorithms to pass interviews
I would say about 80% of the engineers that I spoke with recommended using LeetCode to prep for interviews. I have only used LeetCode and have really enjoyed the platform. However, there are many other algorithm practice websites out there. Do some research and pick the one that seems right for you.
An additional benefit from this that I then didn’t realize, was that these connections would later be willing to refer me for positions at the companies where they worked. Good deal.
So build your network. It’s important.
I started doing #100DaysOfCode right around this time. Really helpful and I can’t recommend it enough. Did two or three rounds just on Twitter, then I started doing it on LinkedIn as well. It’s a great way to hold yourself accountable, and it also allows you to take a look at what other people are working on. Also allows you to feel a sense of community.
From podcasts, blogs, reddit, …etc, I heard it mentioned frequently that it was important for a developer to have their own blog, so I decided that I should have a blog. It took me about a month of weekends to get it set up. I describe how I built it here. There are plenty of different ways to launch a blog though. If you do launch one, do some research and choose whichever way you think is best.
Although on the other hand, during interviews, many interviewers had some pretty nice things to say about my blog. I don’t think they would have said these nice things if I had just been using DEV or Medium. Another plus was that my blog also allowed me to become familiar with the AWS ecosystem. I used Amazon Lightsail, Route 53, and S3 to build it.
My blog was built with WordPress. While this option is not as ideal as coding it myself, I did not know how to code well enough at the time to build one. Building a WordPress blog allowed me to build a blogging platform without having to first become proficient with web development. Pretty good deal in my opinion.
Next I started learning Java. At the time here was my thinking for learning Java:
- Used by many large software companies
- Language used in Cracking the Coding Interview
- Language frequently used in LeetCode solution articles
Also I heard that this Java course was a great way to learn an object-oriented programming language. After completing this course, I agree.
Now don’t get me wrong, Java is now my favorite language, but if I could go back in time I don’t think I would have focused on learning Java. At least not if my goal was to get a job as a software engineer as quickly as possible.
Here is what I have come to realize:
I would recommend starting with either of these two courses:
I have worked through about half of both of these courses and you can’t go wrong with either. Each one also has a Slack/Discord community as well, which are a great way to network and see what other people are working on.
The creators of the two courses mentioned above also have courses about React that have good reviews. I haven’t tried them though.
I am also mentioning React a lot, but haven’t mentioned Angular or Vue yet. That is because React is in much higher demand right now. My suggestion would be to learn React instead of Angular or Vue. Of course this can always change.
You might have noticed the both the Java course and the MERN course that I mentioned are both offered through the University of Helsinki’s MOOC. I really enjoyed both of these courses. I have only taken these two courses from the University of Helsinki, so I can’t speak about the others, but the two that I have taken were really well thought-out.
The main thing that I liked about the University of Helsinki’s courses was that there was lots of exercises. I have yet to find another online course that is as exercise-dense as the courses that I have taken from the University of Helsinki.
The problem with a lot of programming tutorials on the internet is that there is too much video watching, but not enough actual doing. This can lead to tutorial hell.
So when choosing courses, make sure that there are plenty of exercises and then be sure to build projects with what you have learned.
I also took a course on MySQL. Good course, but not really not needed to get that first developer job. I think I had two interviews that asked about SQL queries.
I didn’t start doing problems on LeetCode until I had finished the Full Stack Open and made it about 80% through the Java course. I would do one or two LeetCode problems a day while continuing the Java course. Once I finished the Java course, doing problems on LeetCode became a full-time effort.
LeetCode problems were very tough for me when I first got started. Much more difficult than the courses that I had worked on.
The most important thing you can do is not to become discouraged. From what I have read on LeetCode’s forums, nearly everyone is bad when they first start. You just have to keep going.
Here are some resources that were helpful to me when learning data structures and algorithms:
- Cracking the Coding Interview — Great resource. Really gets you in the right mindset for interviews. You can find it here.
- Elements of Programming Interviews — Another great book. Personally, I like this one more than CTCI, but YMMV. You can find it here.
- Grokking the Coding Interview — Can’t emphasize this one enough. Haven’t seen it mentioned it too often. Explains patterns that occur in different coding challenge problems. Great at providing a big-picture of all the different algorithm problems you might encounter. Check it out here.
- Grokking Dynamic Programming — Dynamic programming is tough. This course has definitely helped me get a better understanding.
- Tushar Roy — Tushar really knows his stuff. His dynamic programming playlist is especially good. Check out his awesome YouTube channel.
- Back To Back SWE — Great YouTube Channel. Highly recommend.
- Kevin Naughton Jr. — Another awesome YouTube channel. Great at going over problems and gives helpful advice.
- Base CS — Vaidehi Joshi does a great job of laying out the fundamentals of algorithms and data structures. Check out the blog series here. She also has a podcast that I give two thumbs up.
- Pramp — Do mock interviews! The sooner the better! Pramp has been a huge help to me. Pramp does free peer mock interviews. Doing peer mock interviews has its drawbacks, but it’s free! If it’s free, then it’s for me!
- Interviewing.io — Will cost some money, but it is worth it. Get excellent practice by doing mock interviews with actual software engineers. Check out Interviewing.io.
For me when I was first starting out, Kevin Naughton Jr’s YouTube channel was the most helpful. I started from his earliest videos and went in chronological order. Being able to watch him grow his knowledge over the years gave me hope for myself.
I was advised to do 300 LeetCode problems before starting to send out applications. From my experience, I don’t think that is necessary. I would have probably been fine doing significantly less. I would probably say about 100. Of course a lot of this depends on the companies that you plan to interview with and the difficulty of the questions that they will be asking.
I wasn’t asked too many questions about system design though. I never had a interview round that was dedicated entirely to answering a question like, “How would you design X?”.
The most frequent question I got that was related to system design was, “What is the difference between a relational and non-relational database?”, so I know how to answer that one pretty well by now.
If I could go back in time, I wouldn’t have spent as much time as I did on studying system design.
In my very first technical interview I was asked to design a chess game. I hadn’t prepped for object-oriented design questions, as I thought they more typically asked in interviews for senior engineering positions. Needless to say, I didn’t do very well in that interview.
After that though I did spend a decent amount of time learning how to answer those sort of questions. Cracking the Coding Interview has a great section on it and this course is really good too.
After that interview though, I was never asked an object-oriented design question again, so no need to spend too much time prepping for these questions in my opinion.
Prepping for behavioral questions was actually a lot more important than I initially thought it would be. I’ll admit before I started interviewing, I kind of thought that interviews would mainly be coding-focused apart from the typical “tell me about yourself” types of questions. I certainly had some interviews with some tough behavioral rounds.
I found Dan Croiter’s YouTube channel quite helpful. I recommend writing out about twenty stories using the STAR method. That’s what I did and it helped me quite a bit.
I started sending out applications right at the beginning of 2021. It took me until July to formally accept an offer, so about six months, give or take. I have heard of people getting offers after their first interview and have heard others taking over a year. It is probably best to plan for the worst, but hope for the best.
There was three different sort of distinct phases throughout the period of time that I was interviewing, so that’s how I will break it up.
During this time, even though I had done a decent amount of LeetCode problems, I was still not where I wanted to be. I actually didn’t send out too many applications during this period. I instead relied on LoopCV. Pretty good service in my opinion. I would let it send out applications for me, while I continued to practice LeetCode problems. I actually got a couple decent interviews while using it throughout my job search. I recommend to use it to supplement manually sending out applications, though. You will get much less interviews with LoopCV, compared to if you apply manually.
As I was using it as my primary means of sending out applications, I didn’t have too many interviews during this time period. I was mainly working on improving my whiteboarding skills. Pramp and Interviewing.io are great resources for that. In the first mock interview I took on Interviewing.io, my interviewer had lots of great advice. He introduced me to two great resources that really allowed me to improve my technical interviewing skills.
He also showed me this LeetCode list which I thought was pretty good too.
I did have a couple of interviews during this period, but none of them panned out. However, by the end of this period I was starting to feel more confident in technical interviews, so I started spending more time sending out applications and not as much time doing LeetCode.
Towards the end of March, I started to reach out to my connections and ask for referrals. There are plenty of resources on the internet that say that the best way to get an interview is through a referral. I think this is generally good advice, but in my case it wasn’t working so well. I was getting referrals, but still getting rejected.
Another approach that I tried was to send follow-up emails to people at the companies that I applied to. Sort of how it is described in this article. However, this wasn’t working for me either. I wasn’t getting enough results to justify the amount of time it took to reach out to each person individually.
Eventually I just started manually searching job boards and sending out as many applications as I could. I actually had the best results doing this.
In order for this method to be successful, though, volume was key. I would spend most of my day sending out applications. Probably got rejected by about 95%, but I eventually started to get interviews.
When mass applying like this, it is also important to do it consistently from day to day. Once I started to get busy with interviews, I eventually ran out of time to continue submitting applications. That is why it is important to send out as many applications as you can before you start getting interviews.
I should mention that I was applying all over the country. Being open to relocation allows you to be able to cast a much wider net. Here is a good list of tech cities by the way.
Also there are also quite a few job boards out there, but the ones that I had the most success with were LinkedIn, Indeed, and this one.
Towards the end of May I was interviewing with a couple different companies and ended up receiving two offers. They didn’t work out though and largely this was because I had tried negotiating. Now I know that there are plenty of resources on the internet that do a great job of discussing the merits of negotiating. Take this one for example. I am not saying there is anything wrong with negotiating an offer, especially if you have multiple offers and have leverage. I am just saying that for perhaps your first software engineering role, maybe don’t negotiate. Instead, hold off until you are presented with more senior opportunities down the road. However, if you have three or more offers on hand than I would say that you should definitely negotiate.
Anyways, here is what happened.
I had two offers and I started to negotiate some of the details with both companies. Now Company A knew that I had an offer from Company B, so Company A made an offer to beat Company B’s offer. When I tried to negotiate with Company B they took back their offer. Now I was just left with Company A, so I accepted that offer (only verbally). Eventually Company A was able to piece together that Company B was no longer in the picture, so then they substantially reduced their offer. At that point I decided to continue looking for another opportunity.
I later spoke to a senior engineer who had been offering me mentorship. He said that he had actually seen similar situations happen several times with aspiring software engineers, such as myself. He said that he actually advises entry-level developers especially from non-traditional backgrounds not to negotiate.
After that I decided that the next good offer I got, I was going to accept. No negotiating next time.
I will admit that I was a bit bummed that the last two offers didn’t work out, but I was determined to make it happen again.
During this period I more or less did the same as last time. Lots and lots of applications. Which lead to lots and lots of interviews.
I remember speaking with a software engineer I had met on LinkedIn, while I was still working at Westport. He told me that I should expect to have lots of days with multiple interviews. That sounded ridiculous back then, but his prediction turned out to be right.
Hello State Farm
Eventually I received an offer from State Farm and I was pretty happy about that. I was able to finish up the interviews that I was having with other companies and even ended up receiving another offer. No negotiating this time though.
I made the decision to go with State Farm and I am more than confident that I made the right decision. It was a great interview process and the engineering team seemed like they would be great to work with. Definitely looking forward to moving to Atlanta and getting started soon!
Thanks for sticking with me for this whole post. I hope that one or two of the things that I shared will allow you to reach your goals as well. I know how helpful it was for me to read blog posts like this throughout my coding journey, so I hope that this post was able to help you similarly. Good luck and don’t give up!
If I can do it, then you can too.