Four Things To Consider When Hiring A Developer

Things are a lot different today than there were ten years ago. This is especially so in the IT world, and companies need a different type of developer than they used to. So why are they still hiring like it's 2003?

Here are four things that will help you find the right person for the job.

Creativity is not a good thing

For god's sake, can we all stop advertising for programmers who are creative? It used to be that creativity was essential, but that was when the technology was still in its infancy. Today, we have frameworks over top of frameworks. We have APIs. We have jQuery. We have SASS. We have Symfony. We have doctrine. We have open source projects everywhere.

Ten years ago, we needed creative developers because that was our main problem: we need things created.

Not so today. There are few problems left that haven't been solved. That's why a creative developer is the kiss of death. He's more interested in building a novel solution than finding a correct solution. He's less interested in doing the legwork to find an existing solution, understand it, and use it.

A creative developer can lead you down the path of in-house frameworks that do one or two things really well, and do everything else terribly. A creative developer can shackle you to his own creation, and every new hire loses a month trying to learn a new, incomplete, buggy framework that probably has no documentation. And, worst of all, creative developers don't stay in one place very long. When they leave to follow the next Big Shiny Thing, they leave their creation behind, and a team that has to figure out what to do about this monstrosity.

A creative developer is a dangerous developer.

Resourcefulness is the new badge of honour

Don't hire someone who tells you about his ability to design solutions. Hire someone who tells you about his ability to find a solution. For every problem, there is already a solution available online. There are very few widgets that haven't been built. Trust me: every hour spent finding an available widget or module, is three hours spent trying to build it yourself, debug it, and maintain it.
One of the main strengths of a good developer should be his ability to understand the problem, then find a solution for it quickly. Nine times out of ten, the solution is already out there. That's why efficient teams are teams that go to the net.

Google first. Design second.

The more frameworks, the better.

The best developer is one who is comfortable working within an existing set of protocols and procedures. Coders who have spent their time working with an MVC framework are reliable, predictable, and will give you higher quality code.

Their code will be more standardized, which means that it will be easier to test, and easier to maintain. When they leave, if their work is inside an established framework, new hires will be able to understand it better.

When you interview a new developer, make sure they tell you what established frameworks they've used. Make sure they describe how they've used them, which ones they prefer, and which ones they didn't. This question will tell you a lot about whether or not this guy is a team player who works withing established protocols, or a maverick, who would prefer to code it like a cowboy.

Testable code is essential

10 years ago, the main principle of development was GIOTD: Get It Out The Door. There was less QA. There was less automated testing. But today, it should be a different story. There is enough evidence from empirical studies to conclude that code written with unit and functional tests is better than written without.

Developers should have experience with various test frameworks. More important, they should understand why test are written in the first place. They should have an opinion on TDD - Test Driven Development. Whether or not they agree with it, they should be familiar enough with the concept to formulate an opinion.

No comments:

Post a Comment