How I switched careers to become a software engineer in 11 months (and how you can too) (2023)

by Amanda Bullington

Before I decided to move into software engineering, I was a marketer in the tech world. I tried quite a few types of marketing - events, public relations, search engine optimization, content creation, digital advertising, email marketing - but never found a perfect fit.

My last company was a personal finance startup with solid brand recognition. Their motto was content is king. Unlike most tech companies, there were a ton of editors and journalists and only a handful of software engineers.

A year after I started, the company decided to shake up its strategy. Content was no longer enough. A plethora of new personal finance startups launched mobile apps that year, promising to help consumers track their finances, learn to budget, eliminate student loan debt, and consolidate credit card payments. Not wanting to be left behind, my company began thinning the editorial side of the business while rapidly hiring product folks, engineers, and designers.

An inner feeling made me realize then that it was time to switch gears. ⚙️

In this article, I’ll go through how I switched careers to become a software engineer from start to finish. So let’s get started.

Step 1: Research immersive programs

I began to research immersive classes in software engineering. I liked that App Academy and Hack Reactor both offered free in-person intro classes to help prospective students prepare for their entrance exams. I also heard positive things about Hackbright and have since met a number of talented women who attended their program.

Ultimately, Hack Reactor won me over because it offered a rigorous one-month Structured Study Program (SSP) course. The program was designed to transform participants from beginners to Hack Reactor Immersive ready.

The curriculum seemed practical. It helped that I knew three acquaintances who had successfully landed software engineering roles after completing the program.

Step 2: Coding immersion

Once I narrowed my focus to Hack Reactor, I needed to prepare for SSP and the entrance exam. To do so, I completed the Udacity Intro to JavaScript course along with a few other online courses in JavaScript.

Between SSP and Hack Reactor’s immersive program, I spent four months coding up to 6 days a week, 12+ hours a day. I sharpened my problem solving skills, improved my understanding of JavaScript, learned front-end and back-end frameworks, and practiced working alongside other engineers.

Step 3: Study for the job search with online courses

As intense as my experience was at Hack Reactor, it was only the beginning. I had a growing list of concepts that I struggled with during the program. At the top of that list was algorithms and data structures.

Software immersive programs are great for teaching you the skills you’ll need on the job as an engineer. Training for job interviews is a bit of a different beast, and mastery of algorithms and data structures is often the key to being offered an on-site. I tried applying to companies that forgo traditional white-boarding, but they’re few and far between.

Cracking the Coding Interview is seen as the penultimate resource for learning algorithms. However, it wasn’t the resource I found most useful, personally. Instead, these are the resources I used to prepare for technical interviews and onsites:

• CodePath - an 8-week course covering all the most frequently asked interview questions from data structures to system design
• InterviewCake - a guide that explains the most common patterns found in algorithmic thinking
• LeetCode - endless practice problems
• Grokking the System Design Interview - explanations of the tradeoffs involved in common system design questions, such as how to design Instagram

Step 4: Take advice from experienced engineers

I asked a ton of senior engineers within my network for advice on the job search. Everyone was gracious with their time and excited to see new types of talent entering the industry. Here were some of the most helpful pieces of advice:

• Get a foot in the door: Every engineer has to start somewhere. Many engineers landed at brand name companies after working at tiny no-names. Don’t worry if you don’t find a perfect fit right away.
• Rewrite your Résumé: If you’re a new engineer, your résumé is likely written in a way that makes you look really junior. Focus on the tradeoffs and technical decisions you made, not what you implemented.
• Look for mentorship opportunities: Aim for a team with 30+ engineers, because this will teach you best coding practices and provide mentorship opportunities. Otherwise, know who your manager will be and make sure they’re able to help you make technical decisions (young engineering managers are often thrown into the role with limited people or leadership experience).
• Work on personal projects: This will demonstrate your enthusiasm for engineering during the job search and give you something unique to talk about in interviews.

Step 5: Ignore unhelpful advice from recruiters and others

My job search took place in summer 2018. I learned to tune out a lot of well-intentioned but unhelpful suggestions. These came from recruiters, fellow engineers, and concerned friends. Here are some of them:

• The job market has slowed down for entry-level engineers over the past few years. Mid-sized companies are only hiring for senior positions and have put a hiring freeze on junior candidates.
• Not only is the market oversaturated, but the quality of bootcamp graduates has gone down in past years. It will be tough to find a job.
• You’re a strong candidate but our company doesn’t have the resources to mentor you. Please stay in touch we’d love to interview you again when you have more experience.
• Good luck getting hired during the summer.You’re competing with all computer science students who have summer internships. Try again in the fall when more positions open up.
• Good luck getting hired during the fall. Hiring will slow down as companies approach Q4. If you don’t find a job this summer, you’re going to have to wait until next year.
• Try becoming a product manager or finding an internship. Maybe you can pivot into software engineering when you’re ready.

I’m certain many aspiring engineers hear similar types of feedback. The key is learning to tune it out and stay focused, otherwise it’s easy to burn out.

Step 6: Create a study plan

After Hack Reactor, I spent a lot of time reviewing technical concepts in preparation for tech screens and interviews. Here’s my rough study plan:

• Study algorithms & data structures.
• Study system design.
• Do a hackathon (it won’t teach you engineering best practices, but it’s a fun group experience).
• Build a personal portfolio (or another project you can talk about).
• Write down every interview question from every phone screen & onsite. Review the answers you don’t know.
• Practice with others. Algorithms are more fun when you’re working on them in a small group. (Pramp and CodePath were two ways I found practice partners).

Step 7: Build an online presence

Make it easy for recruiters to find you. Build robust profiles with screenshots of projects and links to GitHub on the following sites. Feel free to click the links to check out my examples (or connect with me):

• LinkedIn
• Hired
• AngelList
• Personal portfolio
• GitHub

It’s important to show prospective employers the quality of your work. Photos, videos, links to live projects, well documented READMEs, and clean coding practices make it easier for recruiters to take a chance on you.

Step 8: Remember, it’s a numbers game

I heard the refrain, “It’s just a numbers game,” frequently from engineers, career coaches, and mentors. Ultimately, here were my numbers:

My applications were mostly front-door, with some referrals, some recruiters who contacted me, and some outreach from Hired or AngelList.

Knowing the numbers helps you take an analytical approach. For example:

• 26% of my total applications (cold, warm, referrals) converted to initial phone screens.
• 51% of my phone screens converted to a tech screen or assignment
• 28% of my tech screens and assignments converted to an onsite

From this, I learned that I was fairly consistent at getting my résumé to pique a recruiter’s interest, successful (with room for improvement) at initial phone conversations, and somewhat weak in demonstrating my technical skills.

Analyzing the numbers allowed me to step back from churning out more applications. Instead, I spent extra time brushing up on technical weaknesses, with a goal of improving my conversion rate from tech screen to onsite.

Step 9: Master the onsite

Once you’re lucky enough to land an onsite or two, there’s still a lot to master. Personally, I found most onsites extremely draining. They lasted anywhere from 2 - 6 hours and ranged widely in topics covered. Some companies forgot to give me any breaks.

Because I was being tested on technical knowledge, there was very little small-talk and I was often grilled with questions for hours at a time.

One company told me they weren’t moving forward with me because I had struggled on the very last question after hours of successful algorithms. I’m still not sure what they learned from that very last question that they couldn’t have gleaned from the tech screen or the previous few hours, but that feedback stung.

Topics covered during my onsites included:

• Algorithms
• System design
• Build an app using the company’s API
• Depth of knowledge questions about my coding language (JavaScript)
• Depth of knowledge questions about HTML/CSS
• Depth of knowledge questions about front-end frameworks
• Depth of knowledge questions about various databases (SQL/noSQL)
• Brainteasers (think SAT prep from high school)
• Clone and explain X GitHub project that you created, what tradeoffs you made, and what you would do differently in the future
• Give us a 1-hour presentation on any topic of your choice (consider this a red flag, unless your job specifically requires interfacing with customers or pitching your ideas)

The variety made it tricky to know what to study.

After each tech screen and onsite, I jotted down a robust list of all the questions I was asked in each interview. This became my study guide for future onsites.

When I missed questions, I tried to view it as a learning opportunity.

Step 10: Bring snacks

