Posted on

Table of Contents

If you are reading this, you have probably asked how to get one, or someone sent this to you.

There are two components to finding an internship:

  1. Getting the Interview
  2. Passing the Interview

I will be discussing both in enough detail to get you started on your journey.

Getting the Interview

When is hiring season?

For most people, hiring season will start in August and end in March. You're not likely to get interviews before or after that, though it is certainly a possibility. If you are looking for a Summer 2025 internship, start preparing prior to August 2024. There are also off-cycle internships with different hiring seasons but I won't be discussing those.

How do you get your application viewed?

The first thing is to get your resume at the top of the stack as fast as possible. This means finding and applying to a role as fast as possible. How do you do this?

Well, there is the simplify list of jobs. That's easy to use and if you check several times a day, you might find some applications as soon as they're posted. You could also try to find jobs as soon as they're posted. I will not tell you how to do this. You are a CS major; you should be able to figure this out.

How do you prevent your application from being tossed out?

The second thing, once you get your resume viewed, is to not get your resume tossed out. How do you do that?

The actual resume template doesn't matter nearly as much as the content. You can use Jake's resume template and modify the LaTeX or make a Google doc. That's easy to use.

How do I format my resume?

Now, how do you format the resume? It depends on the type of company you are applying for and who's looking at your resume.

The traditional advice is to format bullets like this: "Achieved X by doing Y using Z." This method is good at appealing to nontechnical recruiters, so you certainly want to have some of these. Technical recruiters and hiring managers will care a lot more about Y and Z than traditional recruiters, so it is important to have extra points about the last two, in my opinion.

Another point to note is that many companies hire juniors looking to convert them after graduation. Coincidentally, there is no easy way to check graduation dates.

I would also like to remind you that if your end goal is to become a software engineer, becoming a marketing intern or having some other very unrelated internship is unlikely to help.

How do I get more resume content?

If you have no experience, you might find it useful to do any of the following:

  1. Go to hackathons (no one will bully you, don't worry)
  2. Do CS-related research
  3. Make a nontrivial project (no YT video tutorials)
  4. Try your hand at open-source commits. This is quite daunting, and you might find it easy to get into if you have used a particular open-source technology or if you join either Google Summer of Code or the Major League Hacking Fellowship.
  5. Excel in CS-related competitions. CTFs, programming competitions, etc. If you have done math competitions that will also help you significantly.
  6. Unpaid internships. I hesitate to recommend this one, but if you can't do any of the above, providing free labor to a startup is a good way to get a foot in the door. That being said, make sure you're either learning or having fun. You don't want to be doing these unless necessary.
  7. Get lucky. Self explanatory.

Yes, these are hard. 120k+ in total compensation (this is an extreme lower bound) out of college is more than enough incentive, however.

Skipping the line

Often you'll fail to do one or more of the above. Maybe your resume isn't good, or you applied too late. You can always cut the line. How?

If you know someone willing to vouch for you, you can get a referral from them. Do not ask me, I will not refer you.

Another way is finding someone at a company with sway who can get you directly into the recruiting pipeline.

Passing the Interview

Interviews come in many flavors. I will be discussing vanilla, chocolate, strawberry, matcha, and a few others I have personally experienced. It's important to note that for technical interviews you should explain what you are doing. It is possible to solve the question and not move on or fail and move forward.

Behavioral Interviews

The best advice is to talk to more people in real life. There is also the STAR method for answering certain behavioral questions.

Other than that, you may be asked to go into a resume deep dive, so know what you put on your resume and be able to explain it to both a technical and nontechnical audience.

Leetcode Interviews

Many people do not like to do Leetcode. These are vitamins. Take them.

Understanding Data Structures and Algorithms is important to passing many interviews. You will often get asked to use an algorithm or data structure in a creative way to solve a problem.

How do you study?

Take some time, maybe 30 minutes to 1 hour a day a few times a week, and put it into Leetcode. Try and make your way through a popular list such as Grind75 before striking out on your own.

Once you finish that list, you should primarily do mediums and hard problems (I suggest a ratio of 20% Easy, 60% Medium, and 20% Hard. Adjust as you get better). You will never curl 60s if you only do a few reps of 10s. Similarly, you will never be able to difficult questions if you only do easy ones.

You should also do contests because they force you to sit for hours and bash your head against a problem until it breaks. These problems are also new, so it is one of the best technical mock interviews, and you can either do old problems virtually (the inferior method) or do the competitions live on Saturdays and Sundays.

Optionally, you could also try your hand at Codeforces or USACO. These are significantly harder, and, in my opinion, more rewarding than Leetcode. They are also extremely overkill and less immediately useful. I would advise you to do Leetcode first.

Once you can reliably solve hards, you won't fail most leetcode interviews. For context, I have failed to solve problems in only two pure algorithmic interviews (I passed the first interview and failed the second) for the entire hiring season of 2024.

I find that most people who cannot solve easy leetcode questions or give up too quickly on them also tend to be bad programmers. Realistically, you should be able to take a good crack at Two Sum even if you can't solve it optimally.

Write A Lot of Code Interviews

This type of interview often gives you multiple problem statements that build on each other and want you to write clean code. If you write unmaintainable code, you will not be able to move from statement 1 to statement 2. Completion and Quality matter more than algorithmic ability here.

An example is this:

  1. Implement a text editor where you can write to the end and remove from the end.
  2. Now make it so you can move your cursor to the middle.
  3. Add a find mechanism.
  4. Add a replace all mechanism.
  5. Make it so you can replace only the first X instances found.
  6. ...

You could also be asked a single open-ended problem statement. For example, "Write Tetris." These aren't all that hard. You just need to break them into manageable pieces.

How do you pass this type of interview? Write clean and maintainable code. Write a lot of it. It often helps to write object-oriented code for these interviews, but that's not really necessary.

Design Interviews

These will be pretty easy since you're most likely either an intern or a new grad. I've gotten this type of interview at a few places

Usually, this comes in two flavors. Low-level and high-level.

Low-level system design generally boils down to object-oriented programming. For example, "make a package manager and code out these specific functionalities." Usually, the code doesn't have to run. If it does, the problem is either small in scale or some code is already given to you.

High-level system design interviews will usually be talking and whiteboarding. You're given a broad topic and it's your job to break it down into specific functionalities. Your job is essentially to transform "Make Uber, Tinder, etc" into "Store data this way, Design X functionality this way, etc." These are pretty easy because the bar is in the basement. Just keep calm and break the problem down. You'll be fine.

Here is a link for system design concepts, though I am certain you won't need it.

Language Specific Interviews

I've only gotten a few of these. These are usually "write a lot of code" interviews with an emphasis on a specific language. You'll also be asked to talk about useful parts of the language or quirks of the language. A C++ interview could consist mostly of templating or perhaps implementing functions from the standard library. You could also be asked about trivia. I've heard questions like "What is your favorite version of C++" followed by "What came out in that version of C++".

These interviews are uncommon and can generally only be passed by a familiarity with the underlying language.

Systems Interviews

This is my umbrella term for low-level programming interviews. Networking, operating systems, and occasionally computer architecture will fall under this category.

I will not claim to be an expert on these types of interviews. You will also not be asked these often, if at all.

To my understanding, there are no easy ways to pass these interviews or practice for them, you just have to know and understand the material. Questions can be like this: "What is the fastest way of communicating between two processes" followed by "How does that work."

Machine Learning Interviews

This is exactly what it sounds like. I am unfortunately also not an expert as I've only done a few.

My only advice is to know how everything functions under the hood. I was asked to "implement KNN" in one interview and "K-Means Clustering" in another. You may be given access to Numpy and other libraries, you might not.

There are also trivia deep dives to assess that you know how everything works.

Closing

You can also find good advice on the CS Majors and CSCD discords. Just be consistent with whatever you do, and you will most likely be fine.