
Ask HN: How do you recognize a great programmer to hire? - cynosurelabs
I&#x27;m planning on hiring a good programmer but I&#x27;m getting trouble choosing the best from my applicants. I&#x27;m a software developer myself but I can&#x27;t recognize a great programmer from a bad one. Any ideas?
======
cellis
One things for sure: don't waste their time with long puzzles and month long
evaluation cycles. Having just gone through the "find a new job" experience, I
can say that the most decisive companies were the biggest. I know they say you
should hire slowly, but I think that rule doesn't work well for finding really
good talent. When very talented people are looking they will be off the market
in 2 seconds. So instead of "hire slow", hire fast and have the backbone to
fire fast.

~~~
tedmiston
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).

~~~
brianwawok
That is my take of hire slow as well.

Although in most cases if the second guy you talk to is perfect, you may still
need to look a bit more to be sure.

------
craigdfrench
In our most recent hiring activity, We asked that the candidates solve an
adapted simple Kata from codewars.com and asked them to choose the language
that they were most comfortable.

By seeing the quality of the work that they did and the test cases that they
wrote up we had a much better idea as to how they work and what they would
produce.

This common Kata experience between the candates gave us much more specific
questions that we could ask about the problem, the solutions, their
challenges, and their triumphs.

Also agree with asking what they do in their spare time... if they tinker...
good, side projects... good.

------
bsvalley
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!

~~~
RandomOpinion
> _\- 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.

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

------
Davidbrcz
I find the following matrix extremely useful for that purpose :
[http://sijinjoseph.com/programmer-competency-
matrix/](http://sijinjoseph.com/programmer-competency-matrix/)

It is not specific to any language and it gives a grade on many many relevant
aspects of everyday programming (IDE, automatic build, framework, data
structure...)

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

------
mattbgates
The important question to ask is: What does he or she do with their free time?
Do they work on side projects? Do they do freelance work? Are they always
interested in learning new things? That will let you know everything you need
to know.

~~~
dragonlord
A fellow programmer(CEO of a startup firm) used the same tricks and got a
great programmer.Some programmers don't want to work and that leads to trouble
for them and the firm.

------
11thEarlOfMar
I recently had a discussion with a very senior developer about a project he'd
been asked to do. It's a 6+ month effort and he's just getting started. The
project is to be delivered to a customer, but the customer has not been
engaged and does not know we are working on it.

I asked the dev how he'd feel if he completed the project and the customer
said, 'Nah, not interested, thanks anyway.'

His response: 'As long as I get a paycheck, who cares.'

Not sure exactly why, but that just doesn't sit well with me.

~~~
dragonlord
It doesn't sit well with me either.

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

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

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

~~~
holyOrIonsBelt
I have to respectfully disagree. The poster above you is not saying that they
don't verify, they say they verify through different means.

They are saying, in my opinion, that it is important to step away from the
S.O.P. because by doing so we gain the clarity of insight from treating them
not as cogs to fill a gear ratio, but as human beings that bring an enormous
range of abilities that, for various reasons, may not communicate unless one
allows them to, hence the example of a root reduction in the db search space.

------
kayman
Examples of past work. Passion. Can they build things themselves or did they
ride the coattails of a large team.

Regardless, hold your developers accountable to results. Manage by output not
man hours.

If within 6 months you don't feel they're a good fit, move on.

------
SQL2219
Look for a super-nerd, the guy who tinkers with code for fun. I have recently
been through a good hire and a bad hire, looking back the difference is now
clear. What the person does on their time off is a good indicator.

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

------
crdoconnor
My process:

* Make them do a task that is both relevant and realistic with respect to what you do.

* Leave 'natural' traps in the task - code problems that have tripped you up in the past and see if the candidate falls into the same trap or spots it.

* Ask the candidate to clean up their code near the end and watch what they do.

------
rurban
Look at the code, nothing else matters

------
leog7
view code on github profile

------
darkdante
Great programmers have: 1.) Positive Attitude 2.) Great communication skills.
3.) Good time management skills. 4.) Quick learning ability 5.) Broad
technical experience 6.) High end user forecast 7.) Team playing skills

------
dragonlord
Hiring great programmers is hard. I have been advised that great programmers
have great ideas. You can also ask questions (open ended) about coding during
the interview.

~~~
richardfrenzy
Even telling the programmer to create a prototype to solve a certain problem
helps a lot. You get to understand the programmer's approach in solving
problems

~~~
sahn44
We've put together several take-home mini projects as Github repos that have
instructions and sample data or a starter template. Candidate clones the repo,
commits frequently, and builds something demonstratable that works or doesn't.
It's structured to be similar to the kind of early real task they would get.
Key is it's open book, they can google and stackoverflow as much as they want.
We can see evolution of thought process in the commits and have a good
discussion in followup conversation. We do this after they have passed a phone
screen or onsite interview and we are interested. So far, we like the results.

