Hiring team members is easy…isn’t it? Not in technology. – Part I: Before the Interview

Challenges of finding right people for the project on the overcrowded market

By Vitaly Dubravin

Every manager sooner or later is facing a challenge of hiring new team members. I don’t make a big difference between hiring of a full time person or a consultant. Both will be equal team members. This process may be very formal or extremely flexible, depending on the company’s culture. But the ultimate result may either save you tons of money and nerve cells when you find someone really good or cost you a lot if a mistake is made. Here are some considerations from my own team building experience.

Market was going down for a few years in a row and there is a common illusion that there are plenty of high-skilled workers who can be hired for a dime. Yes, many good people were laid off but that was a measure of the last resort. Office plankton was the first to be kicked out. People with outdated skills were the next in the line. Such “talents” present a vast majority of the widely available resources in the online resume databases. It does not mean that it is not possible to hire a person you really need. You simply have to kiss a lot of frogs before finding a princess.

I had to go through a lot of frog-kissing exercises in my career seeking for a perfect (or close to perfect) candidates for my projects. It was really easy in some cases and had a person in less than 24 hours. But also had a situation when I personally interviewed about 50 candidates (not counting resumes I went through), just to hire I reliable person, who worked in my team for almost a decade. Over the years, I have developed my own set of factors to consider while hiring and will describe them below.

Interview has always been and will probably remain the central part of the process. Though I think three main interview-related stages should be taken seriously. You can disagree with my judgment or ignore my suggestions, but my personal experience tells me that any omitted step will cost you more later (often after brining a newbie on board). I intentionally skip role definition assuming you know what kind of person you looking for…

1. Before the Interview.

Resume. It is the first document you receive from your recruiters or trusted suppliers. Don’t get excited for receiving a nicely written resume. There are agencies and good templates on the Internet and very often it has nothing to do with the real person. Great technical gurus can barely express themselves on the paper. It is hard to be a “bi-lingual”, i.e. talking to both machines and people on their language.

Great resume only tells me that the candidate knows how to write a resume. I use resume to disqualify those candidates, whom I do not want to talk to, and not to select people whom I’d like to interview. Key rejection factors for me are: inconsistences in description, substantial “stretching of truth” (I expect some statements may not be 100% accurate, but lie does not fly), frequent drastic career changes, “nomads” (3-6 month on every project).Technical people are also good in remembering software versions used on the project. So I expect to see that on the resume.

Education. Modern world has slowly evolved toward life-long learning. High quality education is a part of job requirements. Education does not mean a graduation from the top college. Best colleges provide an amassing curriculum for systemic mind structuring and help students to think outside of the box, but not all graduates excel in that. Education does not stop after graduation. I prefer candidates with a well-blended mix of formal and informal classes, certifications and self-training. There are more chances that we will be discussing how to help him or her to achieve next career goal during performance evaluation instead of me pushing such employee to attend yet another training class.
Experience. This is a key for a project success today. I rarely have time to start a project from a training program and look for those people who did somewhat similar before. Theoretical knowledge is necessary, but not sufficient. What not to do in some cases is more important than how to do it right. Technology world is changing rapidly and new products and frameworks are surfaced every few months. But it does not mean that there was an empty universe before. Every new technology has its predecessors and some background in those “stone-edge dinosaurs” is a huge plus. Local (in country) experience is helpful for many roles, but should not be the decisive factor.

Trusted source. Knowing the source of the resume is very important. I’d like to have a story behind. Is this the first time we see this candidate? Have we ever worked with him side by side on the prior projects? Was he/she recommended by one of my team members? Is this person known as a true professional on the market? I always check LinkedIn profile to make sure the resume and the “public” story have some common elements. New profile with no connections is somewhat suspicious, but is not necessarily wrong.

Fakes. This is the most frustrating part of the selection process. Recruiters can only do limited checks prior to the interview. I had candidates who were not shy to use fake names just to try to get in again. Checking government issued ID always helps, though it may offend some folks. I also saw people with fictitious experience fabricated by some unknown training facility or candidates claiming years of works on the project I know well with zero traces of their presence there. All this is very disturbing, but this is a homework you have to do to avoid surprises. As Ronald Reagan said – “Trust, but verify”.

Next time I’ll describe some interview strategies and what to do right after it.

See “Hiring team members is easy…isn’t it? Not in technology. – Part II: The Interview and beyond”

(originally posted on CIO.com)