Hacker News new | comments | show | ask | jobs | submit login
What if we hired writers like we hire developers (hitesh.in)
185 points by antrix on June 26, 2012 | hide | past | web | favorite | 93 comments



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.


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.


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.


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


I might be an exception here but I much prefer the whiteboard. I have one in my room and I enjoy problem solving. Pressure environments really do not impact me much. And if you have a whiteboard in your office and you do use it for actual work and not just interviews, this gives me an excellent opportunity to check your quality as a future problem solving accomplice. It provides me a real if brief window into what working with you would be like and I like that.

Having said that, market realities are what they are and I will probably take a month off when I can afford it and put some substantial code out in the wild. Can't hurt to have both bases covered. I will still like to make the point in here that I will be doing this because of the perceived business climate not because I really want to.


"And if you have a whiteboard in your office and you do use it for actual work and not just interviews, this gives me an excellent opportunity to check your quality as a future problem solving accomplice."

Except that when preparing for an interview, most places will clean the whiteboards before you arrive to make things more presentable, and to avoid accidentally divulging company secrets.


I write code every day, but I don't save it and its been 20 years since I wrote any code for 'pleasure'. For pleasure I have sex, go to a symphony or swim in the ocean. Coding is something I do because I'm good at it and people will pay me for it.

Further, I don't save code. I sell it. If I saved it then I would have to organize it, keep track of it and back it up. Why do that? I'm a programmer. Code I have written for fun or for some small experimental reason has no value to me because I can do it again and again at any time, like breathing. Sure, non-programmers value my code and they save it for posterity but I don't. It has no value to me once I've been paid for it.

Why would I go to all the trouble to keep a complete record of something I could do again at any time? Am I supposed to save what I'm typing right now to prove I can communicate? Do I save lawn clippings to prove I can operate a lawn mower? Do I save my waste to prove I can defecate?


You save code + accompanying documents in order to build up a portfolio to demonstrate to a potential employer how you work, how well you know your tools, and what your idea of a shippable product is. During the interview, you can talk about why you wrote the software, what designs you tried, what kinds of challenges you faced while doing so, and how you surmounted them.

At my company, we offer coding challenges for people who don't have a portfolio already. But really, why not just write software of your own choosing so that you don't need to do coding challenges to prove your ability? It's a far more efficient approach.


> If I saved it then I would have to organize it, keep track of it and back it up.

I really find this hard to swallow. It fails for me on so many counts.

Firstly, code is small compared to just about anything else you might keep on your computer. All you have to do to preserve it is drop it in a directory you keep for that purpose. The code doesn't have to be organized in order to preserve it. If you back up your computer, then your code is backed up. You back up your computer don't you?

Sure, it may be hard to find some useful piece of code later if you don't organize it, but preserving it, at least, is easy.

More importantly, you never write reusable code? You never write a library that can be applied to future problems? If not, then, you may not be the type of programmer that I'd want to work with anyway. I firmly believe that the way to increased productivity for any team is to factor out useful components and make them into more general purpose libraries. To do otherwise, is to end up with a codebase that is bloated with boilerplate.

Thirdly, if coding for you is as natural as breathing, surely you can whip up a couple of pages of code as a "code portfolio" in no time. You could have done that instead of typing in the above for your pleasure.


Not against you personally, but I'm fascinated by how clear people are about aspects of candidates they don't want to hire. There are so many dealbreakers in this thread (in the main), it's like a dating site full of people who have a lot of difficulty finding partners (hint: all dating sites are full of people with dealbreakers).


Github is an amazing product.


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

I've met plenty. Interviewed 6 candidates a few years ago - only one even brought anything beyond his resume. He brought a full physical portfolio of work he'd done. Most of it was web screenshots and such - not much 'code' to speak of, but he'd made the effort. No one else did.

I've been in plenty of places where people say "I can't show my work, cause it's for my previous employer". And they don't code when they go home. Or on weekends.

I brought code samples to an interview once, and the interviewer wouldn't look at it because "it wouldn't be fair to other people who don't bring code samples".

No doubt many people can, but you may be living in a bit of a self-selection bubble where everyone you know and mix with has loads of spare code to demonstrate. Many people don't. Now... if you want to use that as a signal for that person's interest level or ability, feel free to. You may be missing out on some otherwise competent or talented folks. But we all have to use signals to filter out candidates, and that may be a valid signal for you to use.


