I can feel my stomach turning before an exam no matter how much I’ve studied for it. But it’s nothing compared to the wave of emotions that overcomes me before a technical interview.
The reason behind my nervousness hides in the mismatch between how interviews are conducted and the reality of our job. The level of rigor and depth of the technical discussions is much wider and deeper than what you encounter in your regular work.
When I study out of curiosity I apply different methods than when I do it because of an exam. It’s the same with interviews - it’s a separate skill that requires different preparation. So when I started interviewing I took up the personal side quest to improve the interview process, even if only a tiny bit.
This proved to be harder than I first imagined.
I quickly realized that I’m more nervous about conducting an interview than being interviewed myself. When you’re on the receiving end of the questions, you’re responsible for your own performance. Bombing in an interview will leave you without a job but failing as an interviewer means that someone else will suffer the consequences of your actions.
Looking at interviewing like this puts a different weight on every question you ask and every decision you make in the interviewing process.
Because of that I never interview with algorithmic questions. I’ve made the conscious decision not to apply to companies that do. There’s a notion that you have to study algorithms to get a well-paid job, but outside of FAANGs, you can find plenty of lucrative opportunities that don’t require you to grind leetcode for months.
This doesn’t mean that I don’t like live coding. In fact, I think writing a small piece of functionality with the candidate is the best way to measure their abilities and thinking.
But it should be something practical that you can work on together as a pair-programming exercise, not a timed algorithm-solving race. Ideally, you want to write a small function in multiple iterations, increasing the complexity each time.
This shows whether the person can solve a problem with code and refactor their solution when new information becomes available. It shows how deeply they think about design and whether they can foresee common problems.
Yes, live coding is stressful. Sharing your screen with a bunch of strangers is like giving them a door inside your mind. Many people fear being judged based on the way they think, so they freeze, unable to write anything.
This is where you come in as an interviewer. You need to nudge the candidate just enough so they can unblock themselves and continue with the problem. This doesn’t mean giving them the answer to their problem straight away, though.
You can paraphrase a question, ask them to summarize what they’ve understood so far, ask them to talk you through their current problem. Talking helps. Give the person silence when they’re actively working. But when they get stuck, break it. You have limited time to uncover their potential.
Take-at-home tasks to develop an application are another common practice to measure a person’s capabilities. I have mixed feelings about it, though.
They take a lot of time and many candidates simply can’t spend their family time writing yet another CRUD application. In the last few years, I’m leaning more towards live coding because of that. It’s more respectful towards the candidate’s time.
You need to be more skillful as an interviewer to conduct live coding properly but it remains the best way to see how a person thinks. Still, if you’ve decided to keep take-at-home tasks there are a couple of things to keep in mind.
It’s best to give them before the technical interview so you can discuss them during it. Also, don’t give an entire service or an application as a take-at-home task. Instead, provide a working codebase in a repository and ask the candidate to modify something in it or extend it.
It’s a small task that won’t cost the person their entire weekend and most importantly, it’s realistic. As an engineer, you spend more of your time working and extending existing solutions instead of designing new applications.
The way a person approaches a small modification can tell you a lot about them. You’ll see whether they write a test for it, whether they make the smallest possible change to get it working, or change the design to address the new requirement.
But live-coding and home tasks are not a replacement for a good technical discussion. You want to learn more about the person’s past experience and identify how much they have actually contributed to an implementation or design.
It’s best to ask a broad variety of questions to get a feel of where their strong sides are. Then dive into a topic or two as deeply as possible. There is no replacement for depth.
When I interview front-end developers I like to ask them a lot of questions on topics like the browser, networking, caching, security, and their framework of choice before we dive into one of them. It should be an area where you have sufficient knowledge to evaluate the person’s abilities.
You may feel that your questions are too specific, too complicated, or even too nosy. But as an interviewer, you need to get an accurate assessment of the person in front of you. There is nothing worse than coming out of a two-hour discussion with no idea of how good the person is.
Unfortunately, it will happen at least once before you realize the problem. It’s better to be annoying with your questions than to exit the room or Zoom call oblivious of the person’s abilities. If you do that it means that you have failed as an interviewer.
So ask even the questions that seem obvious, even the ones whose answers you take for granted. You’d be surprised how often simple things trip up people.
It’s your responsibility to understand the person’s knowledge and if you weren’t able to do that then you are the only one to blame.
Some people are more easygoing than others. You can talk freely maybe even crack a joke. Others are shy or nervous, not sparing any words outside of a straight answer. Contrary to many other situations, talkative people are more difficult to handle in an interview.
You have very limited time and a busy calendar means that you may not have the opportunity to take all the time you need. So you will have to find the bravery to interrupt them every now and then so you can cover all your questions.
It seems very impolite but you must get used to interrupting people when the conversation goes off-topic. It’s not in your or in the candidate’s best interest to turn the interview into a chat.
When you feel that the conversation is going off track or the answer is too abstract, ask specific questions. When you have collected the information you need on a topic, move to the next one.
But make sure you ask the same questions when you’re interviewing people for the same position. It’s normal for a conversation to steer away into technical details or a story about the person’s experience. You should still try to follow a similar conversation outline.
If you talk about performance with one candidate and architecture with another, comparing them would be impossible.
Ideally, an interview should tell you two things - whether the person has the skills and knowledge to do their job, and whether you can get along with them. Scratching only one of the two boxes is not enough.
Perfect technical abilities are not enough to overshadow the inability to communicate or an out-of-control ego. In the same way, being a good cultural fit is not a substitute for technical expertise.
At least for engineering roles, technical knowledge has significantly more weight than communication skills. But if you have good soft skills on top of your tech experience, you would have an exceptional position in the market.
I can’t wrap this article without addressing the common idea that people should be hired for their attitude and motivation. These two qualities can fuel a person’s growth and achievements but they are impossible to measure in an interview.
The best sign that a person is motivated is if they’ve spent the time to acquire knowledge and abilities. They may not have experience, but an investment in their development is a good indicator. A personal project, a finished course, a boot camp - these are good signs.
You want to build teams made of people who can convert motivation into actions. And the only way to know that the person is capable of that is through their current abilities and knowledge.
