How to Solve a Coding Question in a Job Interview? Comments First Approach with Examples

If you are applying for a programming position, one thing is positive - you will be asked to write some code. On a white board. Without an IDE! In this post I will share the way I handle coding questions in a job interview, by asking questions, writing comments, and only then writing code.

In short - this approach ensures you'll have well-commented code, and even if you run out of time to implement everything, the interviewer will know how you would solve it if you had more time.

You might be a great programmer in real life, a coding ninja, a hero, or even a superstar, but that might not be enough to be ready for interview questions.

Even coding ninjas have hard time in job interviews

Coding Ninja? It might not be enough. Photo by Aisha Askhadova on Unsplash

The day-to-day process of writing code involves Googling, reading documentation, consulting with friends and colleagues, having the assistance of your favorite IDE (mine is VSCode at the moment, before it was IntelliJ). And hopefully code review and more useful techniques to make your code robust, readable, maintainable and... working.

All of the above does not exist in the environment of the job interview. In real life, you are not writing code on a white board and then compiling it in your head (unless you are, in this case, please stop reading and leave a comment starting with "IM!=HUMAN").

What's different in coding on a white board?

When writing code in an interview:

You are by yourself (no Google, no documentation)
There's no autocompletion by your favorite IDE
The deadline is very short - there's pressure in the air
Someone is watching you while you code
You have to think real fast about the solution

In this post I will present my approach for solving coding questions in a face-to-face interview. In an approach named Comments First Approach.

It's nothing fancy, but a way to organize your time for solving a question. It won't make you succeed if you don't know the answer. Sorry, didn't find a technique for that yet.

Me, trying to code while I am thinking, without having a plan. Not a pretty sight. Image from giphy.com

The things I want to achieve when solving a question in a job interview

Stop a moment and think about the interviewers. You came to their office, and now they are sitting and watching you while you think and code. Well, that's an opportunity to express more of yourself than only answering the question.

I assume you would like them to know you can:

Solve the question in a decent time
Think about edge cases, weird inputs
Care about performance and complexity or at least have it as a consideration in mind
Express your familiarity with the language, its tricks and limitations

You don't only want to solve the question, you want to make an impression.

The problems with thinking while you code approach

In the past, when I was asked an algorithmic question, I thought a bit and jumped straight to the board, starting to write the code as fast as I could.

This led me to code while I am thinking. Needless to say - I wrote the code before I had the complete solution in mind. While this can work in some cases, it can be not such a good idea:

You will have many loops of writing and erasing your code, or entire blocks of it.
You might be stuck on a specific syntax problem for a long time before completing the overall solution. For example, forgetting if the index is the first or second element in a foreach loop.
In some of the cases, when time was up, I ended up with only half of the solution written on the white board, doing my best to explain my intentions verbally to the interviewer.

It can work of course, and many people think while they code in real life. But in an interview you don't have time for so many deletions and retries.

Comments first approach for solving a coding question in a job interview

The approach I suggest here is very simple. This is the recipe:

Understand the question and ask for clarifications
Write the comments for the code (like you would if there was code inside) - similar to pseudo code + get feedback
Start implementing code under each comment
Run some of the cases in your head to see the code makes sense

Comments first approach - an example

This is the question we are solving - my own original, copyrights protected, SHLOOF BLOOP (does not resemble to fizz buzz in anyway!!, or is it?)

/**
This is the question we are solving: SHLOOF BLOOP
a SHLOOF array is one that has more even values than odd ones.
a BLOOP array is one that there every 2 adjuscent numbers are different. [1,2] is BLOOP, [1,2,3,3] is not BLOOP
a SHLOOF-BLOOP array, is an array that is both SHLOOF and BLOOP.
Write a function checkShloofBloop(arr) that recieves an array as the input
and returns a string with "SHLOOF", "BLOOP" or "SHLOOF-BLOOP" according to its state.
If none of the above applies, return an empty string.
============================================
Some examples:
checkShloofBloop([1,2,4,4]); // "SHLOOF"
checkShloofBloop([2,4,1,3]); // "BLOOP"
checkShloofBloop([3,4,2,1,36]); // "SHLOOF-BLOOP"
**/

