Chapter 2

Handling the Phone Interview with Confidence

I once nearly shot an interviewer in the head with a rubber band. I was nervously fiddling and it slipped and went sailing just over his head. Somehow he didn't notice, but it settled my nerves because it was kind of funny.

This technique was effective for me, but I don't suggest you try it. Your aim might not be as good as mine.

If you pick up a generic book on interviewing and flip to the chapter on handling nerves, you can find a lot of helpful-sounding advice, like remembering to breathe, imagining interviewers in their underwear, and role playing the interview with a friend.

If that kind of advice works for you then go for it. But if you've tried those kinds of things and they haven't worked, here is some advice specifically for programmers.

What you need to realize is that programmers are special. If you take away the project manager, the tester, the document writer, the business analyst, the systems analyst—even if you take away the UX expert and the architect—a programmer can still write code. Maybe it won't be as good as if all those experts had pitched in, but the point is the programmer on the team is the one who writes the code. The others help.

Now imagine that team of people without a programmer. See? That coder-less team might produce an impressive set of PowerPoint slides, or a shiny mock-up of what the product might have looked like, but it takes a programmer to write code that compiles and does something useful.

Don't forget that.

Here is another thing to remember: Good programmers are scarce. At times, it might seem like you are competing with hundreds of other programmers and you might be, but you have a big advantage—you are a good programmer or you want to be, and that will make you stand out.

I might not hire a programmer for many reasons, but first and foremost among the reasons to hire is the ability of the programmer to be capable of writing code. Of course, exceptions exist, such as when a non-technical manager is the only interviewer, or when the job turns out to be something other than actually writing code, such as working with spreadsheets or spelunking around with MS Access.

After all these interviews, just one thing still surprises me, and that is when I ask a candidate programmer to write some code and he can't, or when he writes code without any apparent knowledge of looping constructs, arrays, or basic Boolean logic. I'm not making this up.

Does that make you feel more confident? It should, because you know the basics of programming like the back of your hand, and on top of that you know much, much more. If you need to brush up on some things, no problem—that's why you're reading this book.

Knowing What to Expect

As an interviewer, here's how I run a standard phone interview.

Prior to the interview, I have read the curriculum vitae (CV) and perhaps highlighted a few things. The kinds of things I might highlight vary from CV to CV, but the most basic thing I look for (and highlight) is relevant experience. If you have no commercial experience, I look for relevant school projects. On top of that, I look for anything “extra” (that is, not strictly necessary for the job in question) that might be worth discussing during a phone interview. I can't give you a rote list of things to include in your CV, but here are some things I might highlight in order to ask you about them:

• Non-work-related software projects
• Any kind of special achievement, in any field
• Experience building a framework of any kind
• Experience in less-common programming languages or technologies
• Your personal website

I will have previously arranged a time to call you, and when you answer I will introduce myself and confirm you were expecting my call, and that you do indeed have the time to talk. Of course, if the interview has been pre-arranged I won't be expecting you to say, “Well, actually now is an awkward time”—but it has happened, more than once!

Then I will make some small talk. I might ask how your day has been. I'm not going to pretend to be your friend the instant we start talking, but I will be trying to build a basic level of rapport in the hope that you feel more comfortable talking to me about yourself. Not all interviewers do this, and if you get a call that launches straight into difficult questions you just have to go with it. The interviewer necessarily won't learn a lot about you, and that will be her loss.

Then it will be my turn to talk, and I'll describe the opportunity on offer and talk a bit about the company (more so for smaller companies).

Next, I ask all candidates to “describe what you've been doing recently.” It's an open question, and you can answer it any way you like, but I would normally expect you to talk about your most recent job, perhaps an interesting project you worked on, or something you've been doing that is relevant to your application.

I will usually always ask you some specifics about your most recent experience. Here are some of the questions I might ask:

• Were you working by yourself or in a team?
• If on a team, who else was in the team with you, and how well did the team work together?
• What did you like about your last job?
• What things could have been done better?
• What would your boss say about you if I called to ask?
• What specific technologies did you use? What did you think about those technologies?

I won't ask all these questions every time, but you get the idea.

