How to Conduct an Interview
Interviews have four stages that precede the writing of a story:
- Arrangements.
- Preparation.
- The actual interview.
- The reconstruction.
ARRANGEMENTS
Once an interviewer has decided to interview someone, He
should call the candidate in advance to make an appointment. Identify
himself by his name and the name of his publication. If the interviewer
feels that he need to do so or asked to describe what the story is
about, be brief and general. The shape of the story might change as him
continue his reporting. If the interviewer interviewing several persons
in connection with the story, interview the principal person last,
because he will be better prepared based on what the learning from the
earlier interviews.
PREPARATION
Try to prepare as much research as possible on the person in
advance on topic working on. Sources might be the library, public
records, the internet and the expert people in that technology for
background information. Prepare the questions in advance if necessary
writing and bring them into the interview. Refer to them but don't show
them to the candidate, because it creates too formal an atmosphere.
Ask other questions as they might arise, based on what the candidate
says or something new that might come at the moment. Bring pencil (or
pen) and paper. A stenographer's notebook is usually easier to handle
than a large pad but use whatever is comfortable. Bring a tape recorder
but be sure to get the permission to use it from the person you are
interviewing.
THE INTERVIEW
It is inadvisable to launch right into the interview unless
it’s being given a few minutes. Some casual conversation to start with
will relax both of you. Interviewers should ask Questions should be as
short as possible. Give the respondent time to answer. Interviewers
must be a good listener. If candidate prattles on, it is appropriate to
move on as politely. Interviewer might say something such as: "Fine,
but let me ask you this ". Try to draw out specifics: How long, how
many, when, etc.?
Try to absorb the atmospherics of the locale where the
interview takes place, with particular attention to what might be a
reflection of the candidate’s personality and interests, such as photos
of children or bowling trophies or a paper-littered desk or a clean one,
etc. Note characteristics of the candidate that might be worth
mentioning in your story, such as pacing, looking out the window to
think, hand gestures and the like. Invite the person to call you if
she/he thinks of anything pertinent after the interview. It often
happens, Interviewer should provide his name, email addresses and phone
number on a card or piece of paper before to leave. If that person has a
secretary, be sure to get that person's name and telephone number, too,
in case there is some detail that needs follow up and, again, leave
information as to how you may be contacted. If a photo is needed and is
not taken during the interview, be sure to make arrangements then to
have one taken at a later time.
RECONSTRUCTION
As soon as it's practical after the interview, find a quiet
place to review the handwritten notes. While taking notes, that may
have written abbreviations for words that won't mean anything in a day
or two later. Or some scribbling may need deciphering, and, again, it
is more likely to be better able to understand the scribbles soon after
the interview. Underline or put stars alongside quotes that seemed most
compelling. One star for a good quote, two stars for a very good one,
etc. It will speed the process when you get to the writing stage. One
other thing to look for in the notes: the quote wrote down might not
make a lot of sense, unless to remember what specific question it was
responding to. In short, fill in whatever gaps exist in the notes that
will help better understand them when writing.
How to Interview a Programmer
Finding good programmers is hard because good programming is
dependent on much more than just knowledge of programming language
syntax.
1. The Interviewer needs someone who, despite wearing striped
pants with a polka dot shirt, has a good sense of taste in OO design.
2. He need someone who the candidate is creative enough to find
innovative solutions to problems, yet anal retentive enough to always
line up their curly braces.
3. The Interviewer needs someone who (the Programmer) is humble
enough to be open to suggestions for improvement, but arrogant enough to
stand firm and provide leadership when they are the best person to
provide it.
How to tell all this about a stranger by spending 30 minutes with them in a conference room?
Summery:
Explore an Area of Expertise
Have Them Critique Something
Ask Them to Solve a Problem
Look at Their Code
Ask About a People Problem
Get to Know Them
Conclusion
Explore an Area of Expertise
Rather than simply look for expertise and experience in the exact area
in which the candidate will work, it is necessary look for general
programming talent and ability. One way to explore and judge a
candidate's talents is to explore an area of their expertise:
- Hire for talent. One of the biggest mistakes companies make is to
recruit from a shopping list: I need a programmer with six years Java,
three years Oracle, and two years EJBs. The world changes, so to hire
folks who change with it. Look for people who know computing, not
necessarily particular narrow niches. Not only will they adapt better in
the future, they're also more likely to be innovative in the present.
- To identify how good the candidates are technically, I let them
choose an area in which they feel they have expertise. I need them to
know something well, and I ask them about that. I ask them why. I want
them to know why something in their area of expertise works the way it
does. I'm not necessarily after an expert in the area I need. If they
learned why in the past, I have confidence they'll learn why in the
future.
Have Them Critique Something
Another technique involves the importance of creating a dialog with the
candidate. To get to know the candidate's talents and personality, Do
n’t merely ask questions that have short factual answers. Find a way to
engage a conversation. To stimulate dialog, ask the candidate to
critique some technology:
- I ask candidates to critique a system or platform that we both have
in common, preferably something they will use on the job. For example, I
might ask, "What parts of Java don't you like and why?"
- I give candidates samples of our current code and ask them to
explain and critique it. This gives me a sense of their skills, but also
lets them know what they can expect.
Ask Them to Solve a Problem
Another way to foster an open-ended dialog is to ask the candidate to
perform a task: to solve a problem or create a design. Although everyone
at the meeting seemed to agree that this was important and useful
technique, it also generated a lot of concern. People felt that asking
the candidate to solve puzzles and problems needed to be done with care:
Several expertise interview taken and their review is given below
- I like to ask a candidate to solve a small-scale design problem,
finger exercises, to see how they think and what their process is: "How
would you write a function that tells me if its argument is a power of
2?" I'm not looking for the optimal bit-twiddling solution ((n & -n)
== n). I'm looking to see if they get the method signature right, if
they think about boundary cases, if their algorithm is reasonable and
they can explain its workings, and if they can improve on their first
attempt.
- I ask candidates to create an object model of a chicken. This
eliminates any problems with uncertainties about the problem domain,
because everyone knows what a chicken is. I think it also jars people
away from the technical details of a computer. It tests to see if they
are capable of thinking about the big picture.
- I hate anything that asks me to design on the spot. That's asking to
demonstrate a skill rarely required on the job in a high-stress
environment, where it is difficult for a candidate to accurately prove
their abilities. I think it's fundamentally an unfair thing to request
of a candidate.
- I don't like when I'm asked to write a program that does X on a
piece of paper. Don't ask the candidate to write a program on paper.
That is a waste of time and sweat. People don't write software on paper,
they do it with computers using auto-completion, macros, indexed API
documentation, and context-sensitive help. They think about it,
refractor it, and even rewrite it. If you want to see a person's work,
ask them to write some small module or implement some interface before
the interview and bring the code on a notebook PC or on hard copy. Then
you can review it and discuss the design, coding style, and decisions
that went into it. This will give you a much more realistic and useful
assessment of a person's work and style.
- I like design dialog questions that don't have a single fixed
answer. That way they have to ask me questions, and this sparks a
discussion. It's good to have a whiteboard available in the room. A
dialog lets the interviewer see how the interviewee works, whereas a
question of fact is just that: it is great for TV quiz shows, but
doesn't tell you how someone will work and approach things over time. A
puzzle question requires knowing a trick, which is in essence something
that is either known or unknown. I dislike puzzle questions, because
they don't require dialog.
- What constitutes a reasonable question depends a lot on the candidate's experience and maturity.
- I look for people with curiosity. Present problems, not puzzles.
Look at Their Code
One technique we all seemed to like: Have the candidate bring a
code portfolio to the interview. Look at the candidate's code and talk
to them about it. Although we were concerned that some candidates may
not have code they could legally bring to the interview, we figured most
candidates could probably come up with something. It can't hurt at
least to ask a candidate to bring to the interview a sample of code they
had written in the past.
Find Out What Books They Read Several people indicated that
they ask candidates about the programming books they read to see if a
programmer is self-motivated or concerned about improving their own
programming skills:
Ask About a People Problem
As important as technical ability, or perhaps more
important, is personality. How well would the candidate fit the team?
How well would they fit the work environment? People used various
techniques to judge personality. Good citizenship is probably more
important than technical prowess, because if you have people with the
right kind of attitude and demeanor, you can help them gain the
technical knowledge and software development habits. But if you have
people who lack humility and maturity, it can be extremely difficult to
get them to cooperate in reaching a goal, no matter how bright they are
or what they've accomplished in the past.
Get to Know Them
Perhaps the prominent theme of our discussion was that you
need to try to get to know the candidate as best you can. Talk to the
candidate in the interview. Try to get a feel for them. If possible,
bring them in on a trial basis or for a probationary period. That would
give you more time to get to know the candidate, and give the candidate
more time to get to know you:
Chuck Allison: I talk to them. I get a feel for them. I always
ask about what they've done. I have found that by discovering what a
person is excited about technically, you can learn a lot of important
things about them. In the past I've asked people to describe a project
that was especially interesting to them, or that was challenging and
successful. On occasion I've asked what they've done that they're the
most proud of. This usually reveals the depth of one's understanding and
mastery. It also gets them to turn on the fire hose verbally, and you
can sit back and get most of the answers you need.
Randy Stafford: I look at past projects listed on their resume,
and ask them to talk about those projects—how was the team organized,
what the technologies and architectures were used, was the software
successful in production, etc. In their answers I'm listening for what
lessons they learned from those experiences, and whether those lessons
match with lessons I've learned from my experiences and from
professional literature. I get a glimpse into how they perceive
themselves in relation to the world around them. Some come off as
arrogant, some ignorant, some helpless. Others sound humble,
intelligent, and motivated. I often ask them what software development
literature they read. Continuous education is very important to me.
Angelika Langer: In Germany, hiring is like marrying someone.
It's "until death do us part"—a marriage without the backdoor of a
divorce, because you can't fire employees. The only chance for firing
someone is during a three- to six-month probationary period, or when the
company goes out of business. The major filtering is done before the
interview, based on the curriculum vitae (CV) and submitted papers, such
as evaluations from former employers. (In Germany, employers must
provide every employee with a written evaluation when they leave the
company.) The interview itself is usually brief. The main tool in
filtering is scrutinizing the CV and papers; 98 percent of all
applicants are disqualified in this phase. The interview should confirm
the impression you gain from the applicant's papers and allows you to
sense their personality. The lucky winner then goes on a probationary
period. Probation definitely does not replace the filtering; it just
keeps a last exit open until you really must commit.
Andy Hunt: We've hired people who interviewed well, but they were terrible at the job. If possible, hire them in for a trial period.
Dawn McGee: You could also bring candidates in for half a day, and have them do what they would be doing on the job.
Conclusion
To sum up the overlying themes from our hour-long
discussion in Portland: You should look for talent and fit more than
specific skill sets. Ask open-ended questions to initiate revealing
dialog. Ask candidates to critique something. Ask them to design
something. Investigate their past experience. Review their code. And
through conversation and, if possible, a trial period, you should try to
become familiar with the candidate's technical abilities, talents, and
personality.