Several years ago I was working for a startup as a Director of Sales Engineering. I walked into work one day and had a thumb drive with our product demo placed into my hand. I now owned the demo, and the code, and would need 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.
However, I didn’t have the practical skills to do the work. I was a project manager. I was a sales guy. I wasn’t a developer.
I’ve worked in tech since 2005. I got my start in the video game world as a Producer and 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 had been acquired, I had an MBA, and I’d started my own Mobile App consulting firm. I had been part of hiring and managing our remote teams in the game world, and applied the same principles to my own company.
For the next 8 years I managed teams and hired engineers. I dabbled in coding, then started 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 (we’re 9AM-8PM, 6 days a week!).
I want everyone to have a guide for their 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’re learning all of the necessary skills.
Everyone can learn to code, yes, everyone.
My mission is to empower as many people who want a challenging and rewarding career shift. If you want to learn more about me check out my personal site at www.nickfredman.com
Let me know if you have any questions! And if you find other amazing resources please share them with me. I’d like this to be a living document. 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.
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’ve taken and believe in. There are a couple of affiliate links below.
There’s an 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 too deep into the struggle zone!
Overview Of The 4 Sections Of This Post
- 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.
- 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 about how humans learn new skills.
I will cover resources and tips I’ve seen 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.
- Learning to code – You have to learn to make websites and apps. Period. The only way to learn this is by doing it.
- The job hunting process – I’m going to cover it all. From making your resume, what developer skills you’ll need to have, technical interviews, and white boarding.
One of the hardest things about becoming an entry level software engineer is the actual process of finding the job. It can take 3-6 months after 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 different than 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 weeks will be a mix of a few different activities. There will be meetings, this is a reality of the corporate world. Likely, you’ll go over what you’re working on, plan for future work, explain past work, and show off or test the product with users.
Additionally, you’ll spend time coding. You’ll need to defend this time as it is sacred. Block this out, get some good noise cancelling headphones, and create a strong habit.
You’ll 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’ll 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 you reach a certain point you know most of the things.
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’ve never seen one that humbles the greatest minds with such ease.
Being smart is irrelevant a lot of the time. You need to be constantly learning new technology, and 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 work with the exact same technology.
This requires a total mental shift, which I’ll cover in the next section.
The other questions people tend to have are things like:
- How much does a software engineer make? Or what is a software developer’s salary?
This is tough to answer, but I’ll give some rough guidelines. The most important is that it depends on the market you’re looking in. I’ll give a rough idea of what you can expect as a starting salary and as a starting hourly rate if you go that way.
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.
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 specifically look for an internship or find a job at your dream company, I wouldn’t accept less than $65k for your first job. Your skillset is frankly too valuable.
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 of an offer.
I’m planning to write some future in-depth posts on this topic, I’ll link them when I finish if this is something people would like me to discuss further.
Lastly, what about working in Europe or somewhere more remote like Thailand? It completely depends on the company and the market then.
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 chance to keep growing. I recommend talking to friends and looking on GlassDoor to see what similar companies tend to pay.
- What does junior software engineer vs. senior software engineer mean?
This is a wonderfully arbitrary question. In a nutshell, it 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 at 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 a-ok. It’s great practice!
- How do I find a software engineering internship or entry-level job?
I’m so glad you asked! I have another post I’m working on to go deep into this. Check out the last piece of the guide below. 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. And if you can’t do it in person, phone calls are a great second option. You’ll often be able to 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 article (or the potatoes, for you veggies out there)! The question here is why should you develop a growth mindset? And what does this 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’ve ever spent more than 2 hours programming in a given day without needing to Google something. I have to do it constantly. I’m often stuck, or forget something, or I have a typo somewhere and miss it because I didn’t get enough sleep.
I choose to not get down on myself for not knowing things because I’ve 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. It’s total crap. 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 a learned behavior and not innate.
As a kid I enjoyed messing with 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 this piss me off? Sure it did. Did I give up after? Did I break the VCR in a fit of rage, chucking it out the window into our snowy back yard? Nope. I wanted to once or twice, but in general I didn’t care. I wasn’t ever 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 over night, 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 wouldn’t have enjoyed the process. 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 some fear around an area and aren’t willing to play and fail. When it comes to coding, 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 designed the internet as a whole? What their motivations were? The constraints at that point in time? No. 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 that makes sense for you to believe your code will work. It’s based on your experience in the world. It 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!
One of the core models we teach students is 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. This 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. It’s difficult to find a roadmap. And 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.
This doesn’t mean 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 gooooood!
I’ll remind you about this again later, but seek the Green Zone. Learn to cultivate the awareness of when you’re in the Red Zone. This doesn’t mean giving up when something is a challenge. 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 for people is to either read a whole book or watch an entire tutorial, then try a thing. An almost as common path is to follow along with this book or tutorial. Writing the code you’re 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 or do a thing, 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 doing the thing you want to learn until you get stuck.
- Once you get stuck (spend 20-30 minutes without making any progress) it’s time to get help. Your options are to find the place in the book or the area 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 this! Your goal is not to type the things that someone else wants you to type. It’s to understand why they want you to type those things! When you understand the why, you’ll be unstuck. Viola!
- 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.
A. 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.
B. The technology you are attempting to learn is built on multiple different 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 pieces. I would recommend you learn how to make shrimp first, or properly sauté veggies, and then step up to the whole dish.
Software development works the exact same way. If you are tackling something that’s too far outside where you are now there are two options. You either need to scale back to something easier, or get some serious help from a mentor or friend who is further along. This is okay! I still ask for help all the time. I encourage you to as well, they might even have an idea of a better project for you.
Find A Mentor And A Community
My last chunk of advice for 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, like a friend or a relative. This doesn’t need to be your daily resource for help, but rather someone to talk to when you’re feeling low or need guidance on what to do next.
A big 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 absolute best way to check if you understand something is to teach it to another person. This is hard.
It will also get you to practice technical communication, one of the critical job seeking skills. In a nutshell, this is your ability to talk about code and technology using the 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. As part of launching this post I’ve created a Slack Community for people learning to code who are seeking a job. Check it out here.
Common Pitfalls (and how to avoid them)
- Coding alone too much – for the reasons listed above it is so important to find others to code with. I suggest using meetup.org, asking friends / family, or looking for an online community. In person is the best, but 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 kinda 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’re in the focused mode when reading or coding. You’re in the diffuse mode when in the shower or taking a walk – it’s that feeling of day dreaming. 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 faster and I can’t recommend them enough.
- Everyone gets imposter syndrome. This is the moment where you doubt yourself and think I can’t do this, why am I even here? At some point or another you’ll likely question your ability. Even after making an app you may look back and feel like you got lucky. This is okay. Acknowledge it. Then move on.
Don’t let the feeling change your actions, the goal is to realize that you’re feeling this way. Feel free to tell a friend or a loved one. Make sure to take a break and reward the awareness of this thought process. You’re not an imposter. Everyone can learn to do this, it takes time and commitment.
After each section I’m going to list the resources I’ve mentioned or think are relevant. I don’t want to overwhelm you. Work through them as you have time, they largely build off of each other. If you feel you’ve mastered a concept in any given section then move on to the next resource. Be honest with yourself though. All, yes, 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.
- Carol Dweck’s book: Mindset
- Learning How To Learn course on Coursera, there’s a companion book if you want to dig deeper: Here
- Mark Manson’s book — I think it can help during the actual job search when you’re dealing with a lot of rejection
Learn To Code
This section is a beast. Since you’ll be tested on your ability to code. A lot of your confidence on the job will come from your actual skills. This isn’t the only thing you need to learn though.
Too many guides to becoming a software developer focus only only on this section. Thankfully, there are a lot of amazing resources out there to use for learning to code. My goal is to give you an order to your learning. And to point you in the direction of what I’ve seen as the best resources.
I want to re-iterate something I said earlier. Your fingers and your brain have to do the work. Reading books or blogs, watching videos, or doing code-alongs won’t actually 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. And you should be able to explain this model to a friend or an interviewer. Google 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. But take a lot of breaks. This is a marathon, not a sprint to learn something. Naps are great too!
Whenever you can’t figure something out after a couple of attempts it’s time to ask for help online. Do your best to learn it on your own first (you don’t want to get over-dependent on help from others). But, don’t feel bad or stupid or dumb if you can’t understand something. That’s OK.
Remember that your mental model, right now, is quite different from the mental model of the person who created this piece of tech. Big deal. None of it is a reflection on who you are as a person.
Before you begin on this journey, here’s what I want you to buy or download (today or tomorrow!):
- A whiteboard and dry erase markers
- Sticky notes and flash cards (or a flash card app to practice terminology – I like Anki)
- A small tripod for your phone so you can record video
- An account on zoom (or practice using quicktime to record video if on a Mac) – don’t spend money on this
- VS Code – and get the Bracket Pair Colorizer plugin
You’ll use these tools to help you practice along the way. Whiteboard out concepts often! There’s a whole section on whiteboarding below. Use notes and flash cards 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.
What Programming Language Should I Learn First?
Why not 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.
Overview Of The 8 Areas To Learn
- 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.
- Frontend: React – I’m going to recommend you learn React as your first frontend framework. This will power what your users see of your application.
- Servers: Node/Express – 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 to master them.
- Dbs: MySql, Postgres, Mongo, & Redis – 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.
- DevOps Lite: Travis, Docker, Heroku, & AWS – 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.
- Developer Tools: Git, CLI, Testing – these don’t exactly fit into any other bucket, but are daily used parts of your tool belt. We’ll go over how I recommend learning these before you show up at work your first day and feel 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, and it isn’t something 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 of the major areas of how the internet works in 5 minute videos.
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 over view 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 child-like sense of play.
HTML works like a non-fiction book works. There are words on the page and sometimes images. There’s 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:
- 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.
- Collect data from your users. These are forms, fields, and inputs that take in things like a username / 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.
- Connect your website to other sites. This is 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 the text within. It answers questions such as… “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 learning how to select individual elements and how to layout a whole page.
I suggest you keep practicing it bit-by-bit over time. Whenever you make a new app spend some time trying a different part of CSS out 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!
Resources For Learning HTML & CSS
- 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 here.
- Udacity has a great video series on learning HTML and CSS.
- At this point I would 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 okay! 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, and the CSS Tricks site for Flexbox and Grid.
- To practice both layout tools I would use them in projects going forward. Play around with Flexbox Froggy and Grid Garden.
That’s it. Okay, maybe it’s not quite that easy, but that is my advice. The sooner you can apply something you’ve learned into any kind of project, the faster you will master it.
Your mission for this phase and the next one is to make and break things. Ask yourself every hour or two, “What have I broken to test my understanding recently?” I want you to be comfortable breaking your code to test assumptions.
Cultivate a sense of being a tinkerer during this phase. 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 during a job interview!
Everything we do will tie back to this central goal. You can be asking, “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 fine starting point, but you’ll need more hands-on practice to master the basics.
- Use MDN as your resource anytime you’re stuck when 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 in. Save the harder ones for later, we’ll come back to them during the job prep section.
- As a last resort, I’ll say you can use Codecademy. It’s too easy to type without learning!
You’re ready to move on to the advanced section when you feel able to demonstrate these three things:
- You can manipulate the data in Objects and Arrays comfortably.
- You can create and pass around Functions to other Functions.
- You’re comfortable explaining what your code is doing to someone who doesn’t know how to code!
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 patters
- Closure and Scope
- Dom manipulation
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!
- I am a huge fan of the Fun Fun Function channel on YouTube. He has 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 here.
- 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 fantastic too. He also 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 for how to whiteboard difficult concepts that I’ve found. It’s 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! In general I am a huge FEM fan, and Will runs a coding school which has some great materials I will be linking later.
- 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 it in a way that students have found helpful.
- For ES6, I enjoyed Stephen Grider’s ES6 Course. He makes a TON 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? Only 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.
What Is A Frontend Framework?
Before I start listing out the ways I recommend you study React, let’s talk about what problem they solve. Up to this point you’ve been writing code, for yourself, in local files or in the browser. This is fine for getting started. At some point you’ll want people all over the world to have access to your code.
More importantly, you’re going to want their experience to be the same (or almost the same) regardless of their browser or operating system. Also, you 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 super-power 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 this up method of practice for one reason. Your ability to verbally communicate your technical understanding will be crucial for job interviews. It only comes via practice!
Resources For Learning React
- 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.
- 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. I’d 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’ll feel like you have superpowers! Writing server code usually seems like the hardest or 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.
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!
One of the main challenges in learning Node is that you’ll be dealing with a lot of asynchronous code. This is why we spent so much time learning it during the Advanced JS section above! If you feel rusty on about callbacks and promises go back and practice.
Another big challenge is learning to understand NPM. Node Package Manager 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. Yet, it means you’re adding a lot of code without understanding what it actually does. When you’re still 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’ll begin to see the same packages used a lot. Your understanding of how they are written will improve. This won’t happen over night, but it’s worth the exposure, so start early.
One piece of caution: I highly recommend that you use Node Version Manager or NVM for short, to install Node. It takes a tiny bit more work to set up, but will make your life so much easier in the long run.
Resources For Learn Node and Express
- 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’ve noticed during 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. I’d spend time looking through the Express docs for a few tutorials on routing and middleware. The concept of middleware can be a bit challenging. It’s powerful though: 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 few topics you should understand during 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:
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 async code! This is a challenge, and it’s 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 easy or hard, that make networking & 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 during the networking and interviews section down below.
At this point you want to be in “play” mode. You should start keeping a dev journal if you aren’t already. 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 setup and can treat your data differently. Remember that you’ll be use 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, DBs 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 trouble shoot when things don’t work the way you’d 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 means it’s something other than SQL.
There are tradeoffs for using different databases. 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 cacheing is important. People love checking your understanding of it during system design questions in an interview.
Resources For Learning Databases
- 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 aaaamazing!
- Postgres docs – these are actually a solid reference, I use them often.
- Pg package on NPM, fantastic package with great docs.
- This is a long, but fantastic free course on Posgres from freeCodeCamp.org.
- I don’t think you need to pay for any database specific courses. Some of 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.
- And one from the Redis team.
- Again, there’s LOTS of free DB content. Paying isn’t necessary unless you want to go deep on 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 (Or At Least Enough To Be Dangerous)
Developer Operations is a mighty deep topic. I still consider myself a novice in this area and I’d put most of the developers I know in this category as well. 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 creates 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. During an interview, when you identify the interviewer is creating one of these problem, you’ll know the answer they are looking for.
As an aside, 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 then I’d explore further.
Resources For Learning Dev Ops Lite
- Webpack – the go-to bundler at the moment. Webpack is used on the frontend and backend of many projects. It’s 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. These are a fantastic entry into the how’s and why’s of Webpack. Be wary of Medium articles (make sure you’re looking at Webpack 4 and Babel 7)!
- 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.
- Travis CI: At some point you’ll start to 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.
It’s also a good idea to make sure you lint your code. You also need keys to deploy, and maybe want 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….and you can see where this is going!
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.
- 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.
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’d prefer something visual. The tutorial above shows you how to do it with AWS as well.
Additionally, one of my students wrote a fantastic tutorial about 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)
You shouldn’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 every day 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’re rarely asked direct questions about 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 some practice.
Learn The Command Line
Hopefully, you’ve already spent some time learning the 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’m still working through all the content, but I’ve learned an insane amount from this course. This depth of understanding isn’t required for a junior dev. It can be pretty amazing to see how powerful your OS is, though!
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 too. 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 though. That’s okay.
Start a project with a buddy and try messing up the code. Break things and google how to fix them. When you start to feel comfortable after a couple of days 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!
Learn To Use SSH
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.
Learn To Test Your Code
The last section of this part is testing. Testing is incredibly important, and I would add tests to any code challenge for a job application that doesn’t already include them. There are a lot of methodologies and tools related to testing.
My suggestion is that you go back to the apps you’ve been building for the last few months and begin adding tests to them! This Medium Post is a beast. It provides a well-written and comprehensive guide to testing. I would work through it by researching the different styles of testing listed inside and adding them to projects.
You’ll want to 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 going forward.
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
Overall Timeline And What To Expect When Job Hunting
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 misbelief that looks like this…If you study hard and learn how to code you will get a job. Poof! Anyone who has tried this before knows that it doesn’t work this 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. And, I 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 looks like. How you approach a problem you haven’t seen before, and how you’ll 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 okay! You’re interviewing for jobs that will pay from $75,000 to well over $100,000 a year! This is a large pay increase from whatever you were doing before for most people. 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 during this phase. 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 white boarding and further developing your verbal problem-solving process. The last section is hitting the pavement and 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 imposter syndrome, the second I call good enough syndrome.
What is imposter syndrome?
Here’s a great TED talk on it. Almost everyone suffers from it at one or many points during this journey. You’ll talk to someone who knows so much more than you. This makes you feel like a fraud. Or you’ll get stuck on a problem and believe you’ll never be smart enough to solve it. Both of these thought patterns are a trap. //insert it’s a trap image
Your knowledge is a current snapshot in time. It’s what you know today. No one knows everything. There are no natural genius people out there who came out of the womb understanding how to talk to computers. Learning how a system works may be easier for someone, but what they know today is still a single snapshot.
Your challenge, in moments of self-doubt is two-fold.
- Gain awareness that you’re doubting yourself and your abilities right now. 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. Move your body when you’re feeling this way instead of wallowing.
- Take action. Accept where you currently are and take action to change this. Maybe that means asking a friend how you could’ve 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 imposter syndrome during your job hunt. Make your peace with this now and write down ahead of time what you’ll do when you begin to feel this way. If you come up with a strategy now, before it happens, it’ll 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.
What is good enough syndrome?
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. It’s 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. I need to polish my LinkedIn profile more too.” Next thing, you’ve talked yourself out of even applying for the job for three months until everything is perfect.
There is no perfect. There’s just 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 still apply for jobs and see what happens. There is no magical point in the future where you’ll have all the skills and experience required for your first job.
This is a fantasy that’s 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 this. You’ll be amazed at what happens when you try hard.
Does this mean you’ll 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.
Let’s say you’re going to need 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 first paycheck!) by an entire month.
I have one last ask 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’ll have a target. 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.
You should 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. Use their online presence as a template for your own.
Sample Timeline For Finding Your First Job
- 5-6 months of nothing but coding! At first have this 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.
You’ll also meet people who could open the door to your first job through one of these groups.
- 2 weeks of putting your job application materials together. This means your resume, CV, LinkedIn, AngelList profile, and if you want a personal site then this too. Don’t spend more than 2 weeks getting all your materials ready. You’ll have to iterate on them with feedback later.
- 2 days of practicing whiteboarding and problem solving with algorithmic-type questions. I’m going to have you spend a lot more time studying these, 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.
- 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.
This includes coffee info sessions and meetup groups. During this time you’ll also be learning to whiteboard Data Structures and Algorithms. You’ll split your time between the two each day.
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 and people in their 60s as well.
How To Learn Algorithms And Data Structures
Before you work through any of the resources in this section, I want you to create a GitHub Repo to use. It’s a great idea to track the work you’re doing here and to 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 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.
- 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.
- 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.
- THE classic tome, if you have patience and want a lot of exercises this is a great one – Introduction To Algorithms.
- 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.
- 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. Either one is great. And you can always pull up YouTube when you need help with a specific algo or data structure. If you haven’t seen the sorting dancers before, then you haven’t lived!
- A small final note. If you want to learn Python, this is a fantastic time to dig in. 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 is a challenging section to write for a variety of reasons. The largest being that I don’t know your background and prior experience! I’ll recommend some general dos and don’ts. I’ll also cover what I see as the most common mistakes that people tend to make.
- Write about the recent projects you’ve created — it’s okay if they aren’t all deployed. The two or three that you’re the most proud of are fine. Create a section titled Recent Applications for this. If you’ve been creating something with friends this is a perfect place for it.
- Cover your skills clearly. If you feel confident at React, Node/Express, and Docker, then list them at the top of your resume. Topics like REST and OOP count here too.
To get a feeling for what these topics should be use the research from 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.
- List any relevant work experience. Have you worked along-side 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.
- Use a clean and simple format. Something from Google Docs, Canva, or Apple Pages is fine. I generally don’t recommend Microsoft Word because it can be hard to format, but if you’re a wizard this is fine too.
Save a PDF version. You’ll likely be emailing it or uploading to an Applicant Tracking System that a bot will read and analyze. You need clear keywords that are easy to scan.
- 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.
Here’s an example:
Composed over 300 unit tests with Jest to allow comprehensive refactor of XYZ component for V2 of the app .
If you can be specific this is great. I know it’s hard sometimes, and not possible for others.
- Include a link to your Github, LinkedIn, your email address, your current address, and phone number.
- Refactor your resume so that it’s relevant to an actual job posting that you’re applying for. Look at the Keywords the post is seeking. If you have these skills make sure to highlight them!
It’s fine to have several versions of your resume and it’s a shame to only have one generic version. Put in the effort here.
- 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, don’t get defensive. You’ll have a mix of technical and non-technical folks reading your resume as you apply for jobs – remember this.
- 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, less is more in this area though.
- Don’t use meters, graphs, or charts to show your skills. It’s completely 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.
- 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.
- 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.
- Don’t be goofy or funny on your resume. Sometimes people have success with this, but its hard and not a general tact I would take. 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 😉 .
- Don’t go crazy on the formatting. Remember that a machine may have to read your resume. 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.
- 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.
- 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.
- 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. I know it takes a little while, but you’ll get a few templates that you can use for future applications.
How To Use LinkedIn To Find Your First Software Engineering Job
There are going to be 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’ll explain it in detail.
I’m not going to give you a lot of rules for this section like I did for writing your resume. Instead, I urge you to find some developers you respect (like ones that work at your target companies!) and copy the format of one you find appealing. You don’t need it 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. You’re going to use this as a resource for cold-messaging people to grab coffee, and as such you want to seem normal. Use a nice photo, and write a little about yourself up top.
I’d encourage you not to use things like seeking a new job, but instead put Software Engineer as your title. List the projects you’ve been recently building and highlight the technology used.
A quick note about recruiters — there are two kinds 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, and they will know about the technology you work on and represent a company that interests you. Many don’t have a strong enough grasp on technology.
How To Meet People Through LinkedIn
My ask for you in this section is likely going to push you outside of your comfort zone. People will hire you because they’ve connected with you as a person. This means that your first software engineering role is most likely going to come because you’ve 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 with you is an art form. It will take some practice. That’s okay — it’s an area where you shouldn’t expect immediate results. And 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 and 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 can offer to help out on a project, but I would wait to do that until you’ve met.
- Reach out to anyone in the engineering department at 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 — focus the call and meeting on 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 okay.
- Test several different messages to find one or two that work the best!
Your willingness to go outside of 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 you submitting it online. You should still submit resumes online too, but focus more on meeting people.
Job Application Sites
This is a list of what I’ve seen as the best sites for people finding their first software engineering job. Use different search terms — some companies will call a role a software developer or a UI engineer. Focus on the technology and skills the company is looking for and apply to anything you’re around 50% qualified for. 15% – 25% of my students end up with senior roles. It’ll 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, 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, always look up any information you can find on a company through this site, they also have job postings too.
Ways To Prepare For In-Person Technical Interviews
There are three different hard-skill areas you’ll need to practice to excel at in-person technical interviews. These are demonstrating your problem solving strategy, how to pseudocode, and how to whiteboard.
Most likely you don’t have a repeatable process for any of these three areas, but if you do give yourself a big 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 great.
Then there’s your soft-skills. You need to 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, it means you need to practice more.
How To Develop A Problem-Solving Strategy
One of the most overlooked areas of practice is in your problem-solving strategy itself. 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 a lot of your work will be on auto-pilot.
This second piece can be a bit weird to explain, but it’s like driving a car. It’s much harder to get from your house to the grocery store if every time you sit behind the wheel of a car it’s your first time driving all over again. It’s kind of like driving a rental car in a foreign country.
Thankfully, this isn’t necessary. There’s a repeatable strategy you can use for approaching any new problem. My guess is that right now you:
- Read the problem once.
- Try a solution.
- Try to fix it for awhile 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):
- Read the problem and write down all important information.
- Think about if you are missing any information, if so re-read the problem.
- Draw a few quick sketches using sample data — 2 or 3 (or more if you can see potential for edge cases).
- Break the problem into chunks, see where you can use helper functions.
- Write pseudocode.
- Write code & debug.
- Clean up your code.
I’ve 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’ve missed something during your initial read through. This often saves 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 psuedocoding feel awkward your first several times. It gets easier.
- Here’s a good article explaining problem solving at an abstract level (with a solid description of debugging).
- This is a longer article that I like a lot with an example broken down .
- I also like this short slideshow on problem solving.
- Here’s another framework, it’s a little different from mine but you may find it clicks, the goal is to find something that works for you.
Spend a day or two experimenting, but not longer than that. The goal is to find a process you enjoy and then practice it. Over the next few months it’ll 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’ll find you get stuck less because you’ve worked through the problem down to smaller chunks ahead of time.
As with the other skills here it will take practice. It usually feels a bit awkward. Finding the balance between writing vaguely and writing too specific is a classic Goldilocks story. You goal is to write pseudocode that breaks the problem down into logical chunks, and to explain the control flow of each.
Does these mean you need to name variables? Parameters? 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. Here’s what I recommend looking through:
- Geeks4Geeks is a great site that has a huge amount 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, I wouldn’t spend too much time worrying about how the process shouldwork. Instead, focus on practicing as you pick apart toy problems. I’d also pseudocode whenever you’re working on a new app.
Whiteboarding is the behemoth. It scares people. It 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 highlight any chinks in your armor of understanding.
Thankfully, there is a proven method to practice. I have several links for you to read/watch, and then it’s time to get your hands (and fingers) dirty! Practice either in front of your computer/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 could 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:
- Split the whiteboard into three sections mentally. The first section is for your notes (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.
- Fill out the first section by asking questions. Make sure you get a sense for any relevant information and what kind of strategy is necessary — is this a recursion problem? A while loop?
- Draw some diagrams, usually the data structure associated and how it changes over time. Add some edge cases too.
- Psuedocode and ask questions — if you know this isn’t the optimal solution then say so. It’s fine if 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.
- 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, that’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 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 look like. How do you know? Sometimes a recruiter will tell you ahead of time you’ll meet with 4 people for an hour each. Often, it’s a block of time like 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’ll be having.
Companies typically have three different types of interviews, although sometimes two types are combined. These are:
- A pure technical interview — during this session you’ll be either pair programming or in front of a whiteboard with an engineer. They 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.
- A pure soft skills interview — this session could be with HR or a manager. They are assessing what type of person you are. They want to know your motivations and drives. The goal for this session is to see how you will handle difficult situations, and how you’ve handled them in the past. They want to answer the question, “Who are you at work?”
- 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 questions of those you are hanging with to understand their passions too.
There are several good resources for these, but practicing in person is the best way to get rid of the jitters. Remember not to brag or show off. Be humble and caring.
My favorite resources are:
- A long and great resource covering most aspects of the TI — this is a good starting place to get an overview of everything.
- Interview Cake is fantastic, so much good content, here’s a second great article from them.
- A good resource on soft skills questions.
- A monster GitHub repo with frontend job questions to practice.
- Another monster GitHub resource with full stack questions to practice – these are broad, but can help if you need to understand new tech for the job.
You Can Do This
I want to stress that. 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. These negative thoughts are all self-talk though.
I’ve 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’re willing to work. If you’re willing to put in the hours and push yourself to meet people outside of your comfort zone, you’ll look back a year from now with pride.
I’ve seen people find a job in as little as 6 months, if were willing to sacrifice everything else. I’ve also seen people with kids and a lot of life responsibilities do it in 18 months on 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’ll have a superpower.
Slack Group Invite
If you want to join other people on this journey to ask questions, gain support, and feel a sense of community, then I recommend you join my private slack group. I charge a fee to join, because I want it to be active and I want committed users. I ran a free group for awhile and I’ve found that the engagement has improved dramatically now that I charge.
There’s something powerful about not feeling alone during this journey, and I want everyone to have that feeling.
If you want to learn more about me or my journey come check out my personal site atnickfredman.com. I managed and worked along side 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.
If you found this article helpful please give it some claps and share it with any of your friends or loved ones who are on this journey too!