checkShloofBloop(arr) {

  /** Your code here: **/

}

The SHLOOF BLOOP Problem:

A SHLOOF array has more even values than odd ones
A BLOOP array is one where every 2 adjacent numbers are different
A SHLOOF-BLOOP array is both SHLOOF and BLOOP
We need to write a function that determines which type an array is and returns the appropriate string

Example Inputs and Outputs:

// [1,2,4,4] returns "SHLOOF"
// [2,4,1,3] returns "BLOOP"
// [3,4,2,1,36] returns "SHLOOF-BLOOP"

1. Understand the question and ask for clarifications

Take a moment to think about the solution. Add some more input and output examples of your own. I am thinking about these examples for inputs: [1,1,1], ['a',2], [13,12,1,0]. In an interview, I would present my examples and ask if the output is correct and I understood the question well.

I think I understood the question, but I have some more things I want to be sure of before jumping to the next phase:

Q: Oh, Mrs. interviewer? What about an empty array? A: "Return an empty string"

Q: Can I assume all the elements are valid numbers, can they be strings, booleans, object?? A: Yes, no need for input validation. Great, that saved me some time and code.

Ok, now I am all set, I understood the question, demonstrated the way I think about edge cases, and shared all of these with the interviewer.

2. Write the comments for the code

The goal here is to think about the algorithm, express it in the comments (so eventually you will also have a commented code). After you write it, try to see what's the response from the interviewer. It won't work all the time, but it might give you some confidence to see a nod.

Comments I would write:

checkShloofBloop(arr) {

  // input validation + taking care of empty array for time optimization

  // go over all elements

  // keep a counter for the odd and even numbers

  // keep track of are the elements different

  // use the counters to know about SHLOOF

  // use the tracking to know about BLOOP

}

Go over the array, have a counter for odd and even numbers, calculate on the go the reduction result of each two neighbor numbers. Use the counters and the reduction result at the end for the return value.

Note that I wrote a comment about input validation, but I don't think it will be necessary to actually code it.

The interviewer nodding after seeing your great algorithm. Image from: Giphy.com

3. Start implementing code under each comment

You got the green light from the interviewer? Let's dig into the code.

I believe that at this point the interviewer knows already that you CAN solve the thinking part of the question, it's only a matter of code.

My solution would include:

function checkShloofBloop(arr) {

  // input validation + taking care of empty array for time optimization
  if (!arr || arr.length === 0) {
    return "";
  }

  let oddCounter = 0;
  let evenCounter = 0;
  let isBloop = true;

  // go over all elements
  for (let i=0; i<arr.length; i++) {

    // keep a counter for the odd and even numbers
    if (arr[i]%2 === 0) {
        evenCounter++;
    } else {
      oddCounter++;
    }

   // keep track of are the elements different
    if (i !== 0) { // skipping the first element - important edge case
       if (arr[i] === arr[i-1]) {
         isBloop = false;
    }
  }

  // use the counters to know about bloop
  let isShloof = evenCounter - oddCounter > 0 ? true : false;

  // use the reduction amount to know about shloof
  if (isShloof && isBloop) {
    return "SHLOOF-BLOOP";
  }
  if (isShloof) {
    return "SHLOOF";
  }
   if (isBloop) {
     return "BLOOP"
   }
   return "";
}

Yes, this code can be shorter, I know. And that might be the first question the interviewer will ask, and to it I will provide my ideas about optimization of the function I just created.

4. Run some of the cases in your head to see the code makes sense

After the task is complete, you are pretty excited and want to sit for a bit and take a break.

Wait with this for 2 minutes, and run the examples in your head. Do the code above cover the basic scenarios? Does it cover the edge cases it should?

It is perfectly fine to have a 90% bullet proof code.

Conclusion

Coding without a keyboard, IDE, Google and time can be stressful and annoying. The good news is that you can still express your way of thinking, in-depth analysis of a problem and coding skills, without having a 100% compilable (or transpilable) code.

Thanks for reading! Please share and comment if you like this article. I would be happy to hear what would you like to read more about.