One of the hardest parts of beginning a career as a software developer is getting your first job or internship. This is doubly true if—like me—you came into programming later in life and don't yet have much experience outside of the classroom.

Just like in any field, after you've had your first programming job, that social proof makes it far easier to get the second, third, and fourth. But as someone just starting out, how do you get even one company to give you a chance?

In this article, I will share the process I used to go from worrying I would never get an offer anywhere to having companies fight over me, ultimately scoring an offer from my top-choice company in a matter of months.

Who am I to write this article?

When I was trying to get my first internship, I was convinced that no one would hire me. I didn't check off any of the boxes needed to get a cool tech job. I barely knew how to code and I had no relevant experience whatsoever.

I was not some programming savant. I was not that kid who gets suspended in middle school for hacking into the school computers and changing his grades. In fact, I had already been in college for a whole year before I even wrote my first line of code. A year and a half later, I had struggled through a handful of CS classes and gotten a C+ in Data Structures, only to find out that Data Structures was the only class interviewers cared about. At that point in time, the longest single piece of code I had ever written outside of school was 200 lines of bad Python that I wrote in a few afternoons.

To put it lightly, I felt extremely unqualified.

But, I knew that if I wanted to get a good job after school, I needed to have some internship experience. Somewhere. At least that's what I read on the internet. So, assuming that the odds were stacked against me, but determined not to live in my parents' basement after graduation, I did everything in my power to find an internship.

The end result?

A couple of very stressful months...and four offers. Including one from my top choice: a supercool, fast growing startup that was in the news and made software that dozens of my friends were using—an offer that I ultimately accepted.

Job Applications

Apply to a LOT of companies

Interviewing is a skill. Just like with any skill, you will get better with practice, so it's important to get as much practice as you possibly can.

To get this practice, I decided to apply to an absurd amount of companies. During my internship search, I applied to between 50 and 75 companies. Most either ignored me or turned me down without as much as a preliminary interview, and plenty ended up rejecting me after an interview or two. I'll admit this was discouraging. But despite the rejection, I kept on applying, because I knew that with every interview I got a little better.

I also knew that by sending out many applications, my chance of getting an offer from one of these companies was increasing. By how much? For simplicity let's pessimistically estimate that every time you apply to a company, your chance of eventually being hired by that company is about 1 in 25. With those odds, if you only apply to a single company, you have a depressingly low 4% chance of being hired. However, if you apply to 50 companies with the same likelihood of success, your chance of being hired by one of them rises to 87%.

What this calculation shows us is even if you never get any better at interviewing or applying to companies, you are still very likely to get a job if you just apply to enough places.

Add to this the fact that each interview will improve your interviewing skills and thus increase your chances of being hired in the future, and it becomes almost a statistical certainty that you will be hired somewhere.

So if you are just starting out in your career and you are not confident in your ability to get an offer, your best bet is to apply to the maximum number of companies your schedule and organizational capabilities will allow for.

Now you want these to still be high quality applications. Don't spam 1000 random companies with halfway filled-out applications. Choose your companies wisely (more on this below) and take the applications seriously. Fill out every box on every application. If an online application requires answering some short questions, decide whether this is still a company you want to apply to and if so, take some time to actually answer them.

Also be aware that none of those statistics mean anything if you are missing interviews, failing to respond to emails, or missing deadlines, so you are going to need to step up your organizational game in order to keep track of everything. During my internship search, I kept track of all the companies I was talking to in one giant spreadsheet.

If you want to do the same, then for each company, you should record:

• The company's name (duh)
• The name of the position you're interviewing for
• The city where you would be working
• A description of the job responsibilities and company culture based on the job posting and conversations with interviewers
• An outline of how their interview process works
• Your recruiter's name and contact information
• The last time you heard from them
• Your level of excitement about the position: high, medium, or low
• The city where the company is based
• The next step of the job interview process. This might be an interview or filling out some paperwork. If you are waiting on a response from your recruiter, the next step of the job interview process is for you to follow up with your recruiter in a week or two via email to make sure they don't forget you exist
• A due date for completing the next step
• Next interview date (if applicable)

Every day, update the spreadsheet with new actions you've taken or things you have learned and add any actions that are due soon to your to-do list for the next day. This will help make sure no opportunities slip through the cracks, and will also give you a sense of satisfaction and progress as you see yourself move forward with the interview process at more places.

Apply to a few companies you would be okay with working for, a few you would like to work for, and a few you would LOVE to work for

You want to apply to companies in all three of these tiers because your number one priority is making sure you get hired somewhere. Most of us want to work for a fun startup that works on interesting new problems and lavishes employees with free meals, high salaries, and quality-of-life perks. You should absolutely apply to some companies like that if that's what you want. But the hard truth is that you may not yet have the qualifications to get hired by your dream company, so you need to protect yourself against this chance by also applying to some less sexy companies that might be more likely to hire you.

Here's the trick: before you apply to a single company, assemble a huge list of all the companies you want to apply to. You can add more companies to the list later but try to make it as comprehensive as you can right now. Once you have this list, apply to the companies you are less excited about first, and try to schedule those interviews before your interviews with your dream companies. Scheduling your interviews like this serves two purposes:

