

Ask HN: Requesting code sample from potential employer? - bwh2

Employers frequently request code samples from candidates during the interview process. It seems reasonable that candidates should be able to do the same and request a code sample from the company.<p>Does anyone have experience regarding this type of request?
======
ShabbyDoo
Many times, I have been shown architectural diagrams that painted pretty
pictures of what turned out to be disastrous codebases. In retrospect, there
were other, non-technical "smells" that indicated that the sausage might not
be so well made -- dumb developers, vague managers, production broken-ness,
etc.

I've seen a lot of Java codebases over the past decade, ranging from good to
awful. To get a feel for the overall quality, I've learned to check out some
common things that are usually indicative of overall quality. For example, bad
developers never seem to understand exception handling. Database connection
management is another easy spot to check out -- letting the pool close up
one's connections seems to be a favorite pastime. Other stuff that's not
necessarily Java specific -- use of custom frameworks that, according to the
developers' own descriptions, are replicas of existing stuff.

Perhaps, as @hga pointed out here, sitting at a terminal with an experienced
developer and insisting that he/she show you the stuff you want to see (as
opposed to a passive, guided tour) would be a quick way to gauge overall
quality. And, you'd get a pretty good idea of management's notion of
"experienced developer."

~~~
bwh2
The active approach would definitely require some tact, but definitely seems
like it would be more informative. Plus, you're right about the added benefit
of understanding what management considers to be an experienced developer.

------
hga
Good idea! And for the right company, they'll be impressed that you're doing
your due diligence on them.

I haven't done exactly this (hey, I made some of my best (but most painful
money) working on wretched code bases), but I've done this sort of thing when
helping my company decide whether to partner with another.

If you've got enough experience looking at code bases, you could ask them to
let you at a terminal with one of their experienced engineers at your side. 15
minutes of that could convince me the code base was worth dealing with
(obviously, it can take considerably less time if not :-).

------
mahmud
You do that as a contractor, when you're asked to give a fixed quote for a
maintenance job.

For full time positions, it's reasonable to inquire about the engineering
practices of the shop, code guidelines and similar, what freedoms you have to
make spot decisions, etc. But asking for actual code is just silly. It does
nothing but paint you as a picky cry-baby who couldn't work with others, or
cajole them into working with him (IOW, you lack both a cooperative spirit,
and leadership.)

~~~
bwh2
Hmm. I guess I don't understand why it's reasonable for a contractor to ask
for a code sample, but not a full-time candidate.

I definitely agree that asking for a code sample could make the candidate
appear uncooperative, obnoxious, etc., particularly because it's unexpected.
What if instead of asking for a code sample, the candidate more casually asked
if one of the engineers could show him around the code base for 5-10 minutes?
Would that make it more acceptable?

~~~
hga
EDIT after rereading what I was commenting on: Full timers are frequently
expected to do infinite tasks in highly finite time, so your point holds ^_^.

I don't like the "show him around" idea since it's subject to cherry picking,
but it could be an acceptable alternative if they're obsessed with secrecy
(which 95+% of the time is bogus and a bad sign you should take into account).

You can mitigate the issues brought up by making looking at the code base just
one of all the things you ask about, like process. Hmmm, didn't Joel S. or
someone else write up a short essay on the 5 or so things you _really_ want to
check before accepting a job? They ranged from using SCM to doing after
project analysis.

I might add that one of the things _I_ always ask is what are the finances
like. If they're at death's door I might work for them (have before :-), but I
want to know ahead of time.

~~~
bwh2
Right, I've been thinking about this as an extension to the Joel Test
(<http://www.joelonsoftware.com/articles/fog0000000043.html>).

Good point on asking about finances.

~~~
hga
Yeah, the Joel test [1] is _very_ good, but I confounded it with another that
includes, I think at the end, "after action" analysis of projects. It's not
ideal to be in a company that doesn't learn from its mistakes and inevitably
forgets how to do things right....

[1] I thought most of it was "obvious", but #5, "Do you fix bugs before
writing new code?" wasn't something I'd explicitly realized the critical
importance of. Heh, notice the beginning of it starts with an after action
project analysis.

Hmmm, I just reviewed the list, some time after I read the comments to Mini-
Microsoft's posting on why Vista development failed so badly, and I can see
where Microsoft stopped doing too many of things that Joel said they were all
doing back in 2000.

This is not the place to get into a long essay on that, but by my count:

5\. Do you fix bugs before writing new code? (Similar sort of failure, e.g. a
lot of bugs were officially closed when they weren't really fixed.)

7\. Do you have a spec? (Joel wrote an essay on how it took N people one year
to mis-design the Vista logout? feature.)

9\. Do you use the best tools money can buy? (Developers had to spend at least
one day a week keeping their Vista machines up to date. And the development
process (which is a tool of sorts, think of turning a crank on the side of a
box to push through something) was so bad, so convoluted, so difficult to push
things through, that developers spent a whole lot less time on coding et. al.
than they should have.)

10\. Do you have testers? (RIFFed in favor of "automation" that seldom
happened. They also abandoned the Raymond Chen backwards compatibility "cult"
and that whole function and its people.)

One bottom line is that I'm still amazed at how under resourced such a vital
project was (Vista, the restart from the Windows Server code base after the
.NET Longhorn attempt was canceled).

