If you hire contract software personnel—project managers, programmers and testers—you appreciate the influence hiring has on project success and failure.
For many managers, hiring is a sporadic endeavor, triggered by staffing increases or sudden attrition. You dust off your hiring protocols and interview questions and squeeze recruiting and hiring into your already too busy week. To ease the load and expedite the hiring process, many CIOs turn to contract software recruiters.
But that doesn’t mean you’re off the hook.
Contract software recruiters face significant challenges. Generally, they use keywords extracted from the job description you provide them to search Internet resume boards and their own files. If the job description is inadequate, or if the keywords are wrong, given undo weight or are misinterpreted, a poor candidate may be granted unwarranted consideration. This wastes everyone’s time and, as most waste does, costs money.
Proper guidance from you may avoid lost time and a “bad hire.” Helping yourself means helping the recruiter. The following techniques will help you and your recruiter identify the right candidate efficiently and expeditiously.
Give Your Recruiter a Job Description
Even if your recruiter doesn’t require it, provide him or her with written job description. If you rely on a phone call or meeting to convey your needs, your message may be lost. In a conversation with the recruiter, you may inadvertently emphasize areas that are actually less important to you. A written statement of work will help you focus your thoughts on what is really important to you and make your needs less susceptible to misinterpretation. You and your recruiter will be able to stay on the same page. Candidates will read it and know what to respond to and, perhaps, self-select.
What the Job Description Should Contain
Explain the overall project in terms of goals, timeline and challenges. Describe the state of affairs, both good and bad. If documentation is out of date or absent, say so. If timelines are tight, say so. If recent attrition has occurred and knowledge transfer will be challenging, say so. It’s important that both your recruiter and candidates understand and be prepared for the work landscape. Moreover, candidates uncomfortable with that landscape may disqualify themselves before you spend time and effort interviewing them.
Duties, responsibilities and deliverables
Explain the role of the position even if it has what you think is a commonly understood title. Titles inevitably mean different things to different people. Include all the job’s responsibilities, such as operating within your team, interacting with other teams and people, providing formal or informal supervision, participating in critical reviews, performing according to company methodologies and processes, use of particular tools and producing deliverables within a particular timeframe.
Most of us want candidates with a certain amount of experience working with a system or software package. If there are plenty of candidates with that experience, this part is easy. But if your system or software package is uncommon, or if there is a shortage of candidates, you may help the recruiter by describing experience less narrowly. For example, you may reference software applications that are similar to yours. Or you may describe your application’s characteristics in terms of its functionalities, whether it processes low or high volume transactions, its reliability requirements, whether it manages large or small amounts of data, the user interface or its design, be it proprietary or standardized. Is the system critical to the enterprise or subject to rigorous regulatory oversight? Experience can also be described in industry and organizational terms: private or public sector, large or small, established or start-up, product- or matrix-organized, highly disciplined or ad hoc, fast moving or pedantic, focused or interrupt-driven. You can also provide a list of companies where a candidate may have been able to gain the type of experience you’re seeking. Describing desired experience along these lines might yield viable candidates even if they do not meet your explicit requirements.
Essential technical competencies
Many candidate resumes contain a long list of competencies including operating systems, hardware models (and their manufacturers), languages, third-party packages, development tools, development methodologies, test tools and office products. Candidates use this buckshot style to maximize the chances that their resume will match your list of desired competencies in any search. If you blend essential and non-essential competencies in your job description, you may complicate your recruiter’s search. Too broad a search will yield inappropriate candidates. Your challenge is to target truly viable candidates by specifying only essential competencies. Essential competencies are the ones that a candidate must have to warrant serious consideration. Being rigorous about this will save you and your recruiter a lot of time. To distinguish essential from non-essential competencies ask yourself this question: If the candidate is not competent in [x], can he or she become sufficiently competent with little or no training and without extending the start-up curve? If the answer is yes, it’s a non-essential competency. If you are rigorous about this exercise, you may end up with a short (and useful) list of essential competencies.
Understanding non-technical competencies helps your recruiter identify candidates who will best fit your team’s situation and culture. Although non-technical competencies are unlikely to be used as search engine criteria, they will help you and your recruiter during telephone screening and reference checking. To identify non-technical competencies, ask yourself the following types of questions: Will the candidate work alone or with a team? Be given one long assignment or short, frequently changing ones? Be closely or loosely supervised? Be asked to perform multiple tasks concurrently? Build consensus? Operate within a process-intensive, structured environment? Produce documentation that will be subject to critical review? Represent the team to others in public settings? Communicate with senior management? Train, guide or supervise others? Answers to these questions will allow you to characterize the non-technical competencies you require. For example, “the candidate must be able to supervise junior personnel” or “the candidate must be able to work with other teams to reach consensus about the test approach.”
How to Work with Your Recruiter
After producing a useful job description, another way you can help your recruiter is by screening some resumes at the start of the campaign. Ask for a wide array of resumes so you may point out which ones are on the mark. If you use this sampling of resumes as an object lesson, you will help the recruiter understand what’s important to you. This will help the recruiter proceed independently.
If you choose not to participate in resume screening you may see only a few resumes—and worse—ones that are off the mark.
Before conducting a face-to-face interview, you may want to further validate candidates who emerge from the resume pool. You and your recruiter can explore the candidate’s skills by a telephone screen to determine if an interview is warranted.
One of the best ways to help with telephone screens is to provide the recruiter with a list of questions to pose. The recruiter, remember, is screening, not conducting a full-blown interview. Questions should not encourage open-ended responses. Try to frame questions so that the recruiter may easily capture the essence of the candidate’s responses.
Under no circumstances should the recruiter provide the list of questions to the candidate in advance. Allowing candidates to prepare for the telephone screen undermines your ability to accurately evaluate them.
If a candidate passes the telephone screen and you conduct positive face-to-face interview with positive results, the next step is your participation in reference checking.
Why You Can’t Duck the Reference Checks
In the spirit of providing full service, some recruiters conduct candidate reference checks on your behalf. But an off-the-shelf recruiter reference check may not provide deep insight into the candidate’s ability to perform his or her core duties according to your expectations and in your environment. The recruiter may not be fully conversant with the technologies and methods your team uses, and therefore may not be able to pose the appropriate follow-up questions. The recruiter may not be able to sense areas of weakness, or may not be able to explore areas of strength.
You don’t need to check all the candidate’s references, but you may choose one that is most relevant to your situation. For example, you may wish to speak to a person who worked with the candidate on a similar type of system to yours or under similar project time constraints.
Consider conducting the first reference check yourself. This will allow you to guide the recruiter through subsequent checks. If the first reference conveys information you wish to validate further (either negative or positive) you may alert the recruiter to add or modify questions to cross-check the candidate’s abilities.
If your track record of hiring contract software personnel is less than stellar you might consider providing your recruiter with more guidance and participation. Guidance helps the recruiter maintain clear priorities, cut through cloudy resumes and identify viable candidates. Your participation in telephone screens and reference checks provides valuable feedback that reinforces your recruiter’s efforts. A working partnership that includes these elements increases the chances for hiring success and strengthens the manager-recruiter relationship for future hirings.
Paul Garbaczeski has held a variety of systems development, management and business positions at major enterprises over the past 30 years. You can contact him at to email@example.com.