Next, unless something you've said is a deal-breaker (such as not having essential prerequisites, should there be any) I will go through a list of short technical questions. All I'm trying to find out by asking these questions is whether you can communicate at a basic level. I do expect you to know the answers, but what I'm really testing is your ability to communicate.

Technical questions I might ask during a phone interview include:

• In object-oriented terms, what is the difference between a class and an object?
• What does it mean to pass a variable “by reference”?
• What is a partial class, and what is a key benefit of a partial class?
• What are some differences between an interface and an abstract class?

I won't give you any feedback about your answers unless, as before, something you've said is a deal-breaker. I will have made notes about your answers so that I can digest and reflect on them after the phone interview. The reason I avoid giving feedback at this stage is not to torture you—it's to give me a little time to think about our conversation and to fairly assess your answers, and perhaps compare them to answers from other candidates.

Finally, you get to ask me whatever you like. This is when you ask me the questions you've listed on your cheat sheet.

Preparing your cheat sheets

Now that you know what to expect in a standard interview, it's time to prepare your cheat sheets. These little bits of paper are invaluable references during the phone interview, especially if you expect to be nervous at all.

How many times have you faced an awkward question, stumbled through an answer, and then afterwards had a brilliant flash of genius about what you could have said? Preparing cheat sheets gives you an opportunity to have that flash of genius before the phone interview. You can lay the questions out in front of you while you talk.

The idea of a cheat sheet is simply to help you think about and formulate answers to difficult questions. If you think about these difficult questions before the interview, you are less likely to be put on the spot during the interview. Cheat sheets also serve as reminders of things you specifically want to mention if and when the opportunity arises during the interview.

The key is to think of awkward questions you might be asked. For example, if you've been unemployed for a time you will probably be asked about it. Ditto if you were fired, or if anything is unusual about your work history.

Let's be real—if you don't think about how you'll respond to awkward questions before the interview then you will have to think of something to say on the fly, when giving a good answer will be much harder.

As well as posing and answering the hardest questions about your work history and your experience, you need to think about how to answer common interview questions as well. You'll find a long list of questions to assist with your preparations in Appendix A.

Relating your experience

Every question the interviewer asks gives you an opportunity to illustrate the relevance of your experience. When posing a problem, quite often interviewers will ask you for an example of when you faced a similar problem. Even if they don't, you can still answer in those terms when you do have relevant experience.

So, for example, suppose you were asked how you might go about resolving a bug that was difficult to reproduce in testing. You would talk about the time you visited a customer site to observe a customer reproducing a bug that no one could reproduce on the development servers. Or if asked what you think makes a good software development framework, you might talk about your experience with in-house and third-party frameworks that you've used.

The idea is that you take every reasonable opportunity to demonstrate how your experience can be brought to bear in the situations raised by the interviewer. Relating your experience helps the interviewer to more easily imagine you filling the role, which gives you an advantage over those who speak more generally or in more theoretical terms.

Answering hard questions

The hardest questions are unlikely to be the technical ones. Those will be hard, no doubt, but you should have an opportunity to work through them with the interviewer.

The hardest questions you will face during an interview are the ones where you are asked for your opinion when the question has no clear “correct” answer. One dangerous aspect of questions like this is that you might be tempted to respond in black-and-white terms when the reality—and usually more satisfactory answer—is less clear. Let me give you an example:

“Which is more important, software quality or customer satisfaction?”

Ouch! There seems to be no clear best answer to this question. Without customer satisfaction the business is unlikely to sustain development, but a low-quality product is unlikely to satisfy many customers.

Wait—did I just fall for the trap? (Yes, I did.) Software quality and customer satisfaction are certainly not mutually exclusive; there's no good reason you can't have both, so an answer that chooses one of them and argues how the other is “less important” is probably not the best possible answer. In slightly more formal terms, questions like this present a false dilemma, where there appear to be just two choices (or two extremes) when, in fact, more choices are available than presented or a balanced position exists between the two extremes.

Whatever you do, avoid a situation where you give a dubious answer and then feel obliged to defend that point of view at all costs. If you realize your answer is perhaps not the best, admit it and explain your thinking. Being confident and giving confident answers is good, but clinging to a sinking ship is foolish and counterproductive, especially if it means defending a losing argument.

Another trap for the unprepared interviewee is to answer with a long, rambling discussion of (for example) the various considerations of software quality and customer satisfaction. If you've ever answered a hard question in this fashion you've probably done it hoping that sooner (or later) you would stumble upon a good answer. Try to avoid a rambling answer. Nothing is wrong with taking time to think about the question—just be sure to let the interviewer know you are thinking, or else she might think you've been stunned into silence:

“That's an interesting question; let me think about it for a moment.”

Also, don't forget that you can ask the interviewer for clarification. When the interviewer poses a difficult question, and you can't immediately think how to answer it, you could ask for an example of how that situation might arise. This might give you a clue about the interviewer's motive for asking. Perhaps the company has had a recent spate of quality issues, and wants to hire someone with a sound view on what software quality means. Perhaps it has had some poor customer feedback, and wants to emphasize customer satisfaction. Either way, listen carefully for clues when the interviewer clarifies the question.

Being really stumped isn't necessarily the end of the world. Resist the temptation to start rambling and confess that you are at a loss for an answer. If the interviewer has asked this question a number of times at previous interviews, then you probably won't be the first person to come up blank. He might even expect candidates to be stumped, looking to see whether you are inclined to waffle or whether you are more honest and open in your response.

Asking good questions

The phone interview is unlikely to give you much of an opportunity to ask questions of the potential employer, but you should prepare some in any case. If you don't have an opportunity during the phone interview then save them for the in-person interview.

You should consider asking two broad categories of question. The first are questions where you are, in effect, demonstrating interest and enthusiasm to the potential employer. Questions in this category include:

• “Could you describe a typical week in this position?” (Shows you have an interest in the realities of the job)
• “If I were made an offer, what kind of objectives would I be given in the first few months?” (Shows you are already thinking how you might meet goals and objectives)
• “What things do you think are the most important for this company to focus on over the next few months or year?” (Shows you are interested in the bigger picture)

The second broad category includes questions that might affect your decision if you are made an offer such as:

• “What things do you (the interviewer) like about working here, and what don't you like as much?” (Might reveal some less-appealing aspects of working with this employer)
• “How many of this company's senior managers were promoted to their position from within the company?” (Can indicate prospects for advancement within the company).

Depending on your personal circumstances, asking about the company policy toward overtime might be important for you, such as whether it is expected or assumed, and whether you are expected to travel and stay away from home. Be sure to have a list of important questions prepared before the interview, but choose your moment—the phone interview is almost certainly not the best time to ask the interviewer challenging questions.

Try to avoid asking trivia questions just for the sake of appearing interested. A trivia question is any question that you could easily find the answer to with a web search or by reading the company website.

Always make a point of asking about the expected time frame for the interview to get back to candidates with interview results. You don't want to be left wondering when you will next hear something.

Having a phone interview checklist

Here is a short checklist of things you must prepare before a phone interview:

• A hands-free phone or a headset so you can use your hands while you talk. Not only does this make referring to your cheat sheets (or laptop) easier, but also being able to make gestures with your hands while talking can help you feel more comfortable, and therefore more relaxed.
• A quiet place where you can concentrate and talk undisturbed.
• If using a mobile device, good phone reception (check the reception before the interview!)
• Your printed CV and your cheat sheets, or a laptop (plugged in) with these documents loaded.
• A short list of questions to ask the employer, if given the chance.
• Confidence that comes from knowing how to write code.

Using a phone interview cheat sheet template

Use the following table to consider how you would answer each question if you are asked. Don't write a “script” for answers; otherwise, you will tend to read them out when on the phone and sound unnatural. Instead, after considering how you want to reply, make short notes to jog your memory when on the phone.

Some of these questions won't necessarily apply to you or your situation so just ignore those.

If I'm honest, some of these questions make me cringe. I include them only because many interviewers still like to ask them, and answering them can be difficult if you aren't prepared.

Table 2.1 Phone Interview Preparation