Interviews are useful for filtering out unsuitable candidates, not for finding good hires

I estimate I’ve hired between 50 – 100 programmers over the past ten years. Most of the people I’ve hired I have also worked alongside as their team leader or as their manager.

After ten years of interviewing and hiring I’ve come to a fairly major conclusion about the process: interviews are useful for filtering out unsuitable candidates but interviews do not identify good hires.

Interviews work by weeding out out candidates who are almost certainly not good hires.

This is why as an interviewer it’s important to cover as much ground as you can during an interview, looking for reasons NOT to make an offer.

  • If a candidate can’t code up FizzBuzz during an interview – no hire.
  • If a candidate can’t communicate at the required level – no hire.
  • If a candidate doesn’t have the attitude you’re looking for – no hire.

Similarly, it’s important for candidates to look for reasons to refuse an offer if one is made.

  • If your interviewer is disrespectful – walk away.
  • If the job doesn’t match what you’re looking for – walk away.
  • If the offered terms and conditions are unfair or unreasonable – walk away.

Of course, if you’re desperate, you’re probably going to make (or take) an offer that isn’t a good match, at least (you tell yourself) until you can find a better match at a later time.

I’m not suggesting that interviews are totally useless, just that interviews do not fulfil the common expectation of finding good people to join a team. It’s the other way around; interviews find (and filter out) people who would be bad for a team.

So how and when do you find out if a person is a good match for a team?

The answer is that you find out weeks or months after they join the team. There’s no way to be sure beforehand.

 

 

Posted in Software Management

The one reason for doing a code review

Ask a programmer why they do code review and you’ll get a different answer depending on the phase of the moon. There are lots of good reasons, but there is one killer reason that should be at the top of everyone’s list.

The one reason why code should be reviewed is to improve the quality of that code, and to do so at a time when it is still relatively inexpensive.

This may seem an obvious and redundant thing to say, but depending on the phase of the moon you’ll get one of the following answers;

  • To share code knowledge
  • To share best practice
  • To learn new tricks
  • To enforce a certain coding style

I want to put it on record that every one of these reasons is secondary to improving code quality.

What is code quality? I used to have a Zen-like attitude to quality, believing it too subjective and too ambiguous to be pinned down to a useful definition. These days I’m more pragmatic.

Software quality is its perceived value, depending on who is asking. For an end user, quality means usability and features. For a business owner, quality usually means ROI.

For programmers, software quality should be synonymous with maintainability above all else. Maintainability (it is unfortunate that it’s such an awkward word) means the ease with which a programmer can add or adjust features, and the ease of finding and fixing software bugs.

Related post: What’s wrong with this code, really?

Understanding code maintainability is the key to understanding the code review.

Think about it this way: just about every aspect of software quality can be comprehensively tested by tools or by a user, but assessing the maintainability of a software product is something that can only be done by a programmer. This is why maintainability should be the highest priority in a code review – it’s because no one else can do it except the programmer.

The programmer is the only person who looks at the code, everyone else looks at the product.

 

@KiwiCoder

 

 

 

 

 

Posted in Software Management Tagged with:

UK jobs on careers.stackoverflow.com Jun 2010 to Dec 2012

Posted in Software Management

Difficult bugs

I’ve been working on an interesting chapter of my upcoming book about programmer interviews. The chapter is titled “The usual suspects” and in it I’m writing about some of the difficult bugs programmers will all face, sooner or later. I’ve got some real horror stories, like the time I worked with a team trying to understand why data was going missing from a very sensitive database containing the personal details of families and children.

That bug took about three weeks to fix, partly because the team had very limited access to the database and wasn’t able to reproduce the problem on any other machine. Thankfully the issues were fixed before any real harm was done. One of the many problems uncovered was a nasty race condition which would occasionally save the wrong foreign key in a family record. If you’re familiar with SQL Server, it was because @@IDENTITY was used instead of SCOPE_IDENTITY().

