The Famed Technical Interview

What the technical interview is really like for Software Engineers…

13 min readAug 22, 2022

Background

As you may know by now, I’m a NYC kid through and through. I went to some of the most diverse schools in Brooklyn from kindergarten up until college. This diversity is not only in race, but also ethnicity, socioeconomic background, and passions. So naturally as an adult, I know people in many different career paths. This includes medicine, entertainment, business, and so much more. The thing about the software and technology path is that it is such a new space for one to make a living. As a result, many people have no idea what it’s like to work in this space or even what to expect when trying to make it in this space.

I’ve interviewed with dozens of technology companies from FAANG (or MAANG) to financial companies to the most niche startups. So everything I share in this post comes from my personal experience during the process as well as stories I’ve heard from my colleagues and friends. In this blog post, I’m going to break down one component of the process to getting your foot in the door of a technology company. The component that there are the most complaints about. Everyone’s worst nightmare. That is… the technical interview. You’ll become very intimate with what to expect on the three sections of the interview: Behavioral, Technical, Reverse Interview

Behavioral Section — 5 to 20 minutes

Good afternoon! My name is Chuma Steve Okoro. I’m a Nigerian-American problem solver based in New York City. This is how I start almost every interview because they always start the same with some form of introduction. It makes sense too because you’re talking with someone you’ve never met before so naturally, you’d introduce yourself. Often times, interviewers like to start with something along the lines of “Tell me about yourself and your background”. Some things to keep in mind are:

This is a technical interview, so make sure you share something about your technical background
Your interviewer is a potential coworker and a human being. The more relatable you are and the more they like you as a person, the more likely they’ll want to work with you. So try to mention something about you as an individual.
You don’t have all the time in the world so try to keep it short and sweet… like an elevator pitch!

My elevator pitch will usually sound something like this (depending on the amount of time I have and the context):

Good afternoon! My name is Chuma Steve Okoro. I’m a Nigerian-American problem solver based in New York City. I graduated from Brooklyn College in 2019 with my Bachelor’s in Computer Science. At school I was an active member of several executive boards including the Computer Science Club, Black Student Union, and the Radio Station. In addition to staying active on campus, I also made sure to be active off campus attending hackathons and completing internships with companies like Mastercard, Con Edison, and Justworks. After college, I decided to work at Etsy as Software Engineer. Over my almost 3 yr span with them, I worked on the API’s for the mobile app to develop core features and bring tremendous value to the organization. From there, I moved on to Amazon to work on the the Shopper Panel app. Here, I have continued to design and implement solutions to existing problem; or new ones to support the validation of receipts and mapping of products. In my free time, I like to bike around NYC, write articles/code, and spend time with friends.

With a good introduction about yourself, it makes it easy for the interviewer to ask some natural follow up questions. Some of the ones I’ve received in the past include:

What’s one of the most difficult problems you’ve solved during your time at Etsy?
Tell me about a time you had a disagreement with someone and how you resolved it. This could be a co worker or a peer when you were on campus as a student leader.
Could you share how you designed one of the technical projects you’ve built in the past? What tradeoffs did you consider? Did you face any roadblocks?
Tell me about a time you made a commitment that you couldn’t deliver on

If you scour the internet, you can find a bunch more. The biggest recommendation I would have for this section is have a handful of stories and projects on deck in advance. Recall the important details of them as if you were telling a buddy about the story and be ready for questions. You may have also heard about the S.T.A.R method which I think is useful here too. This acronym stands for Situation, Task, Action, and Result. If you can recall these 4 things about each story/project, you’ll be sure to do well.

Technical Section — 35 to 50 minutes

This section of the interview is the part that I personally have the most trouble with. Even engineers with years of experience making hundreds of thousands of dollars still have trouble with these interviews. From my perspective, this is because they truly are analogous to riddles. You’re posed with a problem to solve from the interviewer and they want you to come up with a process to solve it (an algorithm). So to best describe this process, let’s use the very first Leetcode (a platform that hosts common technical interview questions) question as an example: 2 Sum

If I give you a list of numbers (let’s call that nums) and a single number (let’s call that target), can you tell me the location in the list of 2 numbers (nums) such that when they are added together they equal the single number (target)?