If you didn't ask candidates to bring code samples, it should come as no surprise that most don't, even though they might be able.

Where I work, we don't ask candidates to bring in a random code sample because instead we have them submit a coding exercise that they can do at home at their leisure. Our entire team then code reviews the code. Given the quality of most of the code submissions, it may be true that most programmers never program for fun, but if so, it shows this fact shows in the quality of their work.

All of the people who've given us nice submissions have also been very enthusiastic about what they do. I know this because we ask candidates if they read any programming journals or books just for their own edification, and the good ones always do. They always show some motivation beyond just completing assigned tasks.

We're a Scala shop, though, so we need people who aren't just programming because it's their job and for no other reason. Such people would have no motivation to become skilled in a complex programming language that is not yet mainstream.


I was doing PHP in 1996. If you were doing PHP in 1996, it was generally because you wanted to do it, learn it, etc (arguably web stuff in general then a bit too). There weren't many "PHP jobs" as such back then, so when you found other PHP developers, you knew they were enthusiasts of some sort.

That's where Scala's been, and almost any 'newish' language. If you find people adopting them, they're probably enthusiastic about it, and enjoy living on the cutting edge. :)


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.


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


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.


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


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


If you are explaining how your code works, shouldn't you be rewriting it so it is obvious rather than adding comments?

I don't know about you but I go after people in open source projects I help manage who write comments like that. Such comments add no value collaboration and indeed they get in the way of debugging more than they help. Folks debugging shouldn't be debugging based on comments but rather based on code.

But with clear code, comments are still helpful if they are used to describe difficult design decisions, or flag issues the developer sees down the road. "This is a kludge" is a much more helpful comment than "looping through an array of invoice lines so we know what to print." The first draws the developer's attention to the fact that an area of code may be unusually troublesome, while the second may be out of date, may be wrong, or may otherwise distract from debugging.

Of course there are function header comments, etc, but those don't really need to be under discussion.

You are right about the code needing to talk to you, but if you see comments as a way of explaining what your code does, then it's both a distraction to the next guy and a crutch for you.

Edit: I think this shows the point of the question and why the trivial spoon-fed answers are likely to be ones I would find inadequate.

Edit2: So the way I read your answer is "programmer just wants to get things done and doesn't mind writing non-clear code to do it, explaining it with comments. Suitable for a maintenance programming role but may in time grow into others."


Here's a good example btw of a comment that I found very helpful.

One day a number of years ago, I was reading through some part of the Linux source code (somewhere in the 2.4 series I think), and I was looking at a section of the TCP stack and came across a comment to the effect of "This is the max timeout value as specified in the RFC. This means FTP to Mars will never work"

Perfect comment. Besides making me laugh, it explains why a specific line is the way it is and explains that this may cause some issues where latency in the connection is high enough.


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.


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.


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.


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


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.


I see no problem with trying to hire developers from the contributor pool of the open source projects my company has helped found.


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


> Good spellings and knowledge of grammar rules does not indicate a good writer, and there are tools (spelling/grammar check) and (editorial) processes to take care of that.

Good grammar doesn't indicate a good writer, but bad grammar does indicate a bad one[1]. (Good grammar meaning, in this case, an ear for language. Good writers avoid grammatical errors because grammatical errors sound wrong, like an off-pitch note to a musician[2]. Explicit knowledge of grammar isn't particularly important. For example, good writers may not know what the subjunctive mood is, but they know how and when to use it. Conversely, a writer who has the knowledge but lacks the ear is in for a rough ride.)

1. Unless it's for effect, obviously, which can range from Rimbaud's "Je est un autre" to Zora Neal Hurston.

2. Which, of course, may also be done for effect. Which is why listing out rules (about writing, about music, etc.) is so fruitless. Which is true even if the rule is "Don't start three sentences in a row with the word 'which.'"


I agree with your premise but your post is a case in point. There are as many words inside parenthesis as outside making it incredibly confusing to read. Even worse, you have a reference '[2]' nested inside parenthesis.

Using parenthesis like this indicates that it should be either a footnote or worded differently. Nesting it just makes my brain shut off.

I fall victim to using parenthesis in this manor myself quite often, its a hard habit to get out of.


Indeed. But in this manor is the median the messuage?

(Despite what my spell check says, there are no misspellings there. A dictionary might be useful though ;-) Apologies at picking on typos and showing off knowledge of obscure words.)


the cute thing is, it even makes sense


"Good grammar doesn't indicate a good writer, but bad grammar does indicate a bad one"

that is not true at all - not knowing grammar well doesn't mean the writer has nothing good or creative, or worthwhile to say (or write about).

Grammar is just a technicality to be overcome. Creative writing (as opposed to technical writing), is something that is not measured by the knowledge of the language, but by the knowledge of humanity, science, culture and anything that intersects in between. An eye for details also helps. But not grammar.


>that is not true at all - not knowing grammar well doesn't mean the writer has nothing good or creative, or worthwhile to say (or write about).

Having something to say and saying it effectively are not synonymous. There are many people with worthy ideas who fail to express themselves competently.

I have yet to encounter a good writer who has poor grammar. Good writers care about grammar, for the same reason good programmers care about style: it's a mark of careful and deliberate artifice.

A good programmer doesn't simply want their programs to compile and run without error; they want it to be readable, maintainable, and elegant. They want the quality of their code to speak for itself. Similarly, a good writer seeks not only to clearly express their ideas, but to do so in a way that evokes thought and emotion on the part of the reader. To do so it is necessary, but not sufficient, to achieve technical mastery of the language in which you write.

Good carpenters don't make sloppy cuts, good chefs don't burn the rice, and good painters don't make stray strokes. These are the easy things to get right: the bare essentials for being competent at your task. A person cooking a meal for their family may use too much salt, a person playing guitar around a campfire may play the wrong chord, and someone responding to a comment on the Internet may talk lik dis,, or use unnessary punctuaton!

The difference between the craftsman and the lay person is that the craftsman takes as writ the technical mastery of their skills, and focuses on composition. The lay person is concerned only with the gist.


Having something good, creative or worthwhile to say and saying it well are two different things. I understand the phrse "good writer" to mean the latter. Too often have I come across excellent insights buried like diamonds in a dungheap in ugly, tortuous prose. This runs the great risk of these insights being lost or misinterpreted. The converse is possible too, of course; utter nonsense put beautifully.


To support that, ghostwriters and copywriters are two examples of writers that take the gist of another person's thoughts and express them well in writing. They are creative writers, but they don't necessarily have to have anything to say to do their job.


not knowing grammar well doesn't mean the writer has nothing good or creative, or worthwhile to say (or write about).

In those cases the person in question (and his potential readers) would be much better served if he worked with a skilled ghost writer or co-author, rather than trying to write something on his own. Much in the way a scientist or mathematician, who only knows a little programming, is often better served working together with a skilled programmer rather trying translate their domain knowledge to code on their own.


i see that as the way of the future. Aka, collaboration. Subjects these days are way to difficult to really master anyhting multi-disiplinary.


There are times when good writers use "bad grammar," though. More often though it's "good grammar in a non-standard dialect."


> More often though it's "good grammar in a non-standard dialect."

Exactly! I wrote a blog post about this: http://kuznetsverve.wordpress.com/2010/05/12/what-is-grammat...


Actually, I am not at all convinced by Chomsky's idea of universal grammar. I think here the structuralists and post-structuralists have an important edge (post-structuralism is built on structuralism and the basic thesis is that meaning arises from the system of rules, not the individual rules). IMO Chomsky tries to move away from the basic Structuralist thesis (by Sapir and others) and move towards something else.

So for example when you look across language families you find that most of the constraints follow in an almost mathematical way from other choices. For example, once you have a language which is fairly isolated (as opposed to synthetic or polysynthetic) and doesn't use a lot of inflections, then word order becomes the only reasonable way to express relationships between words. If on the other hand, you have a synthetic language with lots of inflections, you might not need to worry about word order at all (Old English poetry for example).

The options available for polysynthetic languages are different still.

But these aren't the only constraints. Consider for example the way Austronesian languages often essentially "unbound" words by redoubling them, so in Indonesian duduk means to sit, but duduk-duduk means to sit about casually, or informally, or repeatedly (unbounding can occur with regard to time, social structures, etc). Similarly kuru means "horse" and kuru-kuru can either mean "horses" (but only if no numbers are specified) or horse-like (i.e. a sawhorse). Similarly ayam means chicken, and ayam-ayam can either mean chickens or it can mean a kind of fish that people decided is somehow chicken-like ("sea-ckicken?")... On the other hand we would never say dua kuru-kuru to mean "two horses" since that would probably mean "two sawhorses" instead. Instead it is "dua kuru" (translating word-for-word without converting structures, this means "two horse," note the singular).

Where structuralism breaks down (and where post-structuralism is important) is an area which was noted even by Sapir, one of the founders of structuralism, and this is the dynamic quality of grammar over time. Sapir's example from 1912 was the slow, gradual death of "whom" as an objective/dative form of "who." He points out that nobody really would say in every day speech "whom did you see today?" but instead "who did you see today?" and that no cadre of English teachers could reverse that trend. The idea that grammar is not static but changing over time, and hence is fluid is something which really lead to the development of post-structuralism as a general thesis in language study.

I don't think you can get from brain structures directly to grammar for the same reason you can't just treat chemistry as applied quantum physics. The added complexity, esp. combined with neuroplasticity, provides infinite possibilities regarding language structures, provided that we have some way of referencing things (breaking this down strictly into words, phrases, and sentences doesn't work for reasons Sapir points out in his surveys of Native American languages-- all languages may somehow break things down into words and sentences, but there is no natural mapping of objects to words or multiple words to phrases or sentences).

Back to non-standard dialects.... I wonder for example, how the African American Vernacular English (AAVE) phrases in Jason Mraz's song "I'm Yours" get misunderstood. Granted he shifts back and forth between AAVE and Contemporary Standard American English (CSAE) seemingly fluidly. But phrases like "before the cool done run out" have relatively specific meanings and carry a lot more meaning in AAVE while they sound just wrong in CSAE.


I hadn't heard of Rimbaud's letter until now. It's damn crafty! Thanks. :)


A developer is a writer; one writes English and the other writes code, but they both write to a human audience (the only "code" a machine needs to see is 0s and 1s; programming languages are for humans).

So there really shouldn't be a big difference in hiring a writer vs. a developer; and a good test would probably be to have developers write essays in English about a technical question: can they make themselves understood?

I would not hire a developer who is incapable of explaining what he's doing, why he's doing it, what the other options are, etc.

Wouldn't it be a good technique to have interviewees bring an example of their own code that they're especially proud of, and have them explain what it does and why it's great?


> A developer is a writer; one writes English and the other writes code, but they both write to a human audience (the only "code" a machine needs to see is 0s and 1s; programming languages are for humans).

I definitely agree with this! That's what I had been thinking the whole time while reading the articles and the comment threads. This is also my motto, here in the office.

It's too simple to say that there are differences between writers and programmers. I think "writer" should be treated as an umbrella term that encompasses braod ranges of skills. After all, a journalist, a poet, a technical writer and a translator aren't really doing the same thing, are they? I like to believe that the core subset of skills needed to be one of these is also needed (or at least highly valued) to be a good programmer.

Programming is writing. Absolutely.


That's kind of an interesting point. People assume that skill in programming is generally correlated with Math skill and there is certainly some truth to that.

However I generally find that people who write sloppy English also write sloppy code.


At many newspapers they ask prospective reporters for

1. Clips (writing samples) 2. A copy editing test (to make sure they write cleanly) 3. Actual stories written from some facts or info provided.

That's not so different from asking a developer to write some code during technical interviews. Good clean copy requires similar precision, but your compiler happens to be a human.


I think it's very different to give someone a weekend to do an edit test and story sample, than to demand code whilst looking over the applicant's shoulder. One is much like how normal work is done, and the other adds unnecessary stress and pressure that is rare in a functioning workplace.


So give them the weekend to do the code test.


I had to hire a writer previously. Not being a writer, and never having done this before I was wondering what I could ask them. But it seems more relevant just to ask them to write something than to quiz them or ask them to repeat tongue twisters (I don't understand the benefit of that). So I did 2 rounds where I asked candidates to write a short article on a topic with some loose instructions. I figured, whatever they answer in interview questions the real candidate I wanted will be found based on what article they chose to write and the actual quality of their writing.

For the more typical Q&A interview process all I wanted to find out was would they be a good cultural fit.

Perhaps I oversimplified it but it worked out quite well.


The tongue twister was a dead giveaway. Personally, I'd walk out (or hang up) as soon as the Oxford Comma came up, but I have less patience than most.


Really? I thought the Oxford Comma question was the only useful one there. You might have to define the term but it's good at showing basic knowledge of grammar conventions.

Anyway this article has a point that this process isn't effective for finding good writers, but I'll be damned if asking people to write one or two sentences doesn't filter out the illiterate people that wander in your door (think FizzBuzz).


The Oxford Comma question isn't like FizzBuzz, it's like a question on K&R vs BSD brace style.

It's irrelevant trivia. All you're going to do is trip up people who may not have been exposed to the terminology or hadn't encountered both styles yet. Any writer can handle either style and knowing the terms says nothing about whether someone can write.

FizzBuzz is about making sure someone has a basic handle on the actual job. An equivalent for writers would be to ask for a quick poem or three sentence story or something.


A writing sample is a great filter. Any good writer will jump at the chance to write out a quick (and good) piece of text if it means they might get paid.


Why would a good writer be any more likely to do this than a bad writer? Surely it would depend on market conditions?


It's easy to write out a few sentences or a paragraph for something you're interested in. If you really want to test a writer, ask them for their opinion on traditional publishing. There's no "right" answer, but most writers have an opinion on it and shouldn't have trouble writing a little on the subject.


It looks like it's time to recycle some electrons and post the FAQ that Hacker News readers have helped me put together with their previous thoughtful comments about hiring procedures. There are many discussions here on HN about company hiring procedures. From participants in earlier discussions I have learned about many useful references on the subject, which I have gathered here in a FAQ file. The review article by Frank L. Schmidt and John E. Hunter, "The Validity and Utility of Selection Models in Personnel Psychology: Practical and Theoretical Implications of 85 Years of Research Findings," Psychological Bulletin, Vol. 124, No. 2, 262-274

http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...

sums up, current to 1998, a meta-analysis of much of the HUGE peer-reviewed professional literature on the industrial and organizational psychology devoted to business hiring procedures. There are many kinds of hiring criteria, such as in-person interviews, telephone interviews, resume reviews for job experience, checks for academic credentials, and so on. There is much published study research on how job applicants perform after they are hired in a wide variety of occupations.

The overall summary of the industrial psychology research in reliable secondary sources is that two kinds of job screening procedures work reasonably well (but only about at the 0.5 level, standing alone). One is a general mental ability (GMA) test (an IQ-like test, such as the Wonderlic personnel screening test). Another is a work-sample test, where the applicant does an actual task or group of tasks like what the applicant will do on the job if hired. Each of these kinds of tests has about the same validity in screening applicants for jobs, with the general mental ability test better predicting success for applicants who will be trained into a new job. Neither is perfect (both miss some good performers on the job, and select some bad performers on the job), but both are better than any other single-factor hiring procedure that has been tested in rigorous research, across a wide variety of occupations. So if you are hiring for your company, it's a good idea to think about how to build a work-sample test into all of your hiring processes.

Because of a Supreme Court decision in the United States (the decision does not apply in other countries, which have different statutes about employment), it is legally risk to give job applicants general mental ability tests such as a straight-up IQ test (as was commonplace in my parents' generation) as a routine part of hiring procedures. The Griggs v. Duke Power, 401 U.S. 424 (1971) case

http://scholar.google.com/scholar_case?case=8655598674229196...

interpreted a federal statute about employment discrimination and held that general intelligence tests used in hiring that could have a "disparate impact" on applicants of some protected classes must "bear a demonstrable relationship to successful performance of the jobs for which it was used." In other words, a company that wants to use a test like the Wonderlic, or like the SAT, or like the current WAIS or Stanford-Binet IQ tests, in a hiring procedure had best conduct a specific validation study of the test related to performance on the job in question. Some companies do the validation study, and use IQ-like tests in hiring. Other companies use IQ-like tests in hiring and hope that no one sues (which is not what I would advise any company). Note that a brain-teaser-type test used in a hiring procedure could be challenged as illegal if it can be shown to have disparate impact on some job applicants. A company defending a brain-teaser test for hiring would have to defend it by showing it is supported by a validation study demonstrating that the test is related to successful performance on the job. Such validation studies can be quite expensive. (Companies outside the United States are regulated by different laws. One other big difference between the United States and other countries is the relative ease with which workers may be fired in the United States, allowing companies to correct hiring mistakes by terminating the employment of the workers they hired mistakenly. The more legal protections a worker has from being fired, the more reluctant companies will be about hiring in the first place.)

The social background to the legal environment in the United States is explained in many books about hiring procedures

http://books.google.com/books?hl=en&lr=&id=SRv-GZkw6...

http://books.google.com/books?hl=en&lr=&id=SRv-GZkw6...

Some of the social background appears to be changing in the most recent few decades, with the prospect for further changes.

http://intl-pss.sagepub.com/content/17/10/913.full

http://www.economics.harvard.edu/faculty/fryer/files/Fryer_R...

http://books.google.com/books?hl=en&lr=&id=frfUB3GWl...

Previous discussion on HN pointed out that the Schmidt & Hunter (1998) article showed that multi-factor procedures work better than single-factor procedures, a summary of that article we can find in the current professional literature, for example "Reasons for being selective when choosing personnel selection procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and Martin Kleinmann:

"Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure."

http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/prepri...

But the 2010 article notes, looking at actual practice of companies around the world, "However, this idea does not seem to capture what is actually happening in organizations, as practitioners worldwide often use procedures with low predictive validity and regularly ignore procedures that are more valid (e.g., Di Milia, 2004; Lievens & De Paepe, 2004; Ryan, McFarland, Baron, & Page, 1999; Scholarios & Lockyer, 1999; Schuler, Hell, Trapmann, Schaar, & Boramir, 2007; Taylor, Keelty, & McDonnell, 2002). For example, the highly valid work sample tests are hardly used in the US, and the potentially rather useless procedure of graphology (Dean, 1992; Neter & Ben-Shakhar, 1989) is applied somewhere between occasionally and often in France (Ryan et al., 1999). In Germany, the use of GMA tests is reported to be low and to be decreasing (i.e., only 30% of the companies surveyed by Schuler et al., 2007, now use them)."


Are there any actually useful integrity tests?


Look at the personality tests investment banks ask, and reverse the scoring.

- How often do you go to parties?

- Do you find it hard to make friends?

- Are most people basically dishonest?

- Do you get a buzz out of taking risks?

etc.


I'm unfamiliar with these questions… Inverse the scoring? So what, going to parties is good or bad? How is this relevant to determine if you're good at your job?


Looking at typical integrity tests, they use either veiled or overt questions.

Overt questions are things like "are you dishonest".

Veiled questions try to be a bit sneakier. One of the factors they look for is risk taking behavior (going to parties, taking risks, etc). Traders, on the other hand should be keen to take risks.

Of course, there's a lot of other factors the veiled questions look for (asking whether other people are dishonest, looking at attitudes towards punishment) which aren't related to risk-taking.

Ironically, having a harsh attitude towards punishment can indicate dishonesty, possibly because dishonest people think other people are only deterred by the penalties.


The other classic bank question is "do you prefer cycling on an exercise bike or on the road"

I think the idea is that an excerisice bike means you are fitness and performance orientated and able to work toward a arbitrary goal without any obvious reward or it means you are willing to do pointless grunt work instead of something pleasant and interesting - either way you are supposed to say exercise bike


"Exercise bike because I'm somewhat terrified of being around cars, random people, and far away from home/office without a nice metal cage around me and a trunk full of storage capacity." Perhaps one of many reasons I don't work at a bank.


we do a reference check and although this wouldnt normally tell us much we can also structure it this way:

1. get their last 3 (or so) jobs on their resume. 2. During phone interview, ask the person how their last three bosses would rate their performance out of 10. 3. Ask them what their ex-bosses will tell you when you call them. 4. Call the references and ask their bosses what they were like as staff, why they left etc. 5. Ask them if there was one thing they could improve on, what would it be.

This works pretty well as an integrity test and is related to actual behaviors rather than written tests.


I think it would be funny to do one of these for hiring plumbers. And you ask them what toilets they have unclogged outside of work for their own projects. And if they tell you they won't unclog toilets if they don't get paid, you dismiss them for having no passion for their work ...


I'm a professional writer; i.e., I get paid to write. I didn't study journalism but I was in an interdisciplinary programme that consisted of literature, history, and language (somewhat of a modern day philology degree) in Canada. I've just recently started to learn how to program.

I think if this hiring process works for you, great! But as someone who recently started learning to program, I must say writers are vastly different from developers.

There are different kinds of writing. A novelist and a poet (and maybe even an essayist) cannot write business letters. Business writing is vastly different from any creative writing, an SEO writer is neither a creative writer nor a business writer, and so on and so forth. The difference between business writing and creative writing is each follow different rules. That is, each discipline gets away with different things. Creative writing exploits language any which way possible to get a point across, even if it means breaking the rules. Business writers are conservative writers. They follow grammar rules closer, as well as orthography. Most contemporary creative writers use post-structuralist techniques when telling a story; e.g., levels of narration that go from a protagonist to a secondary character to the world in which the book takes place to a far more omniscient narration and much more (narrative modes can get extremely complex). And if they don't, it is almost a given that a type of meta analysis of it is acceptable and encouraged (nowadays, especially). I don't mean to be condescending but business writers use a more primitive form of writing: straight to the point, the nitty-gritty, the meat of the matter. Business writers specialize in a different form of writing. They have more in common with journalists in that they do not exploit language, but seek the simplest form to explain a concept and be completely understood with no room for misinterpretation. I've always said half-jokingly that journalists aren't writers, because they deal with facts and events. I say this meaning journalists do not explore the frightening realm of creative writing, they only dabble in it. Few have ventured to write creatively within their pieces or let abstract concepts permeate throughout an entire piece. For me, journalists and business writers are data-driven and are hard empiricists. There is no market for creative journalists in the entire sense of the word "creative". When companies say "creative" they mean "Can you come up with an idea in which our audience is interested?"

The proof is actually in the tasting. You say you ask your potential hires to <i>spell</i> out a word. There is your first mistake. Do you know how many great writers were poor spellers? Rarely have I seen great writers who are also great spellers. Great writers have great ideas. This is why the world invented editors. It is an old cliché, but one that is true. What's more: do you know professors still teach and believe this? Right, this isn't Academia, and this brings me to another point. Those who do not major in journalism learn to write differently. Most of my peers were bad writers, but they might be a perfect match for a business's needs because they abide by the parameters set by the company. This brings me back to the point that in most business settings, people do not want creative writers. They want someone who writes within the parameters the business calls for or the higher-ups assign.

The Oxford comma. How much does a writer gain by knowing a definition of a word? Let me expand on what Richard Feynman said about what things are called: "I learned very early the difference between knowing the name of something and knowing something". Definitions belong to the category of "knowing the name of something". The problem with this type of 'knowledge' is, most of the time, the interviewer, as someone unfamiliar with the mechanics of language, does not have the capability to ask and know what function the comma holds when placed in a list before a coordinating conjunction. You are testing how many words a writer knows. So, you might as well ask what a Harvard comma is, just in case, to test if the hire knows this and many other words. Anybody can be a technical writer. Anybody can learn the simple rules of language enough to convey a comprehensible idea.

You're essentially looking for a person who fits your idea of a good writer, which should be understood as being a subjective notion. You have a process for knowing who can write best sellers? What are you waiting for? There is lots of money you can be making and, as I'm sure you are a man of science, you can test your hypothesis of being able to pump out best-selling writers.

Seriously. No. Writing a best seller is a completely different ball game, but please feel free to prove me wrong by giving me some results.

Also, I'd just like to clarify that I've not even touched upon the nuances and differing grammar rules from the US, Canada, Australia, and the UK. Suffice it to say that comma splices are not always incorrect depending on where you live and there are different rules for comma usage.

Also, the Elements of Style is an archaic and misguided book, for the most part. None of my professors ever stressed its importance or use. Unfortunately, I've run out of time and must go now. I wish I could touch on other points!

Sorry for any 'style errors' - I've not proofread this :P


Did you really not get that the OP is a parody? The point is that this is obviously NOT the way to hire writers. The implication then being that it is also not the way to hire programmers, even though, sadly, hiring programers is typically done just that way these days.


No, I did not get it. I think this is because, as I said, I just recently started learning to program. I started in January, but I do not commit 100% of my time to it, as I have a full time job that deals with something completely different.

I know nothing about hiring developers or being a developer.

Also, for the record, I just read in Hitesh's blog's comment section that this is not about hiring writers.

Thanks, everyone, for not beating me up for it! :)


Here's a development tip:

Obviously, to dabble in programming you must learn the fundamentals-- the syntax and grammar. However, your ultimate goal is to envision a problem, device a system that solves the problem, and then gracefully describe that system using your chosen language. You can always look grammar and syntax up in the documentation.

I think you will see the parallels to your current occupation.


As a Technical Writer trying to weasel his way into more developmenty tasks, I find this advice insanely insightful. I spend a lot of time frustrated at my lack of development training, and maybe don't step back enough to clearly define the problem-solution before opening Vim.


Thank you. I will keep this in mind as I learn more about development.


Maybe a good way to hire a writer would be to see if they can spot obvious satire...


Nope. Good writers are human too. They miss things.


Evidently the satire was too post-structuralist for him ;-).


I should pretend that I spotted the satire and was just acting as though it were serious for the purposes of discussion.


nah, you should pretend that your response was even more subtle satire and that nobody else got it ;-)


woosh


edit: I should be less eager to click buttons

----

Where do I begin…

'spelling of conscientious'

This would be covered in the first editing pass when I turn the spell checker on. I don't see what this is meant to demonstrate. Even good writers have trouble remembering how some words are spelled.

'explain oxford comma'

What's the point of this?

'repeating a tongue twister; I like the “Betty Botter bought a bit of butter” one.'

What's the point of this?

'Questions about rules in ‘Elements of Style‘'

Elements of Style is not a rulebook. It's a stylebook.

'A few puzzles to test their creativity.'

A good writer is like a good designer. You either like their style or you don't. If you don't, you'd never ask them in for the interview. A quick writing sample is the only test of creativity you need.

'More spellings and grammar questions.'

A writing sample is all you need to assess grammar and spelling competence. My grammers is fine, but I couldn't recite rules and practices in a test.

'Some domain related question, for e.g. ask sports writer, the dates when the last football world cup was played.'

A good writer knows how to research. If you need an x writer for some cultural reason then you'd ask for that in the ad. This is a poor filter since it doesn't tell you how well a writer can write on the subject.

'Question on lexical roots of some words.'

Is this an English class or an interview?

I would show myself the door pretty quickly and advise all my writer friends not to consider your company. Your interview questions display a serious ignorance of the craft of writing. Save yourself some headaches and ask the best writer in your office to hire other writers. The sort questions you ask are easily rehearsed by a bad writer with good memory.


Did you stop reading halfway? The entire point of the article is that you would never hire a creative writer using these criteria, and yet they are the types of criteria being used for 'creative developers'.


Apparently I did! I should be less eager to click buttons. I've edited a little note in at the top so I won't get any impulsive downvotes.


I don't think you read the last portion, "For the Naysayers" although I think you prove the authors point pretty well (in sort of a good way?)


s/write/code/g; s/writi/codi/g;


I almost did this. My post began with this:

>>We have found that we are able to hire great writer

>I see.

And was only going downhill from there.

Don't worry about it, we're all there.


As a writer, some of this strikes me as dumb. There are a lot of people who aren't "writers" that I'd be glad to hire. Why would you grill someone on the rules in the Elements of Style? They can look that sort of thing up. If anything, I'd be more interested to see if they absorbed the real lessons in the Elements of Style. (Hint: Not the rules.) Also:

"We have found that we are able to hire great writer from this process, who are able to create award winning content, whether it is a short article or a book."

Hire a copy editor.


You should read the full article.. the hiring writers bit is just a parody.


If you were hiring an editor, rather than a writer, asking about the Oxford comma is perfectly reasonable.


I'm an English major and I sweat bullets before I read to the "For the naysayers" part. I wouldn't have gotten past the phone screen.


Someone once made a blog with the same argument but used the comparison of a mechanic instead. Anyone know the URL?


This might be the one you're remembering: http://blog.jitbit.com/2011/05/what-if-drivers-were-hired-li...


No Fizz Buzz for writers?

"Write a 20 line poem. Rhyme every third line with "Fizz" and every fifth line with "Buzz."


I am pretty sure James Joyce would fail this test.


I don't know - I can see job offers that say we are specifically looking for experience in consonants not vowels.

Or we need 5 years experience of using the word "necessary"


he probably meant assessing and not accessing in the phone screening part - would he have passed his own interview?


Is this not how we hire writers?!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: