The Five Essential Phone-Screen Questions by Steve Yegge

The Five Essential Phone-Screen Questions

• It's usually pretty obvious when the candidate should have been eliminated during the phone screens.
• The first pattern is that for most failed phone screens, the candidate did most of the talking.
• The right way to do a phone screen is to do most of the talking, or at least the driving. You look for specific answers, and you guide the conversation along until you've got the answer or you've decided the candidate doesn't know it.
• The second pattern is that one-trick ponies only know one trick. Candidates who have programmed mostly in a single language, platform, or framework usually have major, gaping holes in their skills lineup.
• If you only asks the candidate about what they know, you've got a fairly narrow view of their abilities.
• These five areas are litmus tests--very good ones. I've chosen them based on the following criteria:
• They're universal--every programmer needs to know them.
• They're quick--they're areas that you can probe very quickly, without eating too much into your phone-screen time.
• They're predictors--there are certain common "SDE profiles" that are easy to spot because they tend to fail (and I mean really fail) in one or more of these five areas.
• You have to probe all five areas; you can't skip any of them. Each area is a proxy for a huge body of knowledge, and failing it very likely means failing the interviews, even though the candidate did fine in the other areas.
• The Five Essential Questions for the first phone-screen with an SDE candidate:
• Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
• OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple program.
• Scripting and regexes. The candidate has to describe how to find the phone numbers in 50K HTML pages.
• Data structures. The candidate has to demonstrate basic working knowledge of the most common data structures.
•  Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.
• What I'm looking for here is a total vacuum in one of these areas. What you're looking for is candidates who are utterly clueless, or horribly confused, about the area in question.
• When a candidate is totally incompetent in one of these Big Five areas, the chances are very high that they'll bomb horribly when presented with our typical interview questions.
• The candidate has to write some code. Give them a coding problem that requires writing a short, straightforward function. They can write it in whatever language they like, as long as they don't just call a library function that does it for them.
• I've decided that candidates need to be able to code their answers in C, C++, or Java.
• Some properties of a good weeder phone-screen coding question are:
• It's simple.
• You've solved it.
• It has loops or recursion.
• It has formatted output.
• It has text-file I/O.
• You shouldn't ask a question unless you've solved it yourself recently, so you know it's a reasonable question, and you can evaluate their answer to it.
• Being able to reason recursively or inductively is important for many areas of computing, including using hierarchical data representation, distributed computing, searching, and sorting.
• Many candidates simply can't think recursively, and this often goes undetected until interview-time.
• This [formatted output] is a basic skill, useful for debugging, simple report generation, and lots of other things. "printf" is a universal standard; it exists in C, C++, Java, Perl, Ruby, Python, and virtually every other mainstream language, at least as a library call.
• Candidates who have worked in frameworks for too long often become unable to function as programmers outside that framework. Not being able to do simple file I/O is a common indicator that they've grown overly dependent on a particular framework.
• We shouldn't hire SDEs who aren't at least somewhat proficient with OOP. I'm not claiming that OOP is good or bad; I'm just saying you have to know it, just like you have to know the things you can and can't do at an airport security checkpoint.
• OO has been popular/mainstream for more than 20 years. Virtually every programming language supports OOP in some way. You can't work on a big code base without running into it.
• OO concepts are an important building block for creating good service interfaces. They represent a shared understanding and a common vocabulary that are sometimes useful when talking about architecture.
• I draw a distinction between "knows it" and "is smart enough to learn it". Normally I allow people through for interviews if they've got a gap in their knowledge, as long as I think they're smart enough to make it up on the job.
• Candidates who've only studied the terminology without every doing any OOP often don't really get it. When they go to produce classes or code, they don't understand the difference between a static member and an instance member, and they'll use them interchangeably.
• Many C/C++/Java candidates, even some with 10+ years of experience, would happily spend a week writing a 2,500-line program to do something you could do in 30 seconds with a simple Unix command.
• In my experience, a programmer who only knows one language is usually completely lost in one of these Five Essential Areas.
• SDE candidates need to demonstrate a basic understanding of the most common data structures, and of the fundamentals of "big-O" algorithmic complexity analysis.
• Here's what they need to know about big-O. They need to know that algorithms usually fall into the following performance classes: constant-time, logarithmic, linear, polynomial, exponential, and factorial.
• Nobody likes to admit they don't know something you need to know.
• All programmers should be able to count in hexadecimal, and should be able to convert between the binary, octal, and hex representations of a number.