Now I'll try to demystify the interview process and share some ways to improve your performance. Here's what it will typically look like:
The HR call
Your first call will be with an internal recruiter. His job is to make it as easy as possible for you to join. That means understanding your desires, scheduling your interviews, and being your all-around point of contact. He's not looking to weed you out; rather, he's trying to get you on board. Don't worry about not knowing the right answers to his questions. Just focus on having a candid, productive discussion.
Things to discuss (i.e. if he doesn't bring it up, you should):
- Team. Who will you be working with? What kind of work will you be doing?
- Location. Where will you be working? Where will you be living?
- Program. How many other interns are there? What kind of events are put on?
- Timeline. How long will the entire interview process take? What are the next steps?
Afterwards, look to schedule a 30 to 60 minute block to do...
The phone screen
Here, you'll speak with an engineer, who'll evaluate your technical abilities. Your resume and accomplishments have gotten you to this point, but how you perform in these interviews will determine whether you get an offer.
To warm-up, you'll be asked to elaborate on some past work. Talking solely about class projects might signal a lack of passion for CS. Instead, pick an extracurricular project ahead of time and prepare a short pitch about what you did and what the challenges were. Good candidates are club websites, hackathon hacks, or anything you've coded with friends.
Next comes the main event: the technical problem. The engineer will pose a question, for example, "Given a singly-linked list, how would you detect whether there is a cycle?" You'll then be solve it by coding into something like Collabedit or CoderPad, where the interviewer can follow along what you type.
Don't just dive into writing code! First, you want to ensure that you've correctly understood the problem. If you don't have any questions, restating the problem in different words is a great way to check your understanding, and shows that you've been paying attention. You can also ask for a test case and expected output, if they're not already provided.
Now, start talking through your thoughts on how to tackle the problem. A rule of thumb: saying anything is better then staying silent. Your interviewer can't read your mind; if you pause to ponder the problem, your interviewer will just be faced with silence, which is awkward and unhelpful for evaluating your abilities. Instead, brainstorm aloud; speak out every thought about this problem that crosses your mind.
- "Hm, I don't have a solution in mind yet, but I feel like this is something I should be able to finish in O(n) time, if n is the number of nodes in the list."
- "This seems like a pretty good fit for dynamic programming, because it's similar to another problem I've seen before, the maximum continuous sum problem. Should I describe that problem and solution?"
- "The easy thing to do here would be to create a new array, but you might actually be able to swap the characters in place and save on memory that way. Let's explore that possibility."
Then, when you have a general approach to solving the problem, you should begin committing your thoughts as code. Again, you should be explicit in explaining your actions over the phone. I'd recommend getting a headset and microphone so you can talk and type; turning on the speakerphone also works. Some other tips for this part of the interview:
- Make sure to pick language you're familiar with. (I recommend Python, as its concision saves you time and provides fewer opportunities for bugs.)
- You want to make it as easy as possible for the interviewer to follow your thought process -- what is obvious to you might not be to her.
- Relatedly, pick good variable and method names. Include relevant comments.
- You can ask your interviewer for help! She'll be happy to confirm facts, language quirks, or forgotten bits of how an algorithm goes.
Once you finish typing, your interviewer will normally ask a question like, "So do you think you're done?" This is your cue to check your work, as almost inevitably you'll have introduced a bug along the way. The test case you asked for earlier comes in handy here -- you can step through your code like a human compiler and find where the output diverges from what's expected.
When you've successfully completed this problem, be prepared for a follow-up. This might be an asymptotic analysis of your approach, an extension to the same problem, or a completely new one. Now is also a good time to ask what your interviewer would have done! Since questions are often reused between candidates, your interviewer will have seen a wide variety of solutions, and she'll be happy to discuss the tradeoffs between them.
At the end of the phone screen, the interviewer will set aside some time for you to ask them questions. You might think that doing so is optional, but it's really not; failing to ask anything might belie a lack of interest in them and their company. Also, just as a matter of due diligence, this is a good time to get to know the company that you may spend months (and perhaps years) at, from the perspective of someone in the same role as yours. Some go-to questions:
- What was the impact of past interns on your team?
- What kind of technologies do you use in your daily work?
- What has been your career path up to this point?
- What's your favorite thing about working for X?
After a few of these, your phone screen will come to an end. Make sure to thank them for the interview! And if you did a good job, look out for your recruiter to schedule...
Here you'll be whisked to the company headquarters for a chance to interact with its employees in person. In between bites of sashimi and tours of the spa, expect to go through a few in-person interviews.
The structure of these will be very similar to the phone screen, so all the advice above applies. However, there is one major difference: the whiteboard. To make an artificial situation even less comfortable, you'll be asked to scribble out code by hand on a vertical surface. Suddenly:
- Handwriting matters. If your interviewer can't read what you're coding, you probably won't do to well.
- Plan ahead. Think about where to place your function definitions, your loops, your conditionals. You can't just hit "Enter" to get a new line, so leaving extra space will help if you need to go back and insert something.
- Draw diagrams! This is a new ability you didn't have during the phone screen. A diagram can help explain what you're thinking about doing and clarify misconceptions.
Also, your interviewer will be in person instead of on the phone, so make sure to pay extra attention to....
You might think that an interview is about you and how technically qualified you are. That the "right" technical answer will get you to pass, and the "wrong" one will disqualify you. You're wrong.
In any interview, you basically have just one job: get your interviewer to like you. Doing well on a technical level can count for a lot1, but good communication and interpersonal skills matter too. Consciously or unconsciously, they'll take into account whether you're the kind of person they can get along with. After all, it's very likely that you'll end up on their team, collaborating for the entire summer.
Remember that your interviewers are human, just like you. They might be nervous, uncomfortable, or shy -- they, too, are meeting a stranger that they want to impress. Interacting with them as a regular person instead of some unapproachable gatekeeper will go a long way towards improving your own confidence and making the experience enjoyable for both.2
Thus, make your interview a conversation, not an interrogation. Show an interest in their background. Laugh at their jokes. Try to get them to laugh at yours! You'll have at least one common interest to work with.
Practice, practice, practice
If you've never gone through this process before, apply to companies you don't even think you'd want to work for, just to get familiar with the structure. Familiarity will inspire confidence, which will help when you're walking into your first interview with your dream company.
A technical interview can feel like solving a difficult math problem while putting on a dance. It's probably unlike anything you've done in CS class, so make sure to practice. Get a friend, preferably one who's been through this process recently, and ask her to simulate the role of an interviewer.
Brush up on your data structures and algorithms. Interviewers like to spend a disproportionate amount of attention on such topics.3 You should familiarize yourself with the most common questions. On the off chance that somebody asks you something you know the solution to, you can either whiz through the problem or just tell them that you've already seen it.
Best of luck! This can definitely be a nerve-wracking experience, but it can be enjoyable too, in the same way that puzzle solving can be. It's also fantastic preparation for full-time job interviews (structured exactly like this, just with a longer on-site portion.)
Part 2 in a series on internships. Part 1 here. To be continued in Part 3: The Offer.
Being too clever can actually work against you e.g. if they're looking for a specific answer which doesn't match up with what you thought of. A good interviewer will be flexible in evaluating different approaches, but not all interviewers are so accommodating. Thus, I recommend throwing out all the different ways of solving a problem that come to mind while brainstorming -- if your interviewer prefers one, he'll guide you in that direction. ↩
At least, relative to how much of programming is just gluing things together and then Googling/StackOverflowing if and when they don't stick. Solving interview questions involves somewhat different skills than actually programming, so it's good to practice on its own in places like HackerRank ↩