So the first thing to note about this section is what the interviewer is looking for. I used to conduct technical interviews(and probably will continue to do so in the future). What I was looking for and what most interviewers are looking for include the following:

ability to scope out a problem. If you go to ask your friend for advice and tell them the very basics of your problem, do you expect them to jump right into the answer? No! You would expect them to ask you follow up questions about the background to the problem, your goal in a solution, etc. Do the same thing with the technical section. Before jumping into the problem ask about some example inputs, how this solution will be used, how to handle weird inputs, etc.
ability to take feedback. Remember that if you got to this stage, the interviewer wants to see you succeed. So if they see you struggling, they might offer some hints or constructive criticism. The worse thing you could do is ignore them or take offense. Listen to what the interviewer is saying because chances are, they want to see you win.
ability to communicate. Keep in mind that the interviewer is trying to see if you’re a good candidate to have as a coworker. As an engineer, we work on a team towards a greater mission. And it’s no fun working on a mission with teammates that you can’t talk with. So while you’re solving the problem, make sure you’re staying engaged with your interviewer. Let them know what you’re doing at all times whether you’re trying to decide between 2 potential approaches, googling the syntax of a function, or just trying an example.

So how might I start with the 2 Sum question? First thing I’d do is ask the interviewer for an example to help me better understand the question

Example:
List of numbers could be: [2,7,11,15] The target number could be: 9
The answer in this example would be: 0 and 1
Why? In technology, instead of starting a list off from 1, we start from 0. This means the 1st position would be 0, the 2nd would be 1, the 3rd would be 2 and so forth. So looking at the example, the first 2 numbers (2 and 7) are equal to the target number (9). That is why the answer would be 0 and 1 (because the number 2 is in position 0 and 7 is in position 1).

That’s pretty good to understand the general problem, but before talking about potential solutions let’s ask a few more questions.

What happens if you give me an empty list?
What if no numbers in the list add up to the target number?
Will there be negative numbers in the list? decimals? duplicates?

And even with those questions I would come up with a more interesting example with more numbers and where the solution isn’t right at the beginning of the list. For me, this makes it easier to point out edge cases.

Example:
List of numbers could be: [-9, 17, 1, 2, 11, 15, -4, -100, 7] The target number could be: 9
The answer in this example would be: positions 3 and 8
Why? Because the number in position 3: 2 and the number in position 8: 7 add up to equal the target number 9

Now what? Before any code, I might walk through this example with pen and paper and try to figure out the answer manually. The first thing that comes to mind is to try each combination of numbers. It would go a little something like this…

With 1 pencil, I’ll point at the first number in the list. With the 2nd pencil, I’ll point at the second number in the list and check if it equals the target. If they don’t I’ll move the 2nd pencil to the next number
Ex: Add and compare -9 and 17. Do they equal 9 when added? No so let’s move on. Add and compare -9 and 1. Do they equal 9 when added? No so let’s move on. Add and compare -9 and 2. Do they equal 9 when added? No so let’s move on. You get the point…

Once I’ve tried every combination with the first pencil on the first number, I’ll try every combination with the first pencil on the second number. The second pencil will start like before on the number after the first pencil.

Ex: Add and compare 17and 1. Do they equal 9 when added? No so let’s move on. Add and compare 17 and 2. Do they equal 9 when added? No so let’s move on. Add and compare 17 and 11. Do they equal 9 when added? No so let’s move on. You get the point…

Eventually with this approach, I’ll find number 2 and 7 which are equal to my target number 9. Congratulations! That entire process was an algorithm: a set of steps to solve a problem. While going through that whole process, you might have seen a way to solve the problem faster and if so you should call that out. Interviewers love when you try to make your solution better and depending on your level and years of experience, they may even expect it. If you do optimize, you should do they exact same thing we did above with your example and your new algorithm to solve the problem.

Now as a software engineer, most interviewers will expect you to know how to write code and translate your solutions such that a computer can understand them. But before I write any code, I like to ask the interviewer whether they feel comfortable with me starting to write some code. This is key because if they haven’t given you any feedback yet, they might offer you some now. If they tell you “ yes you can start coding now”, it’s fair to say that you’re on the right path. If they say we might be able to do better with our solution, you might want to try and optimize your solution before you start to code.

Now while your coding, communication is so key! Basically, just speak out loud as you write every line of code. Sometimes I imagine my interviewer has blindfolds on and still needs to know what I’m coding. The solution we came up with would be called a “brute force” solution. It basically means try all possible solutions until you get the right one. This is usually the least optimal solution and is usually not satisfactory. That being said, many people in the tech industry recommend you still do it as your first solution before optimizing. That way if you’re stuck or running low on time, at least you have something that solves the problem. Here’s what some code might look like to implement that brute force solution (in Java).

public int[] twoSum(int[] nums, int target) {
   for(int i =0; i<nums.length; i++){
      for(int j=1;j<nums.length; j++){ 
         if(nums[i]+nums[j]==target  && i!=j){
            int [] sol ={i,j};
            return sol;
         }
      }
   } 
   return new int[2];
}

Below is some more code to optimize the above code on time complexity (more on that later), but this time in python.

def twoSum(self, nums: List[int], target: int) -> List[int]:
   num_store = {}
   sorted_nums = sorted([(num, index) for index, num in enumerate(nums)])
        
   for index, num in enumerate(nums): 
      diff = target - num
      if diff in num_store:
         return [index, num_store[diff]] 
      else:
         num_store[num] = index
   raise Exception("we can't find it")

After you come up with any solution, it’s a good idea to talk about the time and space complexity of it. That’s a bit more detailed than I would like to get with this blog post so we’ll save that for another day. This post does get in detail with it if you would like to learn more.

Now at the end of all this, if you have time, your interviewer may ask you a few different things:

Another technical question. The one above is a “Leetcode level easy” question so chances are only an intern or entry level engineer would receive it. If you’re more senior and they ask this, they probably wanted to ask you 2 questions.
They may ask you about scale. Think: What if instead of 10 inputs, you got 20 million inputs? What if you need to solve this problem in 100 countries? etc. They may try to see how you would deal with a change in scope, how you might improve the running time, how you may set up your infrastructure to solve this problem for the markets of the business.
They may switch up the problem itself. For example instead of just adding 2 numbers to get the target, what if it were 3 numbers to get the target? How would you update your solution? (3sum)

When your interviewer is content that he has a grasp on your technical skills, your interview is nearing the end. (Finally!!)

Reverse Interview Section — 5+ minutes

So I like to think of the last 5 minutes or so as revenge time (I kid I kid)! For the last almost hour you’ve been on edge, nervous, and sweating. Now that we’ve reached the end, interviewers will almost always ask if you have any questions for them. If you have no questions, you basically failed this portion in my opinion. If you want to work at this company, you should want to know about the company just as much as they want to know about you. Here’s your chance to ask the interviewer some questions about themself and the company. Here are some stuff that I might ask:

If the interviewer has worked at company X for a really long time, this is big. Engineers have some of the highest turnover than any other career so I might ask them something like “What has kept you at company X for so long?”
If there was something you could change about company X, what would it be?
What types of problems would I work on if I have success in the interview process and start with company X?
If the interviewer is a people manager and would be yours if you get through the process and accept the role I might ask something like, “What is your management style like?”
Looking on the company’s website is usually a good idea if you’re interested in a company. If you see something interesting on the site maybe about their culture, their problem space, or some recent press… ask away!
What are the next steps for me in this interview process?

With some luck, hopefully you hear back from a recruiter and you progress on to the next stage!

You’re done! Remember to stay professional no matter how you think the interview went. If you did well, you’ll hear back from the company. If not, hopefully you still hear back from them with some feedback, but don’t expect it. Some companies decide to just go ghost if they decide not to move forward after the interview. Or even if they do let you know, they won’t give any feedback. Don’t take it to heart! Take the experience as learning for the next interview and stay optimistic. I’ve failed a bunch of interviews and have passed a bunch of interviews. Often times when I go on a streak of passing interviews, they come right after a streak of failing interviews. In my opinion, this is because no interview preparation is as good as a real interview where the stakes are on the line. I’ve also found the people who are the best at interviewing (or really anything for that matter), tend to be the ones that have failed a bunch. This could be the best bikers, entrepreneurs, chefs, etc.

Thanks for reading! If you enjoyed this article, please make sure that you’re following me to stay updated with more content. To my fellow techies, feel free to share your story in the comments or let me know if there’s something I missed.