The Ultimate Guide to Learning to Code and Getting Paid

How to find your first software engineering job in 2019

Nick Fredman
May 16, 2019 · 71 min read
Photo by NESA by Makers on Unsplash

Introduction

Several years ago I was working for a startup as Director of Sales Engineering. One day I stepped into work and a thumb drive holding our product demo was placed into my hand. From that moment I owned the demo and the code. My first task would be to tweak it for an upcoming sales call.

My palms began to sweat. My heart started to race. I have no clue how to do this, I thought.

Panic.

I took a few deep breaths and sat down to Google. I knew a little HTML and CSS, but not much. I did not know JavaScript or this jQuery thing the project was built with. I didn’t know where to begin. I could talk about technology, sure, I knew of coding and had worked around developers for my entire career.

However, I did not have the practical skills to do the work. I was a project manager. I was a sales guy. I was not a developer.

That day I sat down to begin learning JavaScript and it completely changed my life. This is the guide I wish I’d had that day.

About Me

I have worked in tech since 2005. My start was in the video game world as a Producer, where I quickly learned the agile process. I spent most of my free time hanging out with game developers.

Fast forward 5 years and the game company where I worked had been acquired, I had an MBA, and had started my own Mobile App consulting firm. I had been part of hiring and managing our remote teams in the game world and I applied the same principles to my own company.

Over the next 8 years I managed teams and hired engineers. I dabbled in coding, starting to take it more seriously in 2013. With the help of friends I learned a few languages and began to code.

About a year ago I stumbled into a position teaching junior software engineers for a full-time job. I work for a wonderful immersive program in Austin at Galvanize. However, not everyone can afford either the financial or time commitment necessary for an immersive program (we’re 9AM-8PM, 6 days a week!)

I want all of you to have a guide for your entire journey. Even if you plan to take an in-person program, or have a mentor, you can use this as a signpost to make sure you are learning all the necessary skills.

Everyone can learn to code. Yes, everyone.

Let me know if you have any questions! And if you find other amazing resources please share them with me. This is a living document and I’m always open to feedback.

How to Use This Guide

My recommendation is that you skim this once and then evaluate where you are on your journey. If you’re just starting out, fantastic — begin at the top. If you’re already on the path, find the sections that seem the most relevant to where you currently are. Work through these and reach out for feedback from others.

My goal in this project is to make a reference guide. Maybe it takes you 3 months to finish, maybe 3 years. That’s fine. Software isn’t going anywhere.

Either myself or my students have tested every single link. Below are the resources I’ve found the most helpful for teaching specific topics. I’m happy to be an affiliate for courses, but only ones I have taken and believe in. There are a couple of affiliate links below.

There’s a risk of information overload out there which can lead to paralysis. I want you focused — not spending time reading or watching videos instead of doing. I want to provide the resources that can get you back on track when you get stuck or are deep in the struggle zone!

Overview of the 4 Sections of This Post

Section 1: What does a software engineer do? What is a software engineer? How much does a software engineer make? These are common questions I hear every single day.

This section will answer some of the high-level questions if you are on the fence about whether to pursue this career.

A software engineer hard at work

Section 2: Mindset and how to practice — The goal of this section is to give you a different way to look at your learning process. The most common roadblock I see for new developers is the way that they learn.

This often has to do with negative self-talk, trained habits from school, and a lack of awareness of how humans learn new skills.

I will cover resources and tips that help people learn faster and have a blast doing it! There are always dips and rough days in learning and job seeking — we’ll get you through them.

Section 3: Learning to code — You have to learn to make websites and apps, period. The only way to learn this is by doing it.

I encourage you to start with JavaScript since most roles require you to know at least basic JS. It’s also the only language that you can use to write an entire application with. Python is a decent alternative, depending on the career trajectory you’d like to take.

Section 4: The job hunting process — I’m going to cover it all. From making your resume, to the developer skills you’ll need, technical interviews, and whiteboarding.

One of the hardest things about becoming an entry-level software engineer is the actual process of finding the job. It can be 3–6 months before you feel ready from a code perspective. Keeping up the momentum here is critical.

I’m creating a community to help with exactly this problem. Check it out here.


What Does a Software Engineer Do?

The daily work of a software engineer is often not what people imagine. Gone are the days of a lone developer sitting in a dimly-lit room, coding for hours, surrounded by cans of Red Bull and cigarettes. The majority of people work on teams now.

You should expect your first job to be on a team (taking on contract work to practice is fantastic, but I encourage everyone to find a team for their first job). The reason is simple: you learn more from peers and mentors. Your first job is a baby-step on this journey.

Your time will have a mix of different activities. There will be meetings — these are a reality of the corporate world. At these you’ll probably discuss what you’re working on, plan for future work, explain past work, and show off or test the product with users.

Additionally, you will spend time coding. You need to defend this time — it is sacred. Block the time out, get some good noise canceling headphones, and create a strong habit.

You will be called on to solve problems. Sometimes these will be a bug in the code. Sometimes they will be a new feature or a whole new tool. Often, you will need to learn something brand new to solve this problem.

One of the main things I’ve seen people struggle with is the sense of never knowing it all. In many careers, after a certain point you know most of the things there are to learn.

Writers don’t spend hours googling how to write later in their careers. Carpenters don’t spend hours watching YouTube videos on a job site. There are a few other careers like this, but I have never seen one that humbles the greatest minds with such ease.

A lot of the time, being smart is irrelevant. You need to be constantly learning new technology. Having a repeatable process in place assures you’ll be comfortable over time. In fact, you should expect to be learning something new on a regular basis — even if you keep working with the exact same technology. This requires a total mental shift, which I will cover in the next section.

The other questions people tend to have are:

These are tough questions to answer, but I’ll give some rough guidelines. The most important point is that it depends on the market you’re looking in. Here’s a rough idea of what you can expect as a starting salary, or a starting hourly rate if you go that way.

  1. Major Markets (SF, NYC, LA): As a junior, you’re looking at around $100k per year, depending on the company. This could be as low as $90k or as high as $120k. Hourly, you’re looking at $50-$75 an hour in these markets. As you advance, your salary as a mid-level is around 1.5x and as a senior engineer/team lead/architect can be up at 2x that starting rate. Top tech firms pay even more including options and bonuses.
  2. Mid-tier Markets (Top 20 US cities, Austin, Portland, Denver, Chicago, Dallas, etc.): As a junior you’re looking at $70–80k per year, and hourly from $30-$60 an hour. Unless you are looking for an internship or find a job at your dream company, I wouldn’t accept less than $65k for your first job. Your skill set is too valuable.
  3. Other Markets: If you live in a smaller city or want to work remote then it will completely depend on the company. In a small town, I wouldn’t accept less than $50k a year (you can always find remote work for at least this much). Hourly, I wouldn’t go less than $30 still, but would still look for $40-$50 an hour. There are fixed costs to being hourly, such as health insurance, so I wouldn’t accept too low an offer.

Lastly, what about working in Europe or somewhere even more remote like Thailand? That completely depends on the company and the market.

I would strongly encourage you to find a company with strong tech leadership and senior developers who enjoy mentoring. This will make your first job a great opportunity to keep growing. I also recommend talking to friends and looking on GlassDoor to find out what similar companies tend to pay.

This is a wonderfully arbitrary question. In a nutshell, making senior software engineer means you have made a lot more mistakes. An order of magnitude more. You’ve tried a lot of things that won’t work, and are faster and more capable of solving harder problems.

Companies often try to apply years to this metric, but it’s difficult. I’ve seen developers with two years of experience who are much stronger than ones with seven or eight years. It comes down to how often the individual steps outside their comfort zone, is willing to accept feedback and apply it.

If you can do the work the company needs and have 2/3 of the required skills and experience, then go for a senior role. It’s always worth trying — if you don’t pass the interview that’s OK. It’s great practice!

I’m so glad you asked! There’s no one right way. The wrong way is firing off a lot of resumes, without using LinkedIn or following up with individual companies.

The best way to find a job, even as an engineer, is by talking to people in person. It works this way for every single industry. If you can’t do it in person, phone calls are a great second option. You can often skip the first step of the interview process this way.


Developing a Growth Mindset to Learn Software Engineering

Growth Mindset Overview

Let’s dig into the meat of this piece (or the potatoes, for you veggies out there!) The question is, why should you develop a growth mindset? And what does it have to do with becoming a software engineer?

I’m so glad you asked! It has everything to do with it. I don’t know if I have ever spent more than 2 hours programming in a given day without needing to Google something. I have to do it constantly. I am often stuck, or forget something, or I have a typo somewhere and miss it because I didn’t get enough sleep the night before.

I choose to not get down on myself for not knowing things. That’s because I have cultivated a growth mindset.

A growth mindset is the belief that you are not a fixed person. Your skills, abilities, and passions can develop over time. Many, and I mean MANY of us have a fixed belief when it comes to either technology or math. People often say, “I’m just not good at math, never have been.”

This is baloney. What this actually means is that you don’t like to struggle on math problems you don’t understand. Or using technology makes you feel stupid. Especially, when you don’t understand it easily. Guess what? Most of us don’t. This is learned behavior and not innate.

As a kid I enjoyed messing with the VCR to program things. The reward of a taped episode of the Simpsons during basketball practice made it worthwhile to me. I also failed to record things. I would come home and find a blank tape, or a tape that was still recording and had written over the show. Whoops!

Did I find this frustrating? Sure I did. But did I give up? Did I break the VCR in a fit of rage, chucking it out the window into our snowy back yard? No. Maybe I wanted to once or twice but in general, I didn’t care. I never mad at myself for this, I was upset at the choices by the machine’s designers.

I had fun trying to program it. I enjoyed seeing if it could work overnight, or what would happen with Daylight Savings Time. I cultivated a sense of play when it came to remote controls. This lead to me doing something similar with computers as I grew older.

What would have happened if my dad had yelled at me for failing to record a show? Or if he’d grounded me? Or punished me? I would not have enjoyed the process, rather I would have cared too much about getting it right and stopped finding joy in messing around.

This happens to lots of us in many different areas of life. We develop fear in an area and are no longer willing to play and fail. When it comes to coding, discarding this attitude is a must.

You have to enjoy failing and being wrong. Why? Because you have a different mental model than the random people who made your computer, wrote the languages and libraries you’re using. Do you know who designed the internet as a whole? What their motivations were? The constraints at that point in time? I certainly don’t.

Does that mean you’re wrong or bad? No! As a consequence, they had a different model of how things should work than you do. There’s a logical reason, based on your experience in the world, for you to believe your code will work. It just happens to be different than the people who originally created the technology.

This is okay. We all have this. Your goal is to attempt to understand why they made the decisions they did. It will build empathy instead of self-loathing. It will encourage you to have fun and play with code. And you’ll find that you can learn a lot faster this way.

This is the core idea behind developing a growth mindset. The correct answer is never important. The process you use to learn about and adapt to a misperception is the focus. In a nutshell, effort trumps talent!

Struggle Mode

One of the core models we teach students is known as the optimal area of struggle. You have a certain amount of knowledge in a given field. Imagine this is a circle. To increase your knowledge, you need to grow this circle by 10% to 25%.

When you make something in this larger circle you’ll be able to bridge the gap between your current understanding and your desired outcome. This is a fun struggle! The goal is to spend as much time as possible in this struggle zone. We’ll refer to it as the Green Zone going forward.

On the other hand, let’s say you attempt to make something that’s dramatically outside your current knowledge or comfort zone. What if I gave you 3 days to write a better algorithm than Google’s search. Yikes! You’d panic. Sweaty palms and anxiety ensue.

This is the Red Zone. You wouldn’t know where to begin. You’d likely find complete dead ends on your first few attempts and have no clue what to do next. The Red Zone is what we want to avoid when learning.

Time spent in the Red Zone without help can lead to burn out. It’s a big part of why people struggle to learn software engineering. There are a lot of topics and it’s difficult to find a roadmap — what happens when you’re completely stuck?


I want you to spend as much time in the Green Zone as you can. The important thing to remember is that it should be a struggle.

That means not only solving problems you are confident in your ability to solve. It means that with each project you should learn one or two new things. It means you should have to spend time Googling and asking for help on each project. This is more than okay, it’s good!

I’ll remind you about this again later but seek the Green Zone. Learn to be aware when you’re in the Red Zone. This doesn’t mean giving up when something is a challengge — instead, identify appropriate challenges for your current skill level.

How to Practice Software Engineering

This is the section where I suggest how you actually study. The common path is to either read a whole book or watch an entire tutorial, then try it yourself. Almost as common path is to follow along with the book or tutorial — writing the code you are told to write without fully understanding it.

Both of these are poor uses of your time. You only have so many hours! Use them wisely. Instead of using either of those two strategies, here’s a new one to try out:

Attempt to build something or complete a task, for at least 15–30 minutes. More if you end up on a roll. Feel free to look at the technical documentation, or use a reference or cheat sheet you find on Google. Both are fine. The goal is for you to start the task you want to learn until you get stuck.

Once you get stuck (having spent 20–30 minutes without progress) it’s time to get help. Find the section of the book or the part of the tutorial that explains what you’re stuck on.

You usually get stuck when your mental model of the technology is different than the people who created the tech. This is ok, your goal in reading or watching is to make a new mental model.

Remember — your goal is not to just type the things that someone else wants you to type. It is to understand why they want you to type those things. When you understand the why, you’ll be unstuck!

Sometimes you won’t find the answer in the book or videos. This is OK. Do not panic. There are two reasons that this can happen and they both have solutions:

  1. The resource is outdated and the technology has changed. This happens a lot. Check the dates and check the versions to see if they are similar — if not, look for a newer resource.
  2. The technology you are attempting to learn is built on multiple concepts that you don’t understand yet.

Imagine I ask you to make a complex pasta dish with noodles, shrimp, crab, veggies, and a white wine sauce. You don’t know how to make any of these on their own. Pulling each piece together will be hard and you’ll likely fail along the way. Even if you succeed, you won’t understand why you did certain actions. I would recommend you learn how to make shrimp first, or properly sauté vegetables, then advance to the whole dish.

Software development works the same way. If you are tackling something that’s too far outside where you are now there are two options: scale back to something easier, or get serious help from a mentor or friend who is further along. This is OK! I still ask for help all the time and I encourage you to as well. The person you go to for help might even have an idea of a better project for you.

Find a Mentor and Community

My last chunk of advice in this section is two-fold.

First, find someone you can go to when you get stuck. Often this is someone you know well who is already working in the industry, such as a friend or relative. They don’t have to be your daily resource for help, rather someone to talk to when you’re feeling low or need guidance on what to do next.

A large part of my goal in creating this guide is to provide a resource to help students get a sense of all the things to do (and what order to do them in).

Second, you should find at least one other person to learn with. This is important for a huge number of reasons. Coding all day on your own, or job hunting without anyone to talk to is hard. Humans are social creatures.

Additionally, it can be rewarding to learn from and teach to a peer. The best way to check that you understand something is to teach it to another person — this is hard.

It will also give you practice in technical communication, one of the critical job seeking skills. In a nutshell, this is your ability to talk about code and technology using correct language. This is a large factor in how others will determine your competency.

You should practice this skill every chance you get. Whenever you attempt to explain a technical concept and use words like “it”, “thing”, or “thingy”, this is a warning flag. Take a minute to learn the correct terms. When you speak with more experienced developers you will seem more competent.

Coding with others can be a blast too! My favorite times are still working on a project with friends.

Common Pitfalls (and how to avoid them)

  • Coding alone too much. For the reasons I have given above, it is important to find others to code with. I suggest using meetup.org, asking friends or family, or looking for an online community. In person is the best option, but either way, it’s critical to find others to learn with.
  • Take breaks! This is often overlooked, especially by beginners. Sleep and walks are when your brain actually does the learning. Your process should look like this. Struggle > Take a Walk Break to Relax > Struggle > Walk > Struggle > Sleep. This gives your brain time to switch between modes and time to heal.
  • Your brain has two modes: focused and diffuse. You are in focused mode when reading or coding. You are in diffuse mode when in the shower or taking a walk —whenever you get that feeling of daydreaming. You need to switch between the two modes to solve problems. Sleep is where you take information from short-term memory and add it to long-term. It also gives your brain a chance to heal.
  • Below I’m going to give you some resources to learn more about mindset and how to approach learning. These have the potential to help you grow exponentially — I can’t recommend them enough.
  • Everyone gets impostor syndrome. This is that moment where you doubt yourself and think I can’t do this, why am I even here? At some point or other, you will probably question your ability. Even after making an app, you may look back and feel you just got lucky. This is OK. Acknowledge it, then move on.
  • Don’t let the feeling change your actions — the goal is to realize that you’re feeling this way. Tell a friend or a loved one. Make sure to take a break and reward your awareness of this thought process. You’re not an impostor. Everyone can learn to do this — it just takes time and commitment.

Resources

After each section, I am going to list the resources I have mentioned or think are relevant.

I don’t want to overwhelm you — work through them as you can, they largely build off each other. If you feel you have mastered a concept in any given section, move on to the next resource. Be honest with yourself though. All of these high-level concepts are important to your job search. But you don’t need to work through every resource to learn them — it’s about active practice.


Learn to Code

This section is a beast — after all, you will be tested on your ability to code. A lot of your confidence on the job will come from your actual skills. Coding isn’t the only thing you need to learn though.

Too many guides to becoming a software developer focus only on this section. Thankfully, there are a lot of amazing resources out there for learning to code. My goal is to give you an order to your learning, and to point you in the direction of the best resources.

I want to reiterate something I mentioned earlier. Your fingers and your brain have to do the work. Reading books or blogs, watching videos, or doing code-alongs won’t teach you what to do. They can fill in small gaps in knowledge, but you need to be able to make things on your own.

Google will always be a wonderful resource. I highly encourage everyone to practice Google-Fu. You need a mental model of what you’re trying to build, which you can explain to a friend or an interviewer. Web resources can help you understand the concepts and the best way to explain them.

Another great way to practice is to explain what you’re learning to your parents or grandparents. If you can’t describe technology so that they can understand, you don’t own the knowledge yet.

My recommendation is to take a break whenever you’re stuck for more than 15 minutes. Take a walk, read a book, play with your dog — whatever. Learning is a marathon, not a sprint. Naps are great too!

Do your best to learn it on your own first (you don’t want to get over-dependent on help from others), but if you can’t figure something out after a couple of attempts — it’s time to ask for help online. Don’t feel bad or stupid or dumb if you can’t understand something.

Remember, your mental model is different from the mental model of the person who created this piece of technology. Big deal. None of it is a reflection on who you are as a person.

Before you begin this journey, here’s what I want you to buy or download (either today or tomorrow):

  1. A whiteboard and dry erase markers
  2. Sticky notes and flashcards (or a flash card app to practice terminology — I like Anki)
  3. A small tripod for your phone so you can record video
  4. An account on zoom (or practice using quicktime to record video if on a Mac). Don’t spend money on this
  5. VS Code and the Bracket Pair Colorizer plugin
  6. Postman

These tools will help you practice. Whiteboard out concepts often! There is a whole section on whiteboarding below. Use notes and flashcards to keep track of important information. Use your video camera to practice speaking technically for interview prep. This is your toolkit for the next several months.

Which Programming Language Should I Learn First?

I hear this question all the time. The short answer is: it doesn’t matter. The longer answer is: it depends on your goal. For getting a first job as a software engineer my recommendation is JavaScript, with Python as a close second.

Why JavaScript? Every browser uses it. There are millions of youtube videos, stack overflow threads and blog posts covering every aspect. There is also a huge community of people who teach it. And you can use it everywhere in the stack. It’s that simple.

What about Python? It depends on your career goals. If you want your first job to be doing database work or any type of data analytics, then Python is fantastic. A lot of new programmers get tripped up between learning and managing Python 2 and Python 3 as well. This won’t be a problem forever, but it causes a steeper learning curve today.

I would recommend you start with JavaScript and then branch into Python after you feel solid in JS-land, but it’s up to you!

This guide covers JavaScript.

Overview of the 8 Areas to Learn

  1. HTML/CSS: The bread and butter of any website. We won’t go crazy deep here, but you need a decent understanding of how a website works before moving on.
  2. JavaScript basics: The main chunk of ‘how to program’. Learn to build things and feel like you have superpowers in a matter of days!
  3. Advanced JS: The tricky parts of learning JavaScript. These are the pieces interviewers love to ask questions about. I’ll show you the resources I recommend for mastering each of the common interview topics.
  4. React (Frontend): I’m going to recommend you learn React as your first frontend framework. This will power what your users see of your application.
  5. Node/Express (Servers): This is the code that handles data in the cloud. Since we’re in JS-land, we’ll use Node and Express. I’ll explain the difference and show you some great courses on mastering them.
  6. MySql, Postgres, Mongo, and Redis (DBS): This is our data storage section. All the web is about data, and I recommend you get experience with a few different types of database. Practicing these will help you speak with confidence during your interviews.
  7. Travis, Docker, Heroku, and AWS (DevOps Lite) : Enough deployment to be dangerous. Understanding how to deploy and update code is generally enough for your first job, unless you want to pursue a DevOps career.
  8. Git, CLI, Testing (Developer Tools): These don’t fit into any other bucket, but are tools you will use on a daily basis. We’ll go over how I recommend learning these before you show up at work your first day and are overwhelmed.

What is the Internet?

One of the main things people struggle with is their mental model of how the web is built. The piece that I tend to focus on when teaching is data. Everything is data.

What does this mean?

It means that you’re going to create a page on the internet. It may have forms that collect data from users. It may show data from one user to another.

When the user submits the form, it will send the data to a server. The server will send the data to a database which stores it for use later. That’s pretty much it.

The majority of the web works this way — it isn’t scary or complicated. When you go to a page, it makes a request to a server, which makes a request to a database. It then sends the data back down to Google Chrome or Safari. These applications display the data and let you interact with it.

There are nuances to this, of course. The whole process is straightforward, though. No need to be scared or overwhelmed!

To learn more, I’d recommend that you first watch this course on Khan Academy. It provides a good overview on how the internet works in 5-minute videos.

Next, I’d recommend that you read through MDN’s article. MDN is from Mozilla (the people who make Firefox). This is the best resource on the entire web for HTML, CSS, and JavaScript.

If I don’t remember what a CSS property does, or how to use a specific JavaScript method, I refer to MDN. I recommend against using w3schools. They have good SEO and will show up at the top, but refer to MDN instead. MDN spends more time updating articles and getting user feedback than any other site of its kind, plus they have great documentation.

After you have a rough idea of how the internet itself works, it’s time to start learning HTML and CSS.

How to Learn HTML and CSS

This is the foundation of every website. I’m going to spend a little time to give you a high-level overview of both, and then send you off to study.

Remember, for this section and the rest in the module, you must do the work. There are no short cuts. Your brain will only learn by you making things, breaking them, and putting them back together. Tap into that childlike sense of play!

HTML works like a non-fiction book. There are words on the page and sometimes images. There is a cover and titles for chapters. Often, there are links to other parts of the book or reference to other books.

HTML on the web roughly serves three purposes:

  1. To show data to users of your site. This data can be anything, videos, images, text. Your browser downloads the data and displays it on the page.
  2. To collect data from your users. It does this through the use of forms, fields, and inputs that take in things like a username or password, or a comment for a blog post. Sometimes you want to display this data for other users, sometimes you want to save it for later.
  3. To connect your website to other sites through links (hyperlinks). If your website has many pages, you can connect them together with links. Most modern apps are a single page and mimic this behavior. You can also link to other sites on the web or a specific page on another site.

If we go back to our book analogy, CSS is the look and feel of the book and its text. It answers questions like “What does the cover look like?” “What color and size is the text?” “How large are the images?” It also answers some other questions when it comes to the web.

CSS has three main components, the style of the page, the layout of the page, and any movement on the page. It’s worthwhile to split CSS into these different buckets and spend time practicing each one. CSS can be quite frustrating for a beginner. Have patience when learning how to select individual elements and how to layout a whole page.

I suggest you keep practicing it bit-by-bit. Whenever you make a new app, spend some time trying a different part of CSS to learn it. Whenever you stumble across a site you think looks cool, try to re-create it. You can always download the CSS for the site and use it as a reference if you get stuck.

  • First, I recommend learning a bit about the Developer Tools in Google Chrome. The more time you spend practicing with these, the easier your time will be as you get into more advanced JavaScript. Google has a great site to get you started. If you’re more of a visual learner, Traversy Media has fantastic videos on YouTube. I will refer to both his and Net Ninja’s videos a lot throughout this course, as they make some of the highest-quality free content around.
  • The full reference for Dev Tools from Google.
  • Next, spend some time learning and building simple things with HTML. Whatever seems fun to you — try making it and viewing it in your browser.
  • Mozilla has a great written resource for learning HTML.
  • Udacity has a great video series on learning HTML and CSS.
  • I highly recommend working through Shay Howe’s course. It’s organized diffrerently to this course, and focuses on making things using HTML and CSS. Often people don’t invest enough time into learning HTML and CSS before diving into JavaScript — I think this is a mistake. These two are the foundation of the modern web.
  • At this point, test yourself. If you can think of an idea and are able to make a rough approximation of it, you’re ready to move on. If you still need more practice, that’s OK — spend another day or two creating sites!
  • If you want more practice with syntax check out Codecademy. I only recommend this site as a last resource, because it creates a false sense of learning. You usually type a thing, without understanding how it works. This is the trap I want you to avoid!
  • When it comes to a deep dive into CSS I’m a big fan of Wes Bos’ free CSS Grid Course, as well as the CSS Tricks site for Flexbox and Grid.
  • Play around with Flexbox Froggy and Grid Garden. To practice both layout tools I would use them in projects going forward.

How to Learn JavaScript

Build Things

That’s it. Okay, maybe it’s not quite that easy, but that is my advice. The sooner you can apply something you have learned in a project, the faster you will master it.

Watch a video or read some content, then test it on your own. One of the most powerful things about JavaScript is that you can use your browser to test any ideas you have. The console gives you a REPL (Read Evaluate Print Loop) environment, and some other nice bells and whistles.

Your mission for this phase and the next is to make and break things. Every hour or so ask yourself, “What have I broken to test my understanding recently?” Be comfortable breaking your code to test assumptions.

Cultivate a sense of being a tinkerer. It’s fine if you want to read and understand how things work, but your understanding needs to come from your own experimentation. This will give you the ability to explain your understanding in a job interview.

Everything we do goes back to this central goal. Ask, “how do I gain knowledge as fast as possible to be able to show this knowledge to others?”

Let’s dig in.

  • Udacity has a great free course if you like video content. I think the course is a fine starting point, but you’ll need more hands-on practice to master the basics.
  • Eloquent JavaScript is a fantastic free book. It’s comprehensive, so I recommend only working through the first 6 chapters for now. However, you can use this as a reference for several other sections of my guide. Feel free to refer to it during the advanced JavaScript sections and when learning Node.
  • Use MDN as your resource any time you are stuck trying to build a project, especially with syntax (how does that method work again?)
  • The goal is to keep practicing building things until you feel comfortable with a given topic. There are two wonderful sites for practice: Repl.it is great for simple JS practice and CodeSandbox is fantastic for building small applications and seeing them in a browser. If you want to mess with pure JS, use repl.it, if you want to see what you’re building in the DOM tryout CodeSandbox!
  • A couple of great places for toy problems are codewars and codesignal. For now, I would generally stick with the easy challenges in order to get more repetitions. Save the harder ones for later, we’ll come back to them in the job prep section.
  • As a last resort, I’ll say you can use Codecademy — but again, I think it’s too easy to type without learning in this resource!

You are ready to move on to the advanced section when you feel able to demonstrate these three things:

  1. You can manipulate the data in Objects and Arrays comfortably.
  2. You can create and pass around Functions to other Functions.
  3. You’re comfortable explaining what your code is doing to someone who doesn’t know how to code.

Advanced JS

