What to Expect
Jason Truesdell
What are interviewers looking for?
Sometimes, they aren't even sure. Many interviewers, like me, are
relatively inexperienced making hiring decisions. Many haven't quite
figured out how to ask questions that elicit responses useful for making
hiring decisions, so they are almost as uncomfortable as you.
If you know what interviewers need, you end up being in control of the
interview rather than being in a defensive position.
A high-tech employer usually wants a problem-solver; an intuitive but
logical thinker; somebody who is capable of making the connections between
big-picture thinking and mundane details. But they are also looking for
people with a relevant set of technical skills.
I usually ask a combination of specific technical questions based on
the skills my team needs and what the resume describes, and some more
abstract questions designed to assess a candidate's reasoning skills and
to learn how that person approaches unfamiliar problems. We also ask
questions that are ultimately used to determine very abstract things, like
what we call "fit", or appropriateness for our position.
The work history
An interviewer will ask questions about your work history to get a feel
for your background, but they will also make judgments about you based on
your responses.
Among the things we judge when listening to your responses are your
enthusiasm about work, your ability to adapt to new situations, the way
you react to project ownership and leadership roles, and your skills and
experiences.
Additionally, we try to figure out how well you understood your role
and what the impact of your work was. We want to know if you just went
through the motions of your job or whether you actively worked to increase
your value to the company. We want to know how you deal with adverse
situations. We want to find someone who thinks of constructive ways of
dealing with tough problems.
We'll often ask you why you made a particular decision and what you
would have done if a particular variable had been different. We want to
know how you evaluate alternatives, how you defend your decisions.
The indirect
We frequently ask bizarre-sounding questions that don't sound like they
have direct relevance to the job, but test your flexibility, creativity,
and the way your thought processes work.
Why are utility hole covers round? Here you have to think about the
advantages to roundness. You can move in and out no matter which direction
you turn. The covers can't fall in that way.
How would you test a beverage dispenser? You may have been brought in
for a software testing position, but maybe you have too much software
testing experience (or maybe too little) and we want to see how you'd do
this in a different context (or a context that you better understand). We
want to see how you assess the problem, break down the components, and
develop a test plan or procedure.
The hypothetical
"Let's say you don't have time for that." "Let's say
that this doesn't work... now what can you do?"
You'll frequently encounter broadly-scoped hypothetical problem-solving
questions, but what do you do when the interviewer starts making up rules
as you start to answer the question?
You're not necessarily getting negative feedback; you're being directed
to try different ways of looking at the problem. Sometimes you're being
asked to prioritize; one time I was in an interview for a product support
position at a company which provided services for a number of major
software vendors. I was told "let's say you have made a whole bunch
of FAQ-level suggestions to fix the installation problem, and none of them
worked. Now what do you do?" I suggested offering to call the
customer back after doing some additional investigation. "What if
that doesn't work?" "Well, I could ask a more experienced
technician," but was told that they couldn't figure out the problem
either. I suggested calling up the software supplier directly and asking
them to assist. I suggested sending a technician to look at the computer
directly, but was told that they couldn't figure it out either. Eventually
I was told, "now you've spent 10 hours working on the problem, you've
involved other technicians, you've called the software vendor, and you
still haven't figured it out. What else can you do?" The only
reasonable answer I could think of was "well, we could offer to
refund the customer's money and write off this one." It turned out to
be an acceptable answer (or at least I think it was; I was offered the
job.) It required being willing to accept that the software was at fault
and that there wasn't a technical solution that product support could
provide.
Shifting focus
Sometimes an interviewer changes the focus of a question midstream.
When you hear a phrase like "what else?" after giving an
answer, the interviewer is trying to steer you to think outside of the
obvious boundaries of the question.
Let's say you're asked how you would develop a system that supports
searching for a telephone number based on a person's name. You immediately
start talking about implementation details--"I could use a hashtable...
or an AVL tree... if the list was really large I would use a trie or a
B-tree with secondary storage." Suddenly the interviewer asks,
"what else could you do?" You've just given four technical
solutions to the problem. They probably aren't asking you to come up with
another data structure or algorithm you could use.
You should step back and think about another way of addressing the
problem. You could come back with, "well, I could talk to other
developers or look for a code repository to see if someone's already done
something like it... Then I could reuse that code." You may be asked
again, "what else?"
This probably means the interviewer is no longer thinking about the
original phrase, "how would you develop a system that...." Now
you have an opportunity to break out of the question itself. "I would
ask program management who the intended customer is and how they
anticipate the feature being used... Maybe looking up a phone number by
name isn't enough and we need a way to look up the information in reverse.
Maybe the feature isn't really necessary because the OS provides some
built-in functionality; we could leverage the system's address book or
directory services."
You're playing a bit of a guessing game, but if you take advantage of
the feedback you're getting, trying different approaches to answering a
question that may not have a "correct" answer will show the
interviewer that you don't lock yourself into one way of thinking about a
task. We often want to know whether you're capable of different planes of
thinking to see what kind of potential you have to contribute to the
organization as a whole. We're assessing your ability to think deeply
about a problem, not just about the surface-level issues.
The technical question
We usually ask you to apply the technologies you have learned in school
or in other settings to some basic types of problems encountered by users
of that technology. We do this for the obvious reasons, which is to verify
that you actually know the technologies we need you to know. We also try
to verify your honesty. But again, we
want to see how you solve problems when faced with a set of known
parameters and multiple acceptable paths. I've discussed this kind of
question elsewhere on this site as well.
You may or may not be given access to a computer to demonstrate this
on; sometimes you're only granted a whiteboard. You may get a development
environment or you may only be offered access to Notepad. You won't be
allowed to show source code you've developed elsewhere (except perhaps
HTML) due to intellectual property risks. The focus here is on you, not on
previous experience.
Fit and rapport
Being likable is not sufficient to get you a job (in most companies),
but your responses will also be judged to determine how you would fit in
with the team, and whether your attitude and personality characteristics
fit in with company culture.
We won't necessarily ask questions designed specifically to assess
these factors, but as you talk with the interviewer, you'll be
establishing a rapport that ultimately can sink you or differentiate
between a "maybe" and "hire." The only thing I
can really say here is that you should be positive and adopt the right
attitude.
The close
Toward the end of the interview, you might be asked if you have any
questions for the interviewer. The wrong way to deal with this is to ask
about compensation, vacation time, and benefits. Many managers don't know
the details of the compensation plan or don't have direct control over how
it would be applied in your case.
If you feel like you've done well in the interview, you might ask about
the company's culture. If you feel like you've bombed and the interview
ended 10 minutes into your conversation, you might just cut your losses
and say, "No, I think I have a good idea what you're looking for, and
it was nice to meet you; thanks for your time."
But you also have an opportunity to extract feedback about whether you
met the expectations of the interviewer and made effective use of their
time.
|