I thought it would be a good idea for this chapter to include some ideas for tackling difficult bugs like this. I don’t think there is a universally applicable algorithm for bug-fixing, just like there is no universal algorithm for writing good code, but in a general sense many bugs can be resolved by

  1. thinking hard about the problem,
  2. coming up with a hypothesis,
  3. testing the hypothesis
  4. studying results, repeating the process

Unfortunately this is quite hard work.

If only there was a magic bullet like the one your non-technical boss secretly believes you’re sitting on.

Cheers,
@KiwiCoder

Posted in Programming, Software Development

Free minutes aren’t. Unlimited data isn’t.

I absolutely love the English language. It’s so wonderfully slippery.

There are hundreds of ways you can say a thing, depending on what effect you want to have. I love that.

But I hate it, too. I hate the way words are hijacked to deceive and to manipulate.

Free minutes (provided you pay).

Unlimited data (subject to fair use).

Problems are in fact opportunities, and Agile means damn near anything you please.

Machiavelli was an amateur clown compared to the marketing gurus of today.

It’s as if the morally degenerate have staged a coup and no one has noticed.

Which brings me to the subject of recruiting-speak.

“This position requires a heavyweight” means you’ll be working with bullies, so you need to be one too.

“We need a middleweight developer” means they actually want a heavyweight, but don’t want to pay that much.

Rockstar or ninja or superstar means they’ve coded themselves into a hole and now need a hero to fly in to the rescue. It could also mean they have no idea what they’re talking about, they just want someone who will get wasted with them on VC funded hallucinogens.

A ground-floor opportunity usually refers to compensation. Exciting opportunities are mostly vapid. Fast-paced means impatient and intolerant of deviation. Self-motivated means no training.

I could go on. I won’t.

Cheers,
@KiwiCoder

Oh, and PS: I’ve started a thing for volunteering as a programmer: SocialCoder.org

Posted in Hiring, Recruiters

A flowchart for hiring programmers

Hiring a programmer is not rocket science.  Notice the flowchart does not necessarily involve recruiting agents.

@KiwiCoder

Posted in Hiring, Recruiters, Software Management

This is why BT should pay me to keep a land-line

@KiwiCoder

Posted in Uncategorized

It’s a great time to be a programmer in the UK (Part 2)

Part one here
@KiwiCoder

Posted in Hiring, Software Management

Why software projects are always late (Part 2)

The list of reasons why software projects finish late is seemingly endless. Here are four more.

The first part of this post is here.

Absent project sponsor

The most sensible thing I’ve ever heard about project management is the vital importance of the project sponsor. This is the person who sets the project agenda, has ultimate power over the project, pays the bills, and the person who should make all the big decisions about budget, time, and scope.

But often the project sponsor is absent or pays scant attention to the project until it is too late. You would think for a project of any importance the sponsor would be over it like a rash. Maybe that happens in small businesses, it almost never happens in large businesses and large projects. Maybe it is simply too scary for the sponsor to stay focused on what must appear at times a chaotic shuffling zombie.

Sometimes, inexplicably, the project sponsor will delegate their executive privilege. Which leads me to my next reason for project failure…

Inappropriate outsourcing

The arguments about when it’s good to outsource software development rage on. On the one hand we have  cost and flexibility, on the other hand we have software quality, process transparency, and effectiveness of communication.

My view is that you should never outsource your brain. The heart might be well replaced by a mechanical beat-box, but the management and production of software development, with all the quirky organic edge cases and reciprocating parts is simply too much.

I realise this is not a popular view, and that the multi-billion dollar industry is evidence that in some sense (though I argue it is a limited and often irrelevant sense) it must be concluded that outsourcing provides measurable benefits.

I would never do it with my own money except in the most limited and routine cases.

Disproportionate emphasis on (what should be) supporting activities

Project manager, salesman, marketer, stakeholder, sponsor, tester, business analyst, systems analyst, line manager, documentation writer, packaging and deployment specialist, infrastructure consultant, user-experience analyst, user representative, programmer.

