The Interview Process: Technical Phone Screen

A few weeks ago, I wrote a blog about my preparations for phone screens/interviews. Lately, I've had technical interviews on the brain (both because of my job search progress and because of a great meetup I attended this week). After a successful phone screen, the next step in the interview process is often some sort of technical challenge, whether that's a take-home project, a timed assessment, or (what I'm talking about here), a technical phone/video screen with an engineer at the company.

Within the technical phone screen category, which I like to think of as coding and non-coding (although many technical interviews are a mix of the two). Coding interviews are ones where you are writing code as part of the interview, often either pairing with your interviewer or having them on the phone with you serving as a resource as you write the code. Non-coding interviews are ones where your interviewer asks you questions about your technical knowledge and the languages you will be using as part of the job, but you're not expected to write or submit any code.

While these two types of interviews are somewhat different, I find that I do some of the same things to prepare, so I decided to put them together in one blog post.

The Day(s) Before

So, you've passed the initial phone screen and been invited to do a technical phone/video screen. Congratulations! Now it's time to prepare!

One of the most helpful things you can do is try to find out more about the interview. Here are some questions I try to ask:

• Will there be coding or questions or both?

  • While there is certainly some overlap in how you prepare, knowing whether you'll be asked to code or to explain concepts (or both) can help guide your studying (more on that below).
  • Be aware that even if it is a coding-based interview, you may be asked some questions or asked to explain something you did. Even if you know you will be writing code, make sure to understand the code you're writing well enough to answer questions about it.For example, in a recent javascript interview, when I called .toUpperCase(), I was asked how I was able to do that - my interviewer wanted to be sure that I understood the concept of String methods and inheriting from the prototype.

• What technologies, libraries, and functions should you be prepared to answer questions about?

  • Most likely the company will not tell you exactly what questions they're going to ask. But they may be willing to guide you towards what is most important to them so that you know where to focus your preparations.
  • For example, for a recent technical interview, I was told to practice fetch, DOM manipulation, and async. As part of my prep for the interview, I wrote some code (from scratch) that fetched data from an api and put that information on the DOM (and then applied some styling) so that I didn't get tripped up by the basics during the interview.
  • If they mention a library or technology with which you're not at all familiar, that's a good place to focus your studying. Don't expect to be able to write code in an entirely new language, but make sure you know the differences and similarities between this tech and the tech you're used to well enough to explain them.

Now that you know what you're going to be asked, it's time to start studying!

If you'll be writing code...

If you're expected to write code, it's important that you practice by actually writing code. The more you know about what you will be doing, the easier it is to figure out what code to write while practicing. If you know it will be an algorithm-based interview, practice by writing algorithms, whether that's practicing well-known algorithms (while traversing a binary tree may not be relevant to most jobs, it's still something you don't want to be caught not knowing in interview) or using one of the many algo practice websites to find problems to solve with algorithms. If you're interviewing for a web development position, it may be a good idea to write a small app from scratch (even though you likely won't be asked to do that). If you're not sure what will be asked, practice a little bit of everything.

If you have enough time and knowledge about the company's product, it may be good practice to try to create a rough clone of the product you'd be working on. This is likely to be time consuming, though, so it's not something I'd recommend for most interviews (unless you have a lot of prep time).

If you won't be writing code...

Just because you won't be writing code, that doesn't mean you can't write code to practice. If you find that writing code really helps reinforce your understanding of concepts, then it's definitely important that you write code related to everything you study to be sure that you fully understand it.

Personally, I find that I can sometimes understand understand and explain concepts without having to code them, so I don't always write code as part of my studying. Be sure that you can answer questions about the topics that are relevant to the interview. See if you can find a list of potential questions online and make sure you can answer each one. If you've had similar interviews in the past, try to remember what questions you were asked and focus on the answers to those questions.If you have a non-technical friend or family member who is willing to help you prep, try to explain some concepts to them. If you understand something well enough to explain it to someone with no experience in that particular tech, then you most likely understand it well enough to answer questions about it in an interview.

But ... what if you don't know what you're going to be asked?

Studying is a little harder if you don't know what you will be asked, but it's still possible to do well in a technical interview without knowing what to expect going in. If you don't know if you will be asked to write code, make sure you practice writing code. Study any technologies that are on your resume and in the job description, because those technologies are likely the ones that led the company to feel that you're a good candidate, so they'll want to know about your proficiency with those technologies.If there are any technologies listed in the job description with which you are not familiar, take some time to get a basic overview of those technologies. It's okay if you can't answer detailed questions, but just having a basic knowledge of the technologies and how they're relevant to the job description can show that you're interested in learning that technology on the job.

Over the course of your studying, if there are concepts that you struggle with or feel you might not remember on interview day, feel free to take notes! These notes are great to study the day of the interview, and depending on the setup of the interview, you may be able to consult your notes during the interview to help jog your memory.

Interview Day

On the day of the interview, I like to do two types of prep - preparing for the content of the interview and preparing my setup for the interview. I try to set aside an hour before the interview is scheduled to take place to do all of this prep.

Once my hour starts, the first thing I do is read over my notes from any previous interviews with the company so that I know what we've talked about already and have some sense of what kind of questions the company asks. After that, I start reviewing any notes I left for myself about topics I want to re-study. If I haven't left myself any notes, I try to do 1-2 algorithm questions or review things that I know will be asked during the interview. If there are things you need to know and you're afraid you'll forget, feel free to make yourself a quick cheat sheet (unless you've been explicitly told not to do so) that you can reference during the interview with a few key pieces of information (this is also a good thing to do for timed technical challenges that are not phone screens).

I also try to write down a list of questions for my interviewer. If this is not your first interview (and especially if it's not your first interview with this particular person), it can be tough to think of questions, but make sure you have something written down, even if it's just a repeat of a question you asked someone else. Remember that you're interviewing the company as much as they're interviewing you, so this is a good time to try to figure out if the company feels like a good fit.

About halfway through my hour of prep, I start to set up my physical environment, which means making sure I have a pen and paper, making sure my desk is organized in a way that I won't get distracted by random things, refilling my water bottle (or making sure I have enough coffee), and charging my computer and phone a bit if I need to. If the interview is a video interview, I make sure to test my camera and microphone (I use a MacBook, so I usually test using FaceTime, unless I'm preparing for a Zoom or Skype call, each of which has the ability to test your mic and camera built-in). If it's a phone call where I will be coding, I make sure I'm set up for hands-free conversation - I generally use headphones with a microphone (which is also what I use for video calls), but if you're in a place where you can comfortably use your phone on speaker, that works too.

I make sure that I'm all set up and ready a few minutes before the interview (which is a good thing, because I recently had an interviewer call me a minute or two early), but I try to keep myself distracted so that I'm not just sitting around nervously waiting for the call (lately I've been doing the New York Times Set and KenKen puzzles to help with that).

During The Interview

Once the interview starts, it's important to remember that everyone makes mistakes and it's okay not to know something. During a coding interview, your interviewer will often remind you that they're available to answer questions - take advantage of this if there's something you don't know. If your interviewer does not want to answer your questions, ask if you can look up the documentation. Most likely, you're interviewer will be totally fine with you looking up documentation, as long as you're not copy and pasting from stack overflow or something similar. For example, I recently was asked to do something using the .reduce() array method, and that's something I have struggled with since I started learning javascript, so I looked up the documentation while I was using it just to make sure I was doing it right - and my interviewer was totally fine with that.

If the interviewer won't answer your questions and doesn't allow you to look up documentation, to me, that's a big red flag. In a real world situation, you'd be able to look up documentation or ask for help. There's no reason not to allow a candidate to do that during an interview.

If you come across something you don't know, whether that's writing code or answering questions, it's tough to know whether to guess or just say that you don't know. For me, if I have some idea and think I could turn that into an answer that works, I'll do that, but if I have no clue, I just tell my interviewer that (and if it seems like they'd be open to explaining things to me, I'll ask them to explain). However, this is a very personal decision, and you have to decide for yourself when you're okay guessing and when it's not even worth trying.

If you say or do something wrong and your interviewer corrects you (which they may or may not do), make sure to take note of this correction and use that information going forward. It's okay to make a mistake, but if you've been told that it's a mistake, it's not okay to make that mistake again. Interviewers want to see that you can learn from your mistakes and apply corrections.

I like to take notes during my interview on the things I was asked. I like to know what I was asked, and I particularly like to have notes on what I struggled with. If my interview is on the phone, it's easy to take notes, but it can be trickier for a video interview - I usually try to write without looking, but if you're not comfortable, it's okay to look at your notepad during the interview, and if your interviewer questions what you're doing, explain that you're writing notes for yourself about what you're doing.

The Aftermath

After the interview, I type up my notes, including what I struggled with. If there's something I really did not know the answer to, I look up the answer and include that in my notes so that I know to review those topics if I have another interview with this company (or so that I have a better answer for the next time I'm asked that question).

If it was a coding interview and I found what I was doing interesting, I try to reproduce what I was working on (to the best of my ability - sometimes I was given enough boilerplate that I can't easily reproduce it) and finish anything I didn't have time to finish. For example, in a recent interview, I was using some API calls to get data that I then built into a widget, and since we didn't have time to finish the styling on the widget during the interview, I decided to use static data to build the widget (complete with styling) after finishing the interview.

If the interview uncovered some big holes in your knowledge base, take it as an opportunity to spend some time brushing up on those subjects. Every interview can be a learning opportunity, and whether or not the company moves you to the next step in the process, the interview can help bring you closer to your next perfect position.