What are your essential phone-screen questions?

Question

I loved the article from Steve Yegge where he explains to get the most out of phone interviews

1. Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
2. OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
3. Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
4. Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
5. Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.

What are your essential phone screen questions when you are interviewing over phone?

Answer 1

• What would your current or previous boss say about you if I phoned them right now?

• (If I'm interviewing someone who would, in turn, interview others) What are some good questions to ask candidates when interviewing them by phone?

• In object-oriented terms, what is an Interface and how are they helpful (if at all)?

Answer 2

I like to find developers that are passionate about their work:

• What about this job interests you?
• Tell me about your favorite piece of software.
• What don't you know that you would like to learn if you had the time and resources to learn it?

etc.

Answer 3

I liked these questions asked at Microsoft Dublin. It has some good engineering questions as well as some classical ones.

Answer 4

What books on programming have you read lately?

Answer 5

Joel Spolsky wrote a great essay on The Phone Screen.

Answer 6

General questions are a good way to start off.

"Are you an idiot?"
You can learn a lot from that answer about how well they will fit in to the development team. Its also a good ice breaker for a first question.

"Are you wasting my time?"
Honesty, humility here.

Answer 7

• Do you read blogs? Who do you find the most influential on you? Do you have a blog?
• What was the last tech book you read?
• What kind of code to you write on your own time? OSS Projects?

Answer 8

The way I conduct phone interviews is as follows:

Preparation

I never interview the applicant on the first phone call. This doesn't give me the time to go over the candidate's CV and consider if there are points I'd like to bring up on the interview, such as specific work experience or glaringly missing skills. Additionally, setting up a specific time for the phone interview allows the candidate time to mentally prepare, drink a coffee and settle down in a quiet spot somewhere. Just puts everyone at their ease.

When first calling the candidate I always take the time to introduce the company I work for, a synopsis of what we do and a general description of how the company operates. I then proceed to inquire if the applicant sees this as a potentially interesting place to work in and whether or not they have any questions; you'd be surprised at the time this can save, for example it's not always obvious whether or not the applicant is interested in working for a start-up company, or alternatively may not find the problem domain engaging.

Getting to Know The Candidate

To start the interview off, I usually skim over the candidate's CV and select two or three interesting projects that the candidate was involved in. I ask the candidates to describe their involvement (sometimes, but not often, going into a bit of detail if the domain is familiar to me), their specific contribution to the project, whether or not they had fun and why. This usually gives me a sense of what the candidates are looking for; are they heavily into design? Are they enthusiastic about a specific technology, and if so, do they have a sound reason for it? Were they frustrated by administrative issues, did they try to improve their working environment?

Technical Questions

Once those formalities and niceties are out of the way, I turn to my ever-growing collection of interview questions and select a small subset to present to the candidate. For example, a typical interview may include the following questions:

Integer Arithmetic

Does the candidate have a decent grasp of bits and bytes? I consider this a must-have; a candidate that fails this part has no chance in hell of tackling even the most trivial native code.

• "Take an integer. How do you turn the 7th least significant bit off?" This question alone removes about half of the applicants from the equation. Some people tell you "you need to apply bitwise AND, but I can't remember the number you need to AND with" -- this isn't what you're looking for. A good answer would be something like "x &= ~(1 << 6)".
• "How would you quickly divide an integer by eight (8)?" A good answer is, you shift right by three. A better answer would be "is the integer signed or unsigned?", with a bonus for Java developers who know the difference between >> and >>>.

Pointers and Pointer Arithmetic

This really depends on what your company does. Most developers today don't need to know in practice the particulars of pointers and pointer arithmetic optimizations, but if you're developing a highly scalable system and/or one with serious performance considerations, this is a very good measure of how likely the candidate will be able to tackle such challenges.

• "How big is a pointer?" The only correct answer is, "depends on the architecture". 32-bit operating systems will have 32-bit pointers, 64-bit systems will have 64-bit pointers. Anything that doesn't fall into these two categories is not relevant for my purposes, and likely yours as well. If the candidate fails this question I usually mark this section as "failed" and move on.

Floating Point Numbers

• "What is NaN?" A programmer who can't answer this question has never really worked with floating point numbers.
• "How are floating point numbers represented in a typical modern architecture?" Failing this question is not a deal-breaker, but answering it correctly will score the candidate a lot of points. "sign, exponent, mantissa/fraction/significand" is a sufficient answer.

Essential Data Structures and Algorithms

This is the bread-and-butter of programming. A candidate should exhibit robust familiarity with commonplace data structures (hashtables, linked lists, trees etc.) and algorithms (sorting, graph traversal).

• "Describe how quicksort works. Elaborate on its performance characteristics." Any professional developer should be able to explain quicksort in a few minutes, know its average- and worst-case complexity, and recognize pathological cases (typical school-level quicksort implementations exhibit horrible performance on pre-sorted data).
• "How are hashtables commonly implemented?" A candidate should be able to describe the concept of a hashing function (uniform distribution) and how it relates to the internal data structure (normally an array of buckets).
• "What backing data structure would you choose for a simple text editor?" The classic answer is a rope, but it's unlikely that a candidate will be familiar with this data structure. A more likely response would be a "linked-list of strings", in which case you should ask about the complexity of various editing operations (deleting a line, inserting a line, deleting a character etc.) This question typically takes slightly longer to answer but I've found that it gives me a good measure of the candidate's intuition in choosing/analyzing data representations.

Threading and Sychronization

This is fast becoming the most important subject with which to distinguish the truly brilliant candidates from the merely competent; the ubiquity of multithreaded code nowadays also means that these questions can be used to quickly weed out the unworthy candidates.

• "Describe one common way of synchronizing access to a shared resource." This is just a starter question, and if the candidate takes more than a few seconds to come up with an answer (mutex, semaphore, monitor or "synchronized" for Java developers, "lock" for C# developers) it's usually a good sign that they don't have any reasonable experience with multithreaded development.
• "You have a shared cache with a very good hit ratio. How would you synchronize access to the cache with as little performance overhead as possible?" The answer is trivially a read-write lock which can accomodate multiple readers and a single, exclusive writer. Where appropriate, ask how the candidate would implement such a lock.
• "Describe a nontrivial problem that you've had with threaded code." Responses usually fall into one of three categories: either (1) a reasonably experienced multithreaded developer would never make the same mistakes, in which case the candidate obviously isn't one; (2) a classic race-condition/deadlock/etc. scenario, which merely tells you that the candidate has some experience with multithreaded code and appears capable of tackling such challenges; or (3) rarely, a candidate may have a genuinely interesting "war story," in which case you'll probably want to hire them right away.

Peripheral Technologies

Approach this section with caution. A canditate that's familiar with a great deal of today's hot technologies may prove completely incompetent, whereas it's quite possible to find brilliant programmers that have never touched COM in their lives. I still like to get a sense of how "in touch" the developer is with contemporary technologies; familiarity with tools and technologies can definitely be a tie-breaker between two promising candidates.

• "Are you familiar with COM? Describe an interface which any COM object must implement and its methods." Anyone who's even a bit familiar with Windows software development should be able to answer this question fully. For those unfamiliar with COM, describe it in a few words and ask the canditate to guess what the required methods of IUnknown are.
• "What is a well-formed XML file? Give two examples of errors in an XML file which would render it non-well-formed." XML is prevalent in almost every software development domain. A candidate which cannot answer these questions (and doesn't have a very good excuse) will not go past this interview.
• "What's XPath? Explain what a predicate is and how it's used." This is not most-have. I'd expect serious developers to at least have an idea of what XPath is. The second question is there to differentiate those who profess to know XPath from those who've actually done work with XPath and/or XSLT.
• "If you had to verify the input of an e-mail address field, how would you go about it?" There are only two valid answers to this question: "I would use a regular expression," or "I'd like to use a regular expression, but I know that fully matching e-mails according to the RFC is insanely complex, which is why I'd get a proven library to do it for me." If the canditate is being a smart-ass you can always ask them about the performance characteristics of commonplace regex engines (which have pathological cases).
• I also like to just toss buzzwords (Ruby, Boo, JSON, Struts, J2EE, WCF) around and examine the candidate's responses. It may also provide an interesting subject to ask about in a personal interview later on.

Concluding the Interview

The previous section usually takes between 10 and 15 minutes. At this point I normally ask the candidate if there are any questions they'd like answered, or anything I should know before we conclude the interview. Once that'd done, I thank them for their time and tell them (even if they've failed miserably) that I will call them back in a day or two with an answer.

Hope this helps, comments are welcome.

(Crossposted on my blog. Yes, it's a shameless plug :-))

Answer 9

Is that typing I hear???

So many phone interviews with people typing in the background, or sound like. For 60 seconds they seem to have no clue and magically the answer appears.

Best to ask questions about how would you do this. talk me through the design that you would use rather than, what is the option ls to show this, or how do you blah in Perl.

For those cheaters out there:

The best way to cheat is 2 people, one more expert than you ( or fast googler ) . 2 phones and 2 computers. The expert dude is on mute and sending instant messenges to the person being interviewed.

I always like to see people in person and now you know why.

Answer 10

I like to ask for the three cardinal virtues of a programmer, particularly when it's a Perl position. (The answers are at the end of "man perl".)

No, of course I wouldn't flunk someone who didn't know. But it would impress me to know that someone read the manpages and groks Larry Wall's vision.

Answer 11

(for a .NET candidate)

"Say you have some data in SQL Server, and you want to put that data in a table on an HTML page? How would you go about doing that? I'm not looking for something elaborate, just something that will work."

A surprising number of people can't detail the basic, simple way (SQLDataAdapter to fill a DataSet to bind to a DataGrid - and that's far from the only way) which is a good way to weed people out. A few people just need a push in the right direction (in case they're overthinking the question) but some people you have to drag it out of them.

Answer 12

(for a .NET candidate, though I suppose it will work for others)

"Give me an example of an Interface you've implemented"

I guess it depends on what level of developer you're looking for but pretty much anyone you want for a "Senior" position has at one time or another implemented an interface like IDisposable.

Answer 13

"What is your favorite programming language, other than [primary language of the position you're interviewing for]?"

If they don't know other languages, that could be a red flag but still not a showstopper. If they list off some language you don't like, who cares - at least they have a range of programming interests. But if they list something like "XML", that's not even a programming language, then I wouldn't bring them in.

Answer 14

Seriously, for phone calls? Writing code? LOL. OK.