6 ms·

This ignores different realities in how programmers and writers work. If you're hiring a writer, you cam ask to see his previous work. Unless he worked for CIA

This ignores different realities in how programmers and writers work. If you're hiring a writer, you cam ask to see his previous work. Unless he worked for CIA, he can point to books he's written, articles he published etc. You can then read them and that's all you need to make a decision if he's competent enough (you might still interview for cultural fit). If you're hiring a senior engineer that claims he spent last 5 years coding Big Table at Google, you have to take his word for it. It's not that you wouldn't like to see all his past checkins, you just can't in most cases. Not being able to see past work, we do the next best thing: interviews, coding questions etc. The simple explanation is: we don't hire programmers like writers because we can't, not because people hiring programmers are inexplicably so much more incompetent than people hiring writers (despite running much more profitable businesses). This is changing a bit due to open-source in that more and more people are hired like writers i.e. based on their publicly available past work, but it'll never be the case that every programmer will be able to show his past code.

jaems33 14y ago
Where is the fine line between coding tests and spec work? I'm not a programmer, but I've seen startups co-founded by engineers try hiring designers in a similar fashion to I assume programmers as they test designers with a variety of unpaid projects. I've found it to be pretty annoying given that I've already shown a portfolio of work and it's not unlike spec work. I get that some people may have fabricated their history, but that's why some companies do a trial period before committing to a full-time gig.
- kkowalczyk 14y ago
  I don't think the line is fine. If I ask someone to implement a linked list during 1hr interview, it's clear that it's not because I need a linked list implementation in my company. If I ask someone to stay for a week to work on the company's code base, that's clearly a work that should be paid for at a market rate. Similarly, I'm pretty sure that you, as a designer, know without a doubt when company's request crosses the line from "I need to make sure you know what you're doing" to "I need you to do free work for me".
- einhverfr 14y ago
  I see no problem with trying to hire developers from the contributor pool of the open source projects my company has helped found.
- rhizome 14y ago
  I don't like all their advice, but one thing that 37Signals does in this situation is just pay the person whatever rate they ask for. In the greater scheme of things, it's not a huge expense, and if you're to the point in the interview process where this actually makes sense, then you have a decent idea that this person is a candidate, and so you can invest a little in the process for everybody's benefit. It's a step beyond the whiteboarding "jump, monkey!" coding interview.
- excuse-me 14y ago
  I was once asked a fairly involved technical question in an hour long interview - I later interviewed for a different group in the same organization and they mentioned the problem the other group had been having. I talked about the solution I had proposed and was told - "oh yes, some consultant they had in suggested that and we tried it last week".
nessus42 14y ago
If you're hiring a senior engineer that claims he spent last 5 years coding Big Table at Google, you have to take his word for it. I find this assertion to be virtually nonsensical. I've never met a programmer who hasn't written some code that they could show you, if for no other reason than programmers who are passionate about what they do, usually write at least little programs just for fun. And if I were interviewing a programmer, I'd think twice about hiring one who has so little passion for programming that they'd never written anything just for the pleasure of it. But let's assume for the moment that there are tons of great programmers who've never taken a class for which they could show their code, nor written any code just to write it: Where I work we have a small programming exercise that we ask applicants to submit for code review before we interview them. This process is much more natural than having people code on a whiteboard, because they can do it at their own rate and with their own tools, without having the stress of having someone look over their shoulder. They can also pay proper attention to issues of style and maintainability of their code. The assignments are also something kind of like the work that one might do in the real world.
- india 14y ago
  I write lots of code just for the sheer pleasure of it. None of it is publicly available though nor would I like to share it. Shipping code is a lot of work. The other day I wrote a quick app at my end to analyze and make sense of some parts of a project that I am about to take on. It does what it needs to but if I had to ship it, I would want to proof read it and describe it's purpose to a general audience and make it at least general enough to have some utility outside my immediate needs. That's a lot of work. I write a lot of code for fun and profit. Writing code and publishing/sharing code are two very different things.
  - nessus42 14y ago
    Okay, well Google doesn't want to hire you if you can't write efficient and elegant code on a whiteboard for a problem they've specified while they look over your shoulder. Me, I only don't want to hire you if you can't take a few pages of code you've written for fun and make it presentable. Who would you rather interview with? (Assuming, of course, that I was offering jobs as nice as the jobs at Google.)
einhverfr 14y ago
In addition I would tend to ask a few important questions of developers: 1) Tell me about one case where you came back to code you had previously written and decided you didn't like the style. What was the issue? Did you rewrite it to fix it? Why or why not? 2) Tell me about one case where you departed from general design best practices where it worked. What did you do? Why did it work well? 3) Tell me about your commenting style. Why and how do you comment your code? Oh and asking to see code samples is a good thing :-)
- dr42 14y ago
  These sound like the sort of thing an HR person would ask, not a developer. Commenting style. Seriously? What in all honesty do you expect someone to say, you must know you're going to get spoon fed a perfect answer just for asking such a dumb question.
  - einhverfr 14y ago
    Why do you say that? As a developer the comments are talking to me, not to the HR department and not to the computer. I want to know someone has thought about this area regarding the way bad comments get in the way of collaboration and the way good comments facilitate it. The point is that answers to these questions show the extent of introspection a programmer has regarding code. I am looking for thoughtful answers, not right answers. If you think they are stupid questions, I don't want to put you in charge of doing the basic creation of new frameworks. Edit: One really good follow-up question is something like, 'So you are reading code and you see a comment that says "This is broken." Is that a good comment or a bad one? Why?' It's a good question because right or wrong isn't in "good" or "bad" but rather the reasons they might give. Edit2: If it's such an easy question what's your answer? ;-)
    - dr42 14y ago
      "As a developer the comments are talking to me" -- As a developer the code is talking to me. It's a trivial question, comments are a chore that developers do because they provide someone who is later looking at and/or modifying their code with the knowledge about how it works in a way that isn't obvious from the code itself. Comments have morphed into more structured form with annotations that the IDE can make use of in some languages, but asking about comments in an interview is asking to get spoon fed what you want to hear.
xyzzyb 14y ago
A senior engineer that has spent 5 years coding Big Table at Google would certainly (if genuinely interested in being hired) be able to take a day and throw up some code on github. Not Big Table code of course, just some interesting code examples tailored to the position being negotiated. Worried about people passing off copy/pasted code on github? That's what the interview is for. It's great to be able to discuss code that someone has written after you've taken some time to review it. They should be able to have a discussion about the code, their design choices, what they would do differently given a twist in the requirements, etc. If they can't do that: then even if they genuinely wrote the code they don't understand it enough. I feel I should stress that the code doesn't have to be the next big open source project forked/watched by thousands. Not comfortable putting code up on github because people might see it? I get that, it is scary to put your code out in public. In that case, a simple Dropbox (or whatever) shared folder would suffice.
antiterra 14y ago
More importantly, I think it ignores the reality in how the output is consumed. Writing is generally meant to be read; that is its use. When evaluating a text, the qualities it has when read by a human are the primary criteria. When we evaluate code by reading it, our largest concern is how it will be interpreted by a machine. Clarity matters in comments, but can be justifiably sacrificed in code for an elegant or efficient solution. It might be more appropriate to compare the requirements of composing legal documents to that of coding. Testing for understanding of methods, patterns and common concepts is far more applicable in that case. Asking if a candidate knows the parameters for a work to be classified as work-for-hire or what kinds of indemnifications and disclaimers should be in a contract are arguable useful indicators of suitability.
- jaylevitt 14y ago
  If you're writing code in any environment but an early-stage startup, the qualities it has when read by a human are ALSO the primary criteria.

jaems33 14y ago

Where is the fine line between coding tests and spec work? I'm not a programmer, but I've seen startups co-founded by engineers try hiring designers in a similar fashion to I assume programmers as they test designers with a variety of unpaid projects. I've found it to be pretty annoying given that I've already shown a portfolio of work and it's not unlike spec work. I get that some people may have fabricated their history, but that's why some companies do a trial period before committing to a full-time gig.

kkowalczyk 14y ago
I don't think the line is fine. If I ask someone to implement a linked list during 1hr interview, it's clear that it's not because I need a linked list implementation in my company. If I ask someone to stay for a week to work on the company's code base, that's clearly a work that should be paid for at a market rate. Similarly, I'm pretty sure that you, as a designer, know without a doubt when company's request crosses the line from "I need to make sure you know what you're doing" to "I need you to do free work for me".
einhverfr 14y ago
I see no problem with trying to hire developers from the contributor pool of the open source projects my company has helped found.
rhizome 14y ago
I don't like all their advice, but one thing that 37Signals does in this situation is just pay the person whatever rate they ask for. In the greater scheme of things, it's not a huge expense, and if you're to the point in the interview process where this actually makes sense, then you have a decent idea that this person is a candidate, and so you can invest a little in the process for everybody's benefit. It's a step beyond the whiteboarding "jump, monkey!" coding interview.
excuse-me 14y ago
I was once asked a fairly involved technical question in an hour long interview - I later interviewed for a different group in the same organization and they mentioned the problem the other group had been having. I talked about the solution I had proposed and was told - "oh yes, some consultant they had in suggested that and we tried it last week".

nessus42 14y ago

If you're hiring a senior engineer that claims he spent last 5 years coding Big Table at Google, you have to take his word for it. I find this assertion to be virtually nonsensical. I've never met a programmer who hasn't written some code that they could show you, if for no other reason than programmers who are passionate about what they do, usually write at least little programs just for fun. And if I were interviewing a programmer, I'd think twice about hiring one who has so little passion for programming that they'd never written anything just for the pleasure of it. But let's assume for the moment that there are tons of great programmers who've never taken a class for which they could show their code, nor written any code just to write it: Where I work we have a small programming exercise that we ask applicants to submit for code review before we interview them. This process is much more natural than having people code on a whiteboard, because they can do it at their own rate and with their own tools, without having the stress of having someone look over their shoulder. They can also pay proper attention to issues of style and maintainability of their code. The assignments are also something kind of like the work that one might do in the real world.

india 14y ago
I write lots of code just for the sheer pleasure of it. None of it is publicly available though nor would I like to share it. Shipping code is a lot of work. The other day I wrote a quick app at my end to analyze and make sense of some parts of a project that I am about to take on. It does what it needs to but if I had to ship it, I would want to proof read it and describe it's purpose to a general audience and make it at least general enough to have some utility outside my immediate needs. That's a lot of work. I write a lot of code for fun and profit. Writing code and publishing/sharing code are two very different things.
- nessus42 14y ago
  Okay, well Google doesn't want to hire you if you can't write efficient and elegant code on a whiteboard for a problem they've specified while they look over your shoulder. Me, I only don't want to hire you if you can't take a few pages of code you've written for fun and make it presentable. Who would you rather interview with? (Assuming, of course, that I was offering jobs as nice as the jobs at Google.)

einhverfr 14y ago

In addition I would tend to ask a few important questions of developers: 1) Tell me about one case where you came back to code you had previously written and decided you didn't like the style. What was the issue? Did you rewrite it to fix it? Why or why not? 2) Tell me about one case where you departed from general design best practices where it worked. What did you do? Why did it work well? 3) Tell me about your commenting style. Why and how do you comment your code? Oh and asking to see code samples is a good thing :-)

dr42 14y ago
These sound like the sort of thing an HR person would ask, not a developer. Commenting style. Seriously? What in all honesty do you expect someone to say, you must know you're going to get spoon fed a perfect answer just for asking such a dumb question.
- einhverfr 14y ago
  Why do you say that? As a developer the comments are talking to me, not to the HR department and not to the computer. I want to know someone has thought about this area regarding the way bad comments get in the way of collaboration and the way good comments facilitate it. The point is that answers to these questions show the extent of introspection a programmer has regarding code. I am looking for thoughtful answers, not right answers. If you think they are stupid questions, I don't want to put you in charge of doing the basic creation of new frameworks. Edit: One really good follow-up question is something like, 'So you are reading code and you see a comment that says "This is broken." Is that a good comment or a bad one? Why?' It's a good question because right or wrong isn't in "good" or "bad" but rather the reasons they might give. Edit2: If it's such an easy question what's your answer? ;-)
  - dr42 14y ago
    "As a developer the comments are talking to me" -- As a developer the code is talking to me. It's a trivial question, comments are a chore that developers do because they provide someone who is later looking at and/or modifying their code with the knowledge about how it works in a way that isn't obvious from the code itself. Comments have morphed into more structured form with annotations that the IDE can make use of in some languages, but asking about comments in an interview is asking to get spoon fed what you want to hear.

xyzzyb 14y ago

A senior engineer that has spent 5 years coding Big Table at Google would certainly (if genuinely interested in being hired) be able to take a day and throw up some code on github. Not Big Table code of course, just some interesting code examples tailored to the position being negotiated. Worried about people passing off copy/pasted code on github? That's what the interview is for. It's great to be able to discuss code that someone has written after you've taken some time to review it. They should be able to have a discussion about the code, their design choices, what they would do differently given a twist in the requirements, etc. If they can't do that: then even if they genuinely wrote the code they don't understand it enough. I feel I should stress that the code doesn't have to be the next big open source project forked/watched by thousands. Not comfortable putting code up on github because people might see it? I get that, it is scary to put your code out in public. In that case, a simple Dropbox (or whatever) shared folder would suffice.

antiterra 14y ago

More importantly, I think it ignores the reality in how the output is consumed. Writing is generally meant to be read; that is its use. When evaluating a text, the qualities it has when read by a human are the primary criteria. When we evaluate code by reading it, our largest concern is how it will be interpreted by a machine. Clarity matters in comments, but can be justifiably sacrificed in code for an elegant or efficient solution. It might be more appropriate to compare the requirements of composing legal documents to that of coding. Testing for understanding of methods, patterns and common concepts is far more applicable in that case. Asking if a candidate knows the parameters for a work to be classified as work-for-hire or what kinds of indemnifications and disclaimers should be in a contract are arguable useful indicators of suitability.

jaylevitt 14y ago
If you're writing code in any environment but an early-stage startup, the qualities it has when read by a human are ALSO the primary criteria.