People who have tons of experience are looking for jobs. Too often, hiring managers don’t want to hire them because the manager thinks the candidate will leave as soon as the economy improves.

I have a question for you hiring managers: Can you read minds? If you do, I want to know your trick, because it’s not working for me.

I know of a very talented mid-level manager who decided she wanted to be a technical writer again, and get out of management. She did. She loves the writing.

A talented program manager decided he wanted to write code again, not manage projects. He does.

Hiring managers, think about what qualities, preferences, and skills you need. Consider the value that a candidate brings. If you can’t pay a candidate what you think the candidate wants, ask what the candidate will take. (I advocate having the salary discussion in the phone screen anyway, to make sure everyone is on the same page.)

Look to your job analysis, not mind reading to see if you are hiring under- or over-qualified people. Don’t practice age discrimination because you think a candidate needs a certain salary.

Remember that careers are non-linear. People want to achieve different things at different points in their careers. You may get more than you have to pay for.

Tweet This Post

Tweet This Post

Why? You would think it would be easier to find great candidates, because so many people are out of work or are looking for better jobs. But that’s exactly why it’s so hard for hiring managers to find people–there are too many great candidates out there. That leads to looking for perfection. But eventually, if you decide you really need to fill a job, you decide it’s time to use a recruiter.

And, for many people that means HR is firmly in the middle. HR decides which recruiters you can and cannot use. HR does all the negotiation with the recruiter. HR provides the recruiter a job description. HR does a first pass reviewing resumes, looking for buzzwords or keywords. HR does the initial phone screen (and I’m not talking about the dirt-bag phone screen). HR sets up the interview. HR decides when to have a followup meeting to discuss the interview, and HR extends the offer.

But that’s not the best way to use a recruiter. Hiring managers need to work with the recruiters. I suggest HR has a real role: in selecting and negotiating with recruiters, in helping the hiring manager and the interviewing team make good decisions about how to hire and who to hire. If your HR person is an internal recruiter who knows your group and how they work, maybe that person can help. But too often, the HR person is not an internal recruiter, but an HR generalist. And, HR generalists have no business being in the middle of the recruiting and interviewing work.

For those of you in HR, I suspect this feels like a slap in the face. But here’s the reason I feel so strongly about this: as an HR generalist, you have too much to do to do a great job at recruiting. You not only recruit, you do the health care negotiation with vendors. You make sure the corporate policies keep the organization away from lawyer’s offices, and especially out of court. You make training decisions. You may even conduct interview training or management training. You certainly conduct new hire training.

If you wanted to be a full-time contract recruiter, you would be. Being a full-time contract recruiter means you network with candidates, that you build relationships around the local area, and maybe around the world. If you are in HR in an organization, it’s a formidable task to develop all those relationships and still do your HR job. I don’t see how you do it. (It’s just barely possible if you are an internal recruiter and you never touch the rest of the HR jobs.)

A contract recruiter needs to build a trusting relationship with a hiring manager. Every time a hiring manager rejects a candidate (even just reviewing resumes), the hiring manager needs to explain why to the recruiter. The whys are myriad: You explain how the job works, the corporate culture, what you are looking for, all the quirks of how things work for this position. The more the recruiter learns, the better the recruiter can source the candidates for this job.

When you allow HR to be in the middle, HR takes control of the transaction. That means delays. It certainly means someone else is playing telephone with your job description and analysis. Is that what you want?

Yes, it’s more work for the hiring manager, as you learn about recruiters and how they can help you. And, over time, you work with those recruiters and you build that relationship. It’s to the hiring manager’s benefit to build those relationships and make it work.

If you have internal recruiters, take the time to get to know them, and have them get to know you. Explain your group’s culture. Review resumes with them. But if you don’t have an internal recruiter, don’t let HR get in the middle of the sourcing process.

Tweet This Post

Well, maybe not right away. And, maybe it’s not just technical skills that make a candidate a perfect or imperfect fit. (You and I both know it’s not!)

And, at some point, it’s time to hire a candidate who is good enough. Otherwise, you have to change which projects in the project portfolio you can staff, or how the people work on projects. (See Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People for more details)

But how long can you wait? How long should you wait? In this economy, chances are good that you can find good candidates relatively quickly. If you are a hiring manager who’s had an open position for several months and you haven’t found the right person, make sure you review your job analysis. Maybe what you thought you needed has evolved. Iterate on your job description–maybe it’s not working for you, helping you filter in the right people and filter out the ones who aren’t quite right.

The problem is that waiting does cost you capacity. Only you can know how long you can wait for the perfect candidate. And remember, the “perfect” candidate does not exist. You can hire people who are very close.

Tweet This Post

Tweet This Post

Well, if you’ve hired for zero diversity, you might be able to discuss the team’s mean. And, if you haven’t thought about diversity of personality or experience, you might be in that position. I don’t know how to assess the team’s mean, so here are ways to think about this idea.

