fbpx

Additional menu

NickFredman.com

Learn To Code and Get Your First Developer Job

The Ultimate Guide to Learning to Code and Getting Paid – Part 5: Job Hunting

This is Part 5 of a 5 Part Series. If you want one of the other parts:
Part 1
Part 2
Part 3
Part 4

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

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

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

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

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

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

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

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

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

Common Traps and How to Avoid Them

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

What is imposter syndrome?

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

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

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

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

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

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

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

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

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

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

I have one last suggestion before we dig in. Choose 3–5 target companies before you proceed with the next steps. Even if you don’t end up working at one of them, you will have a target to aim for.

Why is this important? 

You can research what types of interview questions they ask, you can check the LinkedIn/AngelList (and sometimes resumes) of the people they’ve hired recently. Use their current employees as a measuring stick. 

This doesn’t mean you should feel bad about all the things they’ve done that you haven’t, instead use their online presence as a template for your own.

Sample Timeline for Finding Your First Job

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

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

How to Learn Algorithms and Data Structures

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

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

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

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

How to Write a Technical Resume

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

Dos:

  1. Write about recent projects you have created — it’s okay if they aren’t all deployed. The two or three that you are most proud of are fine. Create a section titled Recent Applications for this. If you have been creating something with friends this is a perfect place for it.
  2. Cover your skills clearly. If you feel confident in React, Node/Express, and Docker, then list them at the top of your resume. Topics like REST and OOP count here too.
  3. To get a feeling for these topics, research the companies you’re interested in working for. Look at the skills they are seeking in their job postings. Add the ones you know to your list.
  4. List any relevant work experience. Have you worked alongside developers before? Or maybe you made websites in high school? If you have none this is okay too, write any recent work experience, but don’t go overboard. You want to focus your resume on the applications you’ve been building.
  5. Use a clean and simple format — something from Google Docs, Canva, or Apple Pages is fine. I don’t generally recommend Microsoft Word because it can be hard to format, but if you’re a wizard this is fine too.
  6. Save a PDF version as you will probably be emailing it or uploading to an Applicant Tracking System that a bot will first read and analyze. You need clear keywords that are easy to scan.
  7. Write 2–4 bullet points per project. Same goes for prior work experience. These bullet points should follow this general format:

    |Action Verb| some technical thing |so that / in order to| add value or solve a specific problem.
  8. Here’s an example: Composed over 300 unit tests with Jest to allow comprehensive refactor of XYZ component for V2 of the app.
  9. If you can be specific — great. I know it’s hard sometimes, and will not be possible for some.
  10. Include a link to your Github, LinkedIn, your email address, your current address, and phone number.
  11. Make your resume relevant to the job posting you’re applying for. Look at the Keywords the post is seeking — if you have those skills make sure to highlight them!
  12. It’s fine to have several versions of your resume and a shame to only have one generic version. Put in the effort!
  13. Share your resume with friends and family for their feedback, especially if you’re new to making one or have never worked in a “professional” capacity before. Take their feedback and don’t get defensive. Remember — there will be a mix of technical and non-technical people reading your resume as you apply for jobs.
  14. It’s okay to share a little of your personality on your resume, I wouldn’t go overboard though. Some hobbies or fun facts are okay, but less is more in this area.

Don’ts:

  1. Don’t use meters, graphs, or charts to show your skills. It’s irrelevant that you’re a 3.5 out of 5 on the React skill-o-meter. Either you have a skill and are fine being asked technical questions to show understanding, or you don’t. If you don’t, then don’t include it on your resume.
  2. Along the same lines, don’t list any skills you’re not familiar with. Don’t lie. Spend a weekend to learn a language or library if you want to list it on your resume.
  3. Don’t try to impress someone too hard. If you’re trying too much this will come across. Be sincere and subtle, list your accomplishments clearly.
  4. Don’t be goofy or funny on your resume. Sometimes people have success with this, but its hard and not a tack I would take in general. Let your personality come across in person. Developers aren’t known for reading between the lines well — that’s why we write so many comments!
  5. Don’t go crazy on the formatting. Remember that a machine may have to read it— if it can’t your resume goes in the trash!

How to Write a Technical CV or Cover Letter

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

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

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

How to Use LinkedIn to Find Your First Software Engineering Job

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

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

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

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

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

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

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

How to Meet People Through LinkedIn

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

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

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

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

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

Here are some basic rules for reaching out:

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

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

Job Application Sites

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

Here’s the list:

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

How to Prepare for In-Person Technical Interviews

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

  1. Demonstrating your problem-solving strategy
  2. How to pseudocode
  3. How to whiteboard

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

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

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

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

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

How to Develop a Problem-Solving Strategy

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

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

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

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

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

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

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

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

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

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

How to Write Pseudocode

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

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

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

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

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

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

Whiteboarding

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

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

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

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

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

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

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

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

What to Expect on the Day of Your Technical Interview

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

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

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

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

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

My favorite resources are:

Conclusion

You Can Do This

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

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

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

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

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

As always, let me know if you have any comments or questions about this post! I hope you enjoyed this series and it helps you along your journey.

Happy coding 🙂

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *