Introduction

The general format of the interview process at software companies for software engineers consists of three parts: recruiter screen, technical screen, and on-site interview. A phone screen is usually the only part of the technical screen and the immediate barrier to being brought on-site for the final stage. The technical phone screen is where you complete a set of coding challenges given through some shared collaboration editor while speaking to another person who is evaluating your performance.

The question of why I might have perspective on what goes into passing the phone screen is pretty easy to answer: my pass rate for coding challenges and technical phone screens is 16/19 companies, lifetime. To date, they are:

Pass

• Amazon
• Asana*
• Bloomberg
• Common Networks
• Dropbox*
• Epic
• Facebook
• FactSet
• Fieldbook
• Google*
• Instrumentl*
• LinkedIn
• Microsoft*
• Square
• Triplebyte
• Uber

* denotes companies with had an additional coding challenge or multiple technical phone screens

Fail

• Meraki (2013). Rejected for lack of familiarity with operating system concepts.
• Zenefits (2016). Rejected for lack of familiarity with relational database concepts.
• Oracle (2016). Rejected for lack of familiarity with UML.

In this post I’ll describe what I think the most important skills are in the technical phone screen. I’ll outline what I think is a reasonable way to approach building or polishing these skills.

First, I’ll focus on the skills that matter.

If there was one skill that mattered it’d be…

Coding ability.

Coding ability is writing syntactically correct code which compiles and can solve the problem given to you in real time within a reasonable time frame. You need to write working code quickly, and it needs to be correct. You need to be able to write your code in an editor with substantially less functionality than any IDE you might use. You may have to debug your code if it doesn’t pass certain test cases so coding ability includes debugging ability. Also, you need to know the core features of your programming language as they pertain to certain fundamental operations, like custom sorting and how to implement polymorphism. These core features you need to be familiar with to the extent that you can write these constructs almost from muscle memory.

If this is your most weakest skill you might have a high-level understanding of how to approach the problem but won’t be able to actually implement it during the interview. If you do manage to implement it, you might not be able to debug your code in time. You will probably be spending too much time with small syntax errors and figuring out why your code either isn’t compiling or running correctly at the expense of the minimal time you have available to solve the problem. It may seem like the problem you were given is overly complicated and something that would take you hours to solve, because you are dealing with too many new things at once.

Generally you’ll know you failed your phone screen if this is your weakest area. You’ll feel overwhelmed from the interview and it’ll be apparent to both you and the interviewer that you’re struggling. Interviewing with this weakness can make the job search psychologically burdensome and uncomfortable.

If there was another skill that mattered it’d be…

Knowledge of data structures and algorithms.

Data structures and algorithms is important because you will be implementing algorithms and using data structures for your solutions. You are expected to solve the problems with minimal time and space complexity. Also, you’ll be asked to explain the time and space complexity of your solution.

If this is your weakest skill you might implement solutions which are technically correct and pass the test cases, but you’ll be rejected anyway. It’s very difficult to understand that this is your weak area by self-reflection because you don’t know what you don’t know. The interviewer may ask you if you can come up with a better solution (which is a hint that there is a better one) but he will eventually stop asking if he feels you aren’t able to come up with anything better.

Generally you’ll be surprised by the feedback that you didn’t pass the technical screen if this is your problem. You will feel you did well and gave it your best shot, but somehow the interviewer wasn’t impressed. It may seem confusing that the interviewer seemed satisfied with your performance over the phone, though in practice interviewers tend to mask their feelings about your performance and try to give a positive impression during the interview. You really can’t predict your performance from the body language of the interviewer to say that you passed. The reason a rejection here will be surprising is that you were disqualified for lacking knowledge about computer science fundamentals that’s necessary for developing a much more performant solution. What you came up with in the interview was probably the naive solution or a variation that is not much better than the naive solution.

How do you get better at these skills?

The short answer is practice and feedback. The things that you are being evaluated on are either things you can learn or things you can get better at with practice.

If your weakest point is coding ability, solving coding challenges or doing competitive programming is your best route to go. To an extent, the coding challenges you’ll be doing should have a substantial algorithmic component if you want practice with the kinds of questions you are likely to be asked in an interview setting. You need to be comfortable with things like creating classes, polymorphism, custom sorting, subclassing, file input/output, pointers, etc. in your programming language of choice in a practical sense, not just a theoretical one. You will need to know the main containers, performance characteristics, and their APIs. Like driving, when you become more familiar with coding, you will be able to write code on auto-pilot without needing to think much at all. It can take several months to get really good at this.

If your weakest point is algorithms, you should probably be learning about the subject from an academic standpoint. With that said, there is a substantial difference between following a discussion about some algorithm and implementing it yourself. If you lack knowledge of algorithms, by definition you also lack practice implementing those algorithms. Just as important, it will be helpful to take the questions you were asked and talk with someone more experienced about your solutions. This way they can identify what you were missing in your solution. It can take many months to a few years to get really good at this. There is so much content in computer science that measurable progress in this area occurs much more slowly.

The difference between the two approaches above is that for coding ability it doesn’t really matter what kinds of problems you will be working with. You just need more practice coding and implementing algorithms. To solidify your understanding of algorithms, a good approach might be to learn about the algorithms at a high level, then the solve a number of coding challenges that require you to implement some aspect of that algorithm or the entire algorithm (e.g. binary search).

What did you do to prepare for your Google/MSFT/Company interview?

Very little. The questions you might be asked in an interview are so broad that there’s virtually nothing I could do to prepare for whatever I might be asked. The most I did was to refresh myself on the core features of the programming languages I might be using for the interview. I would also generally check that my phone had battery for the call, that the shared collaboration tools (e.g. collabedit) were working before the interview, and that there would be no interruptions.

Most of my foundational knowledge I had been cultivating for years. The time I spent learning algorithms and everything else hadn’t been done for any specific interview but rather for all interviews I might possibly go on at some unspecified points in the future. The concept of preparing for a specific interview or a set of interviews doesn’t really make sense in my case. I only started to interview when I knew my skillset was reasonably solid, so my interviews were planned around my preparation rather than the preparation being planned around the interviews. With that said, there were a few projects that helped me prepare in general:

• Read all five parts of Sedgewick’s algorithm series, 3rd edition.
• Completed a large number of problems in HackerRank’s algorithms section – 99th percentile in that area.
• Learned about my programming language’s containers, libraries, core features, etc.
• Wrote programs covering special features of my programming language that were considered to be useful but I didn’t have familiarity with (e.g. polymorphism, generic programming, operator overloading, etc.). For safety, you never want to use an unfamiliar language feature for the first time in an interview setting, so it’s important that you practice using it if you wouldn’t otherwise get exposure.

Conclusions

The pre-onsite technical screen is not a black box where arbitrary standards dictate success and failure. Virtually all companies are looking for the same two fundamental technical skills that include coding ability and knowledge of data structures and algorithms. If your weakness is coding ability you will frequently feel overwhelmed with the questions you are being asked to solve, with difficulty actually implementing and debugging your solutions in timely manner. If your weakness is knowledge of algorithms and data structures you may feel satisfied with your (unknowingly inefficient) solution during your interview but you will be mysteriously rejected later on. Both these skills can be improved but it takes long-term sustained effort. When you get very good, these skills will be ingrained so deeply that they feel automatic so that your brain can just focus on the problem at hand and not all the other aspects of the solution or implementation that would otherwise distract you or slow down your progress in the limited time you have.