Hacker News Reader

> I'm still amazed by how many "experienced" programmers can't do this.

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

Can you do fizzbuzz in 15 minutes?

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.

Sure, fizzbuzz is trivially easy – under normal circumstances. But some people find these types of exercises irrationally difficult in the context of an interview, especially when coupled with the artificiality of writing it out by hand on paper.

> 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

Oh, then you're a non-hire (rightfully so). If you can't adjust to such a simple context, there's no way I can be sure you can handle an occasional tight deadline, urgent and critical failure in production, rewrite of stinky and hairy piece of code left by a less competent colleague, external system that mystically fails for no reason and writes no logs whatsoever, etc, ad infinium.

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

If you can't adjust to such a simple context, there's no way I can be sure you can handle an occasional tight deadline, urgent and critical failure in production, rewrite of stinky and hairy piece of code left by a less competent colleague, external system that mystically fails for no reason and writes no logs whatsoever, etc, ad infinium.

Citation needed.

And you think if I solve fizzbuzz in 15 minutes on a sheet of paper, you can be sure I can handle those things?

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.

How does your team manage to accomplish all these tight deadlines while having to use paper and whiteboards to rewrite stinky code? Do your production servers run A4 or legal? What's your cardstock uptime? I've had trouble switching to glossy for all but the most specialized of tasks, I'd be really curious to hear about your paper stack.

I think it is really pretty simple: in an unfamiliar environment and especially using totally unrealistic tools (paper or whiteboard), your "muscle memory" loses its memory and your thought process is totally derailed by thinking about the pen and whiteboard. In a familiar environment, the mechanical process of typing is subconscious and your brain can concentrate on the problem, and not get tied up thinking about how to write in straight lines on a whiteboard.

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

Bad bad bad idea. There is nothing more off putting than to be asked to dance like a monkey and write code with someone over your shoulder.

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.

1. No one's looking over his shoulder (re-read GP).

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)

Why pen/paper and not some sort of computer? Even coding in Notepad seems better to me than paper, and can't be that hard to set up for an interview.

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

>Why did you name your variables like this?

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

See. You're also proving my point.

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.

Maybe so, but if that's the case, isn't the entire process a case of unspecified, morphing requirements?

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.

No one I generally know writes good or relevant code in 15 minute increments. In my own experience, I generally get warmed up by the 3rd or 4th interview, and it's an acting class as I regurgitate stuff.

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

violated pen & paper, left the interview

I got fizzbuzzed in an interview recently. I knew exactly what to do, came out with it in a simple way in python.

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.

I kind of agree with you, point 7 is unrealistic, What problem could you give to the interviewee that could take a couple of days and that he/she will resolve it willingly and honestly. Yes it sounds nice but in practice I don't think so, totally agree with points 1-6 though

So it may not be perfect but I like approaching interviews in a similar way to the article. The questions leading up to and including #7 will let you know whether they can code or not so I'm not sure your #8 is really necessary.

That's appealing. If you handed me a pen and paper and asked me to code, I'd leave.

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

Thanks for proving my point.

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.

He/she didn't say he/she wouldn't code during an interview, just only made a commentary about his/her reaction if expected to do so with pen and paper.

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.

Thanks for being so upfront about your expectations; it saves applicants so much time, too.

I've had to code for interviews where I was given a project to complete in my own time, and then talk about it later if it was a good solution. I aced that process and got the job.

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.