This is one of the most important sections, if not the most important. A lot of people end up only learning the basics of JavaScript before they dig into learning frontend and backend. This is a huge mistake. Why? Because when it comes time to find a job, people want to know that you understand the advanced features.

The tools you use to write frontend code and the modules for your server will change as projects change. However, the fundamental parts of JavaScript don’t change. This is why experienced interviewers love asking questions about how both JavaScript and the Internet as a whole work. It makes sense right?

The key areas I want you to spend time learning are:

  • The this keyword (and context)
  • Object Oriented Programming in JS
  • Functional Programming in JS
  • Asynchronous code (Callbacks, Promises, Async/Await)
  • The Event Loop
  • Inheritance patterns
  • Closure and Scope
  • Dom manipulation
  • ES6

In my experience, the majority of hard JavaScript questions in interviews are based on your understanding of one of these topics. How do you go about studying them? A combination of two ways. First, you need to be able to code them out. Second, you should practice whiteboarding them. It’s fine if you only code for now. Keep a list of the ones you find the most challenging so that you can practice them in the whiteboarding section of this guide.

I have a bunch of these. It is likely you will need to see something explained in a few different ways to completely understand it. Practice by creating small projects and quiz yourself based on your conceptual understanding of a topic. Use console.dir to dig deeper into your functions. Be able to explain these topics in code!

  • Wes Bos has several great courses. I recommend his free Javascript 30 course for Dom manipulation. Spending time making small projects like these is my favorite way to learn. His ES6 course is great too.
  • I am a huge fan of the Fun Fun Function channel on YouTube. Here is some of the best free content for learning advanced topics (it is all theoretical though, so you still need to practice to master the concepts!) Check out the what are higher order functions playlist.
  • Tyler McGinnis’ Blog and Courses are very useful. I would work through both his Advanced JS course and his Modern JS course. His blog posts on individual topics are also fantastic. He has YouTube videos covering many of these subjects. His explanations can be challenging but he uses clear language.
  • Will Sentence’s courses on Frontend Masters are the best on how to whiteboard difficult concepts. The course is all whiteboarding in front of a live class. He has three courses up now. I would work through the first one (JS the hard parts), then come back to the other two as you dig into OOP and Async code (JS the new hard parts). He has a couple of other courses coming soon! Will runs a coding school which has some great materials I will be linking later. I am a huge FEM fan!
  • MDN has a great read on the Event Loop.
  • This is a classic talk on the Event Loop given at JS Conf by Philip Roberts.
  • NetNinja has a pretty good series on Async Code. There are some newer techniques, but he explains them in a way that students have found helpful.
  • This is a wonderful guide to Functional Programming in JavaScript: Professor Frisby’s Mostly Adequate Guide To Functional Programming.
  • For ES6, I enjoyed Stephen Grider’s ES6 Course. He makes a lot of courses and a lot of people love him. However, it can be easy to fall into the trap of coding along with him without understanding what he’s doing. This course has mini quizzes to test your knowledge in-between sections which is why I recommend it. Wes Bos’ course listed above is free and great too.
  • Lastly, I’m going to link my favorite articles on callbacks, promises, and async/await. I highly recommend that you master all three ways of dealing with asynchronous code.
  • I know of interviewers who still ask about the differences are between callbacks and promises. Here’s a short overview post of the 3 on Medium that is a good primer. This is a great video/blog post from Tyler M, it goes very in depth. Finally, here’s my absolute favorite post comparing all 3 — the code examples and explanation of each are fantastic!

How to Learn Frontend Web Development

I recommend that everyone learn React as a starting point. Why not jQuery? Or Angular? Or Vue? One reason: there are more React jobs right now than any others, by a large margin. This makes it a practical starting point. There’s also a wonderful and large community of React developers and the React documentation is absolutely, amazingly, delightfully beautiful (can you tell I’m a fan?)

As you progress through this guide you will see lots of documentation for different frameworks and libraries. The React docs are the gold standard. I recommend walking through their tutorials before going anywhere else.

A lot of what you read or explore may not make that much sense at first, and this is okay. I have a lot of resources for you here, find the ones that fit your style the best.

A word of caution around React Hooks. They are great to learn later, but you still need to understand how to use class-based components. Most of the codebases you’ll end up with at work for some time will be class-based! The same goes for learning Redux — you should learn it for now. I’ll update this guide later if this recommendation changes.

Before I start listing the ways I recommend you study React, let’s talk about what problem it solves. Up until now you’ve been writing code for yourself, in local files or in the browser. This is fine for getting started but at some point, you will want people all over the world to have access to your code.

More importantly, you are going to want their experience to be the same (or almost the same) regardless of their browser or operating system. You also want them to be able to get updates to the website in real-time. Remember when you used to have to hit the refresh button on your browser to get new messages? If not, lucky you!

React is one of the solutions to manage writing a single page application (SPA) for client-side code. The main superpower in SPAs is how they manage the state of your application. State is the condition (data, user interactions) of your application at a given point-in-time. This blog post gives a great explanation of state.

React has a cool way of handling state internally and passing it to different components within your application. I recommend reading both React’s definition of how it works and this post from Stack Overflow.

Now that you have a rough sense of the basics, I encourage you to start building things. The goal of this and the next 4 modules are the same — build small practice projects as often as possible to test your ideas and understanding.

If you ever get stuck, Google is your friend. Whenever you understand a topic — explain it to a buddy or write a blog post about it to practice your technical communication. I keep bringing up this method of practice for one reason: your ability to verbally communicate your technical understanding will be crucial for job interviews and i only comes with practice!

  • My favorite courses for learning React as a beginner, are from WesBos and on Frontend Masters.
  • There are some fantastic free resources. My two favorite YouTube courses are from Traversy Media and Net Ninja’s (which also includes Redux). Redux is hard for beginners, work on mastering React before you master Redux. The reason Redux is challenging is a combination of new syntax and new concepts for managing the flow of data.
  • For the above, focus on state vs. props — solidify your understanding of how to pass functions and events around. Whenever you get stuck, refer to the React docs or use Google. There are lots of great blog posts and Stack Overflow answers to help with common questions.
  • When you feel like you’re getting the hang of things, I recommend going deep with Tyler McGinnis’ courses on React and Redux. These have you building both pieces of tech from scratch using JavaScript. They help you to develop an under-the-hood understanding, crucial for explaining the tech during job interviews!
  • There are two other course providers I enjoy. I’ve mentioned Stephen Grider already, who has a TON of content out. I am not opposed to his teaching style, but it can be easy to code along with him and not actually learn the material, so be wary. The second I recommend is Scott Tolinksi. Scott has a fantastic YouTube channel, and he’s focused his energy the past couple of years on Level Up Tutorials. He has some great design-oriented content and goes deep on advanced React topics too.
  • Once you’re starting to feel comfortable, I recommend you practice building several small apps. A great starting point is JSON Placeholder API — it has blog and todo data with RESTful endpoints. I use this as my go-to whenever testing something new. A large list of public APIs is here. Make fun projects using data from the big list and share them with friends!
  • Use CodeSandbox to create practice projects, or use create-react-app to build projects locally. Practice, practice, practice!

Once you feel comfortable with parent-child components, passing state around as props, and event handlers, you’re ready to move on! Don’t shortcut your time here, the concepts of how to move data around a local application are important.


How to Learn Node and Express

By the end of this section you will feel you have superpowers! Writing server code seems like the hardest, strangest thing to beginners. We tend to imagine that a server is some mythical computer in a center somewhere deep underground — this couldn’t be further from the truth.

A server is simply a file listening to requests from the outside world. That outside world can even be on your own computer. Part of what makes JavaScript a great first language is Node.js. Node is the same engine that makes JavaScript run in the Chrome browser run outside of the browser. It lets you use JavaScript code on any file system.

To run a node file, on a system that has Node installed, you type node FILE_NAME.js and it executes the file. It’s like running a file inside of a <script> tag in the browser, except that you don’t need the browser!

Why is this so powerful? For obvious reasons, JavaScript inside the browser isn’t written to give access to your computer’s file system. Imagine if any website could access all the files in your Documents or Downloads directory!

Node on the other hand has modules written to give access to the internal files of the system. This allows your server to access HTML or JavaScript files stored on the server to send them to a client. Pretty powerful.

One of the main challenges learning Node is that you will be dealing with a lot of asynchronous code. This is why we spend so much time covering it in the Advanced JS section above. If you feel rusty on callbacks and promises go back and practice.

Another big challenge is learning to understand the Node Package Manager (NPM). NPM gives access to a huge number of packages written by other developers around this world. This is a blessing and a curse! It allows you to extend your projects easily, but it means adding a lot of code without understanding what it actually does. When starting out I encourage you to look at the original source code of these packages when you begin using a new one.

Over time you will see the same packages used again and again. Your understanding of how they are written will improve. This won’t happen overnight but it’s worth the exposure, so start early.

