Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

I've been on both sides of the resume game for a long time now; in
particular I've been hiring (and either making final decisions or very
closely involved in them) about ten years out of the last thirteen or so.

As far as I can tell, the best thing you can do, if you're looking for a
job with any particular company, is to find out as much as you can about
that company, the department you want to work in, and the people you'll
be working with. What everybody wants to see appears to be different,
even for similar positions. As an example, I expect that Josh and I
are trying to hire similar people for similar positions, but I find
work experience (and work-related experience outside work) far more
interesting than he does; what skills (buzzwords?) you allegedly have
and your education interest me not very much at all. In the end, to me,
the resume just isn't that important: the only purpose of it is to get
through any layers between the submitter and me, and after that, not
ring any alarm bells that say I'd be wasting your time and mine reading
a code sample or doing an interview.

If it's any help, my hiring process for programmers these days goes
along these lines:

    1. Read resumes. Chuck out any that are obviously not a match for
    the job.

    2. Ask for code samples, and read them. For me, code is as much
    about communicating efficiently with other programmers as it is
    about making a computer do something. (For any task, there are many
    more possible pieces of code that get the job done than there are
    pieces of code that make it clear what the heck it's doing and why.)

    3. Interviews. These are generally 30-45 minutes long, and both
    let me both fill in all of the details that I didn't get from
    the resume and get a sense of how the candidate thinks. They're
    not generally designed to make you sweat (unlike, say, Amazon or
    Google interviews). Perhaps this is because I like to work out
    hard problems under relaxed conditions, and do lots of interactive
    testing, and so a "get the details of this algorithm right in the
    next 15 minutes" situation just doesn't seem any sort of realistic
    simulation of a work environment to me.

    4. Pair programming. Each candidate comes in for an afternoon, I
    pair up with him, and we spend the afternoon working together on our
    production code. This gives me a far better indication than any of
    the above about how a candidate is likely to work out.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com