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.

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.

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.

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.

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?

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.

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.

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.

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.

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

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.

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

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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?

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.

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

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.

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.

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

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.

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

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

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.

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

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

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

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.

----

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.

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

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

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

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