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
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.
Share this on your favourite network
0 comments :
Post a Comment