Consider reframing the idea of “raising the bar.” I find that assumption about the team’s mean demeaning to the people who already work with you. (What are these people? Chopped liver?) Yes, I do want to work with people who can teach me something–that’s exciting. I don’t want to always be the senior person who knows how to do everything without learning anything new. So instead of thinking of “raising the bar” consider a reframe to “increase the team’s capability.” Now you are open to alternative kinds of experience, diversity that can increase the team’s capability.

If you only look for senior people who’ve done the same kind of thing you have, you may get the people you want. But instead of pigeon-holing people, consider experience diversity to increase team capability. You are likely to have more great candidates, and if they can learn your problem and solution domain, you can increase your team’s capabilities.

Tweet This Post

New grads have a huge advantage over experienced people: They don’t know the problem you need solved can’t be solved. They’ve been trained through 4 years of university that all problems can be solved before the end of the semester. They will bring that optimism to work.

Many new grads have worked somewhere, but even those who worked as interns or coops may not have had real professional experience. Back when I was a manager inside organizations, I was able to help new grads find their professionalism.

I have had some trying times as a manager. There was the new developer who thought he could come to work the way he went to school: after 1pm. We had several discussions about core hours. There was the new tester who thought he knew everything, but really didn’t know much about test techniques. I suspect that I was that arrogant when I started, so I had a fair amount of sympathy for him and gave him feedback about how he appeared to me.

I found these experiences, the helping people find their approach to work and their passion rewarding as a manager. I stay in touch with many of them now, many years after they and I moved on.

So, hire experienced people. But don’t forget about people with “no” experience. They may well find new and innovative approaches to your product development. Not because they’ve been trained in the newest techniques, but because they don’t know they can’t do something.

Tweet This Post

I once worked with a team who were all introverted, quick to come to decisions, and all had the same kind of product experience. When it came time to develop a brand new product, they had trouble. They had no one who came up with wacko ideas on the spur of the moment, and no one who could keep options open for a while. They hired someone who liked to wait longer to come to decisions. That person also connected problems and solutions differently than the original team members did, so he was a very helpful addition to the team.

When I worked for my first machine vision company, I had no idea how machine vision inspection worked. But I had a product to deliver, so I experimented with different algorithms, different lighting, and different placement of the piece to be inspected under the camera. I didn’t know much about machine vision, but I knew about problem solving. One of the more experienced engineers told me that the color of the light would not make any difference. Except, that was the variable that made all the difference in solving the problem.

I wish I could claim brilliance, but I can’t. I can claim that previous experience of varying parameters in experiments and keeping a notebook of the potential solutions and how they worked was helpful. That, I’d learned in an instrumentation company.

Remember that personality and experience diversity is a piece of diversity when hiring. Do you need people who think differently? How about people with different kinds of product experience than you have? You might be pleasantly surprised. Problem solving skills transcend product experience.

Tweet This Post

Diversity’s Not My Problem

Screw that, it’s everybody’s problem.

He’s correct. That’s why I have several drafts lined up to discuss diversity.

The problem with hiring women is that if only about 20% of new college grads in computer science are women, are there enough women to work on our teams? Do we need to find women somewhere else? Is that what we want to do? I don’t know. (I am getting involved in a program to talk with middle- and high-school girls, so they can see that technology is a field to consider.)

Women are not the only disempowered group. Look around your workplace. How many people are white men? How many are not?

I want to hire people who are capable of doing the job. I don’t want to hire people to fill a perceived type of vacancy, an unfilled diversity bucket. But we need to do a better job of finding people who don’t look just like us to work on our teams. I don’t have all the answers. But I do know this: if you are a hiring manager, look inside yourself. Do you discriminate against people based on their gender or school affiliation or first or last name? If so, please reconsider.

P.S. In case I wasn’t clear, I never advocate hiring anyone who is not capable of doing the job, just to fill a diversity bucket.

Tweet This Post

• Pseudo-code that shows how you solved a problem as a developer
• Description of an automated test framework or pseudo-code that shows the interviewer how you put the framework together
• Description of a project schedule, explaining the iterative and/or incremental parts
• Description of a project and what it was that made that project agile (or not)

If you are worried about sharing code or asking for code, it doesn’t have to be real code. And, notice that all of these items can be considered auditions of a sort.

Many years ago (more than 20), I wrote an FFT multiply loop on an embedded processor. If I had to describe that now, I would explain it this way:

• The inner multiply loop had 7 or 8 steps. I can no longer remember.
• During the steps, I loaded a different accumulator to perform some other computation, and then created another loop for the next few steps, testing for done for that computation along the way
• The issues I had to deal with were:
  • What if I finished the other computation first? What happened then?
  • What if I finished the multiply first? What happened then?
  • How did I know the multiply was faster?

I no longer remember the answers to any of these questions, but I do remember asking them. At the time, I didn’t need the real code for that code snippet (or description). But explaining why I felt proud of that code and how I knew and resolved the issues was helpful in my next job interview.

So, yes, be careful about asking for real code or real tests or a real Gantt chart (or any other project artifact). But you can certainly ask for pseudo-code or the thinking behind code (or whatever artifact you want).

Asking for evidence of the thinking behind a real problem the candidate encountered at work is an audition. Asking for something the candidate feels strongly about helps a candidate retrospect.

Tweet This Post