One piece of caution: I highly recommend that you use Node Version Manager (NVM) to install Node. It takes a bit more work to set up, but will make your life much easier in the long run.

  • I encourage you to spend at least a few days using Node without Express. It is a little frustrating, but it will show you where Node ends and Express begins. I have noticed in job interviews that a lot of newer developers don’t understand where this line is. This tutorial by Traversy Media is a great starting point.
  • As usual, NetNinja has a fantastic series on Node and Express. Spend time looking through the Express docs for a few tutorials on routing and middleware. Middleware can be a challenging concept but it’s powerful. In a nutshell, you can use middleware to intercept requests and transform them if they fit a specific pattern. BodyParser is a great place to begin learning about middleware.
  • There are a few topics you should understand in this section but they don’t require entire courses to master. The first is writing RESTful routes from this article on Codecademy. The second, is how Semantic Versioning works and how NPM uses semantic versioning.
  • If you’ve purchased a Frontend Masters subscription (and I highly encourage it), then there are two courses I recommend. The first is Introduction to Node, and the second is How To Write an API using Node.
  • I want to make sure you feel confident using the file system too! One of the major benefits of Node comes from this superpower! Devslopes.io has a Complete Node.js course. And Stephen Grider has a deep course called Advanced Node (this covers things like Redis and some AWS tools as well).
  • The last few topics to cover are Encryption, Hashing, and Authentication. You don’t need to go deep on any of these topics right now, but how they work are common interview questions. Here are a few videos I would watch on the subjects:
  • Public Key Encryption
  • Web Encryption
  • SSL
  • Hashing
  • Passport.js from Traversy Media
  • OAuth from Net Ninja

As usual, my recommendation is to build lots and lots of small projects. Practice building a small server, creating routes, saving things to a local file, and sending them back to a client.

Get comfortable with asynchronous code! This is a challenge and something that beginners don’t practice enough. There’s a reason the most common take-home project is to build a RESTful API. It shows that you have an array of skills and can put the pieces of a server together.


How to Learn Databases: MySql, Postgres, Mongo, and Redis

For some of you, this is going to be the most challenging section of all. We tend to have mental models that make CSS either easy or hard, that make networking and interviewing easy or hard, and databases easy or hard.

I believe this has to do with what you enjoyed and spent the most time doing as a child. If you liked math, and now enjoy spreadsheets, then learning how to use databases will seem natural. If not, then you should commit to practicing a little more. Be patient with yourself during this process. I’ll give the same advice again in the networking and interviews section below.

At this point, you want to be in “play” mode. If you aren’t already, you should start keeping a dev journal. Write down your war stories — what works, what doesn’t — so you can tell them later in job interviews. You also want to turn these into bullet points on your resume.

Start by learning SQL, first with MySQL and then with Postgres. Both are wonderful and have lots of tutorials. The syntax is almost identical, but they are set up and can treat your data differently. Remember, you’ll be using a connector package — something installed from NPM to actually connect to the database. This means you’ll have to read the documentation for the DB and for the NPM package too.

I’m going to say this again: databases can be hard for new engineers. Have fun and don’t get frustrated if things don’t click right away. There are a lot of 3rd party tools, called ORMs (or ORDs) that can help you write cleaner code. I encourage you to write raw SQL to begin with so you can troubleshoot when things don’t work the way you expect.

After you’ve created a few small projects using one database you should switch to the other. You can swap out this piece and plug a different database into your server.

Repeat the process with Mongo (& Mongoose) once you’re comfortable with SQL. Mongo is considered NoSQL (horrible name), which just means it’s something other than SQL.

There are trade offs for using different databases, but your goal is to become familiar with how they structure data (Schemas) and how to store and query the data.

Before moving on, spend a little time learning Redis. The concept of caching is important — people love checking your understanding of it during system design questions in an interview.

  • MySQL docs just as reference (remember when I said how great the React Docs are!?) Don’t spend too much time with these, but keep them in your back pocket. The Mongo and Postgres docs are better.
  • Traversy Media MySql with Node course. A good, free, YouTube course that you can follow along with.
  • MySql NPM package as a reference.
  • Codecademy’s tutorial is actually decent for learning SQL. I’d work through it then just practice building things. Swapping over to Postgres should be a breeze.
  • If you like GUIs check out Sequel Pro — it’s a free tool! I use Tables Plus, which is paid, but amazing!
  • Postgres docs. This is actually a solid reference, I use it often.
  • Pg package on NPM. Fantastic package with great docs.
  • A long, but fantastic free course on Posgres from freeCodeCamp.org.
  • I don’t think you need to pay for any database specific courses. What you already have purchased should suffice. Frontend Masters has a great SQL course and my favorite Mongo course I’ve found so far.
  • Another Mongo course from our pal Net Ninja.
  • A Redis course from Traversy Media, and one with Node.
  • One from the Redis team.
  • Again, there’s LOTS of free database content. Paying isn’t necessary unless you want to go deep into DB optimization, or are looking for something specific you can’t find in a tutorial. Stephen Grider has a Mongo course on Udemy and Colt has a MySQL course on Udemy.

How to Learn Dev Ops (At Least Enough to Be Dangerous)

Developer Operations is a deep topic. I still consider myself a novice in this area and most of the developers I know are in this category. Unless you want to dig deep into AWS and large-scale data management, it isn’t important to master any of the topics in this section. Yet, exposure to deployment and some of the other tools will make your job search much easier.

It will generally impress companies if you’ve used Docker and deployed to AWS before — it gives you fantastic war stories, and that’s what everyone wants in an interview!

Also, interviewers love asking system design questions. You need to know what a load balancer is and also a virtual machine. Your goal is to spend a little time with these tools so that you understand what problem they solve. When you are given one of these problems in an interview, you’ll know the answer they are looking for.

You might find you love Dev Ops and dealing with this kind if tooling — if so, I encourage you to go deep into this area and look for work. There are lots of Dev Ops jobs out there and they pay well!

The next logical question to ask is, “What dev ops tools should I learn first?” This is a hard question to answer. I picked out 5 for this article that I believe are worth having a beginners understanding of. If you find yourself enjoying any of them specifically, explore further.

  1. Webpack. The go-to bundler at the moment. Webpack is used on the frontend and backend of many projects. It is incredibly powerful, has a lot of customization options, and is generally a pain in the butt for new devs. The best tutorial on Webpack I’ve found is a 3-part series on Frontend Masters by Sean Larkin — a fantastic entry into the how’s and why’s of Webpack.
  2. Heroku . There are a range of deployment options for beginners and Heroku has been a classic for quite a while. It’s a great first option, as you’ll need to learn about environment variables and building your code to deploy it. Here’s a decent tutorial, but the Heroku docs are good too.
  3. Travis CI. At some point you’ll hear about continuous integration or continuous deployment. Now that you’ve deployed something to Heroku, imagine that you have a test suite you want to run before you deploy again.
  4. It’s a good idea to lint your code. You also need keys, and perhaps several people on your team, to be able to deploy. You want to make sure each of these things happens every single time anyone deploys. They also need to run the same tests — you can see where this is going!
  5. Travis (or Jenkins, Circle CI, or several other tools) to the rescue! Travis is a good starting place, it’s easy to learn and simple to get your first project up. Give it a whirl.
  6. Great! You’ve got live code online and it updates whenever you update master! This is a powerful moment — one worth celebrating! Let’s dip our toes into the Docker and AWS pools before we get dry for awhile.
  7. This is a fantastic Docker tutorial that my students generally use to get up and running. There are lots of courses and YouTube videos if you prefer something visual. The tutorial above shows you how to do it with AWS as well.
  8. Additionally, one of my students wrote a fantastic tutorial on using Docker with AWS so I want to give him a plug! By going through these two tutorials you should be ready to rock’n’roll. Let me know if you find any resources that were especially helpful and I’m happy to add them!

Developer Tools (Or the Miscellaneous Section)

Don’t wait til the end of this guide to work through this section! If you took my advice and are skimming/reading once through before diving in please bookmark this section and refer back to it often.

This area is the reference for all the tools you’ll need during your everyday work as a software engineer. They will help you while learning too. I don’t want you spending too much time on them all at once. Instead, I recommend spending a little time on each of them every week.

The tools in this section are: using the Command Line Interface (or CLI), git/github, working on a server with SSH, and testing. Each of these could be an entire section on their own. But since you are rarely asked direct questions testing these skills during an interview, I put them in one section.

Remember, the focus of this guide is to get you job-ready for Day 1. Do you need to master these skills or the majority of the skills in this guide? No! But you need to know enough to come across as competent. That takes familiarity and practice.

Hopefully, you’ve already spent some time learning the Command Line Interface (CLI). I would recommend you spend a couple of days during your HTML/CSS phase getting to know how the command line works. To get started, the Codecademy tutorial is great, as is Learn Bash The Hard Way.

There are plenty of good tutorials to work through online, if you want more practice. There’s a killer MIT course about Developer Tools that blew me away. I am still working through all the content, but I’ve learned a huge amount from this course. This depth of understanding isn’t needed for a junior dev, but it can be pretty amazing to see how powerful your OS is!

Git is a hard thing to practice on your own. The best way to learn is to work on projects with friends or contribute to open source. Both of these avenues will help you get a job — engineering Managers want to see that you can work on projects with other people.

I like this visual git tutorial so that you can see what is happening. Pro Git is a fantastic book too. I encourage people to switch back forth between the two as they are first learning. It’s likely that all of this will seem abstract and weird — that’s okay.

Start a project with a buddy and try messing up the code. Break things and google how to fix them. After a couple of days, when you start to feel comfortable, it’s time to try submitting code to an open source project on Github.

My recommendation is to pick a smaller project at first and look at their rules for submitting pull requests. You can even reach out to the maintainer, let them know you’re learning, and ask for a good first issue. People are nice — give them the benefit of the doubt!

Here’s a short and quick guide on using SSH to get into an EC2 instance. There are tutorials about more specific things based on what you want to learn. I’d practice installing some software on an EC2 and try running a server. It will be a little awkward at first. See what you can do and what you can’t . Try testing the limits of the environment.

