Getting the Interview Phone Screen Right

I like the idea of asking indirect questions about tools and practices. IHMO a good programmer will have reasoned opinions about the tools he uses, the style in which he codes, and the process by which he codes. That can’t be the only thing you quiz, but you can learn a lot by asking “Tabs or spaces?” and listening to the justification.

These types of posts always seem to bring out the “best” in people.

Anytime I read a post regarding the types of questions to ask in an interview, the subsequent replies devolve into a pissing match. Almost nearly as fast as a “.NET vs Java” or “VB vs C#” flame-war of zealots.

This speaks to both the hubris of many developers and the complexities of what it means to write software. There are no “magic bullets” for interviewing because the needs of various positions differ so damn greatly.

Imagine an advertisement that was titled “Pilot Wanted”. Ok, fixed wing or rotary? What type of aircraft? What a “pilot” is can mean a great many things, but any pilot should understand “altitude”, right?

Steve Yegge’s and Jeff’s point is that there can unifying questions; so pick and choose what is applicable to you in a thoughtful manner and f*ckin’ save yourself a lot of wasted interview time.

I’m glad you corrected yourself, Jon. I was about to put that code into production :stuck_out_tongue:

been on both sides of the phone. Basically, you have a staff position to fill, a contractor is too expensive, management wants to hire Steve Wozniak at the guy on the corner holding the “Going Out of Business” sign’s salary.

You have approx. 200 applicants for the position (once you’ve weeded through the kids of people who attend church with your managers - if you wanted a Facebook page or someone to type your questions into Google all day, hoo-yah, but you’re just looking for somone to mentor), all of whom are (according to their CV) dynamic proven self-starters with long tails of success at jobs working at the print shop and university computer lab.

Pop quiz - what do you do? what do you do?

Keywords! Everyone comes up with some questions they think are interesting - after 8-10 years of practical software development experience.

Then you surf the web and come up with a few more, collectively cooing “ooh, that’s a good one” because the idealistic side of you wants someone bright-eyed and dedicated to lapping at the oozing pores of your wisdom, not considering that pretty much everyone coming out of college has just spent 4+ years alternating between learning how to have adult relationships, trying to cope with the expectations of their parents and working meaningless jobs while getting the entire collected history of humanity jacked into their heads Matrix-style.

So, you need to weed. Most of it is personality - you want someone who’s not an ass, someone who can look at a set of poorly understood facts in miniscule timelines and solve the problem at hand without creating too many additional ones. It would also be nice for them to admit when they are wrong and show you when you are wrong without turning every discussion into a deathmatch.

Plus, it would be cool if they liked Golden Tee and anime and debating who would win a battle between the Death Star and Battlestar Galactica.

So anyway, now you have three goals in your little “interview this person” user story:

  1. Conceal the fact that your system is a 2001 value proposition with a tree-ring like series of patches, fixes, stuff a contractor dude did during a 30 day contract, good ideas unrealized, bad ideas overmaintained, things people forgot to maintain and semi-tested code layered on top;

  2. This person will not in fact be doing the job that’s advertised, but maintenance and support work until s/he proves themself capable of wearing the big-boy pants and not ruining another one of your weekends with an untested patch;

  3. Gently ease them into the idea that this is a job, which means you lose the right to expect justice when you cash your first paycheck. There’s a great group of people, who are smart and dedicated and often leave you dumbfounded with respect for their intelligence and professionalism. You’d really like to bring someone new in and teach them some good things they could build a career on, but always remember that this isn’t really a family and if the stock price tanks or some VP needs to have an accomplishment on his PMI you can and will be out.

So, they come in. It’s cool when they dress up (at least to me) - not like we all hang out wearing ascots and drinking martinis but it shows someone is trying to tell you they take the job seriously and they want you to take them seriously. If I want to spend time chatting with a guy in Dockers and a muscle t-shirt I can play GRAW 2 with my sister’s idiot boyfriend.

Of course, you’re in the middle of a fix because Mr. Dipsy J. Doodle once again checked experimental code into production (and he’s in a different reporting org so you can’t properly beyatch-slap him, just write a five-paragraph email both managers will delete at the first detection of obtuse techie-speak acronyms like CVS and FUBAR) and you didn’t have time to prep the great story about how this is a fan-fricking-tastic place to work.

You’d really like to ask “Hey, I have this process that keeps terminating on Wednesdays when the outside temperature goes over 60 degrees - it’s a J-21 implementation of the RBVA-16 use case that tries to implement a singleton strategy pattern factory because that was what the architect we brought in to catapult a design specification at us had read about on the plane ride here” but you’d spend seven hours explaining the business problem.

So you have keywords. Because it’s objective and easy and you have to get the pool down somehow so you can get back to work and fix the build in time to have dinner with your wife before the 10 o’clock news.

The respondents fall into three classes:

  1. People who try to rephrase the first Google answer that came up;
  2. People who sit blankly and say “um…I don’t know.”
  3. People who say “I haven’t worked with that, but I would try Google.”

