Landing a SWE Internship: Acing Your Interview
Now that we’ve gone over how to get your foot in the door, we’ll be sharing our tips and tricks for behavioral and technical interviews!
Behavioral Interviews
Behavioral interviews (or just “behaviorals”) are almost always the first type of interview you’ll encounter during the process. These are usually much more chill than technical interviews, so don’t worry too much! You’ll be talking to your recruiter for around 30 minutes to an hour over the phone, and the topics will generally involve talking about your life and goals to how the company can help meet them.
This is also the interview where you’ll most likely be asked those standard interview questions such as talking about your greatest weaknesses or strengths. Following the general tips section below, there’s a more comprehensive guide on how to answer some of the more common questions that behaviorals tend to have.
If you get cut this round, don’t worry about it (really). It’s more likely than not that it was a decision due to the company culture, and it’s also likely that the company wouldn’t be a great fit.
General Tips
Behaviorals are a way for companies to see how you’ll fit into their company culture. Of course, this depends from company to company. As a result, a broad tip is to check the company’s website for information regarding their mission, culture, and values. Looking through Quora or Reddit posts written by people from a particular company can come in handy too.
You’ll want to show that you’re aligned with the company’s values. When you talk about your past experiences in any form, try to emphasize traits that exemplify those. If possible, make the connection explicit and mention that the similarities were the reasons why you applied to that specific company.
A big part of behaviorals is trying to see if you can keep the conversation going without too much prodding from the interviewer. It’s completely okay if the interview turns into something more of a conversation with questions and discussions from both parties. From the recruiter’s perspective, this will make you stick out since most people they interview don’t do this. Keeping a friendly attitude and asking deeper questions that spur dialogue can really help with this.
Towards the end of the conversation, you’ll be presented with an opportunity to ask questions. Make sure you’re prepared for this! Asking interesting questions is a wonderful way to stick out from other applicants. When you prepare for the interview, try to put some time aside to really look through the experiences that people from the company have had to ask questions that are unique and thoughtful.
The STAR Method
For some behavioral interview questions, you’ll be asked to give concrete examples of a particular action or situation that took place. A great way to structure your responses and keeping this in mind is by using the STAR method. Here’s a breakdown of how to use it.
S — Situation
Present the situation that you want to talk about, and set the stage. What was the context around what happened? Share relevant details that inform the story.
T — Task
Talk about what you were trying to solve or fix. In addition, give your responsibility or role within the situation.
A — Action
Mention what you did to address the task that you at hand. If you solved the problem as part of a team, talk more about what you did personally. Spend most of your time here!
R — Result
What happened as a result of your actions? Discuss how your action addressed the task. If you can, try to quantify your actions.
Technical Interviews
This is the tough one. Although every stage of the process is difficult, this one can be particularly stressful for students due to the time-limits, difficulty, and talking to people. However, technical interviews are easier than coding challenges in many cases. Cracking the technical interview comes down to two factors: preparation and the Triple-E method.
Overview
The technical interview is usually a 1-hour interview with a software engineer at the company going through an algorithms and data structures question. These interviews generally start off similar to a behavioral interview, so come prepared to talk about your past projects and experiences. In addition, try to form a strong human connection with your interviewer and ask questions.
After this, your interviewer will present you with the problem statement of the technical question. There’s a lot to unpack here, so make sure you ask questions when you want something to be clarified! Think of tackling the problem as something you do with your interviewer rather than for them. It’s a process that involves teamwork and questions, which are both traits that interviewers like to see in potential interns.
Keep in mind that the point of a technical interview isn’t to get the right answer. There’s often multiple approaches to difficult problems. As a result, working through a less-efficient answer with a critical eye and struggle portrays something better than getting the right solution in 10 minutes and not communicating. There’s several aspects to work on here, and coding is just one of them.
The Triple-E Method
The EEE method is something you can take advantage of in every technical interview. We’ll go over each part of it here, as well as explain why each stage has something that interviewers are looking for.
First E — Explain
When you’re presented with the technical question, make sure you understand it. Some problem statements are ill-phrased (potentially by your interviewer), but it’s your responsibility to make sure that you understand it well-enough to proceed forward. Asking for example inputs and outputs is important here, and if they’re not given to you, try to work them out as an example for yourself on the whiteboard. Don’t be afraid to ask clarifying questions before starting and throughout the process! Most interviewers will be happy to help.
Explain your thought process at every point in time, regardless of whether you think it’s a “good” or “bad” idea. If you can think up a brute-force solution as soon as you hear the problem, make sure you state it. This often starts a good discussion with the interviewer and really makes sure you know the problem. Drawing diagrams on the whiteboard (if there’s one nearby) can help you work through the thought process and generate potential strategies to attack the problem.
It’s completely okay to be stuck at this point as well. Feel free to ask for hints from your interviewer once you’ve communicated your ideas and approach to them. You won’t be penalized for this, and it’ll usually be taken as a positive sign of various approaches that you’re using. If you want to use a library or helper function, clearly state what it will do and ask if it’s allowed.
Once you have the idea that you want to work with, communicate it effectively. Once again, draw diagrams or write pseudocode if necessary, and make sure that both you and your interviewer know exactly how you’re intending to tackle the problem.
Second E — Execute
It’s time to execute the approach that you’ve chosen. Using the method that you communicated with your interviewer, start your coding. Don’t worry if you’ve chosen a particular algorithm that you think is potentially not the right answer.
Companies generally care a lot about the quality of the code that you output at this point. Writing clean code on the spot can be stressful, so make sure you take it line by line. You want your code to sound close to human language when being read out loud, so try to keep that in mind as you go through the process. Here are a few clean code tips that you’ll want to keep in mind:
- Name your variables and functions something meaningful — it’s okay if you take an extra moment to think about what an appropriate name would be. Single letter variables are not a good idea!
- If there’s time, write a quick docstring for the function. Likewise, write a comment documenting what a particularly strange piece of logic does.
- Use helper functions. Don’t put all your logic into a giant function: break it up at convenient parts and use function calls.
Sometimes, your interviewer will tell you that their interview process doesn’t require clean code. Even so, make sure you try to follow these ideas to some level to make sure your code is easier to follow when we get to step 3.
As you go through the process, you may realize that an assumption you made previously was incorrect. That’s completely okay. Let your interviewer know what the relevant error was (it’s possible they may have caught it already and not mentioned it) and work on discussing a new plan before executing.
Third E — Evaluate
The last step of the process is to evaluate what you’ve written. If you do this without much prodding by your interviewer, your initiative will really shine! First, work through the test cases you established in the first step to make sure that your algorithm is correct. If there’s something wrong here, try to debug the relevant parts that don’t work by using ideas from the first step.
Next, state your algorithm’s complexity. Remember that runtime complexity and space complexity are different concepts that you should mention. Don’t worry if you don’t know what these mean: make sure you bring this up to your interviewer so they can give you a helping hand here. This is also a great place to state if you made any tradeoffs between them and to bring up what these are. If you can, mention complexities of other algorithms that could solve the problem.
If you have time, work on making test cases that push your implementation to its limits. Try to take advantage of off-by-one errors or creating inputs that maliciously take longer to run. Explain each of these to your interviewer, and discuss if there’s something else that you can do to break the algorithm as you’ve written it.
Other Thoughts
As you’ve seen, technical interviewing uses lots of soft skills that go beyond simply solving the problem that’s presented to you. As a result, attending mock interviews if you have the opportunity can be especially helpful if it’s a skill you want to work on.
You’ll sometimes have an option to either whiteboard or live-code on a computer. Always choose to whiteboard! You won’t have to spend valuable time fixing syntax errors, and its easier to convey ideas on a whiteboard rather than simply talking to an interviewer. It’ll also be a lot easier to fix logical issues as you run through sample inputs and outputs instead of debugging your code manually.
If you’re given a choice of programming language, always choose Python! Python often expresses ideas in a concise manner that doesn’t involve lengthy statements like some other languages might. Of course, feel free to use another language if you feel you’re a lot more proficient at it, or if you’re applying for a particular role that requires skills in a particular language.
Closing Thoughts
Although interviewing for software engineering can be discouraging at times, keep in mind that practice makes perfect! Even if you are not able to land the next round or the offer, every interview you go through is great practice for ultimately finding your dream job. After all, even if you’ve crafted amazing responses to your behavioral interview questions, nothing is better than putting your skills to the test in a real interview.
Tune in to the final article in this series to learn more about the final steps of the recruitment process: going to onsite interviews, managing negotiations, and choosing between multiple offers.
Written by Nagaganesh Jaladanki
Edited by Kathleen Kong and Sahil Thakur
