Chapter 3

In-Person Interviews

Human beings and interviews, as a rule, are wonderfully unpredictable. You never really know what you're going to get. This might lead you to think that preparing for an interview is pointless, but that is about as wrong as it is possible to be. Preparation is your secret weapon. The interview might go any which way, but that won't matter if you are prepared.

“It usually takes me two or three days to prepare an impromptu speech.”

—Mark Twain

Preparing for the Interview

The well-prepared programmer brings a lot more than just technical readiness to an interview. No doubt there will be questions on data structures and algorithms, perhaps a few brain-teasers, and probably a coding exercise. But technical questions are just part of the interview. There will usually also be questions about teamwork, getting things done, and questions designed to see if you are a good match for the culture of the company. The interviewer might want to see how you handle stress, how well you communicate, and how you react to criticism.

If the interview was just about how well you code, you could do it online. Face-to-face interviews are much more than just a technical assessment. Although some companies like to give the impression that the “best programmer” will get the job, I can tell you first hand that being technically best will not always win you the job. This might seem unfair, but that, as they say, is life.

Knowing what to expect

Every workplace is different. Companies might have similar décor and facilities, but no two companies are exactly alike when it comes to philosophy and culture. What determines the culture of a company? It's the people, and more specifically it is the people at the top that set the tone for everyone else. If the people at the top are relaxed and friendly, that attitude will tend to dominate. If the people at the top are formal and serious, that is what you will tend to find in the offices and in the break rooms. Smaller companies tend to be less formal than bigger companies, but the size of a company alone won't tell you much.

You probably already have a good grasp of the cultures at Microsoft, Google, and Amazon (and if not, there are plenty of public web sites that talk about nothing but the culture of these companies) but other, lesser-known companies will require you to do a bit of research.

By far the best way to research the culture of a company is to talk to someone who works there. If you are lucky enough to know someone on the inside, then I suggest you buy them lunch and hit them with 100 questions. The rest of us will need to find other ways.

A web search should be the first thing you do. (Incidentally, the hiring manager will probably search for information about you, too.) You will find the carefully constructed marketing image of the company, but without too much digging you should be able to find some clues about the company culture. If you are lucky, you might find a statement of company values, or, even better, a company blog. If you can find the names of the people at the top you can search for news items where things they've said may have been quoted. These quotes can be revealing.

If you happen to be working with a recruiting agent, ask them about the culture of the company. A good agent will have first-hand experience of working with the company, albeit as a supplier, and should be able to give you some useful insight.

If all else fails, call the company and ask directly. This need not be awkward; it is a perfectly reasonable question.

“Hello, I'm calling because I have an interview with your company next week and I was wondering if you could tell me a bit about what it is like to work there?”

The worst that can happen is that you talk to someone unwilling to help, but no one is going to hold this approach against you. If the person you call is unhelpful, ask to be put through to the HR department, or even better, to the department that is looking to hire you. It almost goes without saying that you should be polite and respectful of the time people give to you, but, in general, people love sharing opinions, especially about their employer, and who better to share those opinions with than a potential workmate? You might find that some companies have a communications policy that forbids employees talking about their employer, but that in itself is useful information.

After researching the culture of the company you should turn your attention to the hiring manager. Again, talk to people who know, do a web search, and ask the recruiting agency. I would be a little wary of calling to ask about the hiring manager directly, but if you call to ask about working at the company then you could also ask about how interviews for this role are typically organized.

At the very least you should be sure to find out about the structure of the interview:

• How long will the interview last?
• Are there multiple in-person interviews or just one?
• Will there be a technical test? If so, how will it be administered?
• Will you write code during the interview?
• How many interviewers will be present, and who are they?
• Is there anything specific the company advises you to prepare for?

Doing your homework

Once you have done your research, it is time to start practicing, with particular focus on the things you've learned about the company and the hiring manager.

If the interview is with a high-tech company (like Google, or perhaps some start-up companies) then you will benefit from focusing on data structures, algorithms, and how software can be designed to scale up. Very small tech companies are likely to expect their programmers to be knowledgeable in a wide variety of areas so you should brush up on server administration, network troubleshooting, database configuration, and so on. You are unlikely to need this kind of knowledge at larger companies because they have dedicated teams (if not entire departments) to look after servers and infrastructure.

Something you really need to do at this point, if you haven't already, is to ask yourself the questions that you dread being asked.

