How To Get A Job In Tech: Interviewing (3/4)
Cracking the behavioral and coding interview.
Have you ever failed a tech interview? I have failed a ton of interviews from behavioral interviews, phone-screens, and onsite whiteboarding questions. I can remember the embarrassing situations of having massive pit stains and having to restrict raising my hand to write code.
For the most part, I thought I was well prepared to face Interviews. But, I kept on failing interviews one after another. I realized that I didn’t have a set schedule and didn’t put in enough prep time and thought that coding experience in previous internships would help me crack these interviews. Well, coding interviews are a different beast. The test for algorithmic puzzles is very different from coding in real life, and therefore, one needs to prepare accordingly.
Interviewers want to work with candidates they like. Leaving a good impression on them improves your chances of success.
Tell me about yourself. How did you get into coding? Why was X(job-specific) a good fit for you? How do your goals align with X companies?
An elevator pitch is a short description of an idea, product, or company that explains the concept in a way such that any listener can understand it in a short period. This description typically explains who the thing is for, what it does, why it is needed, and how it will get done: imagine you are stuck in an elevator with someone who you want to sell yourself to. You have about 30 seconds to a minute to get your point across.
- Keep it short
- Get straight to the point
- Grab their attention
For example, for internships, you can say your name, school, area of focus, and past internships/noteworthy projects. For full-time positions, you should mention past-companies, note-worthy projects, etc.
My name is Gautam and I’m currently a student at CSU Monterey Bay. I have previously interned at the Museum of Natural History, where I developed an application that visualizes climate change in Monterey county, which is used by over 50 researchers.
I became interested in the mapping space because I loved the power of spreading a message across using a Map. Since then, I have been working at learning X tools and researching X possibilities, which is when I came across Uber maps. I’d be grateful to speak with you about X opportunity.
With an interviewer, you must always ask the question: Why do they want me? Align yourself with the values of the company, understand what tech-stack they use, read their engineering blog, and impress the interviewer.
The first assumption is that you know how to code. You know a language that you are familiar with and (hopefully) know it thoroughly.
This article covers a general tech-interview blueprint: Behavioral interviews and technical interviews. It does not cover specific area questions like web development, embedded systems, etc.
Assume that to cover preparation end to end; you will need a full month of dedication, spending 2-3 hours a day prepping. You can increase or decrease that based on your experience.
- Cracking the behavioral interview
- Cracking the technical interview
- Practicing mock interviews
Now that you have a good understanding of what to cover, let’s dive right into it.
You’ve spent hours crafting your resume, applying to jobs, and practicing coding. Now the time is to put your skills to test. In this section, we will discuss how to crack the behavioral and coding interview and what type of questions you can expect.
Later, we will talk about what to do and what not to do during each type of interview, followed by tools that we can use to help us succeed.
Succeeding in an interview involves more than just technical skills. Behavioral interviews are crucial, and their level of difficulty is directly proportional to how much experience you have. Senior engineers are expected to lead, strategize, and mentor with other engineers, and therefore the bar of people skills is much higher.
You might be a talented SWE, but if you cannot work well with others, you will not be an asset to the company. There is a surplus amount of talent in the valley, and therefore companies want to hire talented-engineer with people skills they don’t want to hire brilliant jerks.
The company is more than happy to find a lesser talented engineer than someone who cannot work well with others, which can cause the team to be worse off, and behavioral interviews are one way of determining if someone will be useful to work with from a non-technical standpoint.
Pretty much all tech companies in the bay area have behavioral interviews. When I interviewed with Salesforce, they had three behavioral interviews. One before even the remote technical challenge and two during the onsite interviews.
- Any project on your resume is fair game. Be able to talk 30-40 minutes about it.
- Talk about how you faced a challenge and how you overcame it.
- Example of what you did and what it resulted in.
- What are you looking for at Salesforce and why this role?
The technical interview, whether whiteboarding or remote boils down to the same things:
- Can you solve a problem?
- Can you solve it efficiently?
- Can you communicate your thought process well?
Most coding interviews boil down to Hashmaps, DFS/BFS - Nikhil Dev
It’s time to review the basics: Data Structures and Algorithms.
List of The most essential Data Structures and Algorithms:
- Arrays and HashMaps
- Linked Lists
- Kadane’s Algorithm
- Djikstra’s Algorithm
The important thing here is to know all the technicalities of a data structure in a language that you are comfortable with. Knowing the data-structure well gives you the ability to solve questions that you haven’t faced before.
How to solve questions: The way I approached solving problems was by setting a time of 1 hour for each question. No Matter what, after 1 hour, I would stop, and this was to replicate an interview setting. I would try to solve a problem for 30 minutes, and if I couldn’t, I would look up the solution and code it up in the last 30 minutes.
Take note of the question that you had to look up and try to solve it again without looking the next day and then one more time after a week. Make sure that you’re comfortable with it.
A great source that I found that someone created a curated list of 50 or so questions on Leetcode and this list is by far the best out there. I have seen the same pattern of questions being repeated over and over in interviews just with a different language.
How many questions should I do?: My suggestion would be to approach the Breadth of problems rather than the depth. What I mean by that is try multiple variations of different data structures and algorithms as opposed to going deep in just one topic (say, Arrays).
Now, you are ready to put your skills to test! In a coding interview, you will be given a programming question by the interviewer, and you will code it in real-time using an Integrated Developer Environment (IDE) or using a Whiteboard(onsite). The time for a question is usually 30-45 minutes with 10-15 minutes reserved for asking questions at the end.
- Find a quiet environment where you won’t be disturbed.
- Use earphones or noise-canceling headphones and avoid using inbuilt speakers.
- If you don’t have a laptop and need to use a phone, let the recruiter know beforehand.
- Make sure you have a pen and paper in hand to write the question down.
The interviewer will usually spend 5 minutes asking you to tell them about yourself. Make sure you are prepared with an elevator pitch.
The next step is receiving the question. Most candidates at this stage will jump to coding without clarifying the question. This can be a fatal mistake because the question might usually contain hints or aspects of the problem that you need to understand. Before coding, take a deep breath and repeat the question back word-to-word to make sure you got it right.
Try to ask questions regarding possible edge-cases(discussed below) and try to understand the question end-to-end. Some interviewers omit details to see if you can notice that and ask questions.
Before you code, explain your high-level approach to the interviewer. Make sure you explain the brute force solution and state it’s time and space complexity. Don’t jump into an optimized solution just yet. Most likely, the interviewer will ask you if we can do better? Now state another solution that you know and again state the time and space complexity.
After you both have agreed upon a solution: Ask if you can code the solution out.
This is how an example might look like:
Interviewer: Write an algorithm that accepts an array and a target number as inputs. Your goal is to find two numbers that add up to that number.
Me: So, I’m writing a function that accepts an array and a number as arguments and two numbers in the array add up to the number?
Interviewer: Yes, that’s correct.
Me: Okay, is it guaranteed that two numbers add up to the target?
Interviewer: That’s a good question. Yes that is guaranteed.
Me: Okay, What about an empty array, infinitely large numbers, NaN target, Infinity as inputs?
Interviewer: If you get an empty array, throw an exception, and for others, assume you just get real numbers as inputs.
Me: Thanks. I think I have a solution in mind. I can run two-for-loops one that points to the first number and the other that iterates from the second onwards and keeps checking if it adds to the first number and if not keep checking every subset until the target is reached. The time complexity would be quadratic (O(n^2)), and space would be O(1).
Interviewer: Great. But do you think we can do better than quadratic time?
Me: Umm, I guess, We can throw the list of numbers into hashmap where insertion is O(1), and as we add an keep checking if target + added number is in the hashMap until we get to a solution. The time complexity would be Linear (O(N)), and space complexity would be O(N).
Interviewer: Yeah, that sounds like a good solution! Let’s code it up.
It’s completely natural to be stuck during an interview. I remember one interview where I was completely lost, and the interviewer didn’t want to give any hints, so I just stared at him and the whiteboard for 45 minutes.
But don’t worry, this is just a part of the process and here are something’s you can keep in mind when you are stuck:
- Talk through what you initially thought and explain why it doesn’t work.
- Talk about all the data-structures that you can use and whether they can be applied to the question.
- Try to think of questions that you think might be related to the question and communicate to the interviewer.
- The worst case, it’s better to let the interviewer know that you don’t know the answer and in that case, the interviewer can help you with tips or even ask a different question.
It’s important that you don’t just announce that you are done. Always keep questioning every line of code. Ask the interviewer is it okay if I run through a couple of test cases to see if the code is working?
Walkthrough your code and try to break it every way you can think of. If the interviewer is happy with your solution, the interview ends here. But there is one last thing which is important.
If there is time left, ask your interviewers questions that you have prepared. Questions specific to their work would be great or questions about the company, team, etc. Questions to ask interviewers
- Do: Dress well. This is a weird one. Most engineers don’t care how you dress, and the dress code in silicon valley is casual as already, but some (older) interviewers make a decision based on how your appearance is.
- Do: Start the interview by greeting the interviewer and trying to make an excellent first impression. Be confident.
- Do: Listen to the interviewer carefully. A lot of times, the interviewers drop hints in their questions. (Ex: The list is sorted which means that you can do the problem in a time better than O(N log N))
- Don’t: Do not under any circumstances assume anything about the question on your own. If you have a doubt, clarify it!
- Do: Ask about edge cases! spend at least 5 minutes clarifying all the edge cases that come to your mind (What happens if a list is empty?) ** We will discuss a list of edge cases below.
- Do: Have a Brute force solution. Never assume that it’s too simple, and the interviewer doesn’t care about the brute force. The interviewer wants to see that you are capable of coming up with different solutions and iterate on it to make it better!
- Don’t: Keep quiet during the interview. Even if you need time to think, let the interviewer know.
- Do: Communicate what you are thinking! It is very important to keep talking during the interview. Let the interviewer know what your approach is and what you plan to do next. I cannot iterate how vital this point is.
- Do: Let the interviewer know if you cannot solve the problem. Usually, you know within 10-15 minutes if you can solve the problem. It’s essential to let the interviewer know so that he/she can give you a hint, or give you another question! [You might face some interviewers who want to see you struggle: screw them. A good interviewer wants to help you out, so believe that.]
- Do: This is extremely important and cannot be stated enough. Have questions for the interviewer at the end. No Matter how you did, have questions that you have researched about them, or have great questions about the company! This really-really shows your interest.Questions to ask interviewers
Some of these things might not be as highly ranked as solving the problem, but we want to be able to control every aspect of the interview, including impressions and leave nothing up to randomness.
String Questions - Empty String, If all characters are same, upper/lower case chars, ridiculously long strings, if spacing matters, odd/even length.
Number Questions - If the number is: 0, negative, infinite, floating-point, huge values, smallest values, NaN.
Array Questions - If list is empty, null. Can the array wrap around? Worry about Time-amortization — Dynamic Arrays take O(N) time to insert when array size has been reached, and therefore capacity must be doubled.
Other DS - Null, Head/Root does not exist.
General - How big is the range of values? Are there Duplicates? How is input stored [If given dictionary of words is it a list of strings or a Trie]
Interviewing is a skill that you can get better at. The steps mentioned above can be rehearsed over and over again until you have fully internalized them, and following those steps become second nature to you. A good way to practice is to find a friend to partner with and the both of you can take turns to interview each other.
Mock interviews are probably the most critical aspect of interview prep. Getting used to the nerves during the interview isn’t easy. It isn’t easy to just go up there and start talking. It takes practice because INTERVIEWING IS A SKILL.
- Pramp: Practice Mock Interviews with peers for free.
- interviewing.io: Practice Anonymous interviews.
- ME: Email me (Buy me a coffee), and I’d be happy to help to chat about interviewing or even conducting mock interviews — In-person and Remote :)
Preparing for Interviews is tough. I know, I failed dozens of interviews and prepared for seven months day in and day out after I graduated college before I joined Salesforce. I realized that Interviewing is a skill that needs to be mastered.
It’s easy to feel nervous right now, but trust me, it’s a numbers game. Keep interviewing, keep practicing, and block all other noise out. It doesn’t matter what people say, what family says: You are good enough to work here. All it takes is a lot of practice and a bit of luck.
I’d love to hear about any job updates, or if I can help in any way so, please reach out at My Email.
The last part of the series covers Negotiation. See you there!