The last section of this part is testing. Testing is incredibly important. I would add tests to any code challenge for a job application. There are a lot of methodologies and tools related to testing.

My suggestion is that you go back to the apps you have been building for the last few months and begin adding tests to them. This Medium Post is a beast — it gives a well-written and comprehensive guide to testing. Work through it by researching the different styles of testing listed inside and adding them to projects.

You should also master Unit and Integration tests. Frontend Masters also has a great course on testing from Kent C. Dodds.

I’ll recommend you stick with Jest as your test runner, but you can research the other options on your own. Have fun testing — it can challenge how you write code!

Make your next couple of small projects through TDD (write the tests before writing any code) and see how it changes your thought process.

Let me know if you find any other resources you enjoy! A fun one to practice with is the Gilded Rose (do the js-jasmine or js-mocha ones).


How to Prepare for Technical Interviews

Practice makes perfect! Or at least better…

There are lots of guides out there that provide information on how to learn your first language. Or how to study. For some reason, people don’t like to discuss how to actually apply these skills to get paid!

There’s a misguided belief that looks like this: if you study hard and learn how to code you will get a job. Anyone who has tried this knows that it doesn’t work that way. What you actually know when you start work will be a fraction of the skills you need on the job.

You might ask, “why did I spend all this time learning the tools you’ve listed above!?” That’s a wonderful question. It’s because you need to learn how to learn! There’s a general framework of how the web works and how building an application works. This framework exists regardless of what languages you choose, whether you’re working on a mobile or web-based project, and regardless of industry.

In essence, once you’ve learned how to do this well, you can apply the same principles to any project. Once you’ve built several large houses of the same style, it’s not too difficult to build a different style house. The guts of the house will largely be the same and the cosmetic differences shouldn’t be too much of a headache.

How does this relate to interviewing for a software engineering role? If I am the hiring manager, I want to find out if you’ve mastered how to build one style of house. I also want to know how you’d handle me throwing a wrench into those plans — how you’d deal with a custom build.

I want to know what your thought process is — how you approach a problem you haven’t seen before, and how you will explain that problem to me. I also want to know how you’ll handle saying “I don’t know.”

So what does this all mean for you as you begin your job search? It’s going to be hard.

And this is OK! You’re interviewing for jobs that will pay from $75,000 to well over $100,000 a year! For most people this is a large pay increase from what they were doing before. I’ve trained Starbuck’s baristas, librarians, and music teachers who were barely making ends meet. If they can gain these skills and find a job, so can you!

There are some shortcuts along the way. Ultimately, the harder you hustle during the phase, the easier it will be. People tend to not like hearing this. It doesn’t matter how much you know, it matters how hard you’re willing to work and how willing you are to step outside of your comfort zone.

There are three phases to this section. The first is setting up your materials so that you’re job ready. The second is preparing for live technical interviews. You’ll do this by practicing whiteboarding and further developing your verbal problem-solving process. The last section is hitting the pavement, applying for as many jobs as you can.

Common Traps and How to Avoid Them

There are two common traps that I see students fall into during this phase. The first is impostor syndrome, the second I call good enough syndrome.

Here’s a great TED talk on it. Almost everyone suffers from it at one or many points in this journey. You’ll talk to someone who knows so much more than you, which makes you feel like a fraud. Or you get stuck on a problem and believe you are not smart enough to solve it. These thought patterns are a trap.

Your knowledge is a snapshot in time — what you know today. No one knows everything. There are no natural geniuses who came out of the womb understanding how to talk to computers. Learning how a system works may be easier for some, but what they know today is still a snapshot.

Your challenge, in moments of self-doubt, is two-fold.

  1. Gain awareness that you’re doubting yourself and your abilities in this moment. Take a breath. Feel this doubt and accept it. This is fine — it’s okay to have these feelings, there’s nothing wrong with you for having them, we all do. Go for a brief walk or do some jumping jacks. Instead of wallowing when you feel this way, move your body.
  2. Take action. Accept where you currently are and take action to change this. This might mean asking a friend how you could have answered an interview question better. Maybe it means spending extra hours this weekend to practice. Or maybe it means you need to take a day off to reset because you’ve been pushing yourself too hard. Don’t underestimate the value of a long hike or a date night with your partner.

There is a high chance you will feel some impostor syndrome during your job hunt. Make your peace with this now and write down ahead of time what you will do when you start to feel this way. If you come up with a strategy now, before it happens, it will be easier to deal with in the moment.

Talking to loved ones for re-assurance is always good too. Just remember, your knowledge is only a snapshot in time, it’s okay to not know it all today.

Good enough syndrome is a trap that I see almost everyone fall in to along this journey. It’s a method of procrastinating getting outside of your comfort zone. It looks like this…

You see a job that looks great — a cool company with great benefits. Maybe your friends work there. As you look at the job you start to think, “I’ll apply once my resume is better. They want me to know xyz-framework so I’ll spend a few days learning that and I need to polish my LinkedIn profile.” Before you know it you’ve talked yourself out of even applying for the job for three months until everything is perfect.

There is no perfect — there’s only good enough. That means you need to do your best with what you have today and take risks to get feedback. Do your best on your resume and LinkedIn, but meanwhile apply for jobs and see what happens. There is no magical point in the future where you will have all the skills and experience required for your first job. This is a fantasy driven by fear. Whenever you feel yourself starting to slip into this place, it’s time for a reality check — you’re not going to find your first job by being a perfect fit on paper.

I can’t count the number of times I’ve seen companies make special exceptions or create a new role for someone who didn’t fit the bill. The reason the company does this is that the individual went for it by showing initiative and hustle. Everyone respects that. You will be amazed at what happens when you try hard.

Does this mean you will always succeed? No, but you should always be asking for feedback so that you can improve. It means you will eventually succeed, and that this will happen sooner.

Say it takes 15 interviews to land your first job. If you wait an extra month to have that first interview, you’ve pushed back your start date (and your first paycheck) by an entire month.

I have one last suggestion before we dig in. Choose 3–5 target companies before you proceed with the next steps. Even if you don’t end up working at one of them, you will have a target to aim for. Why is this important? You can research what types of interview questions they ask, you can check the LinkedIn/AngelList (and sometimes resumes) of the people they’ve hired recently. Use their current employees as a measuring stick. This doesn’t mean you should feel bad about all the things they’ve done that you haven’t, instead use their online presence as a template for your own.

  1. 5–6 months of nothing but coding! At first, this should be your only focus. During this time I highly recommend you start to code socially. Either join a meetup group or find an online community. Talking about code is as important as learning to write code. I have a community for job seekers.
  2. You’ll also meet people who could open the door to your first job through one of these groups.
  3. 2 weeks of putting your job application materials together. This means your resume, CV, LinkedIn, AngelList profile, and a personal site too, if you want. Don’t spend more than 2 weeks getting all your materials ready. You’ll iterate them with feedback later.
  4. 2 days of practicing whiteboarding and problem solving with algorithmic-type questions. I am going to have you spend a lot more time studying these later, but I only want you to spend 2 days doing it before you begin applying for jobs. While applying for jobs in the next section spend 1–2 hours per day practicing.
  5. 3–6 months of applying for jobs every single day. I’m going to go a lot deeper into what this means below, but I want you to spend at least 30 minutes every single day applying to keep up the momentum. Ideally, this is more like 2–4 hours per day depending on what your current life commitments look like.
  6. This includes coffee info sessions and meetup groups. During this time you will also be learning to whiteboard Data Structures and Algorithms. Split your time between the two.

This is the basic structure, it’s roughly 9–12 months from zero experience to your first full-time software engineering position. This is realistic for anyone who is willing to put in the time. Sometimes people get lucky and find their first job quickly through a friend. Sometimes it takes a lot longer, especially if this is your first professional job. I’ve watched 18 year-olds follow this strategy as well as people in their 60s.


How to Learn Algorithms and Data Structures

Algorithms can be pretty

Before you work through any of the resources in this section, I want you to create a GitHub Repo. It’s a great idea to track the work you’re doing here and save it for later. It’s also going to be the vast bulk of coding you do while searching for a job. As a consequence, you want to both keep up your green check marks on Github and actively work towards a larger project.

Another tip on this section — be patient. Computer Science degrees teach a vast amount of information. Expecting to learn it all in a matter of months is naive. Instead, we are going to focus on getting the most bang for the buck. There are common interview questions, and there are fantastic resources out there to help you prep for them.

Over the longer term, if you enjoy these, then I recommend going deep. You’ll gain a broad mental model of how systems actually function.

  1. Start with Grokking Algorithms. This illustrated book is a great way to get a visual feel for the basic data structures and algorithms. Write code for solutions to the questions posed, in JavaScript.
  2. When you’re ready for a deeper dive I recommend a few different resources. Colt Steele has a great course on Udemy — JavaScript Algorithms and Data Structures Masterclass. If you prefer Stephen Grider, he has a course too.
  3. If you’ve purchased a Frontend Masters subscription then you can work through Bianca’s courses there. They were a bit slow for me, but she’s quite thorough.
  4. MIT and other schools also have great open courseware covering this topic. MIT’s, Stanford’s (and on Coursera), and Harvard’s course on edx. I would watch a video or two from the different instructors and choose the one you enjoy the most. Again, the goal is to practice not passively watch these.
  5. THE classic tome, if you have patience and want a lot of exercises— Introduction To Algorithms.
  6. And of course, there’s the wonderful Cracking The Coding Interview. It’s the best resource because the odds are your interviewer is drawing their questions from this book. Cheating? Kinda, but it shows you’re willing to do the work.
  7. My two favorite sites to practice on are CodeSignal and LeetCode. I like CodeSignal’s style a lot more, but LeetCode has a deep variety of problems. Both are great. You can always pull up YouTube if you need help with a specific algorithm or data structure. If you haven’t seen the sorting dancers before you haven’t lived!
  8. A small final note. If you want to learn Python, this is a fantastic time to do it. There are a huge number of resources for learning Python that use data structures and algorithms. I recommend this to students as an intentional challenge that makes learning Python fun.

How to Write a Technical Resume

This section is challenging to write for a variety of reasons, the biggest being that I don’t know your background and prior experience! I will give you some general dos and don’ts and cover the most common mistakes that people tend to make. If you want more details I have a post on my blog dedicated to resumes.

  1. Write about recent projects you have created — it’s okay if they aren’t all deployed. The two or three that you are most proud of are fine. Create a section titled Recent Applications for this. If you have been creating something with friends this is a perfect place for it.
  2. Cover your skills clearly. If you feel confident in React, Node/Express, and Docker, then list them at the top of your resume. Topics like REST and OOP count here too.
  3. To get a feeling for these topics, research the companies you’re interested in working for. Look at the skills they are seeking in their job postings. Add the ones you know to your list.
  4. List any relevant work experience. Have you worked alongside developers before? Or maybe you made websites in high school? If you have none this is okay too, write any recent work experience, but don’t go overboard. You want to focus your resume on the applications you’ve been building.
  5. Use a clean and simple format — something from Google Docs, Canva, or Apple Pages is fine. I don’t generally recommend Microsoft Word because it can be hard to format, but if you’re a wizard this is fine too.
  6. Save a PDF version as you will probably be emailing it or uploading to an Applicant Tracking System that a bot will first read and analyze. You need clear keywords that are easy to scan.
  7. Write 2–4 bullet points per project. Same goes for prior work experience. These bullet points should follow this general format:|Action Verb| some technical thing |so that / in order to| add value or solve a specific problem.
  8. Here’s an example: Composed over 300 unit tests with Jest to allow comprehensive refactor of XYZ component for V2 of the app.
  9. If you can be specific — great. I know it’s hard sometimes, and will not be not possible for some.
  10. Include a link to your Github, LinkedIn, your email address, your current address, and phone number.
  11. Make your resume relevant to the job posting you’re applying for. Look at the Keywords the post is seeking — if you have those skills make sure to highlight them!
  12. It’s fine to have several versions of your resume and a shame to only have one generic version. Put in the effort!
  13. Share your resume with friends and family for their feedback, especially if you’re new to making one or have never worked in a “professional” capacity before. Take their feedback and don’t get defensive. Remember — there will be a mix of technical and non-technical people reading your resume as you apply for jobs.
  14. It’s okay to share a little of your personality on your resume, I wouldn’t go overboard though. Some hobbies or fun facts are okay, butless is more in this area.
  1. Don’t use meters, graphs, or charts to show your skills. It’s irrelevant that you’re a 3.5 out of 5 on the React skill-o-meter. Either you have a skill and are fine being asked technical questions to show understanding, or you don’t. If you don’t, then don’t include it on your resume.
  2. Along the same lines, don’t list any skills you’re not familiar with. Don’t lie. Spend a weekend to learn a language or library if you want to list it on your resume.
  3. Don’t try to impress someone too hard. If you’re trying too much this will come across. Be sincere and subtle, list your accomplishments clearly.
  4. Don’t be goofy or funny on your resume. Sometimes people have success with this, but its hard and not a tack I would take in general. Let your personality come across in person. Developers aren’t known for reading between the lines well — that’s why we write so many comments!
  5. Don’t go crazy on the formatting. Remember that a machine may have to read it— if it can’t your resume goes in the trash!

How to Write a Technical CV or Cover Letter

I’m going to keep this section pretty simple. I’m always open to suggestions here though! You should write three short paragraphs.

  1. In this first paragraph write about what draws you to the company, the specifics about the team, project, and role that impress you. Be excited about what they are doing.
  2. In the second paragraph write about your specific skills that connect to the specific asks the company has. Show how you can deliver real value.
  3. In the third paragraph, summarize why they should interview you and make a tangible ask. Be clear and direct in all three sections.

Make sure you write a different version of this CV for each job you apply for. It takes a while, but you will end up with templates that you can adapt for future applications.

How to Use LinkedIn to Find Your First Software Engineering Job

There are two parts to this section. The first is how to create your LinkedIn and AngelList profiles. The second is how to reach out to people for coffee meetings. This is by far the most effective strategy for job hunting, so I will explain it in detail.

I’m not going to give you lots of rules in this section as I did for writing your resume. Instead, I urge you to find some developers you respect on LinkedIn and AngeList (such as those working at your target companies) and copy the format of their profiles. It does not need to look as professional and bullet-point driven as your resume.

Include the highlights of your professional career, or academic career if you don’t have professional experience yet. The goal of your page is to appeal to recruiters and not come across as weird if another engineer looks you up. Use this as a resource for cold-messaging people to grab coffee — you want to seem normal. Use a nice photo and write a little about yourself up top.

I encourage you to not say things like “seeking a new job”. Instead, put Software Engineer as your title. List the projects you have been recently building and highlight the technology used.

A quick note about recruiters . There are two types of recruiter that use LinkedIn: internal and external. Internal recruiters work for a company and they will be your advocate throughout the hiring process. If an internal recruiter for a company reaches out they can be a fantastic resource.

External recruiters can be a mixed bag. Some are fantastic — they know about the technology you work on and represent a company that interests you — many, however, don’t have a strong grasp on technology.

Many external recruiters that reach out to me are looking to fill Java positions and see JavaScript on my profile, which is not a good fit. Don’t write off a recruiter immediately though, ask them a couple of questions about the role first. I have had some students find jobs this way, and I have used them to hire for technical roles at companies I have worked for in the past, with great success! It depends on the person.

This section is probably going to push you outside your comfort zone. People will hire you because they have connected with you as a person. This means that your first software engineering role is most likely to come to you because you have built up a relationship with someone.

This could be a friend or a family member. However, it’s a great strategy to build connections with as many people in the industry as possible. I have watched a huge number of folks get their first job through LinkedIn, AngelList, and Meetups.

You can use these tools to build an in-person connection with others. It’s going to be a little weird and likely awkward for you at first. This is okay.

The mindset I want you to cultivate is one where you believe you can provide tremendous value to anyone who will hire you. This means talking to friends and family and asking if they know anyone. It also means sending cold messages to people on LinkedIn and AngelList.

Learning how to message people and convince them to meet you is an art form and will take practice. That’s OK— this is an area where you shouldn’t expect immediate results. If you find people willing to meet you, that’s wonderful!

Here are some basic rules for reaching out:

  • Be friendly and don’t expect anything.
  • Message lots of people, if 1 in 10 reply that’s great!
  • Make your message personal, look at their GitHub and see if you have anything in common from your past (or compliment their code).
  • You might offer to help out on a project, but I would wait to do that until you have met.
  • Reach out to anyone in the engineering department of a company you’d like to work for. If the company is small this means the CTO, otherwise, Directors, VPs, and Engineering Managers are all fair game.
  • Let them know you’d love to take them to coffee or have a 20-minute phone call to talk more about their work experience. Try to make it clear that focus of the call and meeting is them, not you.
  • If you can help them somehow, then offer — it’s not required though.
  • Be respectful. Sometimes people agree to meet up and then get busy and have to cancel. This is OK.
  • Test several different messages to find the one or two that work best!

Your willingness to go outside your comfort zone by reaching out to others will determine how fast you get your first job — it’s that simple. I tell this to every single student I work with because it’s true. It’s much easier to get hired when your resume is handed to the recruiting manager or team lead, versus submitted online. You should still submit resumes online as well, but focus on meeting people.


Job Application Sites

This is a list of the best sites for people finding their first software engineering job. Use different search terms — different companies will call the same role a software developer or a UI engineer. Focus on the technology and skills the company is looking for and apply to anything you are at least 50% qualified for. 15% — 25% of my students end up with senior roles. It will depend on your background, your confidence, and your willingness to sell yourself.

Here’s the list:

  • LinkedIn (See the above, lots of companies list jobs here).
  • AngelList. If you’re looking for startups this is the best resource. You can usually reach out to leadership directly to pitch yourself.
  • Indeed. See if you can get onto indeed prime, it tends to have decent listings.
  • Built In network. If you live in or want to work in a major city there’s likely a BuiltIn for your town.
  • Remote Work or We Work Remotely. These are both great resources if you want to find a job-based in a different location. They often skew more senior, but junior roles do come up from time to time.
  • Specific company career pages. Companies often post here before anywhere else.
  • Glassdoor. Look up every company on this site. They also have job postings.

How to Prepare for In-Person Technical Interviews

There are three different hard-skill areas you will need to practice to excel at in-person technical interviews:

  1. demonstrating your problem-solving strategy
  2. how to pseudocode
  3. how to whiteboard

You probably don’t have a repeatable process for any of these three areas, but if you do give yourself a pat on the back! In the next sections, I’ll break down what these skills look like and provide resources for study.

As with the other sections, there is no shortcut to mastery. Intentional and repeated practice is the key to gaining comfort. In this case, there are two methods that work well.

