The goal of a phone screen is to get to a quick "no." That require a deep understanding of the types of what makes a successful developer (or really any other profession) in your environment. In our case, we look for passionate programmers who are looking to develop great systems and be not just willing, but happy to move on to new project. A Quick "no" is meant to make sure that the candidate's time and the interviewer's time are well spent. It's not about the general quality of the candidate, it's about the quality of the potential relationship between the hiring agent (the company) and the candidate. I don't want to waste the candidate's time in a long face-to-face interview that will end in a "no"; I'd rather find out as much as possible early on. A honed screening could be performed with a 10-15 minute chat.
In our case, we look for solid fundamentals. I don't care whether or not you know a particular API. If one can google it, a passionate programmer will find the answer quickly. A passionate programmer has a deep understanding of fundamentals.
Collections are a great way to understand the depth of fundamentals. Most people simply use some of them because they're there, but a passionate programmer will peak under the covers and know how to use them almost without thinking.
Here are some of the "basics" questions we ask:
- How a HashMap works (equals()/hashCode(), prime numbers & etc.)
- Describe how you can sort a collection
- Describe how a Singleton works (the use of "static," "private," "synchronized")
On a face-to-face interview, we'll ask a question that requires looping that should be quick to answer. We'll specify the method signature, so that the candidate is pointed in the right direction. There usually a simple "trick" to it that a passionate programmer will see pretty quickly:
- reverse a char ("Solomon" should become "nomoloS"... in place)
- take a char with your name ("Solomon" in my case), and copy the characters forward ("Solomon" becomes "SSolomo" because you can't change the size).
Passionate programmers will have the answer that I'm looking for pretty quickly. They will also describe alternatives... For example, System.arraycopy for the second problem (will that actually work? Passionate programmers will try to figure that out...).
90%+ of the time, those questions will weed out the inappropriate candidates. Hmm.. we really should be doing a coding question before a candidate even comes in. I don't know if those array questions are right for pre-face-to-face interviewing. Perhaps something more generic, like "write and send a snippet of code that you'd like to discuss on the interview."
We're interviewing like crazy these days in NYC. If you have any more suggestions on how to get to a "no" (or "yes") faster, please let me know by email or by comment. I'm looking for more ideas (and of course more candidates...)