
Some tidbits from Joel Spolsky's talk last night on recruiting programmers - frederickcook
http://cdixon.posterous.com/some-tidbits-from-joel-spolskys-talk-last-nig
======
edw519
_Joel is super strong advocate of : 1) private offices for each programmer, 2)
free, nicely catered lunch every day (everyone eats together and bonds), 3)
usual internet stuff - comfortable office, dogs, flexible schedules etc._

On one hand, a little voice inside of me cries, "Yes! This is what it takes to
produce great software: a programmer-appreciative environment."

On the other hand, another little voice claims, "This stuff is all well and
good, but nothing more. It's cosmetic, not functional, like putting perfume on
a pig."

I have been in many situations with Class A office space, private offices,
catered team-building breakfasts and lunches, etc., etc., etc. and was ready
to jump out the window. Why? Because the work sucked and all the window
dressing in the world wasn't going to change that.

Then I think back to some of my most favorite projects and remember the great
work that we did. Sometimes in squalor-like conditions, sharing cubicles or
tables, sitting in the server room with too much air conditioning or in the
warehouse without enough, eating vending machine garbage and drinking old
coffee because that was all there was.

Bottom line? The _work itself_ is 100 times more important than the working
conditions. Sure, everything being equal, I'd rather have nicer digs. But
everything not being equal, I'll choose the better project every time, no
matter what the environment is like.

I suspect Joel gives the programming environment more credit than it deserves.
His people are probably happy, and the office helps. But the real reason is
the work itself, and they'd be almost as happy no matter what the office was
like.

~~~
nickelplate
"But everything not being equal, I'll choose the better project every time, no
matter what the environment is like."

Really? Don't get me wrong, I largely agree with the spirit of your post,
but... there are some real shitholes out there. At one job my chair was so bad
that I could barely move at the end of the day. I had to exercise more often
than usual to ease the back pain. The office was often dirty because the owner
was too cheap and would only send a cleaner when he really had to. I don't
care if you're working on an OS kernel or movie special effects, doing
something you love should not come at the expense of your health or personal
hygiene. Now I don't particularly care for free lunches or private offices (I
prefer shared offices myself, with 3 or 4 developers per office). But the
reason Joel's message resonates strongly with so many people is precisely
because most developers work in conditions few professionals would put up
with. Even in software companies where software is (or should be) a profit
center, the accountants, office administrators, etc. often work under much
better conditions than the developers.

------
agentultra
_Screening process: Resume screen, phone screen, web based Etherpad code test,
then fly/bus in and day of interviews and whiteboard code test._

As a programmer currently looking for work, I find this screening process to
be draconian and insulting.

I cannot vouch for it's efficacy as I've never used it when hiring people.

However, the problem I have with it is the rigidity with which I've seen it
enforced. I've a number of open-source projects that I've started and
contribute to and a plethora of code examples I can send upon request. I like
to think of it as a portfolio of code. I've sent links to these projects and
made sure the recruiter knew that I could provide further code samples as
required. Yet each time I walk into the interview, the interviewer hasn't read
a single line of my code and hands me a dry erase marker. I then get the sense
that I'm just another number and they could hardly care about who I am or what
I do.

I don't know what writing code on a whiteboard is supposed to show the
interviewer. The person they're interviewing is not in the normal state of
mind they are in when they're doing they're job. What good is a pressure test
other than to keep very good, capable people out of your organization?

Certainly a production artist wouldn't walk into an interview with a portfolio
and be asked to draw a puppy. The gall of the interviewer would force the
artist to walk out unless they're especially desperate. The same is true for
programmers, IMO. If a candidate sends you code to read, take the time to read
it before you interview them. Otherwise why should they even bother
sacrificing their time on this Earth to your benefit if you won't even
consider their work and effort?

~~~
edw519
_As a programmer currently looking for work, I find this screening process to
be draconian and insulting._

As a hiring manager, I look for someone who _gets things done_. No surprise
that this takes many things: knowledge, skill, smarts, creativity, experience,
team work, and maybe most important: attitude. You have just self-identified
your bad attitude. If you think this is "draconian and insulting", just wait
until your knee deep in digital shit with customers barking at you all day
long.

 _I cannot vouch for it's efficacy as I've never used it when hiring people._

I can. Nothing works better. Period. If I have 30 to 60 minutes to find out
how well you'll perform, I'll have you code and teach me what you've done. I
don't care what you've done before, your state of mind, or even if your code
ever runs or compiles. If you're any good at all, I'll find out. If you're a
poser, I'll find that out, too. And if you don't want to play along, then
either you're a poser avoiding exposure or a prima donna who is saving me a
lot of suffering down the road.

I'm not trying to insult you, just give an honest answer to your (very good)
question. This comes up so often, I've responded to it before. A little more
light shed here:

<http://news.ycombinator.com/item?id=89669>

<http://news.ycombinator.com/item?id=834513>

<http://news.ycombinator.com/item?id=835092>

~~~
agentultra
Thank you for the honest reply. I was hoping someone who uses these techniques
in their hiring process would explain what they find so useful about it.

I've hired many programmers before myself and I've never used such a rigorous
process. I'm just curious why it has become so popular, There's got to be a
reason, right?

 _You have just self-identified your bad attitude. If you think this is
"draconian and insulting", just wait until your knee deep in digital shit with
customers barking at you all day long._

Actually my bad attitude has left me with a list of references from customers
and managers who'd be happy to tell you that they've been satisfied with my
work. Some of them are my best evangelists.

What I find insulting is ignorance. In my original comment I mention that it's
the rigidity with which the process is enforced which is insulting. I think
it's ignorant of the interviewer to not bother reading a candidates' source
code when they offer it (the same for their website, etc). You validate that
by saying that it doesn't matter what code a candidate has written prior to
the interview. That is exactly the ignorance I have a problem with.

I suspect that if the goal of this process is to understand what a person's
attitude, knowledge, skills and such are really like then reading their source
code and blog posts would be the first step in getting to know them.

 _I don't care what you've done before, your state of mind, or even if your
code ever runs or compiles. If you're any good at all, I'll find out. If
you're a poser, I'll find that out, too. And if you don't want to play along,
then either you're a poser avoiding exposure or a prima donna who is saving me
a lot of suffering down the road._

I find that reading someone's commit history in a project can be very
illuminating. The logs alone can give you a sense of their commitment to a
project, what kind of work they prefer, and even a cursory glance at their
skill level (are they fixing small bugs, introducing bugs, reverting a lot?).
If you have time to sit down and read a few patches you can certainly see how
well they follow coding conventions, whether they understand control and data
structures, and perhaps even algorithms if that's what you're looking for. You
can learn a lot from the code a person writes.

What I was having a hard time understanding is what kind of things can white-
board (or pencil and paper) problems tell you. After reading your other
comments, I think I have an idea. You want to know if they can talk freely
about time vs space constraints, optimization, basic control structures, and
data structures. You want to know if they know the fundamentals. I can
appreciate that.

What I still don't understand about your process is how the candidates'
previous code contributions and experiences do not matter. Can you not get the
answers you seek from reading their code? If it wasn't just Joe Programmer but
Larry Wall or Peter Norvig, would that change your opinion?

I just don't think it's a universally applicable tool, but I find many
companies that seem to think it is the _only_ way to screen candidates. I
think that some flexibility is necessary because you're dealing with human
beings. The hiring process isn't an exact science IMO. Just like Agile isn't
the ONE TRUE WAY to develop software I don't think you'll find a single
process that will find you the best employees.

~~~
berntb
>>I've never used such a rigorous process. I'm just curious why it has become
so popular, There's got to be a reason, right?

I _think_ the feature is the speed and standardization of the screening
process -- the code writing on line probably clears out a lot of incompetents.
(Trivial parallels with CPU instruction queues etc inserted here.)

>>how the candidates' previous code contributions and experiences do not
matter.

They'll look at open source contributions in a later phase, or they are
idiots.

>>my bad attitude

There is nothing wrong with your attitude -- that was way out of line. Don't
work for people who doesn't like if you ask questions. (And don't judge the GP
as an idiot either, he made some good points but might have had to explain
some simple things once too often. :-)

Disclaimer: I'm not an expert or even a good amateur at the hiring process.

