👔 Interview Advice for Computer Science Students ❓

There are a million interview guides out there, but I wrote this because people kept asking me for advice

April 16, 2024, Last Modified: July 27, 2024

I do not claim to be good at interviews, nor do I really have any science to back up my claims, nor do I know what actually happens behind-the-scenes in the hiring process.

Everything I write here is based on my personal experience, and personal opinion, which may not be applicable for your situation, or worse, straight up factually incorrect.

I only wrote this because I realized giving people this as reference would be more helpful than me telling several people the exact same thing.

Interview processes differ greatly between companies, so do your research beforehand! Read up about the company's interview format online, ask past interns, ask current interns.

Typically, there are two main parts of an interview, the behavioral, and the technical portion. Some companies may only do one, some may do both, it depends so again, do your research.

That being said, you will pretty much always be asked some variation of "Tell me about yourself" so just because you only have a technical interview doesn't mean you only need to focus on leetcode!

A few pieces of advice:

1. Use the STAR method or something similar, I wasn't a believer until I tried it.
2. Come up with scenarios and sample answers for common behavioral questions ahead of time. I found that while I had good examples to talk about during behavioral interviews, I struggled to think of them on the spot, especially if the examples were older. So before interviewing, I review my document where I have a list of common behavioral interview scenarios mapped to an example. (e.g. "tell us about a time when you had to learn something new -> project X, had to learn framework Y").
3. Pick good, unique examples, and be specific. Your interviewers probably don't want to hear about how you had some conflict in your group project and how you resolved it through communication. Be specific, describe the situation with sufficient detail that it's not so generic, and give concrete examples.

Practice with a friend!

Just because you're good at leetcode or whatever doesn't mean you're automatically good at technical interviews; doing the question is just one thing, engaging with the interviewer while solving the problem is another.

Coding only is half the battle, for the other half you should be talking to the interviewer. For a significant portion of your technical interview, your hands shouldn't even be on your keyboard!

Here is my personal step-by-step formula for technical interviews:

1. Receive the Problem: Depending on the interview, you may be shown a problem, or you may be given the problem verbally. If you're shown the problem, read it out loud, and if you're given the problem verbally, start typing it up on the coding environment as a comment.
2. Clarify the problem: Confirm with the interviewer that you fully understand the problem, and clarify any ambiguity. If the wording is ambiguous, ask! (e.g. by connected, are we assuming that they share an edge, or they share a corner?). You'll often have to ask for clarification on the input as well (Can we assume the input list is non-empty? Can we assume that the integers are non-negative? etc.). Additionally, if they didn't provide any examples, give a sample input / output pair to make sure you understand the problem.
3. Think of a solution: Take your hands off the keyboard, you should be talking to the interviewer at this stage, not coding. If I can't come up with an efficient solution immediately, I like giving an inefficient solution to buy myself some time while thinking of a better solution. Maybe while talking about your inefficient solution, you might come up with some optimizations to make it efficient! (e.g. say "The first thing that comes to mind is _, which is not necessarily an efficient solution."). You should keep talking at this stage; if you're stuck, communicate what you're stuck on, don't sit there in silence! (e.g. "I'm currently thinking of _, but it's not a perfect solution because of _"). By communicating your ideas, your interviewer can look into your thought process and might even drop a hint!
4. Confirm the solution: Once you have a solution in mind, you should talk about it. Your hands should still be off the keyboard! Explain your approach at a high level, and get confirmation with your interviewer before you start coding. (e.g. "I think this is a good solution, I'll start coding if you don't mind.").
5. Write the solution: You can put your hands back on the keyboard now. Write up the solution, but make sure to engage with the interviewer while doing so! Talk them through what you're doing (e.g. "Here, we'll handle the case when x is out of the boundary"), but don't just read out the exact code (e.g. "So, if x is less than a or x is greater than b, ..."), they can read that themselves!
6. Look through your code: After you're done writing the code, look through it to make sure you haven't made any mistakes. You should still be talking with your interviewer.
7. State the Time and Space Complexity: State the time and space complexity of your code, and explain how you got there at a high level.
8. Try some basic test cases: Try some test cases! Write a few basic test cases, and verbally explain why that input would give that output. If your interview provides you with an environment where you can actually run your code, run it. If they don't, or they don't want you to, take the input and follow it through your code.
9. Debug: You might have found a few issues with your code while trying the test cases. Make sure to keep talking during the debugging process!
10. Follow-up Questions: Your interviewer is likely going to ask you some follow-up questions regarding your solution whether that be "could we make this more efficient", or "could we make it so it handles this case instead?". Just make sure to communicate your thoughts effectively.

1. Do your research on the company to see what language they prefer, and ask the interviewer. Most companies aren't going to really care what language you use as long as you don't use some esoteric language. In that case, use something simple like Python, or whatever you're most familiar with. However, there are some companies that want you to use a specific language, probably C++. Do your research and get familiar with the C++ standard library if this is applicable to you.
2. It's okay to get hints! I've passed interviews with hints. What's not okay is not saying anything so the interviewer doesn't know what hints to give you.
3. It's okay if your solution isn't optimal. While this isn't ideal, it is much better than getting so worked up over trying to get a perfect solution that you end up writing nothing.
4. Practice, practice, practice! Regardless of if you're a leetcode god or whatever, without practice you're probably not going to do so well. Grab a friend and take turns interviewing each other, taking note of any long, awkward pauses. I like using the LeetCode Interview platform for this.
5. Try and lead the interview. Rather than ask your interviewer for what to do, tell them you are going to do something and get confirmation. For example, instead of asking "okay, I've completed my implementation, what should I do", ask "now that I've completed my implementation, unless you had any questions, I'm going to write some tests, is that alright with you?". Of course don't steal the interview and just do everything yourself, but definitely don't sit there waiting for instructions.

• Show up early! 5-10 minutes at least.
• If you're doing an online interview, try and clean up your background. I know that this may be difficult depending on your living situation / room layout, so be clever! I've tried putting a wooden closet behind me to make it look like I'm by a wall without having to move my desk. If you're in ASIP you can book silent interview rooms at the ASIP office which actually are pretty darn nice.
• Research your company to figure out how you should dress for the interview! Depending on the company, you might wear anything from a t-shirt to a full suit and tie.
• Drinking water can be a great way to stall when you're trying to think of a response to a question. Of course this only works in in-person / video interviews!