Help! I Have to Hire!

Now that I’m Señor Web Developer, there’s a good chance I’m going to be blessed with a temporary junior developer to help out with the work tsunami currently breaking on the horizon.  While the final decision will be up to the whole team, it’s going to up to me to decide if the person can do the job.  This will be the first time where I’ve had real responsibility in the hiring of another developer, and I could use your help.  I’d appreciate ny thoughts, warnings, suggestions or ideas you have on the subject.

Specifically, here are some areas I’m thinking about:

  1. What kinds of things would you put on the job description? Anything you’ve found flags better candidates outside of the normal boilerplate?
  2. Suggestions for the phone screen? I’m probably going to use Steve Yegge’s excellent article on it as a guide, but what are your thoughts?
  3. What’s your interview process after the phone screen? Do you have people go through any kind of development tests? If so, what?
  4. What are your red flags? Conversely, what says, “This is a good candidate,” to you?

Your help in keeping me from hiring a train wreck is very appreciated.

This entry was posted in Coding. Bookmark the permalink.

3 Responses to Help! I Have to Hire!

  1. Brennen says:

    So by now I’ve gone through this process filling a dozen or so technical jobs, which still leaves me well in amateur-hour territory. On the other hand, you’ll be looking at a similar class of applicants, and maybe I’ve picked up a couple of things.

    1. I have yet to figure this out. I think specificity is good, in terms of “this is what the job entails”, but not so much in terms of “you must know / have done exactly this to get hired”.

    2 and 3. Yegge’s a smart guy and his points seem sound, although for a junior web position you’re probably going to find that the standard is just short of abominable and depressingly few applicants would come anywhere near passing his phone screen.

    What we’ve done for a while is to straight-up require a code sample before we even get to the phone screen. We publish a git repository and ask that people fork it and show us something they’ve done. This is a pretty big hoop to jump through in some ways. It would have annoyed me if I’d run into it as an applicant before I’d done the hiring thing. That said, it has made a lot of difference, and I won’t hire programmers without something like it if I can possibly help it. First, it weeds out the ones who can’t cope with basic git usage. Second, and more important, it gives them a chance to show you actual work with time to think about how they should present themselves, and without the insane psychological pressures of an interview whiteboard situation. If the code sucks unreasonably, you know all you need to know. If it doesn’t, then you’ve got something to talk to them about.

    (If you see, say, basic SQL injection vulnerabilities from a dude who’s been a working programmer for a couple of years, bounce him with prejudice. If you see the same from someone who’s _just_ starting out and you already expect this to be a position where you do a lot of teaching, well, maybe you see how they respond when you bring it up.)

    Next time I do this, I will have an outline or script for the in-person interview, and it’ll include a basic technical exercise. It’s good to actually watch people think and get a feel for how they interact around problem-solving.

    4. Hiring for entry-level web people specifically, I’m immediately (and so far justifiably) suspicious of those who:

    – Are completely unfamiliar with the command line.

    – Have not developed an affinity for a text editor.

    – Haven’t got at least a very basic mental model of version control.

    – Format or organize code poorly.

    – Run Windows on the desktop and don’t, at least, maintain a VPS or account on some shared hosting environment running a Unix-like OS.

    Those might not be exactly right for the position you’re hiring, but you get the idea. There’s always going to be stuff that signals a basic lack of aptitude or interest.

    In more general terms, fear the person who spends an interview talking shit about their last job(s) or spinning an elaborate victim narrative.

  2. Brennen says:

    Oh yeah. And maybe some things that signal a potential good candidate right off the bat:

    – Published source code or real involvement in an open / community-driven project.

    – Fluency with the command line, the tools approach, and at least one member of the Unix family.

    – Demonstrated competence in more than one language/platform, especially if these differ substantially. (Side notes: Avoid people who _only_ know PHP; demand proof of those who claim to know C, Perl, or JavaScript.)

    – Obvious attention to fit and finish.

    – Literacy.

    – Serious hobbies and interests outside of programming and (electronic) gaming.

    – Experience outside of an academic framework.

  3. saalon says:

    Thanks, Brennen. Really good points that I’ll be incorporating into the process.

    I should have said, re: Yegge’s article, that I’m going to loosely follow it, since I agree that it’s testing a level of competence I’m not expecting to get. Honestly, I wonder if I’d pass that phone screen entirely.

Leave a Reply

Your email address will not be published. Required fields are marked *