I’ve been doing phone screens now for some time. At this point, the first phone screen I give a candidate is basically always the same and it’s based on Steve Yegge’s now famous blog post on the five essential areas of a phone screen. At first, I followed Steve’s areas as closely as possible. However, as time went on, I deviated somewhat from it and thought that I would share my phone screen format that has evolved over time.
Instead of Steve’s five areas I just have my three. But, I tend to dive a little deeper in each of the areas because the software engineers whose work I respect the most tend to know certain things and the ones whose work I don’t respect as much tend not to know these things. These areas are:
- Basic coding
- Data Structures
- OO Design
Later in this post I will dive into each area with questions I ask along with candidate expectations. But the first part of the technical phone screen I do is actually a bit softer.
Warm Up
At first I introduce myself. I ask the candidate how they are doing and whether the current time is still convenient for them. After that I just ask them to briefly take me through their resume and tell me about what they have been doing for the past couple of years. I really don’t care much about any of these things. It’s primarily intended to warm the candidate up and make them feel comfortable. Interviews can be intimidating! As Joel Spolsky said in his great book Smart and Gets Things Done:
I ask the candidate to describe their career history and basically tell me about themselves. This is mainly intended to get them loosened up and feeling comfortable, to eliminate any nervousness, and to let them sort of present themselves the way they want to be presented.
Building on that, there are a couple of things that this introduction can help you to quickly elucidate:
- A history of delivery: Drill down on what exactly the candidate did instead of what their team and company did. Bullshit, shadiness and lack of precision here are red flags.
- A valid reason for leaving the company: You want to hire somebody who wants something that your company has to offer, not just somebody who is seeking to flee their current role until something bigger and better comes along. Try to understand what exactly the candidate is looking for in their next role.
Once the soft pitches and preamble are done, it’s time for the meat of the phone screen – the technical questions.
Core Competency 1: Basic Coding – String Reversal
The first area I dive into is rudimentary coding skills. Specifically, the first question I ask is:
How would you write a public API method to reverse a string in your most comfortable programming language?
This is my most basic weeder question and the first one I ask because it allows me to weed candidates the fastest. If the candidate can’t correctly reverse a string in a language of their choice, I really don’t want to work with them. That might sound arrogant and harsh, but you have to establish a hiring bar from which to base the hire/no-hire decision. There is no non-boolean value for this question.
Also, note the public API component to the question. API design is a key skill for today’s software engineers. We are always interfacing with somebody else’s code. Poor candidates will design their API such that it requires extra input parameters such as start and/or end indices and/or maybe a length parameter. Crap like that is just unnecessary, and good candidates just won’t put in unnecessary information like that. That’s a red flag for me and it makes me think twice about signing off on the candidate for the next round.
As for the code itself, I try to use collabedit. However, given the simple nature of this coding problem, you can also do it just by having the candidate writing it down on a piece of paper and reading the code back out verbatim if a stable internet connection can’t be had. Note that the code needs to be compilable. If the candidate writes code that looks more like pseudocode, I explicitly ask them “Will this code compile?” At that point, they either correct their code or verify their own ignorance.
Lastly, for candidates who use the more standard languages that involve a call stack (which is the vast majority of candidates), I follow up the first question with a part B:
Suppose your colleague performs a code review and they state that you should use recursion to reverse a string. Would you agree with them? Why or why not?
I ask this follow up question because in the real world, recursion can go too deep and result in a stack overflow. Consequently, I think that anybody writing C++, C#, Java, etc. needs to understand these dangers. For something like the reversal of a string, where the reversed string might end up having thousands of extra calls on the call stack, this is a real concern. In my experience, great engineers all realize this fact, and not-so-great engineers tend to not realize it.
To cut the interview short or to not cut the interview short?
If a candidate cannot successfully negotiate a string reversal algorithm, do you really want to potentially hire them? Is anything, however brilliant they say after this point going to change your mind? For me personally, an inability to negotiate this problem is a showstopper. As such, if the candidate cannot reverse a string, and the phone screen is just painful for both involved, I usually cut the phone screen short at 20 or 30 minutes. The 20 minute minimum is based on a conversation with recruiting at a previous employer where recruiting felt that 20 minutes was the bare minimum time required for the candidate to feel like they had a chance to prove themselves. At the end of this question, I politely tell the candidate that that’s all the questions I have for them and ask them if they have any questions for me. I’m as polite as possible, but I also have demands on my time at work. So if I can get back some extra time by quickly filtering an unqualified candidate, then I’m OK with that. Others that I know prefer to go the full length of the phone screen, despite the fact that the candidate can’t recover from it, and that’s fine too.
I think that the choice to cut a phone screen short varies by interviewer. But if you’re going to do it, I think that it’s important to be respectful and polite and just inform the candidate that that’s all the questions you had and whether or not they had any questions for you. Once you are done answering their questions, if any, just part ways politely.
Core Competency 2: Data Structures – Choosing the right one
In my opinion, the ability to pick the right data structure is a key skill for any software engineer. We pick data structures most times we code, and it’s one that can be gauged well over a phone. To test this, I ask a lightning round style set of questions that also tests some secondary skills. The first data structures question I ask is:
Suppose you are writing some server side code that returns recommendations as part of a HTML page to the customer. To determine recommendations for the customer, you call a web service. Unfortunately, this web service is poorly implemented and you have to call it for each recommendation, until the web service returns a null recommendation. While you are calling the web service, what data structure would you store the recommendations in until you are ready to render the HTML page?
That question is a mouth full and is easily confusing on a first pass. As such, my first data structures question actually gauges a candidate’s ability to ask clarifying questions to deal with ambiguity – another key skill of any software engineer. Good candidates will tend to drill down ask a few probing questions such as “Do we know the exact number of recommendations to add beforehand?”, “Approximately how many will we get back?”, and/or “Do we need to access the middle elements?” Reasonable candidates will usually respond with a linked list or possibly an array. Personally, I think that linked lists are preferable here but I have had candidates that give reasonable answers for why an array is suitable as well and I get them to explain why.
Next I usually ask:
How would your answer change if we knew the exact number of recommendations to retrieve beforehand?
Good answers will list an array for this. But again, some candidates give reasonably sound reasons for a linked list and that’s OK too. A big part of this core competency is probing their reasoning. If they have good reasoning skills, then I’m OK with going with either.
My third data structures question is:
How would your answer change if the web service returns duplicates and we need to filter them out?
For this a set is the correct choice.
Next I deviate from choosing data structures and delve in a little to see if they understand how a set is actually implemented. We quickly get to the underlying hash table implementation. So I again delve and say:
Explain to me how a hash table works internally so that it can filter duplicates.
Hashing is meat and potatoes programming, it’s ubiquitous, and again, solid engineers really tend to understand how hashing works at a high level and in my experience shaky engineers tend not to know.
Next, I try to gauge whether or not they understand concurrency by asking:
How could you make a hash table concurrent?
This is not necessarily a no-go for an intermediate level engineer, but it is a definite red flag for somebody interviewing at the senior level. The candidate who truly understands concurrency will realize that you need to synchronize on individual elements (or stripes) of the internal array, and not lock the entire array.
Lastly on data structures, I ask:
Since customers will probably only look at the top ten recommendations, what data structure would you choose to only ever keep track of the top ten recommendations, discarding all others when attempting to add?
This is a classic use case of a heap (i.e. priority queue). Again, in my experience, super-par engineers tend to know this and sub-par engineers tend not to know.
Core Competency 3 – Object Oriented Design
The last part of the phone screen entails object oriented design. In addition to purely object oriented design, I look for the following skills:
- Ability to design a type hierarchy
- Ability to distinguish where composition should be used and where polymorphism should be used
- Ability to deal with ambiguity
- Communication
The question that I ask is:
How would you design an animal kingdom hierarchy for a virtual zoo program?
The question as it stands can’t really be answered correctly without further information. Competent candidates quickly get to asking for use cases where they then find out that intention is for a separate virtual zoo program that we don’t care about to use classes in the type hierarchy of animals to draw them. After a little while, we get to a basic hierarchy where there is a default interface specifying a draw method called Animal. Abstract subclasses include entities like mammals, birds, and fish. Finally concrete classes are for various species that will be drawn in the zoo.
Finally, I ask them how, after the initial release of the virtual zoo, they would insert a flying fish (i.e. a fish with bird wings) into the existing hierarchy. Many candidates just aren’t able to design a solution that doesn’t result in duplicate code for drawing the wings or without multiple implementation inheritance. I’ve lost count of how many times I have seen a crazy type hierarchy with methods and parts of methods jumping between classes and superclasses and child classes. I don’t want to work with such hierarchies, so I filter out candidates who are not likely to be able to design anything better than them. As the Gang of Four said:
… our experience is that designers overuse inheritance as a reuse technique and designs are often made more reusable (and simpler) by depending more on object composition.
Jon’s Final Thoughts
So this is what I ask in my first phone screen. While not strictly Yegge’s five essential areas, I do gauge three of his areas and check for a few more things that I really feel are required by every solid software engineer.
Also, note that interviewing isn’t a perfect science. Acceptable answers in some areas might be just fine for me and unacceptable for other engineers, and vice versa. As time goes on, you will start to be able to perceive how candidates perform relative to others you interview, and you will be able to gradually calibrate your technical bar as time goes on.
I hope that this post was useful and you are able to incorporate some of these ideas into your own phone screens. Feel extremely free to leave comments and/or questions, subscribe to this blog, and/or share this post. 🙂