Maybe it’s just me, but answering technical questions amidst a revolving circle of new people makes me famished.

In my first onsites, I got progressively worse at answering questions as my blood sugar dropped. No surprise - these didn’t result in an offer.

In my third, they scheduled me from 10 - 2pm with no lunch break, so I specifically asked for one. This worked - sort of - until the hiring manager followed me to a lunch spot while grilling me rapid-fire on 50+ JavaScript questions. He ignored my (repeated) requests for a quick mental break. Another no-go.

Finally, I found a viable solution - bringing a large green smoothie to each interview. This was a lot better than trying to sneak peanut M&Ms into my mouth in the restroom (besides, I was usually escorted to-and-from the bathroom so that wasn’t really an option).

Step 11: Refine answers to behavioral questions and avoid burn out

Where do you see yourself in 5 years?

One of the questions that stumped me in interviews was, “Where do you see yourself in 5 years?” To be honest, I still don’t know.

There’s a manager track and an individual contributor track.

There are plenty of engineering career paths that I still don’t fully understand - web, mobile, site reliability, and DevOps, to name a few.

Then there’s back-end, front-end, and full-stack. Sometimes the lines between these roles are clear, sometimes they’re blurred. What I learned during the course of my search is that while I don’t know which path I’ll take, there are certain tasks I like more and less than others.

I don’t love playing with pixels on a website, but it’s fun to design for mobile. Designing architecture and setting up a database is a bit tedious, but I enjoy taking large amounts of data and manipulating it or spinning it into an interesting visualization.

So who knows where I’ll end up. For now, I’m going to try to do what’s fun and exciting.

Some general thoughts

Coding challenges are a learning opportunity

There were plenty of coding challenges that I attempted and was ultimately too embarrassed to turn in. Then, there were some that I didn’t finish but turned in anyway, along with an explanation of what debugging steps I had taken along the way.

At first I saw incomplete coding challenges as a sign of my own inability - some days I wondered if I wasn’t cut out to be an engineer. But they became fun when I shifted my mindset and started to think about what I learned from each one.

For example, one of them gave me a deeper understanding of asynchronous API calls, while another helped me realize the importance of addressing edge cases and error messages. One taught me how to debug Ruby on Rails.

Take rejections in stride

The same was true of each tech screen and onsite. At first, the rejections stung and fueled my insecurities. Then, rejections became normal. I learned a lot more when I was able to brush aside my self-doubt and be curious about what I could learn from each engineer taking time to speak with me.

Everyone has a different way of approaching problems, and I was fortunate to learn from a few dozen engineers in the industry through the interview process.

Find a mentor

I was lucky enough to have an all-star mentor throughout the interview process. For three months, my mentor called and emailed every week to ask how the job search was progressing and what blockers I was facing.

I’ve heard a lot of fellow engineers say a mentor sounds nice, but they weren’t sure what questions to ask. Sometimes we spoke about tactics, such as how many applications to send, how to write an effective Git commit, or how to go above and beyond in a coding challenge. Other times, she simply reminded me that despite the (many) rejections, I was becoming a stronger engineer and therefore closer to finding my dream company every day.

A mentor can keep you accountable to your goals, help you through feelings of burn out, and connect you to the right resources for deeper learning. I’m grateful to have had an advocate throughout the job search process, and I’m looking forward to being able to pay it forward as a new engineer!

Conclusion

Some days, switching careers felt much harder than I expected. My mentor can certainly attest that there plenty of days when I wasn’t sure I could do it.

Becoming an engineer took a lot of hustling. It meant reaching out and expanding my professional network, becoming comfortable with the fact that there’s a huge learning curve ahead of me, and ignoring all the naysayers. It meant finding the right online resources that worked with my learning style. It meant quieting the part of my brain that told me I wasn’t capable and instead focusing on gleaning new knowledge. Every day I worked on a new project, studied a new algorithm, or answered questions in an interview, I became a better engineer.

Was the struggle worth it? Absolutely.

I’m thrilled to say that I found a role that’s perfect for me, where I can continue learning and growing. My professional network is stronger than ever, and most of all, I gained confidence in knowing that I can put in the work to make my dreams a reality.