------
RiderOfGiraffes
I'm not alone in picking up on this:

    
    
      > private offices for each programmer,
    

I refer readers to the comments made by Richard Hamming, quoted here by PG :
<http://www.paulgraham.com/hamming.html> : about shutting oneself away:

    
    
      > I notice that if you have the door to your office
      > closed, you get more work done today and tomorrow,
      > and you are more productive than most. But 10 years
      > later somehow you don't know quite know what problems
      > are worth working on; all the hard work you do is
      > sort of tangential in importance.
      >
      > He who works with the door open gets all kinds of
      > interruptions, but he also occasionally gets clues
      > as to what the world is and what might be important.
      > ... there is a pretty good correlation between those
      > who work with the doors open and those who ultimately
      > do important things, although people who work with
      > doors closed often work harder. Somehow they seem to
      > work on slightly the wrong thing - not much, but
      > enough that they miss fame.
    

Adapting this to programming, intra-team communication is already hard enough
to establish and get flowing. Don't put stuff in the way. Yes, programmers do
need quiet environments, but the gains from good and easy communication will
out-weigh the losses. If you really need silence for a bit of hard-thinking
work, take your laptop and go somewhere else for a bit.

~~~
jtbigwoo

      > I notice that if you have the door to your office
      > closed, you get more work done today and tomorrow,
      > and you are more productive than most. But 10 years
      > later somehow you don't know quite know what problems
      > are worth working on; all the hard work you do is
      > sort of tangential in importance.
    

I think Joel's office will avoid this problem because they have scheduled
interaction time each day. The daily all-company lunches prevent the employees
from becoming isolated and out of touch. I don't think he intended for the
free lunches to be a balance for the private offices, but that seems to be the
function they serve.

Edit: fixed a typo (I'm don't vs. I don't)

------
dagw
I found it interesting that he claims Wall Street offers dull problems
compared to most startups. I've never worked there myself but I know people
who do (and in London), and they tend to work on awesome and seriously hard
core projects. Stuff right on the cutting edge of math, CS and technology and
often far beyond what most start-ups deal with.

Sure I'm not doubting that there are plenty of dull jobs on Wall Street as
well, but I'm surprised he writes off the entire sector.

~~~
hello_moto
That's what I thought so too. Remember that Russian programmer who worked for
Goldman Sach (or was it Morgan Stanley) that got caught for stealing his own
code when he moved to a firm in Chicago? He's coding in C++, Erlang and a
bunch of other things doing hardcore Math and CS.

Has Joel ever worked for a Wall Street firm?

~~~
strlen
That surprised me as well. I really respect Joel for

a) treating his programmers well

b) not taking external funding for something that doesn't actually require (I
suspect points a and b are connected too).

but writing a bug tracking system in ASP.NET seems a lot less intellectually
challenging compare to what's involved in a high frequency trading system
(even if you don't get to use Erlang, Haskell, OCaml and C++ -- and you
frequently _do_ ). Of course that's also nothing compared to many Silicon
Valley companies (you get to work on hard problems _and_ you're in a place
where core competency is software). I'd imagine, this is related to his point
about Stanford (or any other Bay Area school for that matter, even San Jose
State): if given other choices, graduates will tend to work on projects that
are more interesting or "hard-core" (to borrow a phrase Joel himself has used
in terms of of what sort of he experience he looks for on people's resumes).

(Edit: Had a point about GPA, but since others are talking about this, I'll
remove it. That said, does Joel (or anyone else) have any hard data on this,
in a statistically significant sample?)

~~~
jerf
The fastest way to make your bug tracker into a challenging project is to
approach it with the idea that it's not a challenging project and therefore
unworthy of serious developer time or energy.

We had one of those where I work. It just got its ass decommissioned and
replaced by virtue of being too challenging to work with.

Every non-trivial program has significant challenges in it; if you can't see
them, it's probably your lack of experience or your casual assumption that it
must be easy, not the fact that the task itself is that easy.

Of course, that challenge may be hidden behind other problems. You may not be
allowed to actually address the challenges; a code monkey making the same
change to 50 webpages instead of writing the proper code to do it all in one
fell swoop is doing something challenging in the sense of _difficult_ (more
difficult than it has to be!), but not the right things. This is a far more
common cause of "unchallenging programming" than the actual lack of hard
problems; most of the time, most programs completely fall apart under their
own complexity load before the true challenges even come into sight. This is,
however, the fault of the system building the program (programmers and
management), not the problem domain. Wherever there are people to interface to
computers, there is challenge.

~~~
strlen
> Every non-trivial program has significant challenges in it; if you can't see
> them, it's probably your lack of experience or your casual assumption that
> it must be easy, not the fact that the task itself is that easy.

I remember Joel talking about Wasabi, purpose built language for making their
main product cross platform. I see many business software vendors doing this
e.g., SAP with ABAP, but I'm curious as to whether there has been a
significant ROI from it (I heard mixed things about its current status of both
Wasabi and ABAP and since I have no background in business software I'll
refrain from commenting further on this practice).

I agree that are there are significant UI/UX challenges in a system like a bug
tracker (and quite frankly, most of the existing offerings are a disaster in
that space). There's also a whole slew of fairly interesting problems you
_could_ do in the greater space (integration with a VCS/code-review/diff tools
in comprehensive system like Github, Google's internal tools or some of
Atlassian's offerings).

It's also far from a trivial problem, which is why most companies are willing
to pay for bug tracking systems rather than write their own (although, it used
to be common to use heavily customized versions of Bugzilla): problems don't
have to be "hard-core" to be non-trivial or extremely useful (much like Joel
advices, I'd refuse to work in a company that didn't have a bug tracker). If I
ever gave an impression that I considered a bug tracker trivial, I apologize
for it.

What I should say instead is if you're looking for a "hard-core CS" challenge
(systems, networks, data structures and algorithms) -- and certainly only a
small minority of people are both qualified to and are interested in working
in that space, in reality these topics involve lots of fairly unglamorous work
-- a bug tracker seems like the wrong thing to work on.

I wouldn't make the whole point, if Joel didn't spread the whole "we're hiring
best programmers to solve the most difficult problems" aura and has instead
stated "we may not be the most hard-core, but we build great products and
treat developers as more than just cogs". The latter point sounds a lot more
honest and still suffices in terms of recruitment. There are many people
(including many hackers I know and respect) who are passionate _specifically_
about development tools and they're the people you want to be working on
development tools who aren't going to be interested in Wall Street (or any
other place where building development tools isn't a core competency, which
excludes most other software and Internet firms with exceptions of the
largest, who have custom needs) in the first place.

~~~
cdavid
One thing which is surprising with bug tracking is how crappy most of the
products are, especially the open source ones. This strikes me as odd a priori
since open source is generally pretty good at core programming tools - and bug
tracking certainly fits that category.

------
city41
I respect Joel for sure and he's got way more experience than I do, but I
strongly disagree with private offices for developers. I had that while at MS
and at first I thought it was just amazing. It didn't take long before I
realized how much it stifles communication and even how territorial it can
make people. Sure cubicles or even big rooms with open desks aren't nearly as
glamorous or prestigious, but in my experience they foster teams that talk to
each other, constantly, about the product. The overall team knowledge goes up
dramatically. It also fosters an environment where people are more on the ball
and productive, instead of sneaking off to some vice website every 5 minutes.

~~~
Poiesis
In my experience, private offices foster _increased_ communication because a
small gropu can get together and talk without having to get a conference room
or pissing everyone else off.

~~~
city41
Yeah, that is a good point. I guess in both situations, it really depends on
the team.

------
Tichy
I hope dogs don't become an "internet standard". I don't want to work in an
office with dogs. Maybe it would repulse me so much that I would even reject
to work for Google.

Besides, I thought the internet standard is LOLCats.

~~~
dgabriel
I agree with you. I will work with your dogs in the office if you work with my
children in the office.... no? Ok then.

------
jswinghammer
The GPA thing always bothers me to hear it admittedly because I wasn't a great
student in college. I typically always had my own thing going on that I cared
about more. I can see where he's coming from though and I consider high GPA to
a good sign when I'm looking at a resume. Often when I look at resumes I'm
just looking for anything good.

My career outside of school is considerably better than that my work in school
would have ever suggested. Before I started my company I was always the
programmer who everyone hated to see leave and who was offered a lot of money
to stay. I was glad to hear people talking about my younger brother who is
also a programmer the same way. I figure that's the final measure of how good
you are.

I never really cared much about what I worked on though. I always just wanted
to be kept busy. Part of why I wanted to start my own company was to stay
busy.

------
shadowsun7
What interests me is if there's any correlation between objective ability (as
in programming 'skill') and GPA. I'm not surprised that programmers with good
GPAs make better hires for Joel - it means they're more likely to do work on
somebody _else's_ project even when it doesn't particularly interest them
(which is good for an employer in a small/medium size firm like Fog Creek, as
opposed to an early-stage startup).

But is there any correlation with programming ability? Or is GPA just an
indicator of 'obedience'/employability?

Nonetheless - great insights, all of them, as is only to be expected from Mr
Spolsky.

~~~
limist
If the courses were rigorous enough, then I'm sure the correlation between
grades and programming ability would be meaningful and fairly reliable. It's
hard to imagine someone doing well at courses like algorithms, statistics, and
compilers, and not being a decent programmer too.

~~~
xiongchiamiov
> It's hard to imagine someone doing well at courses like algorithms,
> statistics, and compilers, and not being a decent programmer too.

Sure, but are those who did poorly in those classes less likely to be good
programmers?

I aim for slightly over a 2.0. I limit myself from going lower because that
puts me on probation, which does irritating things like prevent me from being
on paper as a club officer (I'm unofficially the president of our LUG for this
upcoming year). I don't aim for higher grades because I find that the amount
of work required is on an exponential order - the difference between a D and a
C is far less than a B and an A. Doing fewer assignments gives me time to work
on all sorts of projects that there aren't any classes for. As a result, I've
got a basic understanding of quite a few different things, enough to realize
if one of them is a good solution for a problem.

But that's what I am - the guy who knows a little about a lot. My role in a
recent team project was essentially that of technical advisor: when my
teammates weren't sure of how to approach a problem, they came to me for
suggestions.

Now, will this bite me in the butt later? Quite possibly.

Edit: I suppose my question is this: would you rather hire someone with a good
GPA but little programming experience outside of school, or someone with a
rather poor GPA but contributions to open-source (with code quality being
roughly what you would expect in order to achieve the first candidate's GPA)?

------
todayiamme
>>>GPA is really good predictor of good programmers (this surprised me). You
can have great programmers who have bad GPA but that often means they are
great only when working on super interesting projects which won't always be
the case in real life.<<<

I think that this is a bad line to draw. Sometimes, it's about bright kids
getting bored with dull teachers, but more often it's about troubled kids who
need to escape. This is quite important because I would hire someone who has
crawled his/her way up through adversity in a heart beat. As compared to
someone with a cushy resume with an equally cushy life.

Think about it in this way. Person A has never had _anything_ to take for
granted and has to fight for every inch s/he has gained in life. Person B has
a much more impressive resume, but grew up in a comfortable life with an
entire army at their beck and call. Who would you choose for a startup
fighting against the odds?

[ _edit_ \- I haven't judged someone on the basis of their financial
background, or something like that. In fact, what I was trying to say is that
until you understand the context of what a person has achieved you cannot
judge them. Kids who have parents with large bank balances can also face a far
from ideal childhood. Moreover, kids whose parents struggle to make ends meet
can have the perfect environment to grow created by their parents.

It's my observation that you can't judge if someone will be good, or not on
the basis of what lies on the surface. You need to truly understand the
struggles of the person in front of you to make that decision.

So, as a rule of thumb I would pick someone who has struggled more in life vs.
someone who hasn't felt the world crash around them.]

~~~
Construct
You make quite the leap from GPA to a person's financial background. I would
still lean toward the individual with the higher GPA, as it really is a solid
indicator of how hard someone is willing to work. Joel makes a great point
that academic projects are frequently uninteresting, but a high GPA indicates
that the candidate can complete these tasks regardless.

Judging someone on their financial background instead is heavily subjective,
prone to all sorts of prejudices and pre-conceived notions, and doesn't
actually tell you anything about the person's abilities.

After all, a driven and motivated person from a troubled financial background
can achieve a high GPA. Your theoretical 'Person A' who lived a cushy life yet
isn't motivated won't be able to achieve a high GPA without working for it.

~~~
todayiamme
My point wasn't to make the case for high or low GPAs. Or, for checking the
parents bank account, but it was just an observation that lines can't be drawn
without context. It's only when I understand someone can I judge his/her
accomplishments.

However, when you are trying to hire someone on a massive scale then this
isn't always possible. So, that's why, I think, it's better to throw the
resume into the dustbin and look at what they've actually built on their own.

So, this way you don't throw false negatives, while having a lower false
positive layer.

[edited it a bit to make the point more clear]

~~~
Construct
I definitely agree with you that lines should not be drawn without context.
However, I don't think anyone here would choose someone solely on GPA either.

Still, I'm not going to hire someone who has poor grades and personal problems
over the smart kid, as in your example. No matter how you cut it, someone who
can complete college with a solid GPA has already proven that s/he can set
goals, handle deadlines, deal with multiple managers (professors) all while
learning the material and completing the homework and tests.

Your aversion to the 'smart kid cruising through' is a bit perplexing. I
usually work hard to get and keep the smart kids on my side.

~~~
todayiamme
It's not an aversion. Or anything like that. I make a point to never judge
anyone. Ever.

Yet, I sincerely think that the kid that struggle to put him/herself through
college and fought against all the odds to sit in the interviewee chair should
be hired. It's about determination to make things work no matter what.

Person B has shown that s/he can work within those constraints, but they
haven't known perpetual hopelessness with fear about their future. They
haven't fought to make things work no matter what. They haven't faced repeated
failure and crawled their way up from there.

So, in a lot of ways I will respect person B, but person A is a determined
survivor and I would prefer to hire him/her.

------
gaius
That's interesting about the bad yields at MIT and Stanford, not something I
would have guessed.

~~~
achompas
Also interesting to hear programmers with "motivation problems" usually fail
to regain motivation.

~~~
Tichy
What does he mean by motivation problems, though? The motivation to join the
company? Or to work on that particular companie's problems?

~~~
arethuza
Motivation to work on what Joel will pay them to work on.

I've known a few really bright developers who would be highly motivated if you
were asking them to produce a streaming media server or debug a problem with
the Linux TCP/IP stack (real examples) but who would probably die of boredom
working on a bug tracker.

------
Revisor
I just bought Smart and Gets Things Done by Joel Spolsky on hiring the best
programmers.

<http://www.amazon.com/gp/product/1590598385/>

This article has whetted my appetite even more.

------
lucisferre
As is often the case with Joel's stuff, some decent but fairly obvious ideas
overshadowed by terrible ideas:

\- Private offices?

\- Over 1:1 ratio of interns? Does this make sense for small "agile" teams?

\- Then some talk about what school people went to and GPAs... right. I
suppose if you are hiring that many interns this will matter somewhat.

~~~
tedunangst
A 1:1.5 ratio is less than 1:1.

~~~
lucisferre
That's what I get for reading in the morning.

------
tomjen3
>Programmers with motivation problems: Joel has rarely seen successful
"turnarounds".

Hmm, this is properly a more specific example of the general point that you
can't change people, only people can change themself - I would imagine that
the successful turnaround would be a lot higher for those who themself
perceive this to be a problem (and not just claiming so to avoid problems).

~~~
Undisclosed
Boy, I gotta tell you from personal experience that Joel's right on. My GPA
was OK, not perfect, and motivation is something I've been fucking fighting
for over a decade.

I've finally even gone to a psychaitrist but it's still a massive struggle and
no magic bullet.

So I have to agree with you, Joel. But damnit, I wish I could prove him wrong.
I fight this every day.

~~~
daniel-cussen
You know, I once went to a doctor to ask about ADD, and was told I didn't have
it. Fast forward a couple years later, I was diagnosed with ADD. I used to
have motivation problems, and don't anymore because of the ADD medication. My
(maybe unwelcome) suggestion: talk to a lot of psychiatrists.

