This post is meant to help computer science undergraduates looking for a software engineering internship in the summer. Applying to internships can be daunting, and this post will hopefully address some of the commonly asked questions that I see on Reddit’s cscareerquestions. Along with some other miscellanea regarding applications, this post covers two things:

1. What are most internship interviews like?
2. How should I prepare for them?

Background

I did research last summer, and this summer was my first time seriously looking for an internship. From the beginning of September 2013 to the beginning of January 2014 (around 16 weeks), I did a lot of interviewing: 20 technical interviews, four recruiter interviews, two coding challenges, one product manager interview, and one trader interview (involuntarily moved from software engineering). One of the reasons that I did so many interviews was that I did poorly on many of my interviews for the first month. Despite having read about interviewing on the internet, I wish I had known more concretely how to prepare.

Finally, note that I mostly interviewed with medium to large companies in Silicon Valley: your mileage may vary with local companies or smaller startups. Out of respect for the companies that I interviewed with, I won’t be linking specific companies to specific interview questions.

The three types of internship interviews

I would categorize my internship interviews as falling into one of three categories:

1. The programming interview: algorithms, data structures, coding
2. The “what you’ve done interview”: you and your projects
3. The language-specific interview: quizzed about a language you claim to know

I’ll explain these in more depth below, adding details on how to prepare for each category. Note that not every interview falls precisely into one of the three categories, and some interviews are a mix of multiple categories.

1. The programming interview

The programming interview is the most common type of interview, especially if you’re not interviewing for a specific team. This is how most people envision computer science interviews: you’re asked one or more programming questions, and you implement solutions on a collaborative editor like Stypi or Collabedit.

I would further divide these interviews into two topics:

1. Questions involving loops, lists, or strings (easier)
2. Questions involving specific data structures (harder)

I think the first category is easier, and it includes questions like: Remove duplicates from a list or Generate all of the permutations of a string. Even if you don’t immediately know the answer, there’s a chance that you can figure it out without requiring knowledge of a specific algorithm or data structure.

I find the second category trickier, and sometimes the question will be hard or near impossible if you don’t know about a specific data structure or algorithm. For example, if you’ve never done breadth-first tree traversal, and you’re asked: Print the values in this tree level-by-level (a question that I received from two different companies), the question will be much harder.
In one interview, I did poorly when we delved deeply into variations of hash tables, but I was only familiar with basic linked list hash tables.

At the end of every question, you will almost always be asked to discuss the Big-O complexity of your implementation.

Checklist

Here’s what I didn’t realize at first: instead of just walking in, you should study for interviews. Unless you do algorithmic challenges on a regular basis, it’s worth the time to read and practice.

• Read Programming Interviews Exposed: Focus on these topics: string manipulation, linked lists, doubly linked lists, hash tables, trees, queues, stacks, depth-first search, breadth-first-search, basic graphs, basic complexity.
• Check Glassdoor: Many companies have interview questions on Glassdoor. Your goal isn’t to study the interview questions in advance, but you can get a good idea of the general difficulty of the programming questions.
• Practice at least once: I’ll let the interview books cover this process in more detail, but if this is your first interview, I highly recommend practicing an interview question from start to finish with a friend.

I would take books like Programming Interviews Exposed with a grain of salt. Except for some of the very big companies, like Facebook, the interview questions for internships are generally much easier than those for senior developers. You won’t be asked to write a red-black tree from scratch. From my experience, the list above comprehensively covers the topics from my interview experience (suggestions welcome).

Depth- and breadth-first search (DFS and BFS, respectively) were extremely popular, and I would estimate over half of my algorithms interviews were best solved with DFS or BFS. Know them!

1. The “what you’ve done” interview

The “what you’ve done” interview is a non-technical, pleasant conversation with your interviewer, where you get the opportunity to talk about your resume and projects. I found that this type of interview was more common in small and medium sized companies.

Empirically, I did better on these interviews than on algorithmic interviews, because it was an opportunity to pitch myself as a passionate developer. I usually talked about my research, my past internship, and/or my experience at the Meteor Summer Hackathon.

Note that I’m a junior (third year undergraduate student). If you’re a freshman or sophomore, don’t panic if you don’t have a lot to talk about yet. Without sideprojects and/or past internships, however, this interview can be tough. You can use course projects, but I think people know that most course projects are a few files that are hacked together in a few days (varies by school, of course).

Checklist

Be prepared to talk in-depth about any jobs and projects on your resume. For each project, you’ll want to be ready to answer these questions:

What was the project?

What was the scope of the project? (i.e., how much time, how big was it)

What was your role in the project?

What did you learn?

What were some of the challenges in the project?

If you prepare these answers, you’ll be ready to answer a more general question that frequently shows up in interviews:

Tell me about a technical challenge that you had.

1. The language-specific interview

The language-specific interview tests your knowledge about a specific language that you claim to know on your resume. This interview often shows up if you’ve been placed to interview with a specific team (e.g., iOS Safari team at Apple, YUI team at Yahoo).

I was never asked coding questions in these interviews, but the interviewers expected me to show my knowledge through my answers to quiz questions, my discussion of relevant projects, and my opinions on language features.

Checklist

If you are placed to interview with a team that uses a specific language (or framework), you should prepare for the following questions. I was asked each of these on multiple occasions:

What makes {language} different from other languages?

If you had to change something in {language}, what would you change?

Tell me about a technical challenge that you had when you were working on a project in {language}.

JavaScript specific questions

In addition to the above questions, I was also asked the following question on three different occasions for JavaScript-related internships:

Tell me about closures in JavaScript.

I usually answered with an explanation of 1. callbacks 2. function scope in JavaScript. Closures allow for more traditional object-oriented programming (e.g., objects in Backbone.js are just closures).

One question that I was not asked in any interview was to recite the value of this in various contexts (not that this means it isn’t fair game).

Odds and ends

Again, not every interview will fall into one of these three categories. I encountered a couple of weird interview styles:

• Straight quizzing: One first round interview a recruiter who read quiz questions about databases, Unix systems, and web requests. The recruiter had a list of answers, and I suspect one important metric, in addition to correctness, was how confidently you answered.
• Coursework: I interviewed with a very cool stealth startup working on something that has it roots in security research. Correspondingly, the whole interview was about my coursework in compilers and theory of computation – no technical questions.

Beginning the interview

Some bigger companies dive straight into the technical part of interviews, but your interviewer will almost always ask you a very important question (or some variant) that you should prepare:

Tell me about yourself.

Keep it succinct! I would say it should be a minute long at most. Hit the important points about your interests and experience, and spare your interviewer the life story. I’m saying this because I made the mistake of having a long pitch in the first few interviews, and I could tell that the interviewer ended up getting bored.

Ending the interview

Even when the interview runs over the allocated time, your interviewer will ask:

Do you have any questions for me?

I used to have a lot of trouble with this, but after I started treating it as an opportunity for conversation, it became much easier. This is a chance to connect on a personal level with the interviewer. If your performance was borderline, having an insightful conversation with the interviewer can’t hurt.

If the interviewer hadn’t described himself or herself yet, the first thing I asked was:

Can you tell me more about what you do?

I let the conversation flow from there. If there’s not much to follow up on, I’ll ask about how they test their product or choose to target new features. There’s a very good list on Programmers Stack Exchange, although not all of them are suitable for potential interns to ask.

Miscellaneous: FAQ

These are my answers to questions that either I was asking at the beginning of the application process or I see frequently asked. Most of these don’t have black-or-white answers.

How long should my resume be?

For companies based in the US, your resume should not be longer than one page. Personally, I don’t like reading resumes longer than one page. From what I’ve read from various recruiters and managers on the internet, they don’t either, although it doesn’t mean automatic rejection.

Make sure your resume looks professional – spacing, font, structure. Use a serif font!

If your resume is too long, consider cutting out parts that are not tech related – clubs, extracurriculars, experience in a different field.

Finally, don’t include things like your high school GPA, because they don’t matter to the people reading your resume.

When should I start applying?

Most internship applications started popping up in October and November. I think it doesn’t hurt to apply earlier, although one friend told me that intern candidates at his company usually fared better in spring than in fall.

Before last summer, after I had already decided to do research, I did receive a few emails for interviews as late as March. If you didn’t jump on it in October, don’t panic.

How important are sideprojects?

It depends on the company, but if you’re a freshman (first year) or a sophomore (second year), it’s important. When I applied to my first internship in freshman spring, the recruiter emailed me back saying that the manager wanted to know if I had any sideprojects. In addition to spicing up your resume, it gives you something substantive to talk about in the “what you’ve done” interviews.

How long can it take to hear back after an interview?

It varies by company. From small to medium sized companies, I heard back anywhere from a day to a week. Without exception, after a final round interview, it took every big company two weeks to a month to respond with either an offer or rejection.

How can I overcome nervousness during interviews?

In some of the algorithmic interviews, when I started doing poorly, I would just freeze and ramble – especially if I hadn’t slept much the previous night because of schoolwork. Eventually, the interviewer would (pretty much) tell me the answer, which almost always led to rejection after the interview.

If this happens to you, my advice is to tell the interviewer, “Let me consolidate my thoughts for a moment.” Take a few deep breaths, don’t think about anything, and then tackle the question again.

If you feel nervous from the very beginning, try to persuade yourself that it’s only a friendly conversation.

How can I know how well my interview went?

In my experience, if the interviewer starts talking about how much responsibility interns have and you didn’t explicitly ask about it – the interview probably went well. This is not a guarantee by any means.

I’ve read a few things on the internet about asking your interviewer how they felt the interview went. I haven’t tried this before, but feel free to let me know if you have. I think it would be a useful source of feedback.

Hope this helps.

Any specific questions or insights? Feel free to to comment or ping me at pong [at] outlook.com

UPDATE: Before publishing this article, I asked one person – Kevin Gong, a senior at UC Berkeley – to edit this article. This was the last time that I talked to him. In March 2014, Kevin passed away in a car accident. He was incredibly passionate about applying technology to the world and helping younger students kickstart their careers. If this article helped you, please consider donating to the Kevin K. Gong Memorial Scholarship for Bright Minds and Big Hearts.