[sethammons]

I've interviewed candidates who can talk an amazing game but can't seem to code. Starting a couple of years ago at our organization, it has been required that candidates produce _something_ that can run (or come real close to it).

[bartonfink]

I had a friend blow a job interview on something very similar. The company gave a description of an app and asked that he code something up over the weekend and host it on github for them to see. He wrote up a pretty basic app that did what they wanted, but the poor guy completely lost his head and couldn't remember `git init`, so they passed. Whether that's fair or not is another ? (I think it was, given he was interviewing for a senior role), but it's important to keep in mind that even though you may have been a productive maintenance engineer, working within an established codebase, basic infrastructure-level stuff that comes up once a project can still bite you.

[henrikschroder]

I agree completely. If you are hiring someone for a position where they are expected to write code, you should verify that they can actually write code, everything else is secondary.

And yet, here we have this article, and a bunch of commenters who seem to think it's perfectly ok to not verify the main requirement of the position. It's madness!

[deedubaya]

Totally agree that is a possibility. I assume you make them write something at the interview? Wouldn't it be more efficient to review code they've already written? I always review code prior to an interview.

Writing code is a process, few people can produce production quality code on the first go especially with someone looking over your shoulder.

If they haven't written code that they can share or that is Open Source, doesn't that really settle it?