In order to practice both a repeatable strategy and pseudocoding, use the toy problems you’re working through to learn data structures and algorithms. If you can take a problem from CodeSignal or LeetCode break it down into a process, you’ll be in good shape. Use the same process for each question.

I also recommend using your phone or laptop to record yourself whiteboarding the same problems. You don’t need to do all of them, but any problems from Cracking The Coding Interview will work.

Then there are your soft-skills. Work on telling stories about yourself that engage the listener. Go to meetups and networking events. Watch to see if you can keep someone interested in learning more about you. This may not come easily and if that’s the case you need to practice more.

How to Develop a Problem-Solving Strategy

One of the most overlooked areas of practice is in problem-solving strategy. This is analogous to practicing form or fundamentals in sports or art. Your first few months or even years of any new physical endeavor is often teaching your body basic movement. Similarly, you need to teach your mind a repeatable strategy for solving technical problems.

Why is this so important? It will help you identify what information you need to solve any problem. This helps in two ways. First, if you’re being interviewed it will prompt you to ask questions to fill in the gaps of information. Second, it’ll give you a sense of confidence because a lot of your work will be on auto-pilot.

This second piece can be a bit difficult to explain, but it’s like driving a car — it would be a lot harder to get from your house to the grocery store if every time you sat behind the wheel it’s like your first time driving, all over again. A bit like driving a rental car in a foreign country.

Thankfully, this isn’t necessary. There is a repeatable strategy you can use for approaching any new problem. My guess is that right now you:

  1. Read the problem once.
  2. Try a solution.
  3. Try to fix it for a while and if that doesn’t work delete everything and start over.

This is where I started and it’s where most of us start. I challenge you to try doing it in a different way. Your new process should look like (and feel free to tweak it a little to what feels good):

  1. Read the problem and write down all the important information.
  2. Think whether you are missing any information, if so read the problem again.
  3. Draw a few quick sketches using sample data — 2 or 3, or more if you can see the potential for edge cases.
  4. Break the problem into chunks. Find out where you can use helper functions.
  5. Write pseudocode.
  6. Write code and debug.
  7. Clean up your code.

I have found this process to work incredibly well with students. After you’ve done this for a week or two you’ll start to get a Spiderman-style sense when you have missed something in your initial read through. This can save minutes or hours of wasted work due to a misinterpretation. Interviewers want you to ask questions, so this process gives you a pattern to match.

Breaking into chunks can also take some practice, but you’ll get better at analyzing where helper functions should be used over time. Don’t get disheartened if this and pseudocoding feel awkward your first several times. It gets easier.

Spend a day or two experimenting, but no longer. The goal is to find a process you enjoy and then practice it. Over the next few months it will cement — it takes around 5 weeks of regular use for a habit to sink in.

How to Write Pseudocode

Pseudocoding needs to become a natural part of your problem-solving process. It will make whiteboarding much easier. You will find you get stuck less because you have already broken the problem into smaller chunks.

As with the other skills in this post, it will take practice. It usually feels a bit awkward. Finding the balance between writing vaguely and writing too specific is the classic Goldilocks story. Your goal is to write pseudocode that breaks the problem down into logical chunks and to explain the control flow of each.

Does this mean you need to name variables? Parameters? That’s up to you. You do want helper functions and the logic of any if blocks or for loops though.

There are some great resources out there to help you practice. I recommend looking at the following:

  • Geeks4Geeks. A great site that has a huge number of explanations around algorithms and data structures. Their pseudocode guide is good (check out their other content too!)
  • This is a quick read on writing pseudocode. I don’t follow it 100%, but it gives a great idea of the “just the right amount” that I was talking about earlier.
  • This is a decent video, it starts off slow, but he explains things well in a visual manner.

Again, don’t spend too much time worrying about how the process should work. Instead, focus on practicing as you pick apart toy problems. Also, pseudocode whenever you’re working on a new app.

Whiteboarding

Whiteboarding is the behemoth. It scares people, brings tears, and crushes confidence. I’ve seen many great programmers terrified when they step up to a whiteboard. Speaking your thought process out loud, while being forced to solve a problem, without a debugger, will immediately highlight the chinks in your armor of understanding.

Thankfully, there is a proven method. I have several links for you to read or watch and then it’s time to get your hands dirty! Practice either in front of your computer or phone camera, or even better in front of a friend or loved one. You want to be able to explain the question so that anyone can understand it.

Remember to ask as many questions as you need. The goal of watching you whiteboard, from an interviewer’s perspective, is to see how you problem solve. They want to know if you can explain your ideas. And, more importantly, they want to see how you handle getting stuck or not knowing an answer.

It’s easier said than done. Here’s my process:

  1. Split the whiteboard into three sections, mentally. The first section is for your note — inputs, outputs, problem-solving strategy, key info, diagrams. The second is for your pseudocode. The third is for your actual code. I usually keep any diagrams in the first section, some people put it into the second along with pseudocode. Either is fine. You want to have one section of just code though.
  2. Fill out the first section by asking questions. Make sure you get any relevant information and a sense of what kind of strategy is necessary . Is this a recursion problem? A while loop?
  3. Draw some diagrams — usually the data structure associated and how it changes over time. Add some edge cases too.
  4. Pseudocode and ask questions. If you know this isn’t the optimal solution then say so. It’s fine to you say “I know there’s a constant time way to do this, I don’t remember it off the top of my head. So can I solve it linearly and then we can work on refactoring together?” Get feedback on your pseudocode.
  5. Once they approve your strategy, then go ahead and write code. This is your last step. You want a clear solution to the problem before you start down this path. This is why having a good problem-solving process is so important!

There are almost too many good resources on whiteboarding. I’m so happy they exist! Here are my favorites:

  • A great overview from SkillCrush. This is a good starting point before diving into video content.
  • Here’s a visual version (with some different wording) of what I described earlier in a blog post. I like the tests section — it’s not something I normally do, but it’s great for some types of problems.
  • Irfan has a youtube channel with lots of whiteboarding solutions.
  • Here’s the author of Cracking the Coding Interview solving a full problem. Pay close attention to how she describes her process.
  • I like YK’s youtube channel a lot. He has great explanations and whiteboards everything out. It isn’t exactly job-interview style, but his presentations are effective.

If you find any resources you enjoy, let me know. This is an area that people struggle with because of how hard it is to think, draw, write, and speak all at once. It’s likely you’ll find materials that click for the areas you struggle with.


What to Expect on the Day of Your Technical Interview

It’s the night before your interview and you are lying in bed imagining what the next day will be like. How do you know? Sometimes a recruiter will tell you ahead of time — you will meet with 4 people for an hour each, for example. Often, it’s a half a day or a full day. How do you handle this?

At least two days before your interview, you should ask what to expect. Ask if there are specific topics you should study and what style of interviews you will be having.

Companies typically have three different types of interviews, although sometimes two types are combined. These are:

  1. A pure technical interview. During this session you will be either pair programming, or in front of a whiteboard with an engineer. The interviewers are assessing what it would be like to work with you. They want to hear your thought process to see how you solve problems, and they want to know how you handle stress and struggle. Remember to breathe during these and say “I don’t know, but…” when you aren’t sure what to do — this is better than pretending.
  2. A pure soft skills interview. This session could be with HR or a manager. They are assessing what type of person you are, your motivations and drives. The goal for this session is to see how you will handle difficult situations and how you have handled them in the past. They want to answer the question, “Who are you at work?”
  3. A culture fit interview. This is often over lunch, or sometimes over a beer. This is the classic would I like this person enough to work with them for 40 hours a week test! Relax during these, share your passions and smile. The goal isn’t to dazzle the person, but to be a normal human who is excited about life (this can be code-related side projects or things like books, video games, travel, or fitness). Be an excited version of yourself and ask them questions to understand their passions.

There are several good resources for these, but practicing in person is the best way to lose the jitters. Remember not to brag or show off — be humble and caring.

My favorite resources are:


Conclusion

I want to stress this. People often limit themselves falsely. I hear things like “I’m bad at math”, or “interviews are too scary”. I get it. It can feel that way. Those negative thoughts are all self-talk though.

I have watched so many individuals from so many different walks of life completely change their careers. People who I didn’t think could make it have proven me wrong enough times that I don’t think this way anymore.

It comes down to two things: how bad you want it and how hard you are willing to work. If you are willing to put in the hours and push yourself to meet people outside of your comfort zone, you will look back a year from now with pride.

I have seen people find a job in as little as 6 months, if they were willing to sacrifice everything else. I’ve also seen people with kids and a lot of life responsibilities do it in 18 months. working nights and occasional weekends.

I believe that anyone can do this. A large part of why I love working with people in this capacity is the sense of empowerment that comes from learning tech. It has a mystique. Your parents and grandparents will look at you as a different person. You will have a superpower.

If you want to learn more about me or my journey come check out my personal site at nickfredman.com. I managed and worked alongside engineers for over a decade before I learned how to build web apps. I’ve built my own teams several times, and I am passionate about leveling up engineers (and humans!) I talk at conferences and at companies. If you have any questions please reach out!

Thanks for reading this far. If you have any resources to add, find any typos or have further questions please let me know! Great luck on this journey.

Better Programming

Advice for programmers.

Nick Fredman

Written by

Blogger at www.nickfredman.com

Better Programming

Advice for programmers.

More From Medium

More from Better Programming

More from Better Programming

More from Better Programming

The Zero-Dollar Infrastructure Stack

1.2K

More from Better Programming

More from Better Programming

Fun Side Projects That You Can Build Today

3.1K

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade