A Jagaimo.com Project tech.job.search guide



New Etiquette

Know Your Stuff
What to Expect

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. 


Last modification to this page: 2000.12.18

Send Feedback

© 1999-2001 Jason Truesdell.
All Rights Reserved.

Best experienced with
Microsoft Internet Explorer
Click Here to start.