How I can help your business find the right talent

Thursday, 24th February 2011

F YOU'RE a very busy person and you like the capsuled version of things, then just read this text in bold, which basically summarizes my philosophy about hiring and then jump right to the section at the end.

If you are a software developer looking for a job, though, get in touch with me.

"Hiring is the most important activity in any organization and is the cause for an organization’s success or failure in the long run. Good people hire more good people. Bad people hire more bad people. If you want your organization to succeed, you need to remove bad people just as much as you need to hire good people."

Now, you may skip to this section at the end. For the others who want the longer version of the story, read on.

Before I tell you what I can do for your organization, let me tell you a bit of a story. It is a story that’s based on facts, but the names of people, places and titles have been changed to preserve anonymity.

Back in the day, I worked for a company that wrote software for telecommunication businesses. For the sake of this true story, we will call my ex-employer Suzy Snores Loud (SSL). Like Secure Socket Layer (SSL), eh?

Founded by an erstwhile army captain who knew as much about computer programming as you’d expect a barber cubicleswould know about performing brain surgery (Hey, they’re both about doing things near the head, how different can they be?), SSL set up its offshore development centre in a plush, leased office space on the seventh floor of a formidable construction in the centre of Zamunda – the one just outside Delhi.

The captain announced himself as the General Manager of the enterprise. He hired one of his known as the factotum, with the designation Project Manager. You have to give it to this guy. He was a bright chap and quite friendly, too. I kind of thought he was nice. And then the captain hired one of his distant family acquaintances, a female, as the head of Human Resources. There were probably one or more people at the time, but for the purposes of our story, we’ll keep it simple and restrict our attention to just these three people. You don’t want to remember too many names in a drama.

The three of these set out on a hiring rampage to recruit engineers.

The format of the interviews was as such. The proletariats applying for programmer positions, among which I was one, had to go through one technical discussion with the Project Manager, following which, if you passed it, you’d be recommended for the HR interview. Pretty normal, I guess. That’s the way it is done.

As is always the case, the HR interview was a no-brainer. You’d be asked easy questions about your strengths, weaknesses, opportunities, threats, whether you had a pet dog or a cat, and that kind of stuff. So for all practical purposes, the only rope you had to jump was making it up to the factotum.

Well, that was how it worked for the freshmen and other subtler variations of have-nots.

But if you were applying for a senior level position, like, a Project Manager or anything above, it was a different deal altogether. You just had to chit-chat with the captain. Your likeliness of getting hired was directly proportional to the positive impression you made in that one rendezvous on the interviewer. I can’t say what questions were usually asked in that discussion, but it would be safe to imagine that they would have been as far removed from the subject of computer software as you could possibly have them so.

About 35 or so people applied. About 35 or so got hired. Roll drums! Ring the bells! Trombones siren! Cymbals clap! The trumpets blow! Party!

Wine was un-bottled and everyone danced and ate lots of muffins, and the world seemed merrier than ever before, a really nice place to live in, a feeling of safety just dawned in, and human life suddenly had so much meaning, and some people probably made love (well, I wouldn’t know), and all that.

Then, the captain went for the killer stroke. He decided to hire a CTO for the company so that he could have someone to talk to. Well, they say it’s a bit dry and lonely up there.

Third party head-hunters were put to work and they came back with a jungle of buzzword-laden résumés. The management must have taken a delight in chatting with the many aspirants that were sent forth by the agencies. The criterion was the number of years of experience and the density of buzzwords. This irrationality probably had its roots in ignorance and wasn’t without a comic aspect.

The tallest guy, literally, was selected. “Behold our new CTO, who stands tall and mighty.” The guy was actually some seven feet tall, no kidding. He claimed to have about sixteen years or more of industry experience and knowledge of virtually every platform and every mainstream programming language that was used on God's own green earth. Amen to that.

“Unburden your technical worries in his care,” we were told. And, holy Beethoven’s for the unfortunate chap that was precisely what happened. With the promise, the programmers, most of whom were rookies, in an expectation to be bolted out, quickly paid frequent visits to the CTO’s “hide-out.”

To stretch an argument for our personal amusement, let us remark that it would only be a slight bit of an exaggeration to assume that the CTO guy didn’t know how many parts a computer had, or if there were other parts than the screen which displayed whatever there was on the computer’s, umm, screen. And there’s one thing they put down, below your desk, near your feet. Or, that could just be to balance the sub-zero air conditioning. It feels nice on days when you wear the floaters. At any rate, I better not move it. It could be one of those -- you know -- parts. Of the. Computer. I mean.

What was that thing about not being able to fool all the people all the time? Yeah, the news eventually reached the captain and they soon bid the CTO a we-love-you-insanely-but-you're-bloody-expensive-and-fucking-useless-you-moron-parting.

As a replacement, though, SSL hired a guy from HCL Technologies who had 16 years of experience. The new hireThis time, the litmus test was that the person had to actually know [sic] all the technologies.

The interview was conducted (guess by who?) and the 16-year experienced veteran passed. He said he knew everything. And he wore a moustache. And he smiled. And he was chubby. Unholy fat. This guy brought in fifteen more of his past acquaintances at stupendously high salaries. Only some of them wore moustaches.

Groups started to form within the company. There were the old employees and the newly appointed acquaintances that had more rights and higher salaries, and soon you had the left wing and the right wing. People from the old group started leaving. At one point, except for a handful of the oldies, the company sized down to just the newbies and some relatives of relatives of relatives of some of the oldies.

The initial capital for the enterprise had come from a US company, who had bought SSL as a fully-owned subsidiary in India. Projects began getting delayed. Work was not up to the mark, quality was pathetic.

One day, the US parent pulled the plug and laid off a battalion, pun intended. “That’ll learn ‘em.”

But what had been already done could not be undone now. It was too late to make good all the work that had been done badly by re-writing from scratch. The enterprise had been time-bombed for the haphazard recruitment it had undertaken. Today, the company is history. Long live SSL!

Moral of the story?

"Hiring is the most important activity in any organization and is the cause for an organization’s success or failure in the long run. Good people hire more good people. Bad people hire more bad people. If you want your organization to succeed, you need to remove bad people just as much as you need to hire good people."

Strangely, though, most organizations do not have a policy of regularly filtering out the dross, so to speak. They should.

About hiring, though, if you are an HR person responsible for the recruitment function in an IT organization, you know how difficult it is to fill a core technical position. You have to keep your résumé databank up-to-date; you have to spot a suitable résumé from the few tens of hundreds of résumés in your databank. And you have to speak to each and every candidate to find out if he or she is on the job market, which is, if they desire to switch jobs, that is, if they are looking for a change, and are willing to interview for the position with your organization.

Most of the times, the candidates on the market don't play easy if they know you are from the HR. Some candidates are even rude because you called them for a skill that they did not have. They expected that you’d have drawn that inference from reading their résumé carefully.

For instance, you call up a C# programmer and start to talk to them, and five minutes into the conversation after you've introduced yourself and the company as being a global world leader in business solutions that empower the customers in the solar system with strategic advantages while eliminating disadvantages that develop and leverage the beverage with synergies between partners, vendors and supply-chain-management thingies and that sort of boiler-plate non-sense that you are supposed to read out of an About Us page, you start to tell the candidate that he's just the kind of candidate that would be ideal for the position because of his stellar expertise in BREW, Symbian and Android.

And if he happens to be a candidate at a senior level, like, say an architect, whatever that means!, you pitch your scale a note or two higher and dish in a nice, cosmetic accent to go with the extra cordial behavior. Alas, it doesn’t end that well!

Or it might have happened that your delivery team asked you to find a senior software engineer with experience in Windows Presentation Foundation and because the poor chap who sent you his résumé in earnest did not mention the magic words WPF or Windows Presentation Foundation on his résumé for the notice of your Reticular Activating System, but instead wrote Silverlight and XAML, you didn't call him up at all.

And, I also understand how tough it is to learn that the candidate whose résumé you sent to the delivery manager, after carefully sifting through three dozen résumés late last night instead of watching TV, does not fit the bill because the delivery manager rejected the candidate based on a résumé scan. Bummer!

You know that this happens all the time at any stage during the recruitment process. You keep sending one résumé after another, and the delivery team rejects them, either during the résumé screen or the telephonic interview or during the in-person interview.

The sweetest part is when you innocently call up a candidate who, it is discovered during the telephonic conversation, already happens to be working for the same company that you already are, asking him if he is looking for a change. It gets even sweeter if the guy had just recently joined.

You can't be expected to read the employer's name on each resume and then call the candidate. That's just too much to ask. And it is not humanly possible either. How many things do you check in a resume before you decide to call the candidate? It is just easier to call and find out, but then you put yourself in an awkward situation and leave no doubts in your colleague's mind -- the mind of the candidate you just called -- about your oversight. And there is always a risk of him or her misjudging that to be your laziness, or even incompetence.

I totally sympathize with you. No matter how sincere you folks in the HR are, you cannot be expected to appreciate the differences in programming platforms, and there's no course that can teach you that.

I would highly recommend this book (that's an Amazon link or, buy from Flipkart), to anyone serious about hiring programmers. Also, I would strongly advise you to read all the articles in the archive of Joel on Software.

But if you are a totally non-technical person, reading all of that material, and then agreeing with all of that given your dearth of experience in programming, and thus the relative lack of empathy towards developers, putting the advise offered in that material to use is, by any means, a long shot. I think the only way to make good judgement in hiring technical people is to be a technician yourself. And in my infinitely humble opinion, the same is true of salesmen in IT.

Given these imperfections that are to be dealt with, in addition, there is an enormous pressure on you to perform. I have seen it. There are targets and deadlines within your departments.

It can also be a challenging task for you and the delivery managers to find a person who will willingly spare time to interview the candidate.

And when you finally have a candidate get through the résumé screening and the phone screen, and some guy in the company agrees to spend extra time in interviewing your candidate, and it all seems like it's going to be just okay this time, the shmuck who is interviewing the candidate plays difficult and happens to just reject each and every candidate you send. And you wonder if he's got a bone to pick with you, or something. Mostly, they don't. They're just being careful not to hire the wrong chap.

In more than one occasion, the interviewer will discover a fair share of false positives. There'll be some candidate who'll have EJB on his résumé, but when probed for an answer to a technical question on EJB's, will confess to having worked on EJB's in 28 BC on a project that lasted one week. A further probe will reveal that the candidate did not actually work on that project, but discussed EJB as an alternative option that they could use in their project, which they did not ultimately use. On being investigated as to the considerations made in order to arrive at the decision, it will be further revealed that the candidate really did not offer any suggestions, but was a passive listener in the meeting where other active participants discussed EJB as an alternative approach. Rare as it may be, it might even be possible that the candidate who started off as bursting with unseasoned and unparalleled erudition at the first glance wasn't even an invitee to the said meeting but simply overheard a discussion in the meeting room near the office pantry where he went to get a refill of his coffee mug.

And did I mention that there's the heat you've got to take from the hiring manager who raised the requirement? I think I did.

And don’t even get me started about the creed of what are commonly addressed by the euphemism of personnel consultants but are really desperate spammers.

And that is where I come in to the rescue. You see, I am a programmer. And I am hardcore. And I can tell the stripes of a tiger from that of a zebra’s. Let me help you and take away all of your trouble. I can do two things for you, one or the other:

I am a developer myself and am passionate about finding other like-minded developers. So, you’ve got only your worries to lose. And if you are a software developer tired of your job, call me.