Hiring People

by Krishna on August 26, 2007

If you ask any manager about hiring, he or she would say, “I want to hire the best employees and my hiring process is streamlined to do that.” There is quite a lot of material, if you wish to read, about how to interview employment candidates to find the best one that meets your project or organizational needs. Typically, most managers seem fine with their hiring process. But what is really, practically going on? Let’s analyze this.

Let us say that you have an opening for a developer. You determine what level of experience and development skills a person should have. You write down a job description. You advertise the position. You get a few responses. You interview the candidates and then you select one. Here is what is happening to you at each step.

  1. Under normal circumstances, at any particular instant, the majority of developers are not looking for a job. The best developers would likely have gravitated towards the companies best suited for them, because they have the capability to get into those organizations. And less skilled developers to organizations that match their needs.

    A developer may be looking for a job if their current employment situation has some drawbacks such as less compensation, unhappy work environment or lack of good opportunities. But this is balanced against the costs of leaving the job including relocation of residence, instability, adjustment to an unfamiliar work situation, etc. This means that even if the person is looking, they may not shift unless there is a significant difference in compensation or they are very disillusioned with their current job.

    Things change during times of economic (or industry) downturn and upturn. It is actually easier to find more developers during times of industry growth because salaries increase and people do not want to be left behind in “making hay while the sun shines”. During downturns, people would rather stay with the existing company if it is holding steady because shifting to an unknown company is riskier.

  2. It is unlikely that most developers will even see your job opening. Unless someone is unemployed and actively searching for jobs, the chances of them seeing your job posting are low. You are also competing against many other companies for developers in all the usual job sites like Monster or Dice. You can try niche job sites, such as those running on some popular blogs, but there also you are competing for eyeballs.
  3. Even if they see your job opening, they may decide not to apply. But this is something over which you have more control. What you need is to provide more information about yourself so that the applicant feels confident about your company, the work environment and career opportunities. Secondly, the more qualifications you put in the job opening, the more potential applications you lose.I have learnt the lesson the hard way. You sometimes write up a very accurate job description and necessary job qualifications. But the more detail you have, the more likely such a person exists only in fiction. You also end up scaring away good candidates who think that the job is more complicated than it seems. The problem is that if you generalize the job description too much, then you get too many unqualified candidates. Finding the right balance is frequently a trial-and-error exercise.
  4. Suppose you receive applications. When you decide to filter them, you are primarily basing your decisions on the resumes. You may actually end up rejecting a few good candidates because their resume did not “look good”. A developer who is not good at presentation or marketing skills may be at a disadvantage in this filtering process.There are 2 schools of thought here. On one side, you could say that someone who does not pay attention to writing and presentation is probably not a good fit for your organization. On the other hand, many technically good people are poor in effective communication and presentation. Besides, most people do not spend every day polishing their resume. Usually, they start working on their resume only after they need a job and probably stop after the first draft to spend time looking for job openings.
  5. Finally, you start interviewing. Let us side-step the issue of how you actually interview people because, to a great degree, how you interview people (phone interviews, written tests, whiteboard coding, group discussions, face-to-face technical interviews, etc.) is dependent on the needs of your team and your organization. The more your interview methods are in sync with your needs, the better people you will hire.But one problem with any interview process is how many people you actually interview. You would actually like to interview as many people as you can, but limitations on time and budget force you to restrict the number of interviewees. The second issue is that if you are doing interviews in series, each interview can bias the nature and result of your next interview. You may also decide to stop if you find a suitable candidate, which means that you are possibly forgoing a better candidate.
  6. Finally, after all this hard work, you really don’t know anything about the person until you see them in operation with your team and producing results. Sometimes, incompatibility problems may become visible soon, if you are lucky. Sometimes, they may only materialize much later when you are more dependent on the person. Also, if you were very dependent on that person for your project needs, you may consciously or subconsciously ignore many warning signs until things come to a crisis situation.

The reason I outline all this is that many people do not have a clue how far they are away from a perfect hiring process. They think that hiring is like evaluating 10 software products and then selecting one of them for the next project. Here, out of millions of software developers, you are only looking at a fraction of a fraction. And if you belong to a small or mid-size company, then you don’t even have that.

It is, of course, not anyone’s fault. It is just the natural rules of the game. And I don’t see much anyone can do to significantly improve upon the percentages. Perhaps the most important lesson from all this is that hiring and getting someone that meets your needs perfectly is an incredible stroke of luck. Cherish such hires.

And don’t be surprised or upset if things don’t quite work out with a new employee. It is really impossible to get a perfect match with such a limited pool of selections and within such a short duration. There is always a possibility you made a mistake. Fortunately, most people are good at adapting and frequently learn how to fit in with the organization. And somehow it all works out.


Alexey Linkov August 28, 2007 at 5:32 am

Well, what I can say, that’s exactly what’s going on. Did you have any positive hiring experience? I mean maybe you could, say, post your 5 tips for getting the right programmer?

By the way, i have just posted my review on Steve Hamm’s Bangalore Tiger, i thought you might be interested, so here is the link:

Krish August 29, 2007 at 6:48 pm

Nice post, Alexey. Thanks for the idea on hiring experiences. I will be posting an article on that soon.

Comments on this entry are closed.

{ 2 trackbacks }

Previous post:

Next post: