How to Hire a Programmer

The best programmers:

• Understand core computer science principles

• Ask lots of questions

• Actually like to develop software, so ask your candidate what he or she is developing after work hours!

• Create simple, elegant solutions for complex problems

• Keep up to date by training online or reading programming books

• Test as they write code, finish early with few bugs, and then help others finish their tasks

• Make their managers look good by doing whatever is needed

• Challenge opinions but embrace the right decisions

• Make a profit for your company

Qualities of an outstanding contract programmer
An outstanding contractor jumps in, keeps track of his or her time, keeps you up to date daily, asks questions when needed, sends you screen shots with questions, and delivers a product you can release.

Jean Tantra is an example of an outstanding Macintosh or iPhone programmer.

What percentage of programmers are exceptional?
Most programmers aren't very good. Many arrive at work, put in their time and expect to be paid high salaries. Others speak confidently but rarely produce. While the average programmer writes just 5-6 lines of code a day, the best can consistently write several hundred.

I'd estimate that 10% of programmers are worth considering. Only about 1% are exceptional. The rest will probably make a mess of your code.

Exceptional teams rarely use external recruiters
Exceptional teams have little trouble attracting talent. Why? Because they are often based near universities and spin-off software companies where programmers know each other and their reputations.

Programmers with five years of experience out of school can't understand why anyone without the same experience could be as good as they are. Then since they have difficulty attracting and hiring good talent, they hire recruiters.

Whenever I am contacted by an external recruiter, I know the odds are I am wasting my time.

Years of experience with specific technologies doesn't make a good programmer
Do you hire doctors differently than programmers? Think about it—suppose you were diagnosed with streptococcus group G. Would you ask your doctor how many years of experience he has curing it? What if he had ten years curing groups A-F but only two years treating group G? Do you move on and thank him for his time?

Five years in ASP.NET doesn't make a bad or marginal programmer good, just as fifty years of being a bad or marginal painter doesn't make a master artist.

More thoughts on hiring programmers (this section needs editing)

1. A talented programmers' ability to hire top talent is about as probable as winning the lottery. Why? Because exceptional programmers just expect other people to be exceptional too.

   Once a talented programmer realizes he or she sucks at hiring, rather than correct the mistake they often turn the task over to non programmers who continue gambling.

2. Don't judge a programmer by his or her resume. Most can't write well. If the resume looks too good, somebody else probably rewrote it. If it looks at all like a fit, request an interview. Judging programmers by their resume is about as accurate as tasting food with your nose closed.

3. The first interview question should be, "Tell us about or show us projects you are working on after work." This question tests for passion. There will be those who for family reasons cannot study or code after hours, but you'll find that most if not all top programmers have ideas of their own and are actively developing something on their own.

4. Gaps in a programmer's resume should not be treated with suspicion, but welcomed. It may indicate they had a vacation.

5. Like Einstein, good programmers don't memorize facts they can quickly look up.

6. Once a programmer is fluent in six languages, additional languages are learned quickly. To them it is just syntax

7. For an educated, intelligent programmer, the time to write code, figure out a new technology, class or method is irrelevant compared to the time it takes to do something right.

8. Because the cost of software development increases exponentially during the software life cycle, it is better to hire a programmer who spends more time up front to produce and test quality code. Those who do will be the first to complete their tasks and help others.

9. Ask if their last manager used agile development and if so why. Agile development is often used as early detection of bad code or programmers.

10. Ask to list and prioritize what makes good code. The first answer on the list should be, "Does it work?"

11. Brain teasers for programmers isn't the best way to test for intelligence. It is better to get candidates to discuss in detail how they solved recent, difficult problems. That will give you a window into their approach and thinking process.

12. References are good, but references of references are better.

13. Once hired, many programmers will assume their duty is to show up to work and the employer's duty is to pay them. Others will look very busy but produce little. By contacting references of references, you can detect such people before extending an offer.

14. When it boils down to it, every programmer must produce a direct or in-direct return on investment for the employer. This must be stated and discussed up front.

15. For most programmers, the best performance incentive is peer recognition and a pat on the back from management, for without them contractual monetary incentives rarely make loyal, over achievers. But in good times if you don't provide them with golden handcuffs, you may find yourself interviewing again.

16. Don't ask interviewing programmers questions about how to solve the problems you are stuck on. That's called consulting, and if you do not pay for it then it is called stealing.

17. Most exceptional programmers are exceptional at something else--usually a one-person sport.

18. The smartest programmers are funny or are outstanding musicians. It takes brains to be funny and persistance to play an instrument.

19. Programmers who are not funny are rarely admired for their comments. They don't write any.

Why asking programmers to take a test is not only insulating but counter productive

• Smart people know there is a lot they do not know. For example, ask a PhD if they are smart.

• Smart people retain concepts, not details they can look up in a book or online. Their brains work exactly the way they were designed to work.

• People or companies that require programming tests before an interview really do not understand how to test for intelligence.

• Spending time on stupid tests before in-person interviews is usually a waste of time, and even if one gets it right it rarely results in a follow-up interview of substance.

• People and companies who truly understand software creation and maintenance realize that finding high-quality people is essential to short- and long-term success. "A" people hire "A" and "B" people, and unfortunately "B" people hire "B" and "C" people who make up the majority of companies, and such people create stupid tests.

• Stupid tests rarely ascertain one's ability to solve a difficult problem, finish an assignment, perform quality work, or predict future return on investment.

• If any smart high school student can learn what is required to pass a test then how do you differentiate them from a true, seasoned professional?

• If it takes certifications and tests to become a hairdresser but neither to become a Congressman, Senator or even the President of the United States, where does the programmer position fit in?

• Do you require your doctor to take stupid tests? Or do you find other ways to ascertain that he or she has the problem solving skills required to serve your needs?

Mr. Stevens began programming in 1981, has developed software almost daily since 1983, has debugged the code of hundreds of programmers, and has hired many from his own profits.