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

I've always interpreted "hire slow" as grow the team slowly and only when you really really need to bring on a new person as opposed to having a slow hiring process. Macro vs micro. I think you can certainly hire slow and have someone through the cycle in 1–2 weeks or less (for an early startup).

>- 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.

Be careful about that; said people are no longer at those companies for a reason. Often that reason is innocuous but there are people who slip through their hiring process and get washed out later.

The other thing to know is there's a lot more process at those giant companies, with good reason; "move fast and break things" doesn't work when you're making OSes or globally used search engines. Some people with long tenure there wind up more adept at managing process than the technical stuff.

Engineers at the big 4 get exposed to a lot more opportunities... In today's world if you stayed at the same spot (title/employer) for more than 2 years I'd be asking myself:

- Why you didn't get promoted?

- Are you not landing any job interviews? Because I know you get tones of emails from recruiters

- Are you still learning new things? Do you want to learn new things?

In terms of processes at the big companies, you're looking for smart people... Processes don't tell me if you're smart or not. It's just you dealing with rules like any other human being.

I think the hardest part is getting some kind of hiring flow anyway. Knowing who to contact is the biggest obstacle. But once you've got someone...

First: actually read the resume and letter. Learn about the experience this person has. Unless you're hiring out of a bootcamp, the candidate has worked on something and you should not be walking in blind. (If he or she hasn't articulated it in the resume and letter, then I wouldn't expect to have initiated an meeting.)

I don't use challenges, homework, riddles, quizzes, etc. anymore. Again, we're not starting from scratch. I hear it and wonder, "Do you really think I haven't yet figured out the difference between fifo and lifo?" (Or, "Here's a little, 5-minute challenge. Just a little date math." Oops. Forgot the leap second.)

I focus on problem decomposition. I ask about problems that the person has worked on. I talk about my own systems and have him or her opine on it. We brainstorm. These discussions get into things like:

* What was the situation? Why was it a problem? Was the solution obvious? Was is tricky to intuit, or was it a lot of work to implement?

* What were your constraints? Were they natural or derived? (Perhaps it was a very-low-resource environment, or there was real-time requirement, or it needed resistance to a type of attack, or it required strict regulatory compliance.)

* What was the mental model and how did the individual arrive at it? Did it change during implementation?

This structure has worked for me at most levels of hiring. I can ask a very junior person who, say, writes SQL to generate reports to talk about a particularly challenging report, or one that is particularly elegant. If he says, "I changed the order of operations to get the rows down from 4 quadrillion to 400,000" then I know that, conceptually, he knows about cardinality.

I can ask a director to talk about a project that he ran with a remote team in the same way. If the drop has to happen in sync and you have people in 4 time zones spanning 10 hours, did he wake people up or did he use some kind of technological orchestration?

Also, I think it's worth noting that quite a few very good programmers do not keep very public profiles, so I really don't trust the greenness of a github profile.

>First: actually read the resume and letter. Learn about the experience this person has.

>I don't use challenges, homework, riddles, quizzes, etc. anymore.

Unless you don't get many resumes, I find it hard to believe that this is a good hiring flow for you at all. A lot of people who agree with me will often say that nobody has time to be reading hundreds or thousands of resumes, but I'll take it one step further: unless you are rigorously verifying the information on resumes, resumes are basically useless.

It is way too easy to lie on a resume. I don't mean mere embellishment or exaggeration. I mean straight-up lying. I looked at your profile. You have an impressive resume. What would stop me from copying your resume and submitting it as mine? Your impressive positions would be harder to fake, so I'd just lower all the CTO, head, VP, and chief titles to lower level titles.

Let's take this even further. Let's pretend that you actually call the references for the positions on all the resumes that you read. What's stopping an applicant from giving you a friend's number and having them pretend to be their former manager/employer? One could argue that the same sort of deceit works for challenges, quizzes, etc., but there's the additional barrier of at least knowing a decent enough programmer who can take the challenge or quiz for you.