Suppose you were forced at gunpoint to pick exactly one of these specialists and still produce a software product, which one do you choose?

 

Hint: It’s not the project manager.

The creeping paralysis of technical debt

Technical debt accumulates as shortcuts are rushed into production to meet short-term urgencies. The shortcuts sink into the foundations of the product as new features are piled in on top, and eventually the temporary measures set like neglected broken bones, crooked and ill fitting.

Eventually the cost of maintenance and support exceeds any possible payback and the product is forced into life-support mode or gets replaced.

A sure sign that a product is approaching this point is when every estimate is met with disbelief and scepticism. Do you know any products like that?  I most definitely do.

For every product that reaches this point there is a preceding period of time where development life becomes extremely difficult and project failure is common.

 

 

@KiwiCoder

 

Posted in Software Management

If I code faster it is by copying the code of giants

I’ve never been expert at DIY, but I’ve always been willing to give things a go. I once replaced the floorboards in an Edwardian terraced house. This was memorable because while cutting a board with a circular saw I managed to also slice through a pressurised hot water pipe.

After days spent repairing the damage to the floor, the walls and the ceiling, I signed up for a plumbing course at the local adult-learning centre.

This was a few years ago, but I still remember a few useful tips from the course;

  • Don’t over-tighten anything, ever
  • Especially don’t over-tighten compression fittings
  • Compression rings (olives) are very easy to crush
  • A deformed compression ring will leak water
  • A deformed compression ring is difficult to remove from a soft copper pipe
  • Soft copper pipes are very easily crushed
  • A crushed pipe means starting over again.

Fast forward to yesterday, a different house and a different DIY job – replacing the sacrificial anodes in our hot water cylinder.

The idea is that these anodes corrode in preference to the metal of the cylinder. They must be replaced every year or two to remain effective.

If you leave them in place for three years they will look like this:

The anodes are screwed horizontally into the side of the hot water cylinder, and are removed by unscrewing and pulling them out. The cylinder must be drained first to avoid spilling 200 litres of water onto the floor.

Draining down our particular cylinder is a tedious process that involves releasing a pressure valve, waiting an hour while water trickles out an overflow pipe, then removing the valve and siphoning water out of the hole exposed by removing the valve. (This isn’t normal, there’s something wrong with our in-line scale inhibitor preventing water release)

Removing the valve itself would have been easy except that it was secured by a compression fitting, and the compression ring was firmly wedged into the soft copper pipe…

So picture me; pipes disconnected, 200 litres of water drained, staring in dismay at a compression ring that won’t budge. I don’t want to risk removing it with a hacksaw for fear of cutting the pipe underneath, and the ring is damaged so I don’t want to re-use it. I can’t cut remove a section of pipe since that will make the impossible to reconnect it without more serious work like soldering in a length of extension pipe.

Basically, at that point, I was stuck.

So I did what any other geek would do; I fired up a web browser.

And wow, did I find a fantastic answer to my problem.

These three rings make the job easy and almost risk-free, here’s how:

Inserting a very short piece of pipe into the fitting and then tightening up the nut will move the ring along the pipe. Repeating this with longer bits of pipe will eventually slide the ring off the original pipe. Three bits of pipe of increasing length make the job simple.

Hey presto, the compression ring was removed.

Which brings me to a confession and an epiphany.

First, the epiphany;

It is absolutely OK to copy a solution from the internet. That’s kind of what the internet is for.

And the confession;

I’ve often maligned other programmers for copying code they find on the internet, and in doing so I’ve developed an unbalanced attitude towards sites like codeproject, dzone etc. I’m sorry about that, especially if you’ve been on the receiving end of a sneer.

The reality is that every programmer stands on the shoulders of giants.

 

@KiwiCoder

 

 

Posted in Programming, Software Development

Ed Guiness

I am the author of Ace the Programming Interview, published 2013 by John Wiley and Sons. In 2012 I founded SocialCoder.org, a volunteering organisation for programmers. I have been a professional programmer for more than 20 years, and a hiring manager since 2004.

Ask me anything.