Some tidbits from Joel Spolsky's talk last night on recruiting programmers

http://cdixon.posterous.com/some-tidbits-from-joel-spolskys-talk-last-nig

by frederickcook • 16 years ago

81 97 16 years ago

cdixon.posterous.com

gaius2• 16 years ago

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

achompas2• 16 years ago

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

Tichy2• 16 years ago

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

unshift2• 16 years ago

I wonder if those programmers typically do better on their own projects or in their own startups. I would suspect the answer is yes, and they're probably a similar class of people to those who are good programmers with mediocre GPAs in school.

singular• 16 years ago

It's interesting to tie that in with the 5-10x productivity claim - what about your working environment? If you're working in a negative environment motivation is staunched which inevitably affects motivation.

Another point about productivity - if you're working in an environment where people want crap shovelled out as soon as possible, then the people who care about maintainability are likely to take longer on software (though once you factor in support, something often shovelled under the carpet, you will often out-gun the 'put out crap then fix it up' approach), and thus appear less productive than mediocre colleagues.

Don't get me wrong, I do agree with Joel on most of these points, and I think he's probably talking about 9-5 developers who have little motivation to improve rather than passionate but burn-out or disillusioned developers.

hga5• 16 years ago

I'm not sure what he means by "bad yield":

I just talked to my friend who's been running the MIT EECS undergraduate program for the last 3 decades and she says the breakdown in graduating students goes roughly like a quarter each in:

Postgraduate education (12% Ph.D., the rest law school, med school, etc.) Quite a few do some sort of postgraduate education some years later but MIT has no hard numbers on them.

Finance/consulting (their math skills will earn them a much higher salary on Wall Street than they can get anywhere else).

Established companies (e.g. as of a few years ago Oracle was the best for starting salaries, $95K then).

Startups.

So with the current per class enrollment of ~200 students that means Joel has a pool of 50 students who might want to work for him.

Maybe they don't work to work on .NET and/or in NYC???

Note that all the above are "official", public and current, straight from the source.

tghw2• 16 years ago

The problem is, you don't know which 50 it is. I mean, we're talking about 22 year olds here, they probably don't even know. You end up having to "advertise" to all of them, which then leads to you interviewing some of them who are 90% sure that they're going on to a PhD, but just want to do the interview [for experience|to make their parents happy|to see if it might change their minds].

Full disclosure: I work for Fog Creek, and went to Stanford.

Tichy2• 16 years ago

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• 16 years ago

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.

tomjen3• 16 years ago

>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• 16 years ago

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• 16 years ago

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.

gcheong• 16 years ago

If you're talking at least in part about procrastination, this is one book I've recently gotten good mileage out of. It's a quick but useful read though, as you say, there are no silver bullets:

http://www.procrastinatorsdigest.com/

city413• 16 years ago

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.

percept• 16 years ago

I prefer an office, but for those without I think there should at least be "quiet time" or consideration given to where different types of workers are located.

This helps avoid the "talkers vs. typists" problem--don't mix the two. For example, don't put me near the support guy who has loud and frequent speakerphone discussions about resetting passwords, his personal doctor visits, etc. ;)

oiuygtfrtghyju5• 16 years ago

I've had it bad at both ends.

The 'we have no heirachy - the owner doesn't have an a office' open cubical farm where you are stuck between chatty secretaries and shouting salesmen.

And the private offices where one office = one person = one module and the only way to talk to somebody about 'their' part was a request up the management chain.

Best was a 'programmers only' room with one huge desk for three programmers on the same project.

hello_moto2• 16 years ago

I used to think that programmer needs to work in a very quiet room because they need ultra-sharp focus. Turned out there are bad side effect from this situation.

This is one of the reason why programmers tend to be weirdos and outcasts.

This is also a reason that you often found crazy complex code. As you mentioned it before, they become territorial. I often met with programmers whom you can't just disagree with. It's like they live in their own world and everything they do is right according to them. Coincidentally when you write your own program, you're a god in that universe.

The stories of "a small group of great developers working together on a great product" were often being told in HN threads. Please understand that we should emphasize more on the word "group" and the phrase "working together". They don't work alone.

By the way, I had experienced private office too before. Boring.

Poiesis• 16 years ago

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.

city413• 16 years ago

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

hga5• 16 years ago

A lot is going to depend on how really difficult the work is. If you must establish and maintain flow then you need a quiet, no distractions environment (unless you're one of the rare sort who can ignore your environment ... I can when I'm doing intense debugging).

I hope you're statement is based on more than your experience at Microsoft or at least them as of late, it's pretty clear that they've become seriously dysfunctional.

Open spaces "foster teams that talk to each other, constantly, about the product".

Well, that's nice, but when does the actual creation of the product occur? And how truly difficult are the products developed in these sorts of environments? E.g. are you just bolting together existing "parts" and the user visible stuff is overwhelmingly critical? ADDED: or are you doing something like ViaWeb (the extreme level of store customization that was never replicated in C++).

If you have people who absent a panopticon are "sneaking off to some vice website every 5 minutes" then you've got much greater problems than anything related to your environment. They're not dedicated to the project, perhaps because they don't have what it takes, perhaps because you've failed to create the necessary conditions. Either way, I don't see any good alternative to solving the root problem (and if your company is a really bad and dis-motivating place, why are you still there???).

city413• 16 years ago

These are all good points. Perhaps the reality is something like physical layout of the office doesn't influence things as much as the team itself. However, something as simple as physical layout still will affect things at least to a degree.

misterbwong• 16 years ago

The more I think about it, the more I'm starting to believe in shared offices or small, isolated cube farms. Noise is minimized and there are people around for ease of communication.

pjhyett• 16 years ago

At GitHub we use conference tables that everyone sits around, along with a couple of couches if you wanna chill out somewhere else. We spent our first two years working out of coffee shops, so we replicated that environment without all of the additional noise and distractions.

If there's something that truly requires uninterruptible concentration, you just stay home and work there, or put in your noise-canceling headphones and zone everyone else out at the office.

When you work with people you consider friends, the last thing you want to do is sit in an office. For that reason alone, I'm not convinced offices make people more productive. I'd rather keep people happy and the productivity will follow.

jdbernard• 16 years ago

I worked for a fairly large company (Gemalto). Developers had shared offices, two to an office. The office had a partitioning wall through the middle, but it did not extend the whole width of the room, so it was semi-open space. There was also a fairly strong open-door culture, so you could hear, softly, the conversations happening in the other offices. That really worked for me. When I needed serious focus time, I just popped on some headphones.

dagw• 16 years ago

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_moto2• 16 years ago

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?

nsoonhui4• 16 years ago

Maybe his sampling is restricted to "dull" programs such as writing UIs for traders, CRUD internal applications etc.

inerte• 16 years ago

Probably a selection bias. He doesn't want the types frequently found on Wall Street firms. He found good people who do NOT want to go there, and assume every good people does not want to go there. Or the kind of programmers he's looking for.

I kinda have this prejudice too. If you're doing Wall Street job, it's probably some boring stuff, 100% focused on money and enterprise, with crappy UI and thousands of slices of the same dozen reports.

strlen2• 16 years ago

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

tedunangst2• 16 years ago

Not everybody on Wall Street works on a HFT program. For every one person working in Erlang, there's a thousand more that aren't.

ajaxian2• 16 years ago

I work in finance (for an investment management firm that's a household name in the CNBC world) and can confirm that the synopsis re: working for finance, "Lots of money but crappy environment, dull projects etc." is correct.

Here's a summary of the work environment:

- no office (hah!) or cubicle, just a space on a long desk, hardly conducive for concentrating on programming

- dress code is shirt and tie, but on Fridays you can drop the tie, and every quarter or so you can wear "jeans for charity" if you pay $10 (yes, I'm serious)

- C++ is the standard language, but it's C++ as written by physics PhD quants who have obviously never taken any classes in software engineering, and have no interest in doing so

- hours are long, 10 - 12 hours a day

- as much as possible technology is done by contractors or is outsourced

Generally speaking the attitude is nobody got fired for buying Oracle, so "awesome and seriously hard core projects" are few and far between if non-existent.

On the upside, the pay is good, so if you're disciplined and don't get stuck in the trap of living the Wall St. lifestyle you can save a lot and at some point take the money and run far, far away from the financial industry.

nsoonhui4• 16 years ago

What are the projects that you are working on? HFT strategies? Statistical Arb trading strategies? Those kinds of projects seem extremely math and CS hardcore to me.

kmt• 16 years ago

How good is the pay? Can you give some examples?

smanek• 16 years ago

FWIW, my experience has been different (I work at a proprietary HFT firm in Chicago).

-Open office space (no one short of C-level gets an office). We all work together in a large open space to collaborate better. We have reasonable sized desks though, with 4-8 monitors each

-No dress code (I'm wearing jeans and t-shirt, and shorts/sandals/t-shirt isn't uncommon).

-A lot of C++ and Java. But more Python, Haskell, and Erlang every day. If you can prove your solution is better (mostly faster), we'll use it. It is true that some of the people writing code are physicists/mathematicians, and don't get some SE best-practices. But they're pretty damn smart and will learn if you teach them.

-Best hours I've ever worked (<50 hrs/week). Home by 5PM most days.

-You have access to any tech you need. If there's an expensive piece of hardware or library that will help, it's no problem.

-Catered meals, smart team-mates, good pay.

Incidentally, we're hiring too (Allston Trading).

fertel• 16 years ago

Joel is pretty spot on with his assessment of being a dev at a wall street firm. While the pay can be immense, it is clear that software is not their core business, and you are treated as such.

Also for every really cool cutting edge internal project, there are a ton of uninteresting internal systems (order management, reporting, accounting, compliance, etc...) that have to constantly be maintained and updated. Some of which have been around for years.

arethuza2• 16 years ago

I worked with ex-traders for a while helping them try and develop real time approaches to VaR calculations (note this was 15 years ago) for an investment bank.

Not only was the area intellectually fascinating, costs weren't a big problem in terms of infrastructure (Sun Enterprise kit all round) but the people themselves were very interesting - probably some of the smartest people I've ever worked with.

svx• 16 years ago

I work in the equities group in an investment bank. Joel's probably right about a lot of wall street jobs but certainly not all of them. I'm not even involved with the most math/CS intensive stuff but I still work on:

- Creating/consuming "real-time" data feeds with thousands of events per second

- Custom pub/sub in-memory databases

- Complex event processing on streaming data

- Homegrown data structure libraries designed for low-latency applications

Honestly, it's a lot more interesting than what I used to do at large public websites. The hours are no worse and when you include the bonus I bring home 2x as much. The cap is also insanely high, even for people who want to stay coding 90% of the time.

Sure, it's nothing like working at a startup. There's lots more meetings, you're a cog in a giant machine and no one outside of the company ever gets to see what you do. I bet working at a small hedge fund/prop shop approaches the best of both worlds.

It gets frustrating when so many otherwise knowledgeable folks write off an entire industry.

todayiamme3• 16 years ago

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

Construct2• 16 years ago

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.

todayiamme3• 16 years ago

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]

unshift2• 16 years ago

Are good GPAs a predictor of good programmers, or good employees? I would argue the latter, though they certainly aren't mutually exclusive.

My take on it is that those with good GPAs are probably more likely to work well within a structured framework (show up 9-5, work, go home) and with more feel-good rewards ("here's an A+" and "here's a $5000 bonus this year for consistently working 50 hours/week"). Those who don't care about things like GPA are more interested in what they're getting out of it (what they actually learn, making FU-money, working for themselves, etc) than rewards bestowed upon them by others for their great work.

Of course that's a huge generalization and entirely anecdotal but I don't think it's all that inaccurate.

nsoonhui4• 16 years ago

Not sure about this. All I know ( in Malaysia at least) is good GPA doesn't mean you can program, but bad GPA means you can't program.

dhume• 16 years ago

Re: the edit

I think the issue was that your original post could be interpreted to mean that GPA is determined primarily by the amount of adversity in one's personal life and very little by academic ability. This is contrary to what I've observed: those with hardships still do fine academically, only a very small step below those with everything going for them, whereas those with genuinely bad GPAs typically aren't putting much effort into their coursework or are simply in the wrong major.

jswinghammer• 16 years ago

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• 16 years ago

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• 16 years ago

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• 16 years ago

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

achompas2• 16 years ago

Testing for correlation would be awesome, but Joel (and many others) always talk about how we're incapable of measuring ability.

This gets complicated by how we'd test for correlation--we'd need to track ability quantitatively, which creates all kinds of problems.

oiuygtfrtghyju5• 16 years ago

There is a correlation between GPA and working hard.

Yes there are awesome programmers who have terrible GPAs because they dropped out of high school to found their own company, or who refused to do any non-programming subjects since kindergarten.

But you want to hire somebody he has been working their hardest on everything they have been given to do - however uninteresting - since the age of 11.

jtbigwoo3• 16 years ago

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

When we were looking at entry-level resumes in a big consulting company we looked at the following:

1. Did they complete college? If not, have they shown that they can stick with something over months and years?

2. Did they have a good GPA? If not, do they stand out from their peers in other ways?

3. Have they chosen a path that takes dedication to master? We found that music majors could do very well on I.T. projects with some coaching. They were used to committing time and creativity to mastering difficult tasks.

Revisor• 16 years ago

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.

RiderOfGiraffes• 16 years ago

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.

jtbigwoo3• 16 years ago

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

agentultra3• 16 years ago

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?

umjames• 16 years ago

I hear you, but if I'm looking at your code that I didn't see you write in front of me, how do I know that code really came from you? You could have copied and pasted most of it from somewhere else and only made slight changes.

agentultra3• 16 years ago

Well if it's an open source project, you could just google some of the code snippets and find out.

Plagriarism isn't hard to detect unless the code is proprietary.

Then I suppose you either have to be paranoid and suspect everyone or accept that most people you talk to are pretty much like yourself and not lying cheaters.

edw5192• 16 years ago

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

danilocampos• 16 years ago

It's a fair point.

Unless you've got a body of work that inspires a manager to recruit you with a stack of spicy magazines and a basket full of candies and fruit, there's a specific dance when interviewing.

It's like an audition. At issue isn't whether you can do a task. Instead, whoever is hiring wonders can you do a task with me.

So there's some jumping through hoops. The hope is that in the process of evaluating and sailing through the hoops, the interview group can establish how you solve problems, how you approach interaction with others, how you take direction, how constructively you can disagree, and maybe, as a smidgeon of the evaluation, how well you actually know your thing.

In the end there's plenty you can teach about how to do the job to best suit the task and the company that's hiring.

No one can teach you how to be a person, so the fit has to work.

It's miserable working with jackasses who are technically competent but personally toxic.

KevinMS• 16 years ago

I agree with the OP and not with you. What you are doing is arbitrarily selecting a subset of qualified employees. It _looks_ like it works for you, but its probably not efficient, and can probably go wrong.

When a developer is screened with tests like that, you are not evaluating them on their product, but rather on some set of skills that might overlap.

I cant believe I'm using a sports analogy, since I hate team sports, but think of it this way. What if a football or basketball recruiter went to colleges, and looked at only how fast somebody ran, and how high they jumped, but never looked and how they played the game! Don't laugh, that's exactly what you are doing. You may have some success because you are screening out some dopes, but that's all you are doing. If I was the MVP on a team and some jerk took me aside and asked how high I could jump I'd be insulted.

As the OP suggested, looking at the candidates past code is more like looking at how they play the game.

If you suspect plagiarism, then have them explain it, beat them over the head with every design decision they made, have them rewrite something with your suggestions, it will become obvious if they wrote it or not, and you'll have a better idea if they know how to actually code, where it counts, at the construction level.

rimantas• 16 years ago

So your programers spend days coding at the whiteboards? And I guess open source projects don't count as getting things done?

agentultra3• 16 years ago

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.

ams6110• 16 years ago

You sound like someone I would not like working for. And that, maybe, is just as valuable as anything else. You've got a process that identifies the type of person you've had good luck with in the past. Your process also identifies you as the sort of person I've had bad luck with in the past. It works both ways. You're missing some excellent developers who maybe are not articulate at the whiteboard but do fine at the keyboard, even under pressure.

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.

How many times do you have your customers in the office, throwing out arbitrary programming challenges for your developers to solve on the spot at the whiteboard?

It's fine if your methodology works for you, but you might consider that it's not the only approach that could work.

JoeAltmaier• 16 years ago

Sounds like a college-hire interview. With years of experience and sound references, having an interviewer insist on this "baby step" IS demeaning. And it breeds a bad attitude, sure.

How about Reading the code the candidate provided? Asking questions about that? Invest some effort in a mature candidate, instead of treating them like a fresh-faced kid.

Imagine the difference between interviewing a business-school graduate (What is accounts receivable? How do you track inventory? ) vs interviewing for an executive position.

brown9-2• 16 years ago

Certainly a production artist wouldn't walk into an interview with a portfolio and be asked to draw a puppy.

No, but I could imagine someone being asked how they might go about starting a new assignment or piece of work (art might be a bad example to use here since the process is likely not as important as the end result).

These coding exercises give the interviewer a chance to gauge how the candidate goes about solving problems, if he/she can think on his/her feet, their problem-solving strategies, etc.

Code that you have already written is great but it doesn't tell the interviewers much about the process that led to it.

oiuygtfrtghyju5• 16 years ago

Would you rather be judged on your ability to write some sample code in the interview.

Or on the more traditional, quality of suit, firmness of handshake, where you went to school and ability to answer "what are your greatest weaknesses" type questions?

bmm6o• 16 years ago

Any test can fail in two fundamental ways: false positives and false negatives. The primary purpose of a screening test is to filter out unqualified candidates (that is, to not certify as qualified someone who is not). The process Joel describes is very effective at this.

Your complaint, essentially, is that it will incorrectly label as unqualified some qualified candidates (or that they will elect not to submit to the process, essentially putting themselves in the no-hire pile). I think Joel would tell you that this kind of error is much less costly to an organization than the other kind.

Suppose he relaxed the constraints enough to get you to pass (we'll posit that you're in the false negative group). This would necessarily imply accepting some lower-qualified candidates who would have been filtered out before. Is the company better off now? Do you think you are that much better than the people they were getting under the old system to risk also hiring lower quality candidates?

Uhhrrr• 16 years ago

The most recent graphic designer to apply at my workplace was asked to demo his Photoshop skills on the fly ("Can you make me look thinner?"). He did great and we hired him.

Also, I've worked with programmers who definitely should have been asked to write "Hello World" at some point in the hiring process. If they'd felt insulted and walked out, so much the better.

lucisferre2• 16 years ago

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.

tedunangst2• 16 years ago

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

lucisferre2• 16 years ago

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

edw5192• 16 years ago

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.

ergo98• 16 years ago

You worked in great conditions but on a bad project, and you hated it.

You worked in poor conditions, but on a great project, and you loved it.

I think you jump to conclusions saying that therefore the work is more important than the conditions. Joel isn't saying that conditions alone suffice, but that it's an input of worth.

Please, for the sake of HN, work at a place with great conditions and a great project and report back on whether it was better than great.

edanm• 16 years ago

Actually, it's not only about making programmers happier. That's a large part of it, but private offices also make programmers more productive, because they have less interruptions.

The way Joel figures it, programmers are your most important asset, not to mention a huge expense (salary-wise). Paying extra to make them more effective is usually a winning strategy.

nickelplate• 16 years ago

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

memset• 16 years ago

I almost feel bad for posting this link, but it does provide some evidence that even at Fog Creek - the Holy Grail of great engineering environments - employees become burned out due to the fact that, hey, a lot of software problems need to be solved in a business are just as boring as the ones that the rest of us cube farmers have to solve.

http://hicks-wright.net/blog/career-break/

Some tidbits from Joel Spolsky's talk last night on recruiting programmers

Related Stories