I left my job at Smartcar about three months ago. In my time off, I've had the opportunity to interview at a variety of different tech companies, big and small, early stage startup to public company, health tech to financial tech.

I've noticed the interview process is different from when I was a new grad. More specifically, the technical interviews were much less focused on problem solving, efficient solutions, and algorithms and more on writing clean, testable code. I'm not sure if this is because I have enough industry experience where the expectation is that my algorithms and data structures knowledge is rusty, but this was a welcome change.

The medium has also changed. In the eight onsites that I had, I only coded on a whiteboard for one of them and this was because my laptop wifi wasn't behaving (Ubuntu on Mac problems). The rest of my interviews were pair programming on a computer, in an editor and language of my choice.

With the new format, here are a few tips that I've found helpful when interviewing.

Ask clarifying questions to understand the problem

This one is obvious. Personally, I struggle to ask the right questions when presented with a problem. Some questions are obvious but others are more nuanced and require you to better define the constraints of the problem. I've found that trying to poke holes in my understanding of the problem helps me think of good questions to ask. For example, if I think I've made assumptions, it's probably a good idea to state them. If my assumptions are wrong, I at least have the option of discussing them before moving forward to the problem solving step.

Another tip is to continue asking questions at all stages of the process. I think it's difficult to anticipate all possible scenarios or questions that you can come up with from the beginning. As you start coming up with an algorithm or method, you'll run into nuances of the problem, which is worth asking about.

Write out your high level algorithm

Some might suggest that this is not a good idea as it wastes time and pseudo code does not demonstrate your coding ability. While I agree it may cost you some time, it's helped me write cleaner, testable code. Verbally stating a solution and aligning with the interviewer may be sufficient for those with good memory, but I tend to get lost in the details if I don't have a high level algorithm to guide me.

I've also found by writing out the algorithm into steps, I can more easily modularize my code if need be. This is advantageous because it also gives you the ability to put off writing the logic for helper functions until later. It also gives you the opportunity to ask the interviewer if implementing said helper function is worthwhile versus continuing to layout the high level logic.

Think about how you'd test your code

Thinking about testing code is a great step in writing maintainable code and mentioning testing methodologies will earn you bonus points. It leads into the next point too.

Write test cases before you write code

Test cases will give you and your interviewer an expectation of what your code will do. It will also give you a better understanding of how your program should behave. This a great time to test edge cases and ask your interviewer what the function should return in a given situation.

Test cases can be as simple as printing the output of the function and commenting what you expect next to it. If you're really fancy, you can create a small assert function that you can use to demonstrate that your code passes the tests. Mine looked something like this:

function assertEqual(result, expected) {
  if (a !=== b) {
    const msg = `${result} is not ${expected}`;
    throw new Error(msg);
  }
}

This makes it incredibly easy to know if your code is passing the tests you wrote.

Run your code often

Just like you would when writing code on the job, don't write all your code and run it at the end. What advantage do you have running it at the end? Running your code as you go will help you find bugs as you make them.

Some interviewers may find this useful while others might not. It's best to ask before running it as there's a delicate balance between knowing what your code does and writing it via trial and error.

Mention time and space complexity even if they don't ask

While many of the interviews I've had did not care about time and space complexity, mentioning it is a good indication that you've thought about the efficiency of your code. Likely on the job, your solution will be sufficient, but acknowledging that your solution has trade offs is never a bad idea. After all, I think engineering is a lot about making different trade offs to achieve solutions that achieve a set of constraints.

Iterate and refactor your code

If you're coding on a laptop, you have the advantage of being able to write code a lot faster than you could on a white board. Another advantage is being able to rename variables and restructure your code. No one writes clean code the first time around. As you get a better understanding of what your code is supposed to do and how the logic should be structured, you can pull some logic out into helper functions. If you don't have time to refactor, make sure you mention how you might refactor your code if given more time.

Final thoughts

Interviewing is very much a skill. With a laptop and a pair programming/collaborative format, the skill set is similar to how you'd operate on the job. The format is in your favor. Put your best foot forward and enjoy solving a problem with your interviewer.