You’ve hired a candidate. She starts on Monday. What will she think at the end of her first day? Will she be in the “honeymoon” phase, or will she be disappointed with your organization?

Being a new hire is a little bit like installing a piece of software. The first thing you see when you buy software is the installation. The first thing a new hire sees is how your organization takes in people. Here are some suggestions for a smooth first day:

• Be clear on whom your new hire is supposed to ask for, and where she should go. There’s almost nothing worse on your first day, than finding out at 8:00 am that you’re a mile away from where you’re supposed to be, and you’re going to be late to start your new job.
• Get the new employee’s office ready. As the new hire, when you realize you new employer doesn’t have a place for you to sit, you start wondering whether you made the right choice of offers.
• When the candidate accepts the offer, get the person’s office ready. Include standard office furniture: a desk, a telephone, and especially a chair!
• Create a standard checklist of stationery supplies people need in their office. I’m always surprised by how many people don’t have staplers, scissors, pens, pads of paper, wastebaskets. New hires may be shy about asking for supplies.
• Create a standard checklist of electronic needs: a computer hooked up to the network, an email address, information as to where the applications live and how to compile and build the product, access the test harness, or read the documentation. If you have this all on an Intranet, create a local set of bookmarks for her browser. If you have process documentation or templates, explain where those are located. If your organization has badges, order one.

Use a “buddy” for these next suggestions. The buddy, from your department, not Human Resources, greets your new hire at the door. If your company requires an initial HR visit, have the buddy meet your new hire when her meeting with HR is over. If there’s any trouble with these next activities, the buddy can fix it.

• Identify the project information location for your new hire’s project. Show her where that information is, and how to access it.
• Create a list of people-oriented questions and their answers: where the cafeteria is; how to get supplies when you run out; and where the bathrooms are.
• Identify the employee’s project manager, if it’s not you. Have the project manager identify the employee’s responsibilities and deliverables.
• Describe how the person gets direction for technical tasks, who receives status reports and when, and what the status reports should contain.
• Describe who the other team leads are, and the other people in your employee’s team.
• Bring your new hire to lunch with the entire project team. Give her a phone list and explain who everyone is, and give her permission to forget everyone’s name a few times.

Consider also supplying a product demo; an architectural overview of the product; and the marketing material, a customer perspective of the product. If you’re developing unique technology and the employee does not have experience in that technology put together a training guide for your particular technology.

It’s not a bad idea to have the buddy for about a month — sometimes questions come up after the first day. With a buddy, your new hire doesn’t have to feel embarrassed to ask questions.

If you remember what it’s like to come in as a new employee in your company, you can start putting together the information you wish you had received on your first day. This might help keep your new employees in the honeymoon phase a little longer — maybe even long enough to refer other people to your company.

convert this post to pdf.

My friend Brad, a Los Angeles cop, mentioned that he regularly sold traffic tickets.

“But it’s not what you think,” Brad smiled. “I work at night and go to school
during the day. If I have to appear in court, I miss classes. ‘Selling the ticket’ is
convincing drivers that they really were speeding, so they won’t take the matter to
court.”

“That’s a side of police work I never considered,” I said. “You have to be a good
salesman.”

“It’s not that hard,” Brad explained. “You see, I give dozens of tickets every week,
but most of the speeders only get one in a year. I get lots more practice than they
do.”

Negotiations between speeders and police can never be equal, because speeders are
amateur negotiators while cops are professionals. By the time you had enough
experience at speeding to become a professional, you’d be in jail.

Negotiations between contractors and agencies can never be equal, because
contractors are amateur negotiators while agencies are professionals. By the time
you had enough experience at contracting to become a professional, you’d be dead.

Unfortunately, you need to negotiate every new contract:

“There will always be issues and disputes between contractors and agencies. The
key, and perhaps the best that can be hoped for, is to understand the other side a
little better

convert this post to pdf.

Contract
professionals, on the average, change jobs more often than employees, so they
are involved in lots of interviews.? One of our SHAPE forum threads was started
by Pat Ferdinandi, an independent consultant, who complained: “I am
continually amazed at some of the ridiculous or inappropriate questions I get
when interviewed by prospective clients. Keeping a straight face and not losing
my cool is sometimes a challenge.”

