Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Mon, 23 Jul 2007, Josh Glover wrote:

> Of course. Joel has a interesting and amusing look at his process here:
> http://www.joelonsoftware.com/articles/SortingResumes.html

Though I don't agree with a lot of his other thoughts, Joel is dead on
with this.

> >      2. Ask for code samples, and read them.
> This is a very good idea....

I should mention that this, like a resume, is more a tool for screening
out the obviously bad candidates than finding the good ones. It's rare
you're going to get something large and complex enough that you can see
whether the guy is really good or not (though if you get almost anything
in Haskell, that would be a pretty big plus). But I've been able to rule
candidates that looked good on the resume when I get Java along the
lines of

	Statement statement = null;	// Create Statement object.

It sometimes truly astonishes me how far wrong someone can go in one
incredibly simple line of code. The three big red flags right there (and
there were a couple more if you put it into the context of the entire
file) were enough to get the candidate instantly disqualified.

> I have people write code as part of the interview (and I certainly
> will not stop doing that)....

Actually, I'd be happy to do it in a TDD environment. It's the "keep all
of this in your head" whiteboard style of programming thing that bugs
me; why should I have to do that when a computer can do it for me?

Particularly what I would miss from TDD is, once you've gotten to a
certain point, the ability to chuck all your (non-test) code away and
start again, and know that all of your debugging and testing effort is
still there working away for you. I often find it faster to rewrite
something from scratch a couple of times than to try and keep hacking on
the same piece of code trying to find or fix that one subtle bug.

> ...[the interviews] 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.

Ah, well that I'm confident I do.

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

Well, I get in those situations, too, though fairly rarely. But does
your process start with, "create a test case to demonstrate the bug?"

My general strategy, after I get that done, is often, "hack anything
stupid at all, with or without understanding, that makes all the test
cases pass, and then roll the darn thing out." Truly understanding
why the bug is there, and rewriting all the parts of the system
appropriately, comes at leisure after that.

I guess in my experience, bugs come in two kinds. One is a "silly" bug
with a trivial fix, these sort of "oops, I forgot that" things don't
require much thought or analytical skill at all.

The other kind is an "I misrepresented this system in some key (though
perhaps subtle) way," and those often require a lot of thought and
discussion, and often lead to massive rewrites touching many classes. An
example of this might be the realization that, from the point of view of
your system, the phone number "12345" is two distinct numbers, one that
called Joe last January, and one that calls Bill now.

> >      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.
>
> If you've drunk the XP kool-aid...

Which comes in many yummy flavours!

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

I've done it both ways. And depending on the situation, I
may pick less sensitive source to work on, hack on some open
source stuff, or even just sit down and do the bowling game
<http://c2.com/cgi/wiki?ObjectMentorBowlingGame>.

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

Well, perhaps you should try looking at this from a different point of view.

First of all, you're not signing an NDA to do an interview; the
interview is already done. This coding section would be the final stage
before job acceptance; at this point you're as confident as you can get
(through interviews, checking references, and so on) that the candidate
is the one for you. So the real question here is, "do I hire him now, or
do I do this pair programming afternoon first?"

In that light, the NDA isn't an issue, because if you hired him right
now he'd have to sign that NDA anyway. Nor, for that matter, is spending
an afternoon with the guy, since if you hired him now you'd have to have
someone do that anyway (not to mention a few more days beyond that) in
order to get him up to speed.

So all you're really doing here is all of the same stuff you'd do
if you hired him right away, but delaying the actually hiring by an
afternoon. If the candidate works out, nothing has really changed; in
fact, with any luck, you can get HR to start processing the papers
backdated to the next day so that he can come in the next morning and
continue working. If it doesn't work out, however, you've saved yourself
a bunch of bureaucratic and other hassles by not having to do a whole
hire/termination process for the candidate. (Note, though, that I'd
still have a one month to six week "termination without cause" period in
the employment contract to deal with issues that might take longer to
arise.)

Particularly the way I work, this is also as much to give the candidate
a chance to back out as it is to give me a chance to evaluate him. There
are a lot of smart people out there who've never done serious pair
programming, and they really do need a chance to see what it's like in a
fairly intensive environment. Some people are just not suited to it, and
it's a sad waste on both sides to hire someone who sits there and mopes
for a month before everybody decides to chuck the investment and part
ways.

If I were looking at a really serious investment to bring someone in,
for example, bringing someone to Japan with all of the attendant visa
issues, relocation expenses, etc., I'd think about stretching out this
"interview" process to a week or so.

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