Re: [tlug] [OT] Good IT Resume

["Josh Glover" <jmglov@example.com>]

On 23/07/07, Curt Sampson <cjs@example.com> wrote:

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

Yes, I could not agree with you more. Companies are like people; they
have egos, and they like to see that you are interested enough in them
to find out all sorts of things about them.

I applied for a different job at Amazon (which I did not get) before I
got my first one, and during the interviews for the second position,
one of the HR people was very pleased to see that I was back. "So
you're interested in working for us, it would appear."

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

Well, you are slightly misunderstanding what I said, but...

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

Agreed. All of my advice was intended to help people past the original
CV screen and into at least a phone screen, if not an in-person
interview. Once you get in the room with me, I don't give a damn about
what was written on your CV, other than giving me an idea of which
direction to steer the questioning and giving you a quick quiz on
several of the subjects you claim to know well (like I said, liars are
right out).

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

Of course. Joel has a interesting and amusing look at his process here:

http://www.joelonsoftware.com/articles/SortingResumes.html

>      2. Ask for code samples, and read them.

This is a very good idea, and I wonder why I had not thought of that
before. I have people write code as part of the interview (and I
certainly will not stop doing that), but having a nice sample or two
before the interview would be quite helpful indeed. And if the
candidate could not come up with any samples for me, that would raise
red flags. "But all of my code is copyright of my employer!" "What,
you've not written a single shell script or little utility to scratch
a personal itch? Next candidate, please..."

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

Well said. People who write code "for the compiler" are missing the
point. Optimise for programmer time--both in the original writing and
the maintenance cycle--which is expensive, not machine time, which is
cheap and getting cheaper every second.

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

I actually find it hard to get a handle on whether a candidate would
be a good fit or not in less than an hour. I try to shoot for 60-75
minutes, and have been known to take one out to 90 if I am really
interested in what the guy or gal has to say.

I have interviewed at both Amazon and Google, and have conducted
interviews for Amazon. I think you are slightly misrepresenting the
interview style; they are designed to make you sweat, but we don't
really care that your answers are correct, we care that you display a
robust analytical process under pressure.

I cannot speak for Google, but when we have a high-impact bug in our
retail website code at Amazon, we are literally losing millions of
dollars an hour in sales. So the pressure to get a solution right can
be quite intense, and it is important to hire people who can not only
cope with that pressure, but excel in the face of it.

YMMV, but I think for Amazon and Google, "get the details of this
algorithm right (enough) in the next 15 minutes" *is* a fairly
realistic simulation of how the work environment can get.

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

If you've drunk the XP kool-aid, this sounds like a very good way to
evaluate a candidate. Even if you haven't, it could be very useful to
have the candidate shadow you and get his input on real issues you run
into.

Do you require your candidates to sign NDAs? Or is all of your code Open Source?

This would never work at Amazon or Google, for two reasons:
1. We have enough candidates that this would be a serious time sink,
even if it were the last stage in the interview process. For example,
my team currently has six open positions (in Seattle, sorry
guys--unless someone wants to move to the US), and if I had to find
six or more afternoons to work with a candidate like this, I'd never
meet any of my deadlines.
2. Our code is quite proprietary, meaning we would have to get
iron-clad NDAs from candidates, which no-one in their right mind would
sign. I personally say "thanks, but no thanks" to any employer that
makes signing an NDA a term of interviewing there.

However, this sounds like a great idea for a smaller company, and when
I start my software company One of These Days, I shall surely steal it
from you. :)

--
Cheers,
Josh