The Shapers then contributed many examples from their own experience,
and I’d like to recount some of them and the lessons they might carry for
my readers.

Insensitive and Oblivious
An interviewer made the following statement to Pat: “A psychiatrist has a model
that answers to specific questions fall within. So, by having a base model, he
can identify that the problem with the marriage is the lazy wife.” Pat, being
a wife herself, didn’t care for this analogy. The problem here is, of course,
his gender biases, which might exist throughout the company – but even more,
his total insensitivity to the person he was interviewing.

Well, not total insensitivity.
For that award, I have to turn to a story from a
woman who was interviewing with the manager of the department she would work in
if she took the assignment.? During the interview, he said, “I want you to
feel free to come in and talk to me any time, about anything. Think of it like
a young girl talking privately to her father where she can practice her
techniques for sexual advances knowing that she’s perfectly safe with him,
because he’s her father.”

How did she handle this?
Apparently, the same way everybody present handled it when
she told us. We sat there for about five minutes with our mouths open,
not able to make a sound. She then just walked out.
Maybe he’s a masher, or maybe he’s totally out of touch,
but in either case, you don’t want to work for him.

Gender bias is bad enough, but maybe you’re the right gender.
Sexual innuendo is worse, but maybe the interviewer won’t find
you attractive. Insensitivity, however, eventually snags everyone
working in the environment, so stay away
even if you’re not a “wife” or a daughter.

The Nedlog Rule
There’s
a variation of the Golden Rule that applies to these and a great
many other the bad interview lines:

As they do unto others, they will eventually do unto you.

I call this the Nedlog Rule. Here are some examples:

Candidate: “So what happens to the staff from the other sites?” (The company was a merger of several companies)

CIO: “We offer relocation to the ones we want. That’s the nice thing: we can start over and define our culture”

The candidate has just learned how he will be handled should he become excess
baggage. The interview continued:

Candidate: “Given that, what culture would you want to have?”

CIO: “That’s a good question.
I haven’t really thought about it.”

The candidate figured they wouldn’t start thinking about the culture
they wanted just because they hired him.

Here’s another Nedlog example:

Interviewer: “We would like to have you working for us.
I already heard about you from them
(thumb pointing over shoulder at his employees) … By the way, one of them,
namely George is not very productive, but I can’t fire him”

This candidate figured she didn’t want to be called “them,”
nor did she want her performance deficiencies to be discussed with
actual or potential co-workers. If they badmouth other employees,
you have to wonder what they’ll say about you.

Dumb or Ignorant
Sometimes, the questions you’re asked tell you all you need to
know about the kind of people who will be managing you if you
take an assignment. A software consultant was interviewing for
an assignment in a hardware organization whose managers knew
nothing about software. They asked questions like these:

• You know something about software?
• Do you write computer programs?
• Can you type? How fast?
• How long does it take someone to write a computer program?
• What’s a database?
• What programming language should we use for everything?
• What’s the one thing we should tell people to do to cut
  development costs in half?

My own answer to this last question would be,
“Get rid of the managers who ask questions like this one.”

Where do such questions come from?
In trying to understand this, I tried to imagine
what questions I would ask if I were going to interview,
say, a brain surgeon:

• You know something about brains?
• Do you operate on brains?
• Can you cut with a scalpel? How fast?
• How long does it take someone to do surgery on a brain?
• What’s a nervous system?
• What surgical tool should we use for every operation?
• What’s the one thing we should tell people to do to cut
  surgical costs in half?

Looking at these questions,
I realized that any surgeon would know instantly that I
knew nothing about surgery, let alone brain surgery.
I would think that the surgeon’s next move would be to ask me,
“What is your role with respect to the job I’m interviewing for?”
If there was any role at all, no decent surgeon would take the job.

Should it be any different if you’re a software developer,
or tester, or project manager? It’s not the lack of knowledge that’s
the problem; it’s the lack of knowledge about the lack of knowledge.
I can work for someone who doesn’t know beans about my specialities,
as long as they know they don’t know.

Hidden Agendas
Sometimes, what the interviewer says will reveal to you that they’re
not really trying to fill a position. Sharon Marsh Roberts identified
two common types of hidden agenda interviews. The first are
“professional courtesy interviews” – ones which are scheduled because:

1. the interviewer owes someone a favor;
2. the interviewee has some (hopefully worthwhile) connections; and
3. there is time on everyone’s schedule.

Sharon opposes this to the “comparison shopper interview”:

1. the interviewer has someone in mind;
2. Human Resources hasn’t approved the decision; and
3. the corporation demands some sort of record of “due diligence”.

Many of the worst interviews fall into these categories,
and the best thing you can do (since your’ll never get the job)
is save time by getting out quickly. One
young contract professional was invited for an interview,
believing that she was under consideration for a particular assignment.
The interview started badly enough and went downhill fast enough so that
she asked the defining question:
“Is there something that I should be telling you to explain that
I could perform this job?”

The answer communicated bluntly something on the order of,
“No, because I’m interviewing someone who’s isn’t qualified
for this position.”

She gracefully departed. There wasn’t much she could say,
and besides, why waste more time?

Conclusion
There are dozens more ways in which interviewers reveal this kind of
information, and if my readers clamor for them, perhaps I’ll provide
some more. The important thing to know, though, is no matter how
inept an interviewer may be, you?the interviewee?can almost
always get the information you need to make a decision.
Just don’t lose your cool and thereby lose the information.

convert this post to pdf.

This article originally appeared on stickyminds.com

Summary: What?s the best way to wade through those thousands of resumes you?ve received for the new testing position? To start, you could ruthlessly weed out those who don?t show experience with your organization?s particular toolset. But in this week?s column, Johanna Rothman warns against this type of approach to hiring. By not looking at the person beyond the tools, you might be letting a star slip through your fingers.

Pamela, an out-of-work tester, has a master?s degree in computer science and is most of the way to a doctorate in quality. She has eight years of experience in testing. Pamela has been unemployed for the past six months, and no one will even interview her.

Pamela doesn?t have any perceptible flaws on her resume, except for the time she took off from work to go to school. She has great references. Okay, she?s a geek, but a socially acceptable and technically astute geek.

No one will phone screen or interview Pamela because she doesn?t have all the toolset vendor acronyms on her resume. She has experience with parts of numerous testing tools, but not more than a couple of months? experience with any piece of one. Pamela?s not comfortable putting the tool names on her resume because she doesn?t have even one year of experience with any of them. Hiring managers and internal recruiters seem to be looking for tool experience rather than a person who can learn about a tool.

What a shortsighted mistake.

Why does this happen? One of the reasons many hiring managers and HR staff rely on tool experience is that they don?t know how to define the requirements for the kind of employee they want to hire.

I recommend against filtering resumes for specific toolset experience. It eliminates some of the most talented people, people who can easily learn a tool?who are already great testers, but not familiar with your toolset.

This mistake is not restricted to test managers or other technical managers. However, as technical people, we are more likely to depend on HR for initial resume screening. And, because most HR staff don?t understand what testers do, or understand the desired experience, they screen resumes based on things they can easily check off as a “yes” or a “no” (e.g., toolset, operating system, compiler experience, etc.).

Instead of letting your HR staff filter out promising resumes, try some or all of these alternatives:

Talk to Your HR Staff

When I have taught HR staff how to read technical resumes, I would write down a grid of the kinds of technical experience I expected to encounter on resumes. I listed the potential operating systems, compilers, and tools experience I wanted. Then, I talked to the HR staff. I explained why I was looking for this experience. I explained the relative importance of each kind of experience. In addition, I explained which personal qualities (such as perseverance, initiative, focus, curiosity, skepticism, problem identification, problem solving, goal orientation, adaptability, etc.) were important, and how those qualities ranked with the technical skills. I discussed what I was willing to trade off, in terms of tool experience vs. other experience. For example, I?m much more interested in knowing that a tester knows how to describe a defect so that a developer will fix it, rather than in which tool she has written scripts. In my experience as a hiring manager, once someone has learned a tool or two, learning another tool is trivial. I?m more interested in a candidate?s personal qualities, so I have a group that works well together.

Screen Resumes Yourself

Even when I?ve had the discussion with HR, sometimes they can?t help us. Some resume-screening tools categorize resumes by acronym, not by what the candidate has done. Or sometimes my HR person is a junior employee, someone who hasn?t worked long enough to understand what I?m saying. Or sometimes the HR staff is too busy to screen resumes in a timely fashion.

If that happens to you, then you can screen resumes yourself. Whenever I hire for an open position, I always screen the resumes myself. I create three piles: Yes, No, Maybe. I screen relatively loosely based on skill, and much more tightly based on how the person has worked, keeping in mind those personal qualities I want. I don?t mind phone-screening lots of people, because I can learn more from a brief phone conversation than I can from a resume. I phone screen the “Yes” resumes, respond via HR for the “No” resumes, and after I?m done with the “Yes” resumes, I decide whether to pursue the “Maybes.”

Clarify Required Experience

One of the reasons many hiring managers and HR staff rely on tool experience is that they don?t know how to define the requirements for the kind of employee they want to hire. If you?re in this boat, don?t feel bad; you have plenty of company! After all, there?s a huge difference between someone who?s a whiz at testing GUIs and someone who tests embedded systems.

Many hiring managers have never analyzed their open positions, to define the requirements. However, you can define the skills and personal qualities you want in a candidate relatively easily. Here?s a quick technique for analyzing the job:

1.Define the roles this person plays, and at what level you think the interactions lie.

2.Define the activities and deliverables of the job.

3.Take a look at your current staff, and identify the personal qualities that make a person successful in your group. If you?d like some ideas for this, review the list of talents in First, Break All the Rules, by Buckingham and Coffman.

4.Define anything that would prevent you from hiring a candidate. I?m not talking about your preferences, I mean anything that would make the candidate not fit into your organization at all. Examples are people who can?t work overtime at release time; people who aren?t available to travel and the job requires travel; classes of people your company doesn?t hire, such as felons; or whatever is specific to your job.

You?ll notice that education and toolsets are only a small part of this analysis. If you absolutely require some specific minimum of education (because your clients demand it) or tool experience, then add that. However, I?ve never found specific tool experience worth hiring for.

So, here?s my plea: Make sure you?re looking at the whole person, not just a tool. Pamela, and all the other Pamelas out there are ready, willing, and able to work. Let?s give them a chance to prove themselves in an interview.

Show this column to your company?s hiring manager(s), people in HR who scan the resumes, and everyone else involved in hiring. Help your hiring managers and recruiters look past the tools to the person.

Acknowledgement: I thank the following people for their helpful reviews of this article: Esther Derby, Elisabeth Hendrickson, and Dwayne Phillips

convert this post to pdf.

Introduction
If you’ve hired new people or transferred people into your group, you know that they’re not immediately productive when they start. If you’re lucky, they start to be useful in a month, but you most likely spend closer to six months or even a year before they raise the entire group’s productivity. One technique for bringing a new employee up to speed quickly is to assign that person to a buddy, someone who will mentor the new employee through the first few days and weeks on the job.

If you’d like to bring new hires up to speed quickly, or if you’d like to cross-train your group, try a buddy system.

Buddies aren?t just for the pool

A buddy system at work is nothing like the buddy system you might have experienced in a pool when you were a kid. You didn’t get into the pool without your buddy, and when the whistle blew, you and your buddy found each other. You and your swim buddy were there to watch over each other, to make sure you both knew where the one was. This is not your child’s swim-buddy system.

A buddy system at work is a technique to help already capable staff learn how to apply their skills more quickly, to reduce the floundering that occurs at work when a new hire starts.

Here’s how to think about the knowledge necessary for work:

Functional skills: what the person knows about their job (development, testing, project management, writing, etc.) People learn these skills at school and on the job.

Product Domain Expertise: how people understand the product and the product domain, and how they apply those skills to the product. People learn about the product and its internals by working with products.

Tools and Technology: how well the person knows the tools of the trade: compilers, testing tools, defect tracking tools, databases, and so on. People may learn some basic skills, but most skills are learned on the job.

Industry Knowledge: what the person knows about the kinds of people likely to buy your system, and the general expectations of the your users. People learn about the industry by working in it, on the job learning.

Your new hire already has the functional skills?that’s why you hired that person. But the new employee may need product domain expertise, both in the problems the customer has and in how your product solves those problems. Your new hire needs to know how you’ve customized the tools and technology you use. The more you can help new staff understand your local environment, the faster they will adapt to your environment, and the more quickly they will contribute to the overall efforts.

Requirements for a buddy system

Creating a buddy system requires that you have people who are willing and able to mentor others. In addition to the mentors, you’ll need to document a few key pieces of information: the physical layout of the building and the security, where the tools are located and how to use them, where the project information lives, and some information about the product internals. The more documentation you have, the less the new staff will interrupt the experienced staff.

The documentation doesn’t have to be a huge honking binder. In fact, if you can keep the information to one web page or one to two printed pages, the information will look accessible and not threatening to the new hire.

Evolution of the buddy from guide into mentor

When someone new starts at work, that person needs to know everything, from how to use the phone and voicemail systems, where the bathrooms are, where the lab equipment is, to how to use the tools of the trade, such as the defect tracking system or the configuration management system, or even the compilers.

When you first assign a buddy to a new person, the buddy acts as a guide, to explain where everything is. If you’ve never had a buddy system in place, this is a good time to document the locations of everything, including the physical facilities and tools. Once the locations are documented, the buddy can explain once where to discover more information, and you’ve already farther ahead for the next new person.

On the first day, it’s helpful if the buddy can take the new employee to lunch, preferably with a group of people in your cafeteria. If you have no cafeteria, choose a lunch location that most people use. Sometime during the first day, the buddy can demo your products or applications to the new hire.

After the first few days, the new person knows where the cafeteria and the bathrooms are, and has probably started reading product and tool documentation. The buddy is available to answer questions about which platforms to make sure to compile on before checking in code, or how you use certain databases, where specific tools are, and so on.

During the first few weeks, discussing architectural or design tradeoffs with new developers, test strategies and choices with new testers, or project monitoring specifics with new project managers will help the new employee understand the context of how you work, which choices you’ve already made, and how to make sure the new employee’s work fits into your environment. As the discussion moves past the basics, the buddy has moved from guide to mentor.

You may choose to have a formal ending to the buddy relationship after one month. If so, one way I’ve found useful is to mark the new hire’s 1-month anniversary in a group meeting and say, “John is now experienced enough to not need the formal services of a buddy. Thank you Steve, for taking on the role of the buddy. John, you can ask questions of any of us at any time, and hopefully you can take on the role of a buddy to a future new hire.”

Pitfalls or common traps

Even when you’ve planned for a buddy system, things can go wrong. Here are some common problems:

The buddy assigned doesn’t want to be a buddy. Some people don’t want the responsibility of helping someone new acclimate into a new job. Sometimes, they’re not temperamentally suited for the role (such as people who are so shy or introverted they have a difficult time speaking in public), or they are on the critical path for some deliverable, or they don’t feel as if they know everything the new person needs to know. If your employee doesn’t want to be a buddy, don’t demand that that the employee be a buddy. Instead, understand why your employee is reluctant, and work on that problem. One caveat: if the employee is too shy or introverted to easily speak with a new hire, find other ways that employee can help new hires. Don’t demand someone perform the buddy role when they are nervous around new people.

The buddy inflicts help on the new hire. Some people are so inspired by their buddy role they give unsolicited advice about the new hire’s work. The buddy needs to provide advice about how the work is performed at your organization, not how to design or how to test or anything else, unless the new employee has requested peer review.

The buddy performs the new hire’s work. Another form of inspiration is to take over the new hire’s work. One of the common reasons I hear for this is, “It would take me less time to do it myself.” Well of course it would. That doesn?t mean one employee can or should take over the work of another employee. The first few months are when you can expect the new hire to be less productive. Don’t allow a buddy to short-circuit the new hire’s learning experience.

The buddy stops being a buddy before the new hire is ready. If the buddy takes a vacation or has a trip during the first crucial weeks, the new hire is left stranded. The new hire and the buddy have already created a relationship. If the new hire has to create another relationship with a substitute buddy, the new hire is less likely to ask the necessary questions.

Use a buddy system for cross training

If you’re concerned about single points of knowledge in your environment, you can also use a buddy system for cross training. In this case, the buddy assumes the new person only needs product domain expertise, or alternative techniques to applying functional skills to the new product domain. When you use a buddy system for cross training, make sure the two people develop a list of milestones where the already-knowledgeable person performs less and less work over time. That way you and the person learning this area both have feedback about how well the new person is learning the product.

When I use a buddy system for cross training, I assume it will take the people about three months to transition the product knowledge, unless you have very short releases.

Summary

Creating a buddy system for a new hire isn’t difficult, but does need to be handled with care. Make sure you’ve chosen a buddy who is willing. Create the minimum set of documentation, and revise it as you hire new people. Set an end date for the formal buddy relationship. Watch for pitfalls so you can guide both the experienced and new employees.

A buddy system can dramatically reduce the time a new hire requires to be productive. A new hire will need to ask questions anyway, so make sure you have an effective system in place to deal with those questions.

convert this post to pdf.

Part of managing the interview is making sure you hear the candidate?s answers ? and questions. In this excerpt, Johanna Rothman explains how to listen to candidate’s answers, how to evaluate a candidate’s answers, and when to consider replanning the interview.

######

Listen to and evaluate each candidate’s answers.

During the interview, practice your active listening skills. Here are some guidelines for active listening in an interview:

1. Stay in the moment. [Hacker, 1999 #8], p.87 Focus your listening on what the candidate is saying now. If you find yourself thinking about something else, make a note if you must, and return your attention to the interview. When I interview people, I use the physical act of closing the door to also mentally close the door in my brain to the problems I’ll have to return to at the end of the interview.
   
2. Maintain your alertness. If you normally run from one meeting or issue to another, you may find it difficult to stay in one place for the interview. If so, consider these techniques: Dress in layers that can be added or removed so you can keep comfortable during the interview; keep water or other non-sugar beverages available to perk yourself up if you feel drowsy or inattentive; do whatever you can to get a good night’s sleep the night before the interview. There are, of course, other techniques that you can use, but these are a good start.
   
3. Allow the candidate to complete their thoughts and sentences. Some candidates speak more slowly than others. Some candidates continue thinking as they talk. Don’t interrupt the candidate, so you can hear everything the candidate has to say.[Rosse, 1997 #11], p.179
4. Encourage candidates to complete their stories. Sometimes, candidates tell a story only part of the way, thinking you’re not interested or the details are not relevant to the position. If you think there’s more to the story, say, ?I bet there’s more to that story. Tell me more.?
   
5. Restate what you thought you heard. Use this technique when you want to check your understanding, especially if you think you heard something that appears outlandish or even merely somewhat unusual. If, for example, a candidate states, ?The project was the longest three months I ever spent,? ask him or her to tell more about the experience. If you don’t understand what point is being made, say something like, ?I think I heard you say the role of the release engineer is to rename everyone’s variables. Is that what you said, and if so, what exactly did you mean??
   
6. Summarize the major points of what you heard. ?So what you liked best about your last job was the pair programming. The product technology wasn’t that interesting, which is why you’re looking for a job. Did I get that right??

When you actively listen, you can evaluate how the candidate answers and the quality of the answers you hear. Table 9-2 presents a checklist you can use to evaluate a candidate’s answers during an interview.

Table 9-2: Questions to Ask Yourself About a Candidate’s Responses.

While listening, you may decide that you need to guide the interview in another direction. Replanning the interview is fine. I recommend that you check the interview pace about halfway into your time and make sure you’re covering the topics you need to cover. If you’re behind schedule, see if you can focus your questions more tightly. If you’re ahead, try to encourage the candidate to speak more about his or her experiences.

Answer the candidate’s questions.

Leave the last two to five minutes of the interview open for the candidate to ask you questions. Some candidates will have questions; some won’t. If the candidate has questions, answer them to the best of your ability, always telling the truth. If the candidate has no questions, suggest that he or she take your card to call you later if any questions crop up. Between interviews, a candidate may wish to use the restroom or get something to drink, so be sure to offer these options.

convert this post to pdf.