Compilation of my advice for undergraduates at MIT looking to find a summer internship or full-time new-grad position in software engineering.


  • Travel Guide: general resources such as best practices, resume template
  • LeetCode: practice technical interviews, with solutions
  • Easy Application: 400 software companies with easy applications
  • Cracking the Coding Interview: the software interview bible; probably not necessary (practice and chats with upperclassmen should do the trick)


Personally, I see 6.006 and 6.042 as corequisites for the software interview process. Unless you have a relevant background, the interview process will be a bad time without at least the first few weeks of 6.006 under your belt.

Given that, the most successful strategy is practice, both offline and real-world. Practice at a real whiteboard, and talk out loud. At first it can be difficult to talk while you’re thinking, but you get used to it.

Apply to lots of companies–something like 20 fallbacks, 10-15 stretch goals. The fallbacks will be good practice and may turn into a desirable job offer.

Types of interviews

  • Phone screen. Interviewer calls you on the phone. Can be behavioral or technical. Sometimes you convey information over the phone, sometimes through a shared online code pad.
    • Time: 30 to 45 minutes
    • Verbal medium: phone, video chat
    • Physical medium: none, online code pad
  • Behavioral. Generally non-technical interviewer calls to chat. Looking to make sure you’re not a weirdo, generally line up with what you claimed on your resume, and ensure your interest in the company. Just be yourself.
    • Time: 15 to 30 minutes
    • Verbal medium: phone, video chat, in-person
    • Physical medium: none
  • Take-home. Coding challenge to complete within usually a week’s time frame. Sometimes timed.
    • Time: around 3 hours
    • Verbal medium: none
    • Physical medium: online app, personal text editor
  • Whiteboard. Solve an algorithmic problem on a whiteboard while explaining your train of thought to the interviewer. Usually one-on-one with a current technical employee.
    • Time: 1 hour
    • Verbal medium: in-person
    • Physical medium: whiteboard, personal text editor

Interview process

The flow of the overarching interview process generally looks something like this.

  1. Career fair. Attend the career fair and chat with as many companies as possible. Start with companies you care less about to A/B test your spiel. I generally spend 1-3 minutes chatting per company. For each chat, follow this general pattern:
    1. Say hi: “Hi Jim, nice to meet you,” while shaking hands.
    2. Introduce yourself: “My name is Hunter and I’m a first year master’s student in computer science working on secure communication for unmanned systems.”
    3. Describe desire: “I’m interested in a software engineering internship position for this upcoming summer.”
    4. Give resume: “Do you mind if I hand you my resume?”
    5. Highlight top 3 essential factors–what of your resume stands out, defines you as unique from other applicants?
    6. Conclude–be sure to ask how, where, and when you should apply. Shake hands and thank them for their time.
  2. Apply. Apply as soon as possible after the career fair. Generally want to apply to the order of 20 companies over the first weekend after the career fair. Less if you already have a return offer, possibly more if you are worried about your ability to land/succeed in an interview (practice makes perfect!).
  3. Phone screens. The recruiters liked your resume/chat and are interested! They want to make sure you’re worth investing more resources into. Often 1-2 phone screens, and one may be behavioral.
  4. On-site whiteboard interview. The recruiting team is definitely interested, so they’re bringing you out to their office for an in-person interview with one of their technical employees. This costs them real money–they’re happy to do it though, because you’re worth it! In some cases there are back-to-back interviews with different interviewers.
  5. Offer. The on-site interviews went well, and they want you to join the team! Sometimes the offer will be with a specific team, sometimes it will be a general offer and the choice of team comes later. Generally will have a few weeks to give a yes/no response to their email. Bigger companies usually have set offer packages for interns, while smaller companies and startups are more open to negotiation. If timing is an issue with regard to other offers, feel free to discuss your constraints with your recruiter.

The whiteboard interview

First, relax! It’s okay if you bomb–there are always more companies wanting to hire you (and you can reapply to the same company about once a year). Develop your own preferences for how to solve technical problems, but here’s a good outline of what works for me.

  1. Understand. Listen as they pose the challenge, write out the key points, ask clarifying questions, state assumptions, and finally read back the overall challenge in your own words. Write out a small, toy example (inputs and outputs) to make sure you understand the problem/potential solutions.
  2. Think. Say “okay, let me take a few seconds to think about this,” then take 30-45 seconds to think about what you want to do. This is the point where “inspiration” often comes.
  3. Forecast. Briefly (10-15 seconds) describe the naive solution, if it comes to you. Give your feel for what the “lowest possible” bound would be (e.g. if an array has N elements, and you must touch all N elements, then can’t do better than O(n)). If you want, give your intuitive guess for what the runtime complexity will turn out to be.
  4. Solve. Begin your solution. Remember to think out loud as much as possible, or at least think quietly but then explain what you’ve been thinking. At this stage, you’re not writing any actual code (except maybe a bit of pseudocode, if you find that beneficial)–just working toward an understanding of how to solve the problem, e.g. “okay well, we could use a hash table here, and that would require O(1) work per element, so let’s say we iterate over the entire array and insert each element,” etc. Write in real words what you want to do. Once you have something you think would work, describe why it would work, then ask for the interviewer’s thoughts. If they like it, then you can begin writing it up in actual code.
  5. Code. First write out, using inline comments, what you want to do. Then implement the comments. Prefer Python (or whatever you’re most comfortable with), but ask/defer to the interviewer’s requests. Ask questions when stuck or unsure.
  6. Summarize. Once you’ve reached a solution, describe why you think it’s an acceptable solution, then ask for the interviewer’s thoughts. They may have you change things, describe decisions, or say you did something wrong. Then they may ask you a few additional, non-coding questions related to the problem, e.g. “what is the space complexity of this solution?”


  • Confidently ask for help. Both when stuck and when unsure. This is possibly the most important thing. You’ll never bomb because you can always ask for help–and it’s seen as a positive, actually, to ask for a small/appropriate amount of help. Interviewers want to know you’re comfortable requesting help with difficult problems.
  • Remember hash maps. They have O(1) insertion, deletion, and lookup times, and are frequently used in algorithmic problems.
  • Define functions as-needed. If you can’t remember the name of a standard library function, or want to use a function but define it later, write something like this off to the side and fill it out later (the interviewer may request that you fill it in now, or might say “don’t worry about it”):

    def pick(array):
    # pick a random element from array
    def swap(array, i, j):
    # swap indices i and j in array
  • Leave scratch space. Leave part of your workspace, off to the side, free for thinking, toy examples, and quick math.

  • Write out a toy example. Can be a great way to (a) have some time to think, and (b) realize a solution you weren’t seeing before.