What are the general guidelines a project manager should follow to recruit the right person?

Question

Since our HR manager is out of station, I have been given the responsibility to recruit people for our hardware design team. I do not have any experience of recruiting people. Posting a job on linkedin, resulted in spamming with 25 CVs in a day.

What are the general guidelines I should follow to recruit right person?

What approach I should adopt so that I recruit best person in least time, and making sure that I do not ignore the best one?

Answer 1

The official scrum question and answer to this question is

According to Scrum guidelines, who is responsible for hiring or assigning a new person into a Team?

• This is outside of the scope of Scrum.

Answer 2

If possible, delegate that task to someone who has recruitment experience. Finding out the right person for the job is not a trivial task to experiment on and there is not a magic formula.

Having said that, in most interviews, HR seeks answers to these questions:

• Can you do the task?
• Are you willing to do the job?
• Can we bear to work with you?

It is PM's task to make sure project is completed successfully. So a PM should have a say in who will be in his project. But recruiting people is a bit more than that...

Recruitment is a specialised area and requires expertise, say, like training, should a PM plan and find the means to train his staff, or do the training himself?

To give an example from the original question, PM have 25CV's, how will he evaluate them?

• Skim the pool of CV's for the gold.
• Plan interviews
• Have the interviewee take an exam to prove his abilities
• Have the interviewee fill a questionnaire to evaluate his physicology
• Do the interviews, (PM should not be alone while doing this).
• Fill out an evaluation form based on the interview and exam results
• Negotiate on money and work conditions
• Reject unqualified ones with an appropriate letter and file their applications for future use

A PM, depending on his experience and age, may do any or all of the tasks above, but it is not his job. It is what HR are for.

Another aspect of the recruitment is, if you are recruiting people with a permanent contract, you need to think bigger than the project and take the company vision into account. You need to answer "what will this person do after this project finishes?" A PM may not always be able to answer this question.

Answer 3

First, I'd say make sure you are aware of what laws around hiring there are in your location. Certain procedures may need to be followed during the process. For some locations you may need to be careful in avoiding asking the candidates certain questions for example. Certain records may need to be kept for X amount of time. Ideally, your HR manager has already let you know about things like this.

Second, I'd make sure you set your goals appropriately. You asked how to make sure that you don't ignore "the best one", but do you really need "the best one", or do you simply need someone of a certain level of ability?

Third, make sure you know what you are really looking for in a candidate. Technical skills are often obvious, but usually there are other things you need to look for as well.

Fourth, many/most hiring processes have several filtering steps that lead to the number of applicants funneling down at each step.

• You want to set up your early filters in such a way as to filter out the most noise as possible while taking the lease amount of time. Often this starts with making sure you are clear with the candidates about what you are really looking for, and giving them enough information that they self-select out of the process.
• Depending on the role, looking at their CV can help you quickly winnow others out. Fair or not, when you've got 25 a day to look at, you need to have some simple criteria to apply to cut that number down.
• Once you've got it whittled down a little, consider a short (1/2 hour to an hour) phone interview to get to know them a little better and determine whether or not you want to bring them in for a full interview. This is also a good way to answer questions they might have that may help them self-select out of the process.
• Once you've narrowed down the list some more, invite select candidates in for more in-depth interviews. This should include time for one or more members of your technical team to talk to the candidate as well.

Something else... Consider alternative sources of candidates than just posting a job opening to a web site. Ask your contacts if they have anyone that they would recommend or if they know of anyone that is looking (make sure you are clear with them about what you are looking for). Depending on the skill level needed, get in contact with the career services department of the closest technical college. And keep an eye out for companies in your area that are looking at downsizing as often some of the best employees leave first.

Answer 4

I highly recommend this article; you should hire people who are Smart, and Get Things Done.

That's it. That's all we're looking for. Memorize that. Recite it to yourself before you go to bed every night. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.

Smart is hard to define, but as we look at some possible interview questions we'll see how you can ferret it out. Gets Things Done is crucial. People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say "Spreadsheets are really just a special case of programming language" and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.

Now, people who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them liabilities to the company because not only don't they contribute, but they soak up good people's time. They are the kind of people who copy big chunks of code around rather than writing a subroutine, because it gets the job done, just not in the smartest way.