A Comprehensive How-To on Internships

Finding an Internship

When a company gives you an offer, they are offering you money to do a job. The core of getting an internship is proving that you can do that job successfully. There are a couple primary contributing factors to whether you can be successful at work (in no particular order):

• CS Fundamentals. You'll be expected to have a strong background in data structures and algorithms.
• Code quality. Your code must be readable and extendable. You should be consistent with your style.
• Speed. You should work as fast as possible without sacrificing code quality, which means you need to be able to both code fast and schedule your time intelligently.
• Communication skills. You won't just be an engineer at work. You'll be an engineer in a team. You'll be working with a group of people every day, so you'll need to be able to clearly communicate your progress, questions, and opinions to that team. On top of being clear, you need to be a pleasant person to work with.

When a company considers you for a role, they are trying to evaluate how closely you meet these 4 points. Your job, when looking for an internship, is two fold: meet these points, then prove that you meet these points.

Projects

Do personal projects! Personal projects accomplish a couple things:

• Demonstrate interest. It takes a lot of work ethic to be a successful software engineer, and it is extremely difficult to motivate yourself if you aren't interested in what you are doing. When you do CS and programming projects in your own time, you're showing that you don't just write code because you have to. You write code because you want to.
• Gain experience. Experience will make you a better engineer. Every time you do a personal project, you should be improving in some way. If you aren't learning some new language or concept, you should be improving your speed, code quality, and efficiency.
• Show off your code. Not every company is going to go through the effort of actually reading your code, but if someone does, you have an excellent opportunity here to impress them.

Resume

There are lots of good resources out there for structuring resumes, but some good general rules of thumb are:

• Keep it to a single page. Recruiters are busy people, so don't force them to read through a 3 page essay on your personal past (because they won't).
• Name, visible, at the top. Who are they hiring? You! So make sure that's obvious.
• Contact info, education, projects and work experience, in that order. Contact info should go right below your name. If someone wants to contact you to offer you an interview, make it easy for them! After that, education is generally considered the most important, so cover that first. Projects and work experience show your experience and skill level, so make sure the bulk of your page is covering that. Other things you should add somewhere on the page are skills such as languages (programming and human) that you're familiar with, your degree of familiarity with those languages, tools you've used in the past, etc.

One of the more controversial resume topics is GPA. The general rule is to put your GPA if it's over a 3.0, but don't put it if it's below a 3.0. Personally, I don't think anyone in software should put their GPA, mainly because it's been proven so many times that GPA and skill at work at top companies are not correlated. As such, I would seriously hesitate to work for any company that still asked me for my GPA. That said, having a GPA above a 3.0 on your resume isn't going to hurt you, so do whatever you want.

Referrals

Don't be a referral beggar. A lot of people like to treat referrals as some kind of magic cheat code for getting jobs, but that is just not true. Referrals get you interviews. If you're good enough to get hired by a company, you will be good enough to get an interview from that company without a referral, so the referral really has very little utility in the context of getting a job. Further, begging for referrals (especially from people you have not even worked with) disrespects the entire concept of internal referrals. The point of the reference system is to help companies find good engineers through their current employees' connections, not for insecure programmers to get some kind of exclusive "in" to a company.

That said, if you have worked with someone, don't be afraid of asking for a referral. Under a time crunch, a good word from a referrer can help expedite the hiring process for you.

Recruiters are People Too

When you're talking to a recruiter, ask plenty of questions and go ahead and sell yourself, but don't waste anyone's time. If you're at a career fair and there's a long line of people waiting behind you, that is not the right time to launch into a 30 minute monologue on your life story and childhood struggles and your dog died and you hate long sleeve shirts because you find them stuffy and hate how the sleeves get rolled up under jackets and... see how it gets annoying? Remember, the recruiter is trying to hire someone for a technical role, so walk up, get the information you need, make yourself available to the company, and get out.

Conclusion on Connections

Connections are very useful, but you should be landing jobs by being qualified, not by making friends with hiring committees.

Where to Find Internships

Apply to just about everywhere. Career fairs are a great place to learn about companies you haven't heard of before (more on career fair etiquette soon), but you should also apply to a lot of companies online. Startups especially are less likely to be present at career fairs, so reach out to all the ones you're interested in.

Interviews

If a company likes your resume, you'll be asked to schedule an interview with them. Then, you'll be asked technical questions, usually solving a problem using data structures and/or algorithms. Make sure you're familiar with the big-O times of adding and searching for all the common data structures (e.g. binary tree, BST, directed and undirected graphs, hash table, hash map, trie, linked list, etc.). You likely won't be asked to recite attributes of these structures from memory in your interview. However, you will be asked questions for which one or more of these data structures will be extremely useful, so you should know when and how to use each of these data structures. Similarly, you should familiarize yourself with the well known classes of algorithms and practices (e.g. recursion, dynamic programming, all the well known search and sort algorithms) and when to use them.

Interviews are definitely something you need to practice for. Throughout the year, you should be meeting up with friends either on or above your skill level to interview each other. Being interviewed is helpful because you get experience solving technical puzzles as fast as possible. Interviewing someone else is also helpful because you start to see what a real interviewer is going to look for in a candidate.

Once interview season starts, you should also practice real interviews. If you get an interview with a company you don't particularly want to work for, don't just say "Nah, I'll find some other job. This isn't worth the effort." Interviewing is a learned skill, so go the whole mile. Research the company beforehand. Go to the interview. Crush the interview. It usually takes me a solid week of interviewing to ramp up to my full interviewing skill each year, so having a good number of these ramp up interviews will solidly prepare you for interviews at the companies you do want to work for.

Specifically, before each interview, you should:

• Research the company. Know what they do, their size, and try to find out what you can about their culture. Not only will this help you endear yourself to them (e.g. I am generally much more direct and aggressive when talking to HFT firms and more casual and friendly when talking to tech companies) but it'll help you decide if you would be a good fit at that company. Obviously, you don't want to work somewhere where you don't fit in.
• Do practice problems. Glassdoor is a great resource for looking up old interview questions from specific companies.
• Get comfortable with your interview environment. If it's a face-to-face interview, practice whiteboarding interview problems with a friend. If it's a phone interview, practice discussing interview questions over the phone.

During the interview:

• Tell the interviewer if you've heard that question before. The point of an interview is to demonstrate your thought process, not to find out how many answers to common interview questions you happen to have memorized.
• Pay close attention to the interviewer's suggestions. The interviewer is always trying to help you, not hurt you, so if they offer you advice, take it!
• Talk about your thought process. The interviewer isn't going to know what you're thinking if you don't say it out loud, but the whole point of the interview is to find out how you think.
• Don't overengineer your solution. Lots of interview problems end up having very elegant, simple solutions. Try to figure out what that is. Don't just throw out a bunch of buzzwords and hope you hit the target close to center.
• Don't be afraid of talking too much about the problem. Sometimes there will be multiple good responses to the same question, with some optimizing for time and others for memory. If choosing between these solutions is subjective, don't try to guess one. Just list all of them and explain how you would choose between them given the use case.
• You aren't there to socialize. Your primary goal in an interview should be the find the best answer to the problem as quickly as possible. Don't get hung up on pleasantries before you hear (and answer) your question.
• Don't forget about style. You may be writing code quickly during the interview, but don't let that be an excuse for writing low quality code. Your interviewer will be judging everything about your coding workflow, from how you think to how to talk to how you write, so keep it legible, consistent, and clean.
• Wear clothes. No one cares what clothes. Unless they explicitly tell you to put on a suit, just wear jeans or something.

Also, read books. Cracking the Coding Interview is wonderful and extremely comprehensive.

Choosing an Internship Offer

Note that everything in this section is just a general suggestion. The offer you go with will vary based on your situation. That said, here's the list of suggestions:

• Don't worry about the money. You're only going to be at this place for 3 months, so in terms of the big picture, what you make at one internship isn't going to matter. You should definitely still feel free to negotiate if you have multiple competitive offers, but don't stress out about it.
• Go where you'll learn the most. The most valuable thing you can do at this stage of your career is learn. Don't even think about whether you're "good enough" for a position. Think about whether the position is good enough for you. Will you be working on things you want to work on when you're full time? Will you being doing something new? How big of an impact will you be allowed to make, and how big of an impact do you realistically think you'll be able to make?
• Don't take your return offer. So you got a return offer from your last internship. Congratulations! Don't take it. You've already worked at that company. You know their culture, their policies, their internal tools... anything you could have gained from that company you should have made sure you got when you interned there last year. Further, returning is not going to improve your chances of getting a full time offer. You already got a return offer! They want you back! That's all you needed to do. Going back isn't going to change that.
• If this is your last internship before graduation, where do you want to go full time? As a general rule, it's easier to get a full time offer to a company as a current intern than it is for an anonymous applicant. For example, a graduating intern at Google only needs to go through 3 interviews to convert to full time, whereas typical applicants have to go through 5 interviews. This dynamic exists because after working with you all summer (or winter, if that's your jam) the company is much more sure of your work quality than they would be of a stranger. As such, if there's a company you really want to go to after graduating, try to intern there between your junior and senior years.