What happens in a technical interview?

To get a job, we’ll inevitably have to interview, as much as we all love those.

So how does a technical interview usually go?

These are typically thirty to sixty minutes, depending on the company. Usually, the interviewer will do a super brief introduction of herself or himself, and then you’ll do an introduction as well. You’ll probably talk about school, major, what year you are, and perhaps what you’re interested in doing if you know.

Then, there will be the question. You’ll be asked to write a function, and the interviewer will give you the parameters of this function as well as an example of expected input and expected output.

First, ask clarifying questions and talk about assumptions, and make sure you understand what the question is asking. Next, talk out loud about potential solutions without coding, although feel free to write down bullet points or psuedocode. Talking out loud here is important so the interviewer knows what you’re thinking, and if you’re going down the right path, they’ll probably confirm which feels great during an interview. If not, hopefully they’ll guide you down the right path so you get the right solution.

If you can’t think of the most efficient way right off the bat, don’t worry about it! I almost always first say the brute force solution that will definitely work while trying to think about a more efficient solution at the back of my mind. If I can’t think of the most efficient way after I get my brute force solution outlined, I’ll say something along the lines of “I know there’s a more efficient way but I’m not sure what it is” and see what the interviewer says to that.

Sometimes they’ll say to just go ahead and code the brute force solution first, then think about a more efficient way later. Other times they’ll spend some time trying to help with getting to the more efficient way. Let the interviewer decide and be open to options, and really try to listen and take the interviewer’s hints without being tunnel-visioned on your own solution. This is similar to actual work in that we want to be open to other people’s feedback, and how well we incorporate that feedback into what we’re trying to do is important and part of the job.

After you have a clear idea of implementation, then start coding, continuing to talk out loud about what you’re thinking and doing. When you’re done, walk through input example while updating the variables in your code to ensure they’re changing correctly, and debug along the way if needed. Talk about test cases including edge and corner cases, and lastly, cover time and space complexity along with any tradeoffs.

Talking out loud throughout the interview is probably one of the most important aspects, as you’re showing your thought process and debugging abilities. Getting the solution is important too but if you had help along the way, this is not necessarily a negative. Being able to communicate and explain your thoughts as well as incorporate any feedback are soft skills needed for the job, and part of the interview is likely evaluating these as well.

Before the interview is over, there will always be at least five minutes to ask questions. Even if you don’t have any questions, ask some. Have questions in the bank to pull out, or if you have genuine curiosities, definitely ask those. As some examples, as an intern I might wonder whether the interviewer had managed any interns before, and if so, what the intern project was, any surprises or challenges the interviewer came across in managing an intern, how closely the intern was working with people on the team (or how many people the intern was working with). In general, I might ask how success is measured for the internship, what the intern program is like, how return offers work.

For new grad or full-time roles — I will caveat that I care about very specific aspects of the job, so these examples might not be questions you care to ask, which is perfectly fine: work-life balance (some specific questions to actually gauge this is whether people have to be on-call and how often that is, along with number of weekend hours worked per month), how priorities and deadlines are determined, how who does what is determined, qualities looked for in a candidate, actionable items done to improve team culture, team’s gender ratio, concrete examples of collaborative (probably every person I’ve talked to will throw this word out, but asking for specific examples will likely get you better answers), favorite part and improvements of working on team / at company, how success is measured.

Lastly, if you want — ask for feedback on how you did during the interview. I’ve only done this a few times, and I don’t remember the reaction from it. A lot of companies won’t release feedback to you, so better ask it during the interview. A good way to phrase this is probably “how could I improve upon this interview experience?”

After the questions, the interviewer will likely close out with next steps, which basically means the recruiter you’ve been working with will contact you. And that’s it!

Interviewing is a lot of work and pretty intimidating sometimes, but lots of practice makes it more natural. I’d suggest that while doing Leetcode or Hackerrank, pretend you’re doing a real interview, so follow all the steps above (including talking out loud) to practice and hopefully doing so will make the actual interview feel a lot smoother. As another tip, stacking interviews you really care about at the end of your interviewing cycle gives you more time to practice on your own and with real interviews!

Hope this helps, and good luck!