4 Questions Good Software Engineers Ask During a Technical Interview

4 Questions Good Software Engineers Ask During a Technical Interview

Β·

11 min read

Imagine you find yourself in a technical interview where you are given a problem; be it an algorithm design problem, a system design problem, or enhancing an existing feature. What will you do first?

Will you immediately dive into solving the problem or will you zone out as you try to think through the problem?

More often that not, a lot of people immediately go straight into trying to solve the problem. Some others will zone out in a bid to think through the problem while the good software engineers start by asking questions in a bid to understand the problem better because they know and understand the importance of asking the right questions and the role it plays in helping to develop the most optimal solution to a given problem.

You are a good software engineer, and that's why you are reading this article.

And so in this article, I will highlight 4 important questions that good software engineers ask during technical interviews. Using this knowledge, we will then see how this technique was/was not applied by the 30+ folks who took on the algorithm challenge for Week 4 of Algorithm Fridays.

It is important to note that these questions are not just suited for technical interview scenarios. Since technical interviews are mostly around solving problems, the lessons learned here can be applied to any problem-solving situation, which happens even while on the job.

So let's get started.

Conversation over Correctness

If you were asked what the main value in a technical interview is, would you say the value is in being able to solve the problem you are given or would you say the value is in the conversation that happens between you and your interviewer.

Which would you pick?

One of the things I learned from doing 60+ technical interviews in 30 days is that the real value in technical interviews is not the correctness of your solution or your ability to come up with a solution, it's the conversation that happens during those interviews.

Did I hear you say "wait, what?"

I know what you just read may seem counter-intuitive at a first glance but think about it.

I should however mention that by technical interviews, I am not referring to the 45-minute coding challenges, from Hackerrank or the likes. I'm referring to interviews where you engage with another person while solving a technical problem.

For those kind of interviews, yes the conversation that happens between you and the interviewer is more valuable than just solving the problem.

One reason for this is because more often than not, when a technical problem is presented to you, there might be some assumptions that you may have made about the problem. So, it is important to ask questions to validate or invalidate your assumptions before jumping right in to solve the problems.

Not doing so could prove costly in terms of time and effort as was the case during one of my interviews where I had assumed the input type, and had developed a solution only to find out later that it was a different type. Needless to say that my assumption cost me the interview because the amount of time I had spent in trying to develop the initial solution was gone.

Another thing to note is that, when you ask the right questions, you are indicating to your interviewer that not only do you recognize the need to clarify the problem statement, you also are a team-player.

Here's an excerpt from the article I wrote on the lessons I learned from doing 60+ technical interviews in 30 days:

Yes, your interviewer wants to see that you can come up with a solution, but one thing you must not forget is that they also want to see that you can collaborate with other team-mates to come up with a solution. While companies want rock-stars, they also want team-players.

I hope that by now you are already beginning to see the value in asking questions. I also imagine that you are already asking, what are some of the questions you could ask. That's exactly what I'll be sharing in the next section.

Walk with me. πŸšΆπŸ½β€β™‚οΈ

Questions to Ask Your Interviewer

Good software engineers understand that part of developing a solution to a problem is testing every assumption you have made about the problem.

So here are examples of questions that good software engineers ask:

1. Questions about the input data

Good software engineers ask clarifying questions about the data to be processed. For example, if you are asked to write a function that transforms some input, you should ask the following questions:

  • What is the data type?

    • Is it a string, a number, an object?
    • If it is an array for example, can the array be empty? Can the array contain different types of elements? For example in JavaScript, can you have a string and a number in the array?
  • What is the data size?

    • How big is the input data that we are processing?
    • For example, if it is a number, how big can the number be? This is very important to know because some operations can't be carried due to overflow errors if the number is very big.

2. Questions about robustness

As a good software engineer, your aim should be to develop a system that is robust, can handle unexpected/invalid input without failing.

Some questions to ask include:

  • Can the input data we are processing have some unexpected values like null or could they be undefined?
  • How should we handle runtime errors? It is important to always check in with the interviewer to note how he/she wants you to handle the errors so that you don't spend a lot of time on it. For most interviews I've had, it was mostly enough to just talk about how you will handle the errors; the interviewer rarely asked me to code it up. However in some other ones, the interviewer wanted to see how I would make my solution more robust.

3. Questions about implementation & trade-offs

Good software engineers know that every solution comes with a cost and there are always trade-offs. If you design an algorithm using arrays instead of hash maps, there is a cost to it. It is important that you understand these and its trade-offs so you can ask questions around this.

This category of questions is mostly important for system design interview questions.

Here are some sample questions to ask:

  • Is there a reason why one implementation method is preferred over another? For example, recursion over iteration? This may give you deeper insight about the problem.
  • Is there a data structure you would prefer? One reason to ask this question could be to demonstrate your knowledge of different data structures that could be used for solving a problem.
  • Is there an acceptable performance threshold? This is a really important question because while we can hope for the most-optimal and perfect systems, it is rarely possible in practice. So it is important to clarify what is tolerable for the solution you are designing. For example, if it is okay to develop a O(N log N) solution, or can we build a system with a 5% latency? This would help you decide on what implementation methods to use in developing the solution.

4. Questions about scale

Not all interviewers may need you to implement scalable solutions but most certainly, all interviewers will be impressed when you ask questions about scale.

These set of questions basically focus on clarifying how your system should behave when the amount of data to be processed as input increases significantly, or if your system

Examples of some questions to ask include:

  • Do we expect that the input can increase significantly? For example if you had a in-memory solution that worked for processing 100 entries, you may want to rethink that if you are processing a billion entries.

Having gone through some of these questions, let's look at how we can apply this to an algorithm problem that was posed to participants in Week 4 of Algorithm Fridays.

Sample Application

The image below shows the algorithm problem for Week 4 of Algorithm Fridays.

Algorithm Fridays Week 4.png

Applying what we have learned, what are some of the questions we could ask about this problem? Anybody?

  1. What is the expected input type? That's answered already in the question - an array.
  2. Can the array contain different types? Again, that's answered already in the question - an integer array, so we know the array is made of numbers.
  3. Can the input be null or undefined? The answer to this question is yes, because we have no control over what values are passed into the function. This tells you that your solution should be robust enough to handle unexpected/invalid input cases.
  4. What kind of numbers does the array contain?

This last question is really important because if you assumed that the input array was made of positive numbers only, you would come up with a solution like this:

const productExceptSelf = (nums = []) => {
  if (!nums || nums.length == 0) return []

  // Step 1: Find the product of all the numbers first
 const product = nums.reduce((acc, num) => {
    return acc * num
  }, 1);

  // Step 2: Loop through each entry in the array and divide the product by the entry
  nums.forEach((num, index) => {
     nums[index] = product / num;
  });

  return nums;
}

The problem with this solution is that when you have an input array where one of the elements has a value of 0, for example nums = [4, 3, 0], this solution fails.

Can you see the reason why?

If one of the entries of the array is 0, the product of all the of all the numbers of in the array will be 0, leading to the result (in JavaScript) shown below:

productExceptSelf ([4, 3, 0]); ❌ // should return [0, 0, 12] but returns [0, 0, NaN]

Now we know we should handle the edge case for when one of the elements is 0, but before we rewrite our solution to handle the zero check, let's think about the problem a bit more deeply.

What if our array has more than one element whose value is 0, will that affect the final solution we come up with?

Yes, because if we have an array with at least two elements with a 0 value, the final result should be an array whose elements are all 0. How? Let's look at the image below:

Two+ 0-element array.png

The image shows us for each position i in the result array, the product of all other numbers except nums[i] will always be 0. So we can deduce that when there are at least two elements in nums with a 0 value, every element in the final results array will be 0, thus eliminating unnecessary work.

Taking into account all of these, we can come up with the final solution shown below:

const productExceptSelf = (nums) => {

   if (!nums || nums.length == 0) return [];

   let countOfZero = 0; // track the number of zero elements

  // Step 1: Find the product of all the numbers except zero
   const product = nums.reduce((acc, num) => {
      if (num === 0) {
          countOfZero++;
          return acc; // Skip multiplying if the element is 0
      }
      return acc * num
    }, 1);

    if (countOfZero > 1) {
      // Every element in the result array will be 0
      nums.forEach((num, index) => {
           nums[index] = 0;
      });
      return nums;
    }

    // Step 2: Loop through each element in the array and
   // populate the results array based on the value of the element
    nums.forEach((num, index) => {
      if (countOfZero === 1) {
          if (num === 0) {
            nums[index] = product;
        }
        else {
            nums[index] = 0;
        }
      }
      else {
          // There are no elements with a 0 value in the array
        nums[index] = product / num;
      }
    });

    return nums;
}

// Test case 1: When the array has no elements with a 0 value
console.log(productExceptSelf([4, 3, 2])); // βœ”οΈ returns [6, 8, 12]

// Test case 2: When the array has only one element with a 0 value
console.log(productExceptSelf([4, 3, 0])); // βœ”οΈ returns [0, 0, 12]

// Test case 3: When the array has only one element with a 0 value
console.log(productExceptSelf([4, 3, 0, 0])); // βœ”οΈ returns [0, 0, 0, 0]
}

Winners of the $20 award

After reviewing almost solutions in 5 different programming languages, the $20 award for Week 4 of Algorithm Fridays goes to @Flappizy and @thisaliaba, and you can find their solutions here and here respectively.

We picked these solutions because apart from being correct and robust, they used a very intelligent approach in solving the problem. Also, the solutions are time and memory-efficient and passed the edge case of when one of the elements of the input array had a 0 value.

A special mention for @abiolaEsther_ who implemented a correct time-efficient O(N) solution and @toritsejuFO who implemented a correct O(N ^ 2) solution in Python using the lambda function.

Thank you once again, to everyone who participated.

Conclusion

I hope reading this article has made you see the importance of asking clarifying questions when developing a solution and also given you examples of the kinds of questions to ask.

Though these questions are by no means an exhaustive list of the kinds of questions you should ask, they show you an example of the things you should be thinking about when you are developing a solution to a problem, whether during a technical interview or in a problem-solving session at your job.

If you are looking for a risk-free, low-stakes opportunity to apply what you learned in this article, you should consider giving Algorithm Fridays a try. You'll love it.

Thanks for reading this article and see you later today for Week 5 of Algorithm Fridays. Have any questions, feedback or concerns? Please share it in the comment section below.

E go be!