So…who would you hire? Is this where I reveal my secret sauce, my magical ingredient that lets me pick out the cream of the crop so we can all be entrepreneural and start our own blogs about developing turnkey Joomla solutions for non-profits saving babies in Afghanistan?

No. It’s not. Because again I have no idea if this guy is a twit or a blowhard or what. I know s/he’s inexperienced. So I ask, how would you find out? Have you ever dealt with problems like this before?

And then they fall into three subgroups:

  1. People who are curious about everything;
  2. People who are curious about what they think they are paid to do.
  3. People who are basically not curious, either because they are obtuse or they think they have all of the answers worth knowing.

I prefer 1 but I have been through enough to know that I need 1 and 2. I do not want 3. If I have too many 1s, we have a great time and loads of fun and no work gets done. If I have too many 2s, there are a ton of related problems in Bugzilla you have to threaten people with termination/death to find root cause and take CA on. If you have too many 3s…well…that doesn’t last.

So the tech questions are a gateway to the thinking process. And finding out if you have any chemistry with the person, which in the end is what hiring is all about.

and all of you outside-the-boxers who want to be snitty about corporate software - I’m sure your new site kicks ass, whether for the Taco Hut or that new social networking board that you and your 20 friends use came up in 5 days with free tools, but I notice you don’t trust your investments, airline reservations and bank balances to the hipster doofuses of the world. And trust me, the affiliators and link managers of the world laugh like hyenas at most of your sites coming up in the affiliate request lists.

When it comes to money, or anything meaningful, you want Gollum in the cave and you want someone to be beating him with a whip while he minds your gold. That’s the consistent side of the business.

One of the problems with phone interviews is that they don’t replicate the process of sitting down and solving a problem very well. I look at programming as like constructing a building - you need tools. You bring many things with you - prior knowledge, experience, knowledge of coworkers (if you asked them a question for example), and various other “tools” such as books, reference materials, and yes, google. It’s not the same as being asked a question and expected to answer right off the bat with nothing but what’s in your head. It proves knowledge, not ability or talent. Any indication of ability or talent you get from the answers is just a projection of how that person sounds, not an actual test of their aptitude in those areas.

As a psych major I studied interview processes and an interview is the worst predictor of how well someone will do on a job – think about it, you’re testing someone’s ability to interview well, or in this particular case, testing their ability to recall specific bits of knowledge. I think that’s why some people have such a negative reaction to it – because if you’re asked to prove your knowledge, it makes you look stupid if you don’t happen to have the answer.

The “If you don’t know this you aren’t a good programmer anyway” responses come off as elitist and condescending to me. Sure, studying for an interview proves that you’re willing to put effort into something, but maybe some people don’t have time to sit around and code and work on brain teasers in their spare time – especially busy people, who have 40 hour a week jobs and families and lives. In other words… more well-rounded people.

I totally agree that for some jobs you need geeks, especially places like Google and Amazon (although I’m sure they also need people with good team skills and problem solving abilities)… some companies just don’t necessarily need that; other skills are more important and should be evaluated for instead. Kudos to the person who said as much earlier, and that companies will in the end be taking a risk on someone and going with their gut. That’s often more important for MOST companies, than looking for the egghead. But as always it depends on the task. Sometimes problem solving is more important, sometimes it’s creative thinking or ‘outside the box’ approaches.

“Write a function to reverse a string.
Write function to compute Nth fibonacci number.”

Just for kicks I wrote my own versions of these in C#, and then again in Scheme. It was actually a really fun exercise to do the latter! Maybe an interview question worth trying would be to have the candidate quickly learn Scheme (it takes all of 3 minutes, a href="http://en.wikipedia.org/wiki/Scheme_(programming_language)"http://en.wikipedia.org/wiki/Scheme_(programming_language)/a) and then write a few of those in functional/recursive style.

Anyway I never thought of the interview from the angle presented here, that of “find something they DON’T know and see how they fare,” but it makes a lot of sense. I actually interviewed for a job about a year ago and I did pretty well. After being asked all sorts of cool questions about some non-typical binary tree stuff, I was asked to reverse a linked list in C. For some reason though, I completely bombed that question! The guy interviewing me obviously knew that this was something that could be found quickly through an online search and wouldn’t actually stump anyone on the job. But, I screwed it up (I was close), and I admitted as much, so maybe that was fair enough. I just thought it was funny that I tripped over such an elementary question! (Yes, I did get the job)

@collator, I think you are exactly right. A lot of the “screening” questions seemed designed to select those who know the same trivia as the interviewer.

You want to hire people that have a spark of intelligence in their eyes, a curious mind. And if they fit in personality wise, to make the team greater than the sum of it’s parts, bonus.

Where are the jobs with interviews like this? I have had 3 programming jobs, out of my 7 total jobs in 9 years of IT work experience, and I have never encountered a phone screening, or even a skills test. Like many here, the samples provided in the linked posts seem trivial, and I have trouble (or would have, prior to reading thedailywtf) believing that someone out there who cannot pass these tests is holding a job as a programmer. I would love to go through such an interview process, if only for the novelty and fun of it.

those things don’t define a good programmer - it’s the research skills and coding experience that really matter, not if I can recite some BS to you - I agree with David
" It’s not the same as being asked a question and expected to answer right off the bat with nothing but what’s in your head. It proves knowledge, not ability or talent. "

I want ability and talent from my developers, not the memorization of how to compute Nth fibonacci number - your theory and methods are way off base - good luck in the real world

OMG, Steve would be also rejected by me if I saw his ‘main()…’ C/C++ program.
The standard says ‘main’ has to return an ‘int’.

The phonenumber thing cracks me up, it’s a very realistic “problem”. I’ve had to solve it multiple times (for different kinds of data) I don’t think it ever took me more than 15 minutes to write a usable regex for anything that can be expressed in one of a few ways and will be on one line.

I guess what I’m saying is that in a worst case scenario it’d take about 20 to 25 minutes for a real programmer to have a working tool to extract the requested information ready enough for testing by someone other than the developer that wrote it. Anything over 45 mins would be unaccaptable i think, even without regexes it’s easy enough to do afterall.

It took me under two minutes to write /(([0-9]{3})|[0-9]{3})(\s|-)[0-9]{3}-[0-9]{4}/ off the top of my head as a probable solution
(xxx) xxx-xxxx and xxx-xxx-xxxx right here in this textbox, so untested and probably with at least one typo, but given an IDE that should mean the regex is probably very doable in under 5 minutes.

The problem is simple enough to make me think its possible to do it with just sh, more, grep and some piping between them on a single command line.

Anyway, just my 2cts. good post btw.

@Lawrence,

Your post is a great reminder to read comments before writing my own. You are so right.

Apart from the technical questions I would also ask something about the company and the company values. I had an interview once were they asked me to arrange some company value words. It was a great way for me to know if I would like to work there or not.

Fresh out of school, I failed a bit on the technical questions (that was something like you mentioned) but got the value words pretty nice lined up. I guess I’ll apply again soon :slight_smile:

It seems to me that a lot of the readers of this article have got the wrong idea. It’s not like if you don’t know this stuff, you will be screened out because you can’t program. The idea is to get a feel for the kind of person you are.

Obviously if they want someone to come in and get a specific job done then not having the skills in that particular area is a bad thing. But if they are looking for a long term employee then they are going to want someone who can learn and adapt to new stuff quickly. Having the skills and having the ingenuity to learn the skills are two different things.

I’ve not really bee working that long and haven’t come across ‘Scripting and Regular Expressions’, so i have no clue about that phone thing. I could guess, and I’ve have an idea of where to start looking and that’s what I’d tell my interviewer anyway.

Besides i could always look up some comments made about a article blog about programming. :smiley:

It is interesting that no one has talked about the setting of a phone interview. I rank them just above telemarketing calls. I’ve done lots of interviews face to face as the interviewer, but never had to do a phone interview as one (the company had buzzword jockeys for that). Yet I did a lot of them as an interviewee during a year long job search. Many of them came while I was preparing dinner for my family. One in particular came on my cell as I was coaching my son’s soccer game. The interviewer refused to call back, and since I couldn’t give any focus to the questions, I refused to waste his and my time and said good bye. A face to face is scheduled, and I make it a point to leave my cell phone and any other distractions behind. Phone calls are ad-hoc, and don’t account for distractions. I only passed one phone interview, and that was for a job I didn’t think I was qualified for. I thought I did well on several given the fact I was fielding questions from the interviewer and my kids, plus getting other calls.

Is that the spark fun cell phone ? Very cool.

@collator - nicely put…

I enjoyed that, thanks :slight_smile:

Albeit cynical, its true.

Let me tell you the “Dec 31 vs. Oct 25” joke is just not ‘funny’. Ask your mother, she will explain why. That kind of joke falls within a ‘geek’ culture that separates programmers from the rest of society… I don’t find that healthy.

Been a coder for 20 years, working with programmers for a good while, I encourage my (often younger) colleagues to “not-be-a-freak”… For the sake of our mental sanity!

Now shut down your freakin’ computer, get out have some beers, and talk about non-computer stuff, ideally with people not interested in computers at all. In other words, get out of the box! That improves your thinking skills, the one-and-only to be asked for at any job interview. Alas, I am yelling that to myself!

I doubt more than 10% of our development staff, myself included, could actually deliver the goods on such a phone screen. If we were lucky you would be able to tell from how we handled ourselves that we were good candidates, but the whole premise here was to get past those gut feelings to an empirical test.

I give it a C-.

I would happily replace all of these tests with a test on coupling and cohesion. If someone doesn’t understand the importance of these two concepts then they have had a deprived education. That is what destroys 99% of projects.

Also, what about a list for hiring managers? They can really suck too.