Ask HN: How do you recognize a great programmer to hire?

My idea of a great programmer (non-founder) is one who can execute and deliver the product that his employer wants, which is what the employer thinks is what the customer wants. Let me provide the reverse perspective as a programmer. If I'm a great programmer and you've paid me for my skills as a programmer, the I'm going to trust that you know what you want me to build. Programmers don't have time nor should care to talk to customers unless I'm a founder. In my opinion, it's the employers job to mitigate the risk of the customer not buying the final product. Sure, the 'who cares' attitude doesn't feel right but If you ask all our applicants that question you're just separating them between those who know to lie to get the paycheck and those who are just honest about wanting the same paycheck.

Do what most of the Software companies do. In order to filter the top %1, look if:

- the applicant worked for one of the big four (Google, Apple, FB, Microsoft). If these companies gave the applicant a GO at some point, maybe you should too.

- the applicant is self-driven and develop non-work related software. Side projects, etc.

- the applicant brings new skills on top of your requirements (e.g. design, other industries, mobile, etc.)

- last but not least, you should value the experience a lot. Someone who worked 5-10 years on a bunch of different projects will save you a lot of time and money. You could have a genius/fresh out of college, if something goes wrong or requires certain skills they don't teach you at school, the lack of experience will drag you down. Don't hesitate to pay a premium up front and save money in a long run.

Good luck!

view code on github profile

Pick the top X programmers and pay them to perform a small but real job that's characteristic of your company in a serial fashion. If the first programmer does a good job, there's no need to bother with the rest. Sometimes the best programmer on paper isn't the best programmer for your company.

Ask them for a solution to a problem. Tell them you want the solution using best practices and with all of the bells and whistles. They should be able to do this. Then tell them the optimize the solution for:

- development time

- execution time

- memory constraints

A good programmer should be able to respond to changing needs. They should be able to see the best solution for the current situation. They know what technical debt they are incurring and should identify it in their solution.

Also, if this is a small team then personality should play a large part in your decision. One person can really ruin a productive team. Does the person respond to your feedback well? Where do they show cracks in their facade? Do they explain themselves clearly? Can they think in the abstract or do they always speak in terms of their domain? Will you be able to give them high level directives or will you have to talk them through line level code? Can they do things the way you do things or do they have to change the world when they are out of their comfort zone? Do they feel a desire to throw code out when they don't understand it or can they work with existing code? Do they use phrases like "it's broken" or other catch all phrases that indicate they don't understand something and are unwilling to learn it? Do they ask for clarification or do they make assumptions and quietly go down the wrong path? When they do ask for clarification, is it at a level consistent with their title and experience? I can go on, but I might save it for a blog post. I have learned a lot from having to staff and lead a team and the above have been some of the points that have distinguished the producers from the consumers.

Cheers and choose wisely.