The CAREER SWITCH GUIDE for non-technical people who are considering becoming software engineers.

Not comprehensive, research-backed, or objective in any way.

I co-founded a production company after doing full stack work (JavaScript + Python) in Silicon Valley. I now take on freelance coding projects, create computer science curriculum, and do video production / VR. This is a picture of me teaching at Code Chrysalis, a coding bootcamp in Tokyo.

I’ve been asked a lot about how I made the transition from a non-technical background into becoming a software engineer, and I’ve compiled that journey into this guide.

When I say “non-technical”, I mean it. I went to college on an acting scholarship to study theater, and I ended up spending the next almost-decade working in education. Around age 30, I decided to learn to code.

There are three steps. Yes, this is the correct order.

Step 1: Decide you want to be a software engineer.

The three reasons you won’t learn to code (and why you are wrong).

Reason #1 — You won’t become a software engineer because you think it will involve “staring at your computer all day”.

Have you ever come home to a puppy that has been left alone all day? That’s how I feel when I’m left alone for more than thirty minutes. I am close to a breakdown from a lack of human interaction.

I THOUGHT YOU WERE NEVER COMING HOME EVER EVER EVER

Naturally, my friends and family thought I was crazy when I confided in them that I was thinking about being a software engineer.

It turned out to be the most collaborative job I’ve ever done.

Here’s my top ten list, based on my experiences, of what software engineers actually spend their days doing:

  1. Collaborate with product managers and designers to figure out how to implement new features.
  2. Get into an argument about why a button is so much more than a button.
  3. Come up with technical designs and go full-Picasso with the diagrams.
  4. Write some code.
  5. Google all the things.
  6. Review other people’s code and get feedback on your own. Most arguments are about what something was named. I particularly enjoy these arguments as they bring back memories of my time as a high school English teacher, but for once, people think words matter. ❤️😭
  7. Present your work to your team and teach them what you’ve learned. THE WALLS ARE WHITEBOARDS. It’s a dream.
  8. Interview and meet new people.
  9. Learn new things. Because by the time you read this list, a new front end framework was probably created.
  10. Pull a chair up next to a coworker to investigate a bug, and strut out of the building together when it finally passes the tests.
#PairProgramming

It turns out that the primary focus of a software engineer isn’t actually coding.

The primary focus is problem solving — and problem solving is a very collaborative process. If you enjoy communication and working with other people, you might really enjoy this job.

After writing this list, I found this comment on Quora: “A lot of programmers hate their jobs because so little of their time is spent programming.” He then goes to list a lot of the same items in my list, followed by, “Does any of that sound like fun? It’s not, but it’s why people pay us”. 😶

Reason #2 — You won’t become a software engineer because you think you aren’t a “math person.”

First of all, there is no such thing as being a “math person.” There IS such a thing as having a math teacher who didn’t make you hate math. There are also such things as hard work, preparation, and self-confidence in your ability to learn anything.

Second, most entry-level software engineering roles don’t actually involve a lot of math. If you want to get into things like AI or data science or machine learning, you’ll want to level up your math game. For most other roles, however, it’s a bit more like you’re writing a novel with 20 other people and constantly writing on top of each other.

You just read a list of how a software engineer actually spends her/his time. Take a few minutes to read that list again.

Chances are, you’re probably pretty decent at most of those tasks. If you’ve worked in a non-technical field, you’ve probably been in situations where you’ve had to flex your communication, problem solving, and collaboration skills.

You can also do these things in ways that are different than someone who has only been a software engineer. This is really important.

Do not underestimate the importance of being the outsider in this field. The number one predictor of career success according to network science is being in an open network. If you’ve had other careers, you’ll be able to dot-connect things in different ways.

You just need to learn to code.

Reason #3 — You won’t become a software engineer because you think learning to code will be too difficult.

I’m going to share a secret I learned. You don’t have to be a genius to learn to code.

I know it looks that way, because I used to think the same thing. You see someone type into the computer, and you watch as colorful lines of gibberish move up and down a black screen. You assume they just hacked into some secret military database and they know all of your secrets, including that your AOL password used to be “FutureMrsDiCaprio9” (because 1–8 were taken).

It looks impressive, but it’s just another language. The difference between learning a programming language and a language like Spanish is that you’re writing code so that computers can read it as well.

And computers need very explicit instructions.

Creating a program for a computer is a bit like training a toddler. You have to be really, really specific and plan for all scenarios. Here’s an example.

If only potty training were this simple.

The three reasons you WILL become a software engineer

Reason #1 — You will become a software engineer because you are passionate about technology.

At the bootcamp I attended, maybe 20% of people fell into this category. They were super passionate about blockchain or did hackathons in their free time. They may have regretted not doing Computer Science degrees in college and often did jobs in the last few years that involved some aspect of coding.

Reason #2 — You will become a software engineer because you aren’t sure what to do as a career, but you enjoy building things, and coding seems like a good skill to have.

The vast majority of the people I’ve met who have become second-career software engineers fit into this category. There were a lot of people in their early-to-mid twenties who had some sort of career already (maybe in San Francisco, maybe not) and it wasn’t everything they had dreamed of. They knew there were opportunities in technology, and they wanted skills that felt more concrete than managing client relationships or creating colorful diagrams in presentations.

Reason #3 — You will become a software engineer because you want the lifestyle that comes with being a software engineer.

Lifestyle can mean a lot of things — for some, it might mean being part of the startup scene and playing ping pong on a rooftop bar. For others, it might mean flexible hours and working location, so they can pursue their other passions, like being in a rock band or being able to volunteer at their kids’ schools. For others, it might be about having a high income, great benefits, work-life balance, and low job stress.


I think there’s a fourth reason to learn to code, because I didn’t fit into any of the reasons above. I was not passionate about technology. I liked my job.

Reason #4 — You will become a software engineer because you want to be a better communicator.

For me, learning to code was a matter of literacy and communication.

We’ve reached an acceleration of technology that is unlike anything that has happened before. No matter what field you are working in, it has probably been impacted by automation in some way. Our interactions are increasingly being operated and run by code.

If my world is being run by machines, I want to know how to communicate with them.

Yikes.

And you know what? Learning to code didn’t just make me better at communicating with technology. It also made me better at structuring my thoughts, giving and receiving feedback, and having confidence in my self.

Step 2: Convince someone to hire you.

Okay, so you’ve decided this might be something you want to pursue, and now you need to figure out how to convince someone into hiring you so you can learn to code.

Note the order of operations here.

If you want to become a software engineer, your primary focus shouldn’t be learning to code. Yes, you will need to learn to code (somewhat) to get hired. However, your real goal — your only goal — is to convince someone as quickly as possible that you are worth hiring, and that your potential is worth their time and investment to train.

The truth is this — no matter how much you think you can learn to code on your own, you will learn infinitely more when you are at a company doing actual work. You will also learn at a more accelerated pace, because you will be receiving real feedback from real people who have made real mistakes and learned real lessons. The sooner you can get into a job, the sooner you will actually start learning what you need to know.

“But if I don’t know how to do the job, I won’t be qualified!”, you might say.

That’s irrelevant.

It’s not your responsibility to decide if you’re qualified for a role — you’re qualified if the interviewers think you are qualified.

Don’t forget — men apply for jobs when they are 60% qualified, and women wait until they are 100% qualified.

I’m only going to say this once, and I never want to say it again. In this very specific situation, be the mediocre white dude.


So let’s talk about how you’re going to convince someone to hire you.

Goal #1 — Learn the things.

There’s a technical bar. There’s no way around it– you need to know enough to pass the interview.

What do you need to learn?

  1. Find a friend or connection who is a software engineer, and ask them what would convince them to hire you as a software engineer. If you don’t know any software engineers, go to a meetup.
  2. Peruse through job postings on Angel.co. Read the skills they want, and the technology stack they are working in.

