Acing technical interviews - part two

In the last post, we discussed how hard technical interviews can be. We also looked at the biggest hurdle for most candidates – having an accurate view of their weaknesses. In this post, we will discuss more about what it is like on the other side of the clipboard. This is useful so that you can give your interviewer the positive signals that they are looking for in an interview.

Why your interviewer is frustrated

Hopefully, you have never been in an interview with a frustrated interviewer. At Skilled Inc, we believe that technical interviews should be a good conversation between two engineers about how to accomplish a specific task or set of tasks.

Unfortunately, far too often when you start interviewing at companies you will find that the interviewer may become distracted or potentially even frustrated halfway through your interview. If you get a sense that you are losing your interviewer it is probably because you are not giving them the positive signals that they are looking for.

🎵 What An Interviewer Wants, What An Interviewer Needs... 🎶

Problem solving, edge case/syntax checking, and strong communication skills are the keys to a good interview. Don't take my word for it though, take Gayle McDowell's word – a leading expert on acing the technical interview. Sometimes it is hard to be a good interviewer. This is usually because candidates often fall short in one of these major areas listed. Let's take a closer look at each.

Communication

Before we even can talk about solving a problem well we need to discuss how to communicate effectively with your interviewer. Often times candidates forget that their interviewer doesn't have critical context that they would need to have in order to understand a story or algorithm.

Take Jamie – a recent candidate on Skilled. When asked to talk introduce himself did well, but once I asked him to describe a specific project that he was working on, he began to use acronyms and company specific terminology. At one point he even started talking about Bill (who was Bill again? It was unclear and that was the problem!). Test your assumptions about what the interviewer knows.

How to fix it

• Avoid acronyms. Just because you know it, doesn’t mean everyone else does!

• Don’t assume that the interviewer knows your coworkers (“I was talking with Dave about this,” who is Dave?). Even the CEO might not be as well known outside of the company as you think they are. There are a lot of companies with a lot of upper level management and it shouldn’t shock you that your interviewer doesn’t know their names. Can you name the CEO of each of the top 50 companies, let alone the rest of upper management?

• It’s ok to think in silence for a bit if you need to, but remember that the interviewer can’t help you if they aren’t even sure that you understand the question. It’s better to work out loud if at all possible.

Edge cases / syntax

Believe it or not, this section is actually the easiest part to get better at in the whole interview process once you learn a few tricks. People that are new to technical interviews ask all the time about how important syntax is. They give stories on how they knew someone that “only had a single semicolon out of place and wasn’t hired.” Thankfully, stories like these are mostly just myth. Usually when stories like these are conveyed to me it’s clear that the candidate actually struggles with a different problem than what they think – not having an accurate view of their current skill set.

It’s not useful for an interviewer or a company to employ a candidate that has memorized every Python function and every linter rule. Tools exist to correct mistakes like these and interviewers largely don’t care if you get details like these wrong.

However, with that disclaimer in mind, there are certain basic building blocks that you are expected to know. Jessie was a recent client and she really struggled even with the basics of the language and that led to her receiving a low score in the interview. As a rule of thumb, if you can’t remember how to write a simple old-fashioned for loop and are trying to use made up keywords like otherwise instead of else these are clear red fags that you need to go back and brush up on the basics.

Edge cases are also easily addressed by looking at individual inputs and considering their individual edge cases and then considering how they may affect one another. Below is a simple chart that illustrates basic edge cases that should be at the top of your mind given specific inputs.

Edge cases to consider, broken down by input type

If you keep these simple edge cases in mind you’ll dramatically reduce the number of edge cases that slip through the cracks!

How to fix it

• Don’t get hung up on little things like whether a method is called .contains() or .includes(). Simply make a note that you always get them mixed up and mention that you would just refer to the documentation online while on the job.

• Don’t get hung up on little things like whether a method is called .contains() or .includes(). Simply make a note that you always get them mixed up and mention that you would just refer to the documentation online while on the job.

Problem solving

Finally, we’re onto problem solving! Many interviewers weigh this part more heavily than the others. Can the interviewee successfully solve the problem using computer science fundamentals? Can they understand the complexity of their algorithm and correctly identify if it’s a good algorithm?

Todd, another client, quickly coded a solution to my question and declared afterwards that it was a linear algorithm. When I asked him to take a second look – hinting that he was incorrect – he said he didn’t need to because there was “just a single for loop” making the entire algorithm linear. He was unable to see that hidden in his loop was another secret loop, built into the JavaScript method he was using, which cost linear time to run… leading to a quadratic algorithm.

How to fix it

• Whether or not you’re explicitly asked, always give the time and space complexity of your algorithm.

• Spend some time brushing up on big-O complexity. Counting the number of for loops in a function is not a good way to analyze complexity.

• Understand how your language does operations under the hood. Methods like .contains() and .includes() are not constant time operations.

Summary

For the most part interviewers are reasonable people that don’t want you to memorize entire code libraries and penalize you for forgetting parenthesis. Interviewers are looking for three key skills from candidates. Good communication, thoughtfulness in coding syntax and edge cases, and basic amount of problem-solving abilities.

Sometimes it’s important to understand what you shouldn’t be focusing on in your technical prep, so in the next post you’ll find out all the things you should avoid studying when preparing for technical interviews.

If you have any questions or feedback feel free to add me on Linkedin!

Thank you for reading!