Ask HN: How to identify promising entry-level coders? | Hacker News Reader

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

20 pointsbillybob22 comments

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?

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?

I'm not talking about CS grads, but someone who's genuinely never coded but is smart and wants to learn.

View on HN

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.

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.

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.

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.

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?)

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.

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.

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.

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.

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.

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"?

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.

"Then what's the difference between being 5 and being 20?" -> you're not hiring a 5-year old. If you're old enough to hire you, you're old enough to have done some programming. Why would you hire someone who hasn't??

Right, SHOwnsYou pointed that out. I missed that the original context was hiring, and inserted the context that's relevant to me (my current situation).

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

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.

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.

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.

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.

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

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

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.

Reply on news.ycombinator.com