Spoiler alert: if you did all this, and it’s still 2018, you’ll realize that you will need to know computer science fundamentals and have a portfolio that proves you can build things. Your best bet is probably learning full stack JavaScript, knowing how frameworks like React/Angular/Vue work, applying for a front end developer role, and hustling your way into the specific job you want later.

How will you learn these things?

There are generally two approaches people take to achieve new learning: they structure it themselves, or they find someone else to structure the process for them. Universities and bootcamps are an example of finding someone else to structure learning for you.

The University or Bootcamp Approach

If you can afford this, do this. School is a luxury and will give you a network that you can continue to use long after your job search is over.

If you’re financially independent and have to worry about things like supporting family members, medical bills, rent, food (etc), a bootcamp might be the right approach. However, do your research and pick the best one you can, because the credential doesn’t mean anything. In some places, being a bootcamp grad may actually make the job search more difficult. I’ve found that it’s better not to advertise that you went through a bootcamp, and say that you “read books, built projects, did an intensive course (*the bootcamp), etc.”

Universities will give you the advantage of a credential on your resume, and a larger base of theoretical knowledge. However, you might get less experience with the modern day frameworks and processes you’ll use in a job, and it will be more expensive. It’s not just the tuition that will be expensive — consider the income loss and opportunity cost of having 3.5 years less on-the-job experience than a bootcamp grad.

The Good Will Hunting Approach

People learn new things all the time without the support of a traditional school. If you have a hobby, you know what I’m talking about. You see something on Pinterest you want to make, you Google how to make it, and then you Instagram the result. If it didn’t turn out, you probably Snapchat it instead.

You can certainly become a software engineer without doing a bootcamp or going back to University. It may take longer, it may be a bit messier, and you may have more difficulty building a network — which may make it more difficult to get an interview. However, it will also be a lot cheaper, and you’ll look super smaht.


All of the approaches above are valid.

I chose the bootcamp approach. The self-taught approach would have taken me too long (my previous job was about 80% travel and I didn’t have time to learn on the side) and I was at the age where going back to university felt financially unrealistic (I wasn’t about to wait until my mid-30’s to get a job again).

So, I got accepted to a bootcamp, quit my job, went on COBRA for my health insurance, sold my car, took out a massive loan, and started using my credit card to pay for groceries. The most stressful part of the entire transition was taking that financial risk.

My Learning Journey

These are the resources I found useful to my learning. However, this list is very specific to my journey preparing for and going through a bootcamp (I went through Hack Reactor in San Francisco). If you’re doing the self-study or University approach, you will likely need different resources.

1. Codeacademy

I did the HTML, CSS, JavaScript, and jQuery courses, in that order. This took four days total. I just locked myself in my apartment for two weekends and drank a lot of coffee and ate a lot of frozen dinners. This doesn’t cost anything, and requires zero knowledge of coding before starting.

2. Codeschool

After that, I went through the JavaScript curriculum on Codeschool (this was much harder than Codecademy). This probably took a few weeks, an hour or two every night. This costs $30 for a month, and you probably only need to pay for one month. This helped sink in some of the concepts I learned in #1.

3. Interview prep for bootcamp

The bootcamp I chose, Hack Reactor, required a technical interview to be accepted. It took me two tries. To prepare for this, I read the first five chapters of Eloquent JavaScript, and made sure I understood the concepts of higher-order functions, recursion, and how to write basic functions — specifically: forEach, map, filter, and reduce.

4. Bootcamp phase one

We did two-day sprints where we focused on things like common data structures, using Github, MVC frameworks like Angular and React, Node, REST principles, etc. I used the tutorials on Egghead to supplement my understanding of the frameworks.

5. Bootcamp phase two

We built a few projects. The biggest project I focused on was an IOT app that allowed homeowners to charge guests for using appliances in their home (successful payment triggered the appliance to turn on for a set amount of time). The stack was React, Redux, NodeJS, PostgreSQL, Redis, and EC2. I went overboard on the planning / diagramming stage, and that really helped me with feeling prepared for interview questions that focused on architecture. You can read about this project and see all my diagrams here.

