Some tidbits from Joel Spolsky's talk last night on recruiting programmers
cdixon.posterous.com
cdixon.posterous.com
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.
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.
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.
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.
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?
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?
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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?
> private offices for each programmer,
> 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.
> 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.
Edit: fixed a typo (I'm don't vs. I don't)
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.
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.
-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).
Only a small percentage of the IT people worked on those. Mostly we built and maintained systems to track and report on trades, keep track of credit, figure out profit/loss on books, make sure traders didn't bet the company on risky trades, scrape numbers off of websites and put them in a db. We also pulled a lot of numbers into spreadsheets so analysts could make charts to email out to the traders.
It was much as the GP says... long desks, lots of noise and distractions, poor technology base (they upgraded to WinXP with IE6 in 2009). On the plus side, the pay was good (high 5, low 6 figures), multiple monitors, lots of snacks and drinks in the kitchen, catered lunch, good healthcare...
Has Joel ever worked for a Wall Street firm?
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?)
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.
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.
He is competing for programmers with grad school (cool projects no money), google (cool projects good pay) and wall st (cool projects* awesome pay)
And he is offering a bug tracker written in a home grown asp.net language.
* He paints Wall St as boring but remember he isn't competing to hire Oracle/Sharepoint back office devs. He is competing to hire C++/CUDA/Erlang/maths realtime quant types.
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.
- 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.
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.
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.
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.
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???).
I know that there's a well established rule of thumb that states close collaboration just doesn't tend to happen beyond 30??? feet or a single staircase (i.e. people further apart just don't tend to collaborate). This is of great interest to universities and other places that do research, you should be able to find something, maybe in Peopleware (which if you haven't yet read you want to anyway).
(To emphasize how different, we can be pretty sure that very few if any of the programmers studied had a memory budget even close to what's been in mainstream CPU caches for some years.)
For another example, see MIT's termination of SICP/6.001/Scheme with extreme prejudice and replacing it with Python based "bolt together" course(s) (I don't know anything about 6.02, but the initial 6.01 robot project is just that ... which is not to say that it's easy, e.g. it requires the use of differential equations and its labs are very instructor intensive, to the point the department is recruiting upper-classmen to help).
MIT believes that things have fundamentally changed....
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. ;)
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.
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.
Besides, I thought the internet standard is LOLCats.
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.
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.
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)?
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.
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.
This gets complicated by how we'd test for correlation--we'd need to track ability quantitatively, which creates all kinds of problems.
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.]
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.
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.
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]
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.
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.
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.
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.
Full disclosure: I work for Fog Creek, and went to Stanford.
Anyway, what you're staying is that it's difficult to qualify your sales leads at MIT and that results in a lot of critical wasted effort. So much it's not worth trying (hard)?
But it was such a crap place to work they their actual hires were from 3rd rate institutions. They would have been better focussing their recruitment on them. But that would mean admitting there was a problem - so much better to convince yourself that the Oxbridge grads all went to do PhDs instead.
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.
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.
http://www.amazon.com/gp/product/1590598385/
This article has whetted my appetite even more.
- 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.
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).
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.