How to Over-Prepare for a Technical Phone Screen Interview

Text Only 02

Written By Siddharth Sambamoorthy

When a company schedules a phone screen interview with you for a programming position, they are looking to find out your chances of clearing their on-site interview. In most companies, the class of questions they ask in a phone screen is a notch lower than an on-site interview; however, for companies like Google, Facebook, and LinkedIn, the phone screen can be as tough as their on-site interview.

Your performance during this phone screen will set the scope and tone of the subsequent on-site interviews and ultimately affect the position you will be hired for. A remarkably bad performance may blacklist you in their database, and you will not be in a position to apply again for some time. Your experience and position at your current place of employment doesn’t matter; in fact, the more experience you have, the more a company expects from you in an interview. It is, therefore, always better to be over-prepared for what turns out to be an easy interview than vice versa.

I have been on the interview circuit twice in the last three to four years. I started out with “below average” interview feedback where I failed at the phone screens, and worked my way up to clearing some very difficult interviews and landing what is a great position in a successful startup.

To help you over-prepare for your phone screen interview, I’ve gathered the most important resources and tools that have helped me (note: these tips help for on-site interviews as well). I hope this information helps and inspires you to increase your odds of clearing the first interview hurdle.

Practice Makes Perfect

Some years back, I was preparing for a phone screen. I was expecting it to include very tough questions that I would not be in a position to solve unless I’d seen them before. To prepare myself, I was determined to glance through the solutions for as many tough questions as I could.

As the interviewer shared the collab/edit page with me, I was eager to impress by identifying the dynamic programming approach to the problem. The following question was posed:

Given string and int size, find if the string is unique up to the length specified in size.

I immediately jumped into coding up the solution and quickly finished, only to be told that I had totally ignored the size argument in my solution. Frazzled, I bandaged the code and wrapped up. The moment I disconnected the call, I realized an obviously smarter way to do what I had just done, but I hoped the interviewer wouldn’t mind—because after all, I did solve the problem posed …

The rejection came with “below average” for feedback on my coding skills. Ouch!

I found myself a career coach who suggested that nerves probably got in my way. He stressed that I should get in front of a computer and solve the problems from the same books a couple of times. I heeded his advice, not even leaving the easiest problems, working through them multiple times.

In the interviews that followed, something changed; the nervousness was not totally absent but it didn’t get in the way. Even if I hadn’t solved the same problem during preparation, having solved similar ones, I knew the kind of effort needed to solve them. That way, I knew problems that seemed very easy were not that easy, so I paid more attention, and those that seemed impossible were usually not that bad, so they didn’t scare me.

I used the following resources for my practice sessions:

Books That Helped Me

The book “Elements of Programming Interviews: The Insiders’ Guide” is an absolute must-read. If you finish it completely, you can skim through or even skip the other books I mention. This book lists detailed plans to study based on the time you have, and the questions are pretty comprehensive and formidable.

“Cracking the Coding Interview: 189 Programming Questions and Solutions” and “Programming Interviews Exposed: Secrets to Landing Your Next Job” are great too. If you are at a level where you struggle with these two books, work them out a couple of times before moving on to the one recommended above.

Websites for Further Practice

The books above are great, but you sometimes need a change of pace/environment. Besides, you can’t take those books with you wherever you go (like your office). Fortunately, there are websites that can help you. Some have their own integrated development environment with a timer and a judge, which can make the environment quite close to an actual phone interview. These sites are a worthy complement to your practice sessions.

LeetCode provides some free questions and paid content starting at $35 a month. There are questions from specific companies, too. I suggest subscribing to paid content once you are scheduled for the on-site interview with those companies you see on their list.

CodeFights’ challenges are timed and force you to think on your feet. But don’t dwell very long; you are ranked based on how short your solution is, which encourages unreadable code.

Mock ‘Til You Make It

After you have practiced to some extent, it would be tempting to jump into the interview circuit immediately. But, like with any exam/quiz, it is best to take a mock test before the actual exam. Mock tests serve as a validation for all your practice and help you to fine-tune your preparation further. Think of it like practicing before your driving test for your license with someone who used to be an invigilator at the local Department of Motor Vehicles. They give you a feel for the actual test with feedback, all without the pressure from fear of failure. If you have never been in a phone interview before, a mock phone interview is an absolute must;it gives you a feel of what to expect during the actual interview, which will make you that much more confident.

When I am in my interview circuit, I usually attend mock interviews after a few weeks (or even months) of preparation. There are quite a few companies that offer mock phone screens, and some are even free. If you are not in a position to avail them, find a friend to do a mock interview for you.

I used the following resources for my mock interviews:

  • Pramp: In Pramp’s mock interviews, you are interviewed by a peer, and then you get to conduct an interview. Before the interview, you are mailed interviewing tips for the question you are about to pose, and afterward, you get to grade the other candidate on various aspects of their performance. This gives you an idea of what an interviewer typically expects from you. Also, it is free (for now). The only downside is you are interviewed by someone who is in the same boat as you are.
  • Gainlo: With Gainlo, you can have mock interviews with employees from top companies for $50 to $130. Interviews last up to an hour and, given you are against an actual employee of the company, this is the closest it gets to the real thing. Apart from the interview feedback, if you manage to do well, the person who interviews you may even offer to refer you for an interview at their company!

Think Aloud

Once I was up against someone who used to be an assistant professor at a top university. The question he posed was related to his specialization, which was not too tough. I expended all my energy on translating my solution to code, unit tested, and retested. After I was done coding, he asked me why my answer worked. I didn’t think much of it at that time; I had seen some similar problems before and when the question was posed, the solution was intuitively obvious to me, and having done a good job coding up the solution, I gave a perfunctory answer. I walked away confidently from the interview.

The feedback was, “Good, but looked like he was answering from memory …”

Replaying the interview in my mind, I realized what might have happened. Being a professor at the core, he had intentionally asked a simple question and wanted to test my thinking process and rationale for the solution the most. So the actual interview had begun after I finished coding up the solution. I needed to do a better job of explaining my solution.

In the interviews I’ve had since then, I’ve made it a point to explain my thought process as best I can, explaining why and what the code I am about to write is going to do, and then start coding.

For problems you are solving completely from scratch, documenting the steps while communicating your thought process is not a trivial task. I have found doing this on a whiteboard is a tad bit easier, especially if the problem involves a 2D data structure.

For phone screens, I use a piece of paper (mentioning I am doing so to the interviewer). I write down my thought process on paper, reading aloud as I write it down. What I have on paper is usually just for me so that I don’t lose my train of thought, and before I start coding, I put down what I am going to do briefly as comments in the shared screen referring to the notes.

Even in cases where you are not stuck, always enunciate your approach, explaining your rationale. If some part of your solution is coming from intuition, mention so. You will leave room for very few questions from the interviewer.

Show Grit

During the interview, if/when you hit a wall, giving up is the worst thing you can do. I have already covered one way to avoid getting stuck by losing your train of thought. It is not good if you get stuck at the stage when you are coding and you realize your solution is wrong, which is why you start coding after testing your approach/idea.

If you get stuck finding a solution and if you had communicated your thought process, continue to think aloud and explain the problem with your approach. Thereafter, try to salvage your current approach.

If that fails, go back to the drawing board and try to find another solution. If all else fails, solve the problem with a sample input without thinking of an algorithm, and once you have solved the problem, try to automate your approach. Always look out for questions/comments from the interviewer—they may actually be a hint and may prove to be a lifeline.

At some point, you will have to forget the time constraints and keep working on the solution. Even if you don’t solve the problem, you can still impress your interviewer with your thinking. Even if they reject you, the feedback in their record can be positive and you may get a chance later down the line.

Sometimes, you may clear the interview but not get an offer, and sometimes, you may get an offer that might not materialize; I’ve received offers from some great startups (some went on to very profitable exits) that were rescinded at the very last minute because of their budget constraints. This after clearing more than a dozen rounds of intense interviews. Unfortunately, things like this happen, and if it does, politely thank them for the opportunity and move on quickly.

Prepare with More Resources

The following resources will give you a certain aplomb during the interview that is sure to give you an edge in terms of your state of mind:

Some Final Words of Wisdom

If you are interviewing with a company that is in the same area where you live, offer to do the phone screen in person. There is something about engaging in person that calms your nerves. Also, as I mentioned previously, sometimes explaining and recording your thought process can be done more easily on a whiteboard than over the phone. Facebook, LinkedIn, and a lot of other companies allowed this during the interview, although Google didn’t. Always schedule the interview in the morning, as your chances of doing well are better than when you do it at the end of a busy workday.

Prepare to describe how you solved a few good problems in your current or previous work role, preferably related to the position you’re applying for. You have to describe your part in it, the rationale behind the decision made, and, if given a chance, what/how you would have done differently.

Read up about the company and its competitors in the field and get as much information from the recruiter as possible. Never ask the interviewer what the company does—you should have already learned that information while preparing for the interview.

And lastly, always ask for feedback, even for successful interviews.

Root Cause-remediate-repeat

My most recent job search started after weeks of preparation and mock interviews, and lasted half as long as it did the previous time. I cleared more interviews than before. Of course, I also lost some, but only by very close margins.

The fact that I didn’t clear all the interviews I attended means there is still work to do; I still have weaknesses. But I now know if I am not good at something, it just means I need to identify the weaknesses and do more of the work to prepare. I’ll keep trying to improve upon my interviewing skills to increase my comfort level with solving problems.

I hope most, if not all, of the tips and techniques that helped me will help you to overcome your shortcomings and get you through your next phone interview with flying colors. Good luck!