6. Interview prep

I gave myself a pretty strict schedule during this phase. I would wake up at 8am, fire off my resume to at least 5 companies, do a few hours of algorithm questions on CodeWars, study technical jargon, and/or try to meet at least one person for a mock interview or to ask them for advice.

Goal #2 — Get an interview.

Once I had a basic understanding of computer science fundamentals and how to build full stack apps, I started applying to jobs.

Here are three approaches I tried:

1. The Always Swipe Right Approach

You can play the number game and cold apply to as many companies as you can. The more applications you put out there, the more likely someone will contact you. The longer you wait, the more likely you are to get a call back. This is a totally valid strategy. I did not do well with this strategy.

2. The Beauty Pageant Approach

Another approach is to put yourself out there and hope someone contacts you first. Some platforms, like angel.co, are totally open. Others, like Hired, require an application. Triplebyte requires a technical interview. I’d recommend going for all three. Even if you don’t get through TripleByte (I didn’t get through the last step), it is incredibly useful interview prep.

3. The Bulk Order of Wine from Costco Approach

You are 40% more likely to get hired through a referral.

“But what if I don’t know anyone?”

You can go to meetups, but you’ll have to be careful about how you approach conversations. If you appear to be networking too aggressively, you might come off as insincere. You’ll also be fighting for attention amongst a swarm of other newbies who are trying to get their foot in the door.

A better strategy is to work your close and soft connections for all they are worth.

Beg your close connections to give you mock interviews and very direct feedback on what you need to improve. Then, give them a list of companies you are interested in and ask if they have anyone in their network they can connect you with. I absolved my Midwest guilt over asking this big favor by gifting a bottle of wine.

Hence, the bulk order of wine from Costco approach.

It’s not just coffee. I’m using you for all your third-degree connections on LinkedIn.

For soft connections, ask for some advice and offer to buy them a coffee if they have time. If they agree to a coffee, ask them to pick a place that is convenient for them. Get there early, but wait until they show up to buy a coffee — so you can pay for both at the same time. Then, be friendly and genuinely interested in what they have to say. Yes, this person might be a means to an end- but they are potentially a new colleague, a new mentor, or even a new best friend… so try and be sincere.

If you’re not sure what to talk about, ask for advice on the job search, how to decide between offers, why they like their company, etc. By the end of the conversation, they will usually offer to refer you or give you the name of someone else in their network you could talk to.

Goal #3– Get the offer.

You probably won’t be the only candidate who passes the technical bar. So how do you convince them to pick you over someone else?

Soft skills.

This is why the bulk Costco wine order is so important. You need to practice as many mock interviews as you can. Here are some tips for what to focus on.

1. Verbalize your thoughts while solving a problem.

Remember, life as a software engineer means you are literally writing on top of other people’s code. If you can’t talk about that, it’s gonna get awkward.

2. Appear knowledgeable and humble at the same time.

You want to come across as competent, but not as a liar. If you don’t know something, own it– and be genuinely interested in learning what your interviewer is sharing. Even if you don’t pass this interview, you’ll gain new knowledge for the next one.

3. Relax.

The total amount of time you will spend in interviews before getting an offer is 4–8 hours. That’s it. After that, your future coworkers will have signed on to spending more time with you than their spouses, children, and closest friends. If you are spending those 4–8 hours in an agitated and nervous state, you aren’t showing the team who you really are. Try to relax! Be your normal and friendly self, to the best of your abilities.

Even if you follow those three steps, the job might get offered to a different candidate. Maybe there’s a “culture fit” that you didn’t pass (p.s. read why hiring for culture fit can actually be a shield for unconscious bias). Maybe someone else was a friend of a friend. Maybe someone else has more experience.

Sometimes, it’s not you.

Stay positive and remember that getting that first job will always be the hardest. You just need to convince one company to take a chance on you.

Step 3: Learn to Code.

When you finally get that offer, you can start learning to code– for real this time!

Ask a lot of questions, take on projects you aren’t ready for, and fix things you aren’t responsible for.