Be honest—what question would make you drop dead at the interview? Perhaps you have a morbid fear of sorting algorithms. Perhaps you don't quite understand the difference between BFS and DFS. Maybe you quit your last job after a big blow-out with your team lead. Maybe you have a controversial opinion; maybe you think code comments are a pernicious form of code duplication?

If you don't face your fear before the interview, you will have to face it during the interview. It's a no-brainer, as they say. Face it before the interview.

Dressing appropriately

Once you have come face-to-face with and conquered your worst interview fears, you will need to choose a nice outfit to wear.

Ok, I will be honest here. I'm a little dismissive of all the advice so freely given about how to dress for the interview. What I will concede is that how you dress does have some impact on how you are perceived. Exactly how much difference your shirt or blouse will make is a point of debate, but I accept that it can make some difference. Unless you've been living the life of a hermit, wearing sack cloth and ashes, you will have a variety of clothes in your wardrobe to choose from. Here's how to choose what to wear.

First, try to find out about the prevailing dress code at the company. If you live close, you could visit during the lunch hour and observe what people are wearing as they come and go. If not, you will need to ask someone. As before, your options are to ask someone who works there, ask the recruiting agent, or ask directly by calling up.

“Hello, I have an interview next week and just wanted to check the dress code in your office.”

If you really have no idea what to wear then you should default to smart office attire, which for men means a nice dress shirt with a collar, and no jeans or sports gear. Motorbike leathers are not ideal, and gang insignia is right out. Don't ever be tempted to dress in a provocative fashion. The same rules apply if you are female; a nice blouse and skirt (not a mini) or trousers. Dressing like a gigolo might score you short-term points with a certain class of interviewer, but think ahead to how you will be perceived once you land the job. Do you really want to be known for the length of your skirt or the tight fit of your shirt?

Men, wear a tie if you are comfortable wearing one, but be aware that some companies, particularly companies with a strong geek culture (which should be obvious) will not have much time for someone who turns up in a suit. If you really aren't sure then take a tie to the interview in your bag and put it on if it seems appropriate. (Put it on before going in to the interview; don't start dressing yourself after the interview starts.)

Finally, whatever you wear, make sure you are comfortable. You will face enough challenges at the interview without struggling with your outfit. If you are hot and sweaty because of your jacket, politely excuse yourself while you take it off. Don't sit and suffer; you really don't need the distraction.

Handling different types of interview questions

Broadly speaking, interview questions fall into the following categories. How you answer a question depends on the category.

Fielding social and behavioral questions

Social and behavioral questions are often asked so that, in theory, the interviewer can assess your style or approach in different situations.

“How would you settle a team debate about whether source code should be formatted with spaces or tabs?”

Your answers should be direct and backed up with examples. This kind of question tends to encourage rambling answers, and rambling answers should always be avoided at the programming interview.

“I usually take the approach that it doesn't matter provided the source code is formatted consistently. When I worked at Acme we used the SpaceMeister utility to ensure consistency, so that would probably be the approach I'd take with the team.”

Handling design problems

To answer design problems need you to go into analysis mode. The interviewer doesn't necessarily want you to come up with a single “correct” answer, which in any case may not exist, but rather wants you to demonstrate how you think about and work toward a feasible design. You will recognize a design problem in one of two ways; either the interviewer will pointedly use the word “design,” or the problem will initially appear to be impossible, difficult, or vague.

“Design an algorithm to calculate how an international aid fund should be divided up between beneficiaries.”

The only way to answer questions like this is to ask questions of your own. You need to demonstrate an analytical yet goal-focused approach. If you ask the right questions the answer will eventually become obvious (or it might become obvious that there is no good answer) and you can proceed with the design (or identify the reasons why no good design is possible).

“Do we want to optimize for a fair distribution?”

“How is a ‘fair' distribution to be defined?”

“Do we need to account for factors other than what is ‘fair'?”

“What are the inputs to this algorithm?”

“What are the expected outputs?”

“Is there any useful precedent we can build on?”

Tackling technical pop-quiz questions

Some interviewers still like to ask technical pop-quiz questions. You can easily recognize these because they will be obscure or excessively specific.

“How many overloads are there for the Tuple.Create method in .NET version 4.5?”

There is little you can do to prepare for this kind of questioning. Unless you have a good memory for programming then you will just have to answer as best you can:

“Oh, I'm not sure; I would guess 8 or 9 based on the idea that the Tuple data structure is for holding a set of values. I would need to look that up to be sure. Also, in general, I've found that if a method has many overloads then it can be difficult to choose the right one, especially if each method has different behavior, so I would think there shouldn't be too many.“

You might try to relate the question to things you do know well, but if the interviewer is fixed on their favorite trivia questions then you can only take comfort that they will probably end up hiring the programmer they deserve. Unfortunately, your wise words might be wasted on a pop-quiz interviewer who will hear nothing but your “8 or 9” answer.

Fielding the general intelligence test

Another type of question that is rightly falling out of favor is the general intelligence test. These questions are dubious even in an appropriate context (mental health assessment) and are even more dubious in a programming interview. Nonetheless, some interviewers want “only the smartest” and see no problem undertaking an IQ test where even a trained psychologist would hesitate. If you have ever taken an IQ test (and again, many programmers have) then you will recognize these questions immediately.

“Find the next value in the sequence …”

“Pear is to apple as potato is to …?”

“If two typists can type two pages in two minutes, how many fingers am I holding up behind my back?”

(I made up that last question; I hope you are never asked that at a programming interview.)

IQ questions tend to be similar in style and, with practice, it is possible to get better at answering them. If you have an idea that your interviewer might favor this style of questioning then you should seek out and practice IQ tests in preparation for the interview. IQ tests are widely available, and they can be fun in a nerdy kind of way. If you search for IQ tests on the web, make sure you try a test from at least two different sites so that you aren't inadvertently misled by one site that might have a unique (non-standard) approach to IQ testing.

Dealing with the stress test question

One kind of question that you can and should practice is the stress test. For this you will need to enlist the help of a friend, preferably an aggressive and loud programmer. Ask your shouty friend to find (or write) a list of really hard questions. Set aside an hour or more, and grind through these questions, acting out the roles of candidate and hard-nosed interviewer. The role your friend needs to play is “merciless interrogator with an inexplicable grudge.” The idea with this kind of practice is not so much to come up with the right answers (although you should try) but rather to build up stamina for the real interview. One hour can be a grueling marathon, but some interviews run for much longer. Train like an athlete for these interviews.

The Most Important Thing

Kirk, McCoy, and Spock are around a camp fire, Kirk andMcCoy are singing “Row Row Row your Boat.”

Kirk: Come on. Spock… Why didn't you jump in?

Spock: I was trying to comprehend the meaning of the words.

McCoy: It's a song, you green-blooded… Vulcan. You sing it. The words aren't important. What's important is that you have a good time singing it.

Spock: Oh, I am sorry Doctor. Were we having a good time?

—From Star Trek V: The Final Frontier (1989)

I briefly touched on the importance of rapport in Chapter 1, and now I'm going to look at in more detail.

Despite the importance of rapport, I will confess some mixed feelings on the subject. No one likes a fake smile, and no one likes insincerity. There is an uncomfortable association between rapport and cheesy sales tactics.

As a teenager I had an extremely strong aversion to insincerity in any form. I felt particularly aggrieved by advertising campaigns that I perceived were trying to induce an emotional reaction in me for the purpose of selling me something. I walked around with a deliberately neutral expression so that no one could accuse me of insincerity. In conversation, I was blunt and candid to the point of rudeness. Frankly, I was a right sourpuss.

Then, in my twenties, I had a revelation.

Of course, this revelation involved a young woman. This young woman taught me that people who smile and who are generally agreeable can be just as sincere, perhaps even more so, than a person made prickly by a stoic aspiration to be sincere. What people want, for the most part, is to get through their day without antagonism and conflict. Politeness is simply a lubricant for the wheels of human interaction. Strangers waiting for a train might smile and nod in mutual acknowledgement, and neither one will have an agenda beyond passing time comfortably while they wait for the train. You can usually spot the exceptions; people with an agenda often have a conspicuous name tag and a clipboard.

These days, a reliable source informs me, I am still a sourpuss. I flatter myself that I am a sourpuss with an insight that helps me get along with people. Is this insincere? I hope not, and I don't believe it is.

If you are interested in this topic and think you can stomach the full-strength dose of how to get along with people, then I (sincerely) recommend the classic book by Dale Carnegie; How to Win Friends and Influence People (1936). It isn't necessarily a book for everyone, and in some places it shows its age, but I still recommend it for its brilliant insight into the mechanics of human interaction. Spock could have used it.

Establishing rapport

What is an interview candidate to do if they want to establish a rapport? Let's start from the basics; rapport is much more likely to exist when two people share a common goal. On the face of it, the interviewer wants to find the best person for the job, and the candidate wants to convince the interviewer that they are that person. That isn't an ideal starting point, because it puts the candidate firmly into the role of selling something to the interviewer (themselves). It would be much better if the interviewer and the candidate had something in common.

As it turns out, they do. They both want to find out if this job is going to be suitable for the candidate. Both want to see how well the candidate matches up to the job specification. Both want to get a realistic view of what it would be like if the candidate took the job.

Don't misunderstand me—I am not suggesting that the balance of power (something I will discuss later) is equal in an interview. What I do firmly believe is that the interviewer and the candidate have a very strong starting point for establishing a good rapport. In a very real sense they both want the same thing. It is a subtle but important shift in perspective. Instead of claiming to be a perfect match, the candidate will be working with the interviewer to see if that is true, or to what extent it is true. This is the fundamental starting point of an effective interview.

With an attitude that you are working with the interviewer, you will see things a little differently. Instead of waiting passively for challenging questions you will be genuinely interested in details about that job so that you can see for yourself how you experience matches up. Instead of worrying about theoretical questions about how you would handle this situation or that kind of problem, you will be trying to relate how your experience has prepared you for the concrete circumstances of the job. You will be taking notes of things you might need to brush up on, and you are more likely to acknowledge those things you may need to learn on the job.

This attitude, more than anything else, will put your interviewer at ease. You are in effect making their job easier, relieving them of their burden of playing the role of interrogator. Some interviewers don't seem to mind playing that role, but for most interviewers this is the quickest way to establish an effective rapport.

It takes work

It would be nice if a change in attitude was enough to make everything go swimmingly at the interview, but there is still a lot more you can do. You might be a gifted conversationalist, but everyone will benefit from reviewing the following basic guidelines.

Be a good listener

Don't ever interrupt rudely, and if you feel compelled to jump in then at least apologize for doing so:

“Sorry to interrupt you, I just need to mention that you appear to have the wrong CV.”

Listening effectively is more than just sitting quietly. A skilled listener will replay what they hear using their own words. This reassures the interviewer that you are actually listening and that you understand. This is such an important technique that is has a special name: active listening.

Ask good questions

Also remember that an interview is supposed to be a mutual exchange of information. You need to ask questions as well as answer them. Similar to the technique of active listening, asking good questions will reassure the interviewer that you have heard them, and also that you are interested in finding out more.

Mirror your interviewer

Sometimes it can be effective if you consciously imitate some of the postures and behavior of the interviewer. So if they sit up, you sit up. If they relax and sit back, so do you. I'm not suggesting you perform an impromptu silent comedy of mime, as amusing as that might be, but rather that reflecting the attitude of your interviewer does wonders for establishing rapport. This is a proven technique that can help put the interviewer at ease. The name for this technique is mirroring. You can look it up when you look up active listening.

Look for ways to interact

If you are naturally introverted, it isn't a problem; so are many software developers. Your interviewer might even be an introvert by nature. Remember that introversion doesn't necessarily mean that you are compelled to be shy. Look for common ground. Look for opportunities to talk about things that are relevant and that interest you. If you are naturally shy, do try to make eye contact at least once or twice, and remember that the clear words in your head need to be equally clear when you speak them. Slow down your rate of speech, and pause for confirmation now and then. In many ways, introverts have an advantage in one-on-one conversation, since they tend to be much better at reflecting on what they hear.

The Second Most Important Thing

Even the very best rapport will be wasted if the interviewer is not left with a strong impression of your competency as a programmer. The second most important thing to remember is that you need to show your stuff in the time available to you.

Speaking up

Interviewers are supposed to let you do most of the talking. Unfortunately, my observation from sitting on both sides of the interview desk is that many interviewers like to talk at least as much as they like to listen. If you encounter an excessive talker then you have little option but to politely interrupt when you have something to say. You will be listening for opportunities to relate your experience to the job. If the interviewer is really hammering away then you will be wise to choose your moments rather than constantly interrupt. If you have the misfortune to be interviewed by a pathological chatterbox then you may need to wait until they pause for breath. Use the time to prepare, try to keep your concentration up, and jump into the conversation when the interviewer pauses to inhale.

Being aware of how much time you have

You will usually know in advance how long the interview is scheduled to run. If the interview is short then you will need to focus on the most important aspects of your experience as it relates to the job. You might be very proud of the open-source data-grid control you wrote, but if time is limited you will need to ensure that you clearly and specifically target the key criteria of the job specification. If they aren't clear to you before the job interview (they should be) then you will need to ask the interviewer:

“What would you say are the most important skills needed for this job?”

Stories are good, evidence is better

If possible, you should try to relate the answer to this question to your concrete experience and to your achievements. Tell a story to illustrate your experience if you can, but avoid veering off track into the realm of making stuff up. It might be entertaining to make up a hypothetical situation to illustrate a point, but the problem is that the interviewer will remember you for the stuff you didn't actually do. You want them to look at your CV afterward and think “oh yes, that is the programmer who sorted out that big performance problem” rather than “oh yes, this is the programmer who, uh…what did he actually do again?”

Communicating Effectively

When it comes to getting your point across at the interview, there are some simple but powerful techniques you should know about. These tricks, though I hesitate to call them that, can transform the effectiveness of your communication.

Using your passion to combat nerves

Almost everyone experiences nerves. It is a basic physiological response we all experience in challenging situations. It used to be caused by Velociraptors but now it is the fear of speaking or being in the spotlight that gives us an adrenaline rush and sets us trembling.

What you need to do is distract yourself. If you have children you will have noticed how the worst catastrophe in the world can often be fixed by the possibility of an ice cream. Use the same trick on yourself. If you find yourself fixated on something that is causing your anxiety then change the channel in your mind. Think of something fascinating or intriguing to push away the trembles. You are a good programmer, what is it you like about programming? What are your pet annoyances with code written by others? Should code be formatted with tabs or spaces? Which is the better editor, Vim or Emacs? Channel your nerd rage, and, while you do, notice how your nerves fade away.

Using your hands

When politicians go to politician finishing school, one thing drummed into them is the power of using their hands while they talk. Watch any political speech and you will see a dramatic performance involving hands. This is less true in England than the rest of the world, but at the highest levels of politics anywhere in the world you will always see pointing and chopping gestures, open palms and pinching motions.

The reason for all this hand waving is simple. Reliable studies have shown that body language counts for at least as much as the words coming out of our mouths. It stands to reason and intuition as well; enthusing about anything is difficult when you are slumped lifeless in your chair like a koala bear. Sit on the edge of your chair and use your hands to emphasize important points. If you aren't used to this it will take some practice, and you might feel a bit theatric at first, but take your lead from the best speakers and get those hands up.

Speaking slower than usual

When you speak rapidly, it makes you sound nervous. When you slow it down, you sound calm and in control. If you are prone to blurting out then you will really need to practice slowing it down. Record yourself speaking to see what I mean. Ask your close friends for their opinion. Listen to professional speakers, especially leading politicians, and you will notice how they almost never blurt out anything. They breathe, they pause, they hold up their hands up as if carrying a large vase, and they speak slowly and clearly.

Starting and finishing clearly

Nothing ruins the delivery of a good sound bite more than rushing the beginning or the end:

“I once saved a whale by coding up a …mumble.”

If you say something and then realize you rushed it, then repeat yourself. You need to make sure you are heard and understood. If you don't take care with your enunciation then a lot of your important points will be lost on an impatient interviewer.

Repeating your main point

When public figures wants to make sure that their key messages are heard, they repeat themselves. Not like a parrot does, of course, key messages are emphasized by focusing on the same point from different perspectives. They might relate different anecdotes to underline a recurring theme. The message is repeated in different ways and at different times. If you have something that you really want to ensure an interviewer remembers then you should do the same. Look for opportunities to repeat your key message as it relates to things the interviewer says.

Spontaneity improves with practice

At the interview more than at any other time, you need to be able to draw on your experience to deliver spontaneous answers to important questions. The best advice I can give you for improving your ability to spontaneously give good answers is to know your source material inside out, and back to front. This means you have to know and recall the details of what you've written in your CV. It means you really do have to know your technologies as well as you claim. It means you have prepared a list of relevant stories to tell, a list of problems you have solved, and a list of challenges you have overcome. When the opportunity arises, as it always does, you draw on that material to talk “spontaneously.” If you aren't used to speaking spontaneously, you need to practice it before the interview. Use your friends to practice with. Take it seriously and get them to ask you random questions about your CV or the technologies in your CV so that you can rehearse relating your experience to those questions. If, during practice, you draw a blank, great! You've just found a hole in your preparation that you can plug before the interview. Offer a prize to the friend who stumps you the most.

Practice, practice, practice.