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’s 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.
Before we can even 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.He communicated well when asked to introduce himself, 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!). Don’t test your assumptions about what the interviewer knows.
- Avoid acronyms at all costs.
- Don’t assume that the interviewer knows your coworkers. Even the CEO and executive suite of the company. 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.
- It’s okay 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.
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 Skilled client who struggled with the basics of the language which led to 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 keywords like otherwise instead of else, these are clear red flags 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.
If you keep these simple edge cases in mind you’ll dramatically reduce the number of edge cases that slip through the cracks!
Edge Cases / Syntax Fixes
- 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.
- Always run through the checklist of basic input types and their associated edge cases. They are pretty straightforward and easy to remember.
Finally, we’re onto problem solving! Many interviewers weigh this part most heavily. 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?
Problem Solving Fixes
- Whether or not you’re explicitly asked, always give the time and space complexity of your algorithm.
- Spend some time brushing up on big-oh 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.
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 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, please feel free to add me on Linkedin: https://www.linkedin.com/in/michael-mroczka/
Thank you for reading!