... can't do this in your incredibly artificial, unrealistic context.

I hate live coding in an interview, especially on paper or whiteboard. I know you say you don't care about syntax and little stuff, but that's not what happens in my brain. I suddenly forget the most basic things. "Wait, do I use semicolons at the end of lines in Ruby? Aaaah, I've been using Ruby for 5 years. How can I not know this. I'm going to bomb this interview. I should just leave now."

I know it sounds ridiculous to you, but something very similar actually happened to me. Give me a block of time and a sample problem to work on at a computer, fine. Ask me to refactor code that already exists, whatevs. I'll happily write and discuss code. Just don't give me that blank piece of paper. My brain goes crazy.

And the funny part is that I've been told one of my best qualities as a developer is my calm, thoughtful performance under pressure. When somebody accidentally drops that table in production or both load balancers go down, I'm your guy. I'll get it fixed quickly, without a lot of panic and fussing about. Just don't give me that piece of paper in an interview.

I can't explain it, but it's true, for me. Maybe it's just that I deal with real crises often enough to have developed a mental muscle for it, but I interview so rarely that I don't have the patterns yet. Either way, I think you're missing out on great candidates with this approach.

The flip side equivalent: many modern writers cannot use computers to be creative: http://mashable.com/2014/02/15/modern-writers-technology/

Here is a list of (mostly manual) typewriters that authors use: http://site.xavier.edu/polt/typewriters/typers.html

It doesn't have to compile or even be right. But you should at least be able to pseudo code your way through it, explain what you did, and discuss it.

For a professional programmer, anything less is just an excuse or an attitude problem.

> For a professional programmer, anything less is just an excuse or an attitude problem.

You're entitled to your opinion. I disagree. I think you're projecting your personal experience of the world onto other people, which is your prerogative as the interviewer. However, speaking from personal experience, I know some people who would otherwise make excellent teammates, top contributors, etc., will fail this test, and many who pass this test will make terrible employees.

As I said elsewhere, you will get many false positives and some false negatives. Thus, I think it's a bad test and a waste of time.

    ... can't do this in your incredibly artificial, unrealistic context

Programming profession is hard and full of rough edges, unfortunately.

That's the part I don't get. It's so arbitrary and artificial. All you can be sure of is that I can solve fizzbuzz in 15 minutes.

> Programming profession is hard and full of rough edges, unfortunately.

I agree completely, but I think paper programming exercises produce false positives AND false negatives.

Citation needed.

Ask for references, read his open source code and talk to him over lunch about some of the stuff he's worked on. Someone who doesn't know how to develop software will be easy to spot.

2. If you think coding = dancing like a monkey, maybe you should do something else.

3. I've done everything you suggest, but the interview test is much more effective. You can bullshit through your suggestions (references are a joke), but not mine.

(2500 technical interviews)

(I think a longer work sample test on the candidates own time is probably still better, but any approximation is better than nothing)

I never know how to approach this question, because often the answer is, "the problem is so simple and general to the point that all variable names are either academic (solved computer science problem with technical name for each concept involved) or hopelessly generic ("counter").

When I code things that actually do things, I just name things what they should be called. I think functional programming makes this glib prescription much more tenable, as many of the things you write are abstract of the implementation, so you never find yourself naming something "screen_refresh_counter_for_process_x."

I don't give a shit about what you wrote on the page, I care what you have to say about it.

Your comment tells me more about you than you imagine.

I'll flatter myself and assume you liked what you saw in what I wrote. But if that's the case, why code at all? Why not just sit down and have a short conversation?

I feel like there's something about a rigorous, test-of-endurance interview process that feels professional. "We can't afford to hire anyone but the best."

So experienced hackers with good instincts end up ignoring them in favor of a gauntlet they know is not representative of actual work.

"What was your approach to the problem?" = I pretend to think for a few seconds, then answer. You're basically just figuring out if I've encountered your almost exact interview previously and I've got the canned answer ready.

Currently we have a timed programming exercise we let people do at home, then review and ask questions like this over email as a filter, it seems to work fairly well.

In person, I just like to ask people about their work experience, especially painful failures and learning experiences they've encountered.

Things like variable names are meaningless, imho. Every company tends to have an arbitrary set of rules they like to follow, unless someone is using things like 1a a1 11a1 a1a1 altogether where I can't read it, I've gotten over caring.

Then "how about without the modulo operator". The solution is so obvious - using the modulo operator, I had a mental block. It was fine once I got nudged in the right direction, but under normal circumstances I wouldn't have needed the nudge.

It bears essentially no relation to my work day-to-day.

If you won't code for me in an interview, why would I possibly be interested in you?

Thanks for saving me so much time.

I bombed the whiteboard/paper tech interview when I was first invited to interview at my current job (lots of ex co-workers here), and was declined as a candidate.

Months later I was invited again, this time just to start, skipping the interview. I'm finishing up my last week here and have nothing but praise and recommendations from my higher-ups, yet I would have never had a shot if people I worked with in the past didn't work here and reach out to me.

Actually at one of the places I recently interviewed, I got past the phone screens, cultural interviews, and even a google hangouts/screen-share session where I coded live while talking about the solution -- but I still had a 'get on the whiteboard and write some twist on academic sort functions' and of course froze up more and more with each time I used the eraser. I'm confident I would have done better with a computer.

I don't code on paper and whiteboards. Most of us aren't trained to, and state-dependent learning is a real thing. You cannot expect most people to perform as well in a drastically different environment from how they typically do their job.

I think I might walk out too, because it's clear that power will be exerted on any candidates who choose to subject themselves to it - it says a lot about the type of work environment that is fostered.

Good. Go work for them.

My "prima donna" filter is working nicely.

I can only assume that I have never noticed these putative canine job postings because I have been looking (or smelling) in the wrong place. At the interview, should I attempt to alter my personal odor, or leave it as is? Will I be asked to sketch out an implementation of "disc fetch" on the whiteboard, or will I be given an actual flying disc and a long hallway? Should I remove experience working for cats from my resume, or leave it in?