1. It makes sure you actually apply to the companies you are less excited about, rather than getting hung up on one or two moonshots and then ending your job search months later with empty hands.
2. It hones your interviewing skills by letting you practice on the companies you won't mind being rejected from, so that you will be well-prepared and practiced when it comes time to interview with your moonshot companies.

It goes without saying that although I'm recommending you apply to some less-sexy companies, you should only apply to companies where you would seriously consider accepting a position. Applying anywhere you don't want to work for is a waste of time for everyone involved.

If you have access to a career fair or career center through your school, USE IT

When I was looking for my first internship, I applied to 30+ companies that I found online, and about 20 that I talked to at my college's career fair. However, more than 80% of my interviews were with the companies I met at the career fair, as were three out of the four offers I eventually received.

Why were the companies that I met at the career fair so much more interested in me than the ones I applied to online? I have a few theories.

First, nothing beats developing a personal connection with someone who works at the company. Even if you only talk for a few minutes, shaking someone's hand and meeting them in-person gives you a chance to make a lasting impression that you just don't have if you apply online.

Second, companies have a financial interest in hiring students they meet at career fairs. After all, the companies pay thousands of dollars for the right to set up booths at career fairs. They want something to show for that investment. As a result, companies are FAR more likely to interview candidates that they have met at career fairs, just so they can feel like the career fair was a good use of company resources.

Resume Building

There are a lot of great resources online about building your resume, so I won't dwell on this too much. That said, there are a few special considerations for someone applying to their first tech job.

Do a little work to make yourself seem like the kind of person who is codes in their free time.

Recruiters really want to hire people who code for fun, so you want to be able to market yourself as one of those people. Go to a hackathon or do some little side project that only takes a few afternoons. Put the code on GitHub as proof that you actually did it. List that you did these things on your resume.

I can't tell you how much having a side project and a hackathon on my resume has helped me. Numerous interviewers and recruiters have looked at my resume and commented approvingly. They usually say something like "We are always looking to hire people who are passionate enough about software to code in their free time, so it's great that you have a hackathon and a side project on here."

Weirdly, they still felt this way if I told them that my side project was less than 200 lines long and my hackathon project was an embarrassingly bad Craigslist clone that comprised 100% of my web development experience at the time. They didn't care, I still checked off the box.

It doesn't matter if what you code on the side is good or complicated. It just matters that you have done it and can talk about it.

You don't need to lie, you just need to market yourself.

Put a "skills" section near the top of your resume

Your actual skills as a programmer are what matters most. So have a section of your resume that enumerates the technologies you have worked with. List the languages and frameworks that you have used for projects in school. If you have taken a class on AI or something, list "Artificial Intelligence" on there. Just whatever you do, don't put Microsoft Office on there. No one cares.

This section should come before your work experience on your resume. Recruiters don't care if you worked the register at a Walmart in high school. They care if you know Java or MySql or Linux. Put the most important information near the top where it has the best chance of being seen.

Once you have a good first draft of your resume, ask your friends who have had tech jobs to read it and give you feedback. They have already gotten where you want to go so they have a good idea of what it takes to make a good resume.

Technical Interviews

Technical interviews can be very daunting at first. How are you supposed to write a program to solve a problem you've never seen before, in only 30 minutes or an hour? Fortunately, this is another skill that you can work on and develop, and the set of things you have to know in order to do well on these kinds of interviews is actually pretty small.

SUPER IMPORTANT: Study Data Structures

The secret with technical interviews is that 9/10 times the interviewer is not asking you some crazy complicated question that is impossible to prepare for. Generally, interviewers will give you a simple question that is easy to solve if you know the right data structure for the job. By solidifying your knowledge of data structures and the trade-offs between them, you can go into most interviews confident that you will be able to figure out the problem. This is doubly important if you didn't go to college for Computer Science or haven't yet taken such a class, but everyone could probably use some brushing up.

This was a big sticking point for me personally because, as I mentioned before, I did very poorly in my Data Structures class and somehow had managed to coast by without understanding the majority of the basic concepts. I addressed this weakness and turned it into a strength by making an enormous deck of data structure flashcards on Quizlet and running them every night for 15-30 minutes before bed. Within a matter of weeks I was able to solve the majority of questions I was asked in job interviews.

These are some of the concepts you need to know:

• All the common data structures. Arrays, linked lists (singly and doubly linked), hashmaps, trees, graphs, queues, stacks. You should understand these all abstractly and know about the tradeoffs between them in terms of Big O Complexity. It is essential that you also know how to use the built in versions of all of these data structures in the language you will be doing your technical interviews in. Interviewers don't care if you know what a hashmap is unless you know how to use one in practice.
• All things graphs. What is a graph? How can you represent it in memory? What are the different kinds of graphs? What are some common applications of graphs in the real world?
• Basic sorting algorithms. At least have a basic understanding of the differences in approach between bubble sort, merge sort, and quick sort.
• Know things about trees. What are the parts of a tree? How do you traverse trees (i.e. depth-first/breadth-first) and what are the trade offs between different approaches? What is a balanced tree (at a high level)? You should be especially comfortable with binary search trees (because interviewers love binary search trees for some reason).
• Recursion. What it is and what are some basic examples

The good news is that these things are all genuinely important and learning them will make you a much better programmer.

You should also understand some basics of Object Oriented Programming. Know what terms like inheritance, encapsulation, polymorphism, and composition mean and be able to fire off definitions for them at the drop of a hat.

Master these overused interview problems

Most interviewers have no creativity, and just ask the same standard problems that everyone else asks. This is actually a good thing (for us), because it means there are a few problems that come up over and over in a large percentage of job interviews.

These problems are not a good measure of your ability as a programmer, but for better or for worse your ability to solve them will have a dramatic effect on whether or not you get a job. What I'm saying is you need to learn how to do these problems in your sleep. The good news is that you can learn how to solve all of them in a week or two, and doing so will dramatically improve your chances of passing a technical interview and getting an offer somewhere.

Here's a list of problems you need to be able to solve at the minimum. I have personally been asked every one in at least 3 interviews each.

• Write an iterative function to print the nth digit of the Fibonacci sequence.
• Write a recursive function to print the nth digit of the Fibonacci sequence.
• Write a function to reverse a string.
• Write a function to reverse a linked list.
• Write a function to perform a depth-first search through a tree.
• Write a function to perform a breadth-first search through a tree.
• Write a function to check whether a number/string is a palindrome.
• Write a merge sort function.
• Implement a stack data structure with Push(), Pop(), and Peak() methods.
• Know how to solve this stupid marble-weighing problem that has nothing to do with programming.

You WILL be asked at least a few of these questions in technical interviews at some point. Each can be solved in less than 20 lines. Practice doing one or two of them a day on a whiteboard, then type your solution into a computer to make sure it runs. Repeat until you can do them all without thinking.

Learn how to solve technical interview problems more generally

Once you master the above problems, you should buy a book that walks you through solving a bunch of practice interview questions and groups them by subject, so that you can learn a system for tackling interview problems that you've never seen before. Your technical interview is by far the most important part of the job-search process—after all, they are considering hiring you for a position as a programmer. They are going to judge you based on how well you are able to program in front of them.

I have personally studied for technical interview problems by working through examples in Programming Interviews Exposed. It's a relatively short book full of practice questions. For each problem, the authors show you how you can find the solution and then give you the code for their final solution to analyze and compare with your own. I have used this book for practice during 3 job searches now. I swear by it and have read it cover-to-cover several times.

Another book that seems to be the standard is Cracking The Coding Interview. Many interviewers simply take questions out of it and ask those, so it is probably worth checking out, but I have not read it myself.

Once you have worked through one of these books, you will be ready for most interviews, but if you'd like you can continue developing your skills by doing problems on HackerRank or a similar site. Google also has a lot of amazing materials on preparing for interviews that you should absolutely check out.

I also recommend watching this video by Google, which teaches you how to communicate and ask questions during a technical interview. In these interviews, getting the right answer is not as important as communicating to the interviewer that you are willing and able to work through new problems methodically. There have been many times when I failed to find a solution to a technical interview question but still received an offer, just because I was able to communicate my thought process and show them all the ways I was trying to get unstuck.

Prepare before every interview

Preparation can make a the difference between an interview going well and it going just okay.

30 minutes before the interview: Run your data structure flash cards for 10 minutes to get yourself warmed up

20 minutes before the interview: Look the company up on wikipedia and read through the about page on their website. It is likely that the interviewer will at some point ask "Why do you want to work for this company?" or "What do you know about this company?" They ask this because nobody wants to work with someone who thinks of their occupation as just another job, so they are trying to screen out candidates who send out a million applications to companies that they don't know anything about. Interviewers want to find candidates who have some personal motivation for wanting to work at this specific company. A little quick research and preparation will help you pass this test, and also help you figure out if this is a company you actually want to work for

10 minutes before the interview: Jot down 3-5 questions that you can ask the interviewer at the end of the interview. Generally interviewers will give you a chance to ask questions, and if you don't have any questions ready it makes it look like you aren't that interested in the company. Taking the time to prepare a few questions ahead of time guarantees that this part of the interview will go well. A few questions that I have used myself:

• How can I expect the rest of the interview process to work if you decide to go forward with me as a candidate?
• Tell me more about the work your team does.
• What is your favorite thing about your job? What is your least favorite thing about your job?
• What tools do you use on a daily basis?
• After seeing my performance in this interview, do you have any reservations about me or my qualifications?

This last question serves two purposes. If they give you an answer, it helps you know what you can work to improve before your next interview. But even if they don't, it shows that you're someone who is open to constructive feedback and genuinely wants to grow. Companies want to hire determined people who constantly seek to improve, and asking this question helps show the interviewer that you are such a person.

Conclusion

It is not easy to get your first tech job, but with enough hard work you too can secure one for yourself. Once you have that first job, getting the next will be far easier.

In addition, the skills that you develop along the way are evergreen. Most people in tech change careers every few years, so as one of them you will likely have to repeat the job search process many times. Learn how to do it well now and you will benefit from the skills you develop for the rest of your career.