Landing the Software Internship (Part 3: Interviews)

Welcome to the third and final blog post of a 3-part series on internships. I recommend reading the previous parts if you haven't already. They discuss how to write a resume and how to look for a job.

The primary audience for this piece is the college student looking for an internship. However, a lot of these interviewing concepts apply to the tech industry as a whole.

Interviews are the biggest hurdle when talking to a company. For software engineering roles, you can expect to be asked technical questions. As a result, it can be intimidating to students who aren't familiar with the process. We'll break down the different parts of the interview process and how to prepare. Later, we dive into what it's like from the interviewer's perspective.

Navigating The Gauntlet

I like to break down the process of interviewing into three parts.

1. Preliminary Due Diligence 📋
2. Studying for the Interview 📝
3. During the Interview 💬

Preliminary Due Diligence 📋

The interview begins before you even start studying. You want to learn as much about a company's interview process as possible. Before you can prepare, you need to know what to prepare for.

Be sure to ask questions about the process before any interviews. For example, it's good to know the format of the entire process.

• How many interviews will there be?
• What type of (technical) questions will be asked?
• How are you assessed? What is not assessed?
• What are the performance expectations?

If you plan to go in blind during an interview, you're rolling the dice. Try not to leave anything to chance. Recruiters should be reasonably transparent about the interview process. If for some reason they don't know or want to keep things a secret, treat it as a red flag. You may want to divert your efforts towards other companies.

Studying for the Interview 📝

When I was in college, technical interviews were a source of stress for most students. Nowadays, I regard technical interviews as a blessing in disguise. You can't lie your way through a technical interview. Answers tend to be objectively wrong or right. Charismatic people lacking substance can't sweet talk their way past a technical interview. If you know how to code, think of the technical interview as your opportunity to shine.

Algorithmic Interviews

The majority of technical questions tend to assess your algorithmic coding abilities. Larger, well-established companies (e.g. Google) tend to mostly give these algorithmic questions. Interviewers will ask you to write a method or function that fulfills some given task. You're expected to write real working code, so brush up on your syntax. I recommend using scripting languages (e.g. Python), since they have have easier syntax. However, feel free to use any common language depending on your comfort levels. You may also have to discuss the runtime complexity of your solution, so be sure to know how Big O notation works.

The best way to get good at algorithmic interviews is to practice a lot. Find realistic practice questions, and try to solve them. Finding a friend to conduct mock interviews with you goes a long way. The algorithms you should know are out of scope for this blog post, so I'll share some resources instead.

• I'd recommend reading Cracking the Coding Interview if you're new to technical interviewing. It gives an overview of problem types you might encounter.
• LeetCode and other competitive programming websites are good resources for practice problems. Make an account and start solving problems.

Other Technical Interviews

Startups have experimented with other forms of interviews over the past few years. If you're interviewing at a startup, you might expect a more diversified set of interviews. For example system design and debugging questions have become quite popular. System design questions don't involve coding. Rather, it covers how a candidate would architect an application and its APIs. A debugging interview usually involves a codebase with a bug and a failing test. The candidate's job is to discover the cause of the bug and fix the code.

• For system design interviews, I recommend learning how popular apps were architected. Focus on why engineers made their decisions and what tradeoffs they made. Reading engineering blogs is a great way to get started.
• For debugging interviews, the best way to prepare is to code a lot, ideally in large codebases. There's no special trick you can do to prepare.

Will this make you a better engineer?

Practicing for interviews doesn't correlate with you becoming a better engineer. That's the hard truth. However, grinding LeetCode is still the best way to get better at interviewing. Interviews aren't a perfect measure of one's engineering ability. But it's the best signal a company can get (without hiring you). In some sense, you should treat interview prep as a means to an end. It gets you the job, which affords you the opportunity to become a better engineer in the long run.

During the Interview 💬

The interview itself won't take long. All of your preparation boils down to less than an hour. Regardless of how well you prepare, you may feel pressure during an interview, so try to stay calm. Doing lots of interviews is by far the biggest help when it comes to curbing nervousness. After you've done a few in a short span of time, each individual interview will stop feeling like a big deal.

Syntax Expectations

Although you're expected to write real code, your medium impacts the coding expectation. For example, at Google, interviews happen on a whiteboard. (At least that was the case before 2020.) There was no compiler to actually run the code. Interviewers still expect accurate code, but it doesn't need to be perfect. Forgetting the name of a library method or missing a semicolon if forgivable. On the other hand, it's not okay to write pseudocode.

CoderPad has become a popular tool for conducting interviews these days. It allows you to run your code during an interview, making a more realistic scenario. If you interview using CoderPad, there's the expectation that your code runs. However, interviewers are usually okay with you using the Internet to look up errors. I recommend compiling and running your code frequently, even if you aren't finished. It prevents syntax errors from compounding over time.

Communicating with Your Interviewer

During the interview, be sure to ask good clarifying questions. Besides curbing some pressure, questions have many benefits.

• It buys you time to think.
• It reminds you that the person on the other side is a human.
• It helps guide you through the question.

In general, your interviewer should be clarifying and hinting along the way. Make sure to state your assumptions and communicate your thought process. The interviewer gets no signal if you solve a problem but hide your thought process.

Finally, remember that you're also interviewing the company. Be sure to ask thoughtful questions about the company if you have a few minutes to spare. You need to know if you're talking to a good employer. It also helps the interviewer understand if you'll be a good fit apart from the technical aspect.

The Interviewer's Perspective

During my career as a software engineer, I've been an interviewer at Google and other startups. Thus I can share a bit about the perspective from the interviewer's side.

Big Company Mechanics 🏢

Google had quite an elaborate scheme when interviewing candidates. In hindsight, it kept everything scalable and running like clockwork.

1. Engineers would fill out what languages and topics they'd be comfortable interviewing. They also self-selected their availability.
2. Recruiters would schedule interviews. They would match the candidate's and interviewer's preferred language and skillset.
3. The engineer would conduct the interview and fill out a feedback form afterwards.
4. An independent hiring committee would review the feedback and make a hiring decision.

Full time candidates would usually go through four technical interviews. Interns would have fewer (2-3) interviews. After an interview, interviewers would grade candidates against a standard rubric. The rubric included fields such as:

• Problem solving (Can the candidate code?)
• Values feedback (Is the candidate receptive to hinting?)
• Thrives in ambiguity (Can the candidate ask good clarifying questions?)

We'd mark down a score for each field and then provide an overall recommendation. The hiring recommendation would fall into six possible buckets:

• Strong No Hire
• No Hire
• Leaning No Hire
• Learning Hire
• Hire
• Strong Hire

Interviewers would pick their own questions to ask for the interview. As a result, your experience could vary a lot depending on who interviewed you. The only strict rule was that interviewers could not use certain banned questions. Those tended to be questions that were publicly leaked as "Google interview questions."

The interviewers themselves were not allowed to make any decisions. Once all interviewers provided feedback, a independent hiring committee would convene. The hiring committee would assess the feedback and make a final hiring decision. The intention here was to remove any personal biases from the table. The interviewer's job was to gather signal; the committee's job to make a judgment.

Interestingly enough, Google kept internal metrics about how interviewers graded candidates. Your final scores would be compared against the hiring committee's decision. The data they collected could determine whether you were too nice (or harsh) of an interviewer. The hiring committee could then adjust how they weighed your feedback. It was grading the interviewer, in a sense.

Small Company Mechanics 🏗️

When conducting interviews at a startup, many of the core mechanics stayed the same.

1. The recruiter would schedule an interview with a panel of engineers. The engineers were picked based off which questions they were going to ask.
2. The engineer would conduct the interview. Then they fill out a feedback form or directly share feedback with the recruiter.
3. The interviewers and hiring manager debrief and come to a hiring decision.

In a startup, there are no hiring committees. Instead, the interviewers gather in a debrief with the hiring manager. (The hiring manager tends to be the candidates potential manager.) In a debrief, interviewers would discuss their assessment of a candidate. The hiring manager then makes the final decision of whether to make an offer.

Startup interview rubrics tend to be less rigid. Instead, they focus on whether a candidate would be a valuable addition to the team. Compared to a large company, each candidate gets personal attention. In my opinion, there's also more thought put in per candidate. However, it allows more room for personal biases from the interviewers. There are trade-offs to both styles.

The Interviewer's Mindset 💭

When conducting an interview, the interviewer has two goals:

1. Gather signal (both good and bad) about the candidate.
2. Give the candidate the opportunity to shine.

The interviewer's job is to understand the candidate's strengths and weaknesses. In other words, it should be a time for candidates to show off their abilities. Anything done to entrap or demoralize a candidate is a sign of a bad interviewer. At the same time, when candidates don't share their thought process, it's hard to gather signal.

I personally like questions with multiple parts. They allow candidates to make incremental progress. This avoid a pass-fail type of situation, which demoralizes candidates. It also makes it easier to gather nuanced signal about candidates. When it comes to a solution, iterating matters as well. You're better off having a correct and working solution first. Then optimize your solution to make it more efficient.

Remember that on the other side of the whiteboard (or CoderPad), you're talking to a human. Interviewers are just trying to gather signal, so do them a favor and share what you know. It makes the experience better for everyone. This is your time to shine.