

Ask HN: How to identify promising entry-level coders? - billybob

I've seen some discussion here about how few opportunities there are for entry-level coders. From a hiring perspective, it makes sense: how do you know if someone will do well unless they have a record of doing well?<p>I'm curious: if you had a small budget to hire a completely inexperienced coder, and the freedom to train them a bit and give them time to study, how would you identify good candidates? What kinds of tasks might you give them where they could become useful in the first month or two?<p>I'm not talking about CS grads, but someone who's genuinely never coded but is smart and wants to learn.
======
DanielStraight
I saw a line once, "hire for attitude, train for skill." I think this is dead
on. There are people on HN who have picked up coding in 6 months because they
were really committed and really wanted to learn.

I think the ideal candidate will have broad interests and experience, be
passionate about achieving excellence/mastery in their interests, and show
some aptitude at logical thinking.

Ask them what they like to do. If they can talk intelligently about half a
dozen hobbies and show that they've achieved excellence (or at least intently
pursued it) in those fields, then they'll probably be able (and willing) to do
the same thing with programming. If they like to watch TV and play video games
to the exclusion of all creative output, then they probably are of no use to
you.

Ask for references. Talk to the references and ask about what the candidate
has done to impress them. If the reference says they're a good kid and will do
well, that's not much use. If the reference says they once single-handedly
cooked a meal for 150 people in one day, then it probably doesn't matter that
they don't know anything about coding yet. They obviously know how to dedicate
themselves to a task.

Disclaimer: I have never been in a position to hire anyone.

~~~
stcredzero
Basically, there's a spectrum people fit into. On one end, are those who
follow instructions to cover their ass. They fulfill the letter of your
instructions in such a way as to make a good case that they were obedient and
they tried. On the other end are those who are goal-oriented. They interpret
your instructions as a kind of goal, and they fit that goal into the general
aims of the organization they are a part of.

Give people small tasks, but with only general goals and leeway for
initiative. See what they do. The goal-oriented people will get things
accomplished. They may not be exactly the things you pictured, but if they are
smart, you will find the result useful from some perspective. Hire those
people, especially if they already share your perspective.

The problem with references, is often you don't know what end of the spectrum
the referrer is on. Maybe they value lackeys that fulfill the letter of the
request. Smart goal-oriented people who see things your way are much better to
delegate to, IMO.

------
ianterrell
Someone who's never coded is a waste of your time. With the extremely low
barrier to entry for learning through all the free and cheap resources
available, and open source projects to work on, the question is simply: why
haven't you coded?

Make them write a simple project and come back in 2 weeks and present it to
you. That will tell you everything you need to know.

~~~
stcredzero
Give some very precise specifications and leave other instructions incomplete
and let them know explicitly that they have the authority to make decisions on
your behalf. See to what degree they make excuses, vs. get useful work done.

------
sagacity
I have (for the last two decades or so) found that getting a candidate to draw
a couple of flow charts usually 'tells the tale'.

Not that I've not found people who could not draw flow charts at all to later
turn out to be _solid_ assets, but poor flow charters have almost always
turned out to be 'duds'.

(Do I need to rephrase the above paragraph or what?)

~~~
jnorthrop
I see no need to rephrase what you've wrote. I think that's a pretty simple
and clever way to determine how someone solves problems. I'm going to give
that a shot.

My personal philosophy is to hire "aggressive learners." This is type of
person who will get visibly agitated when you do something for them without
explaining what you're doing. Or will spend hours teaching themselves a skill
so that can be more independent. That type of personality seems to learn
quickly, adapt easily to new challenges and will welcome change.

------
BerislavLopac
I would definitely never hire someone who's never coded _at all_. These days
it's trivial to install PHP, or even dabble in some browser Javascript.

~~~
martharotter
Agree. It's hard to imagine someone is going to be a great programmer if
they've never given any hobbyist or intro coding a shot.

~~~
Travis
Are you really suggesting that the majority of people who have not coded have
no shot at becoming a great programmer? What if they're 5 years old?

Then what's the difference between being 5 and being 20?

Seems very elitist to eliminate people based on the fact that they simply
haven't been exposed to a field.

~~~
SHOwnsYou
I think you've missed the point.

The topic outlines the person in question is interviewing for a coding job.

If you come into an office looking for a coding job, but have never attempted
to program before, you have not shown any level of commitment to the job of
being a coder.

~~~
Travis
Gotcha. It's more of a signaling mechanism, rather than a generic way to
identify coders at an early stage.

What do you identify with programming potential outside of a hiring context?
I've been working with my friends to get them programming (it's the single
most valuable skill a person can have in this age). I know that I can help
them most by identifying their positive traits (and just pointing these out
can reinforce those traits). So what do you think I should look for and
"amplify"?

~~~
SHOwnsYou
Before you start trying to get your friends to learn how to program, make sure
they are interested in it first.

I know several people that got into programming, hated it, but stayed involved
anyway solely for the money -- They rarely like their jobs.

With that out of the way, I think the two most important traits are curiousity
and good problem solving skills.

------
gilesc
Independence / self-direction. Searches google / manuals for answers instead
of asking you every few seconds.

~~~
ludicast
This is 100% correct. I have worked with and hired people at both ends of this
spectrum.

And I would even say it matters as much as native talent.

------
Ben_Dean
There was a study in a CS dept. somewhere that had a pretty convincing test. I
can't remember where I saw it or the school, so I'll just try to recount it.

The test was given to students before the first bit of instruction in computer
science (and for the sake of simplicity, let's assume it controlled for those
with previous experience). Basically, students were given a problem set of
code snippets in a non-existent language, and were asked to write what the
code evaluated to, i.e. 34 @@ 14 --> [2], followed by possible answers.

It turned out that the students who performed well in their subsequent CS
courses were not those who got the right answers, or those who got the wrong
answers, but those who answered consistently. The best single predictor of a
good student of CS (not strictly equivalent to a programmer in a startup...)
was forming a consistent model of what they were looking at, and sticking with
it.

------
petervandijck
Attitude (willing to learn, willing to listen but also not afraid to ask
questions and challenge things). Willing to make mistakes quickly and fix them
quickly. Not afraid of feedback.

~~~
stcredzero
_willing to learn, willing to listen_

The latter is quite valuable, and less common than many think. (To listen
really well, you need to be constantly seeking what you don't even know that
you don't know.)

 _also not afraid to ask questions and challenge things_

In a constructive way, if possible.

------
wlievens
> where they could become useful in the first month or two

Actually, it often takes experienced coders several weeks to become truly
useful to a team. I've heard a consulting manager say that only after 6 months
do they charge the full amount for their people.

------
mkrecny
The HN community contains many such candidates. More information about the
opportunity (e.g. location) would be nice to have : p

~~~
vnchr
I don't know why you got downvoted, but I'll say that as someone in this sort
of a position as well, this discussion is very informative about what skills
and character traits I should focus on.

Same for PG's essays. HN is a chance to grasp great hacker/entrepreneur ideals
that I can tune myself to while off of HN.

