Notes to self

Not gold alone brought us hither

Sep 24, 2010


Just because there is something we need to do, and there is something else that we can measure, we should not start to think that the thing we can measure will tell us what we need to do.

School Testing by Ian Lance Taylor

Sep 21, 2010

Hiring: the best candidate v/s good enough

In a manager’s life, hiring and [depending on which part of the world you live in,] firing are necessary evils. You never quite enjoy doing any of these, but you have to do it anyway. Firing is always difficult, irrespective of whether it is driven by business reasons or by performance reasons. But hiring can be difficult too especially if you are doing it a lot because it tends to quickly become mundane and boring after you have spoken to a few candidates. You reach a point where you are spending more time analyzing and comparing candidates while you should be spending time comparing, analyzing and prioritizing new features or triaging defects. You are eager to close the hiring because your business is waiting for you to fill up the open position else the budget will go away, or because your team is desperate to have this new engineer to do a job that nobody on the team wants to do. In any case, there is tremendous pressure to close the hiring and to do it in a way that you will not regret down the road. There are two different approaches to choose from that will guide you through the process:

Hire the best candidate (sounds good!)

What do you do if the first candidate you interviewed is good enough? If you are like most managers, you will not stop there because doing so will look (to you and to others around you) like you took the easy way out. What if this candidate does not turn out to be the star you had hoped for? So you continue to talk to more candidates until you think you have spoken to enough of them to make a good hiring decision. That, I call, hiring the best candidate. You select the best of the lot. It feels right because no one can blame you for not screening enough candidates. You were thorough and hence would have made the best possible choice. You hired the best candidate. Sounds good!

Hire the good enough candidate (sounds awful!)

The other approach to hiring is to go for a candidate that is good enough. Not the best, but just good enough. You start the hiring process with a very clear picture of what you are looking for and once you find a candidate that fits the bill, including having the right attitude which is necessary for his long term success in a team setting, you go for that candidate. In this approach, it is never too soon or too late to make the hiring decision. If the first candidate you talk to fits the bill, you call it done and go for that candidate. On the other extreme, if you do not find a good fit even after you have spent enough time talking to an array of candidates, you don’t give in to the temptation of hiring the best among the sample that you interviewed. It’s ok to end up saying that you do not want to hire at this time because you did not find a suitable candidate! Go back and reevaluate if you really need this position to be filled externally. There can be many options including training and ramping up an internal candidate for this position while you hire to replace that internal candidate. Now you can start the search with a new job description which may help make your search more fruitful this time around. Bottom line – hire a good enough candidate. Sounds awful.

A matter of choice

I tend to lean towards the second approach as far as I can, but the way most modern day corporations are structured, that is usually not an option. When a a position is opened for hiring, the expectation is to fill that position within a predetermined duration (typically between 1 and 2 months). This almost always forces the hiring manager to take the first approach, i.e. hire the best candidate. Remember — the best may not be good enough.

Sep 19, 2010

Code formatting

One interesting detail about Google’s new programming language Go is the code formatting tool called gofmt that is bundled right into the Go developer kit. It shows the extent to which the creators of the language care about code formatting. Programmers who are not bothered by poor code formatting will find this tool unnecessary, but most programmers are likely to be bothered by lack of good formatting.

Most programming languages, especially the popular ones, do have utilities that help format code, but it is rare to see this being part of the developer kit from the creators of the language. This could well be a new trend that we will see in the languages of the future. This will also reduce the overhead of sweating over formatting rules in a programming team’s coding guidelines.

The only downside of standardizing formatting rules for a language is: it will now be hard to judge a programmer’s maturity by just looking at their code. I know you are saying ‘but thats no way to judge a programmer!’ I agree, but it is also hard to ignore it entirely.