Hacker News Reader

Comment by martincmartin | Hacker News Reader

I actually look for jobs with a thorough interview process, and having to spend a few hours solving a puzzle, on my own time, before an in-person interview, is a plus. It means the other people I'll be working with have been through the same thing, and there'll be a higher percentage of good programmers among them.

View on HN

I get what you're saying, but I really don't think it's fair to ask people to do work on their own time -- for free -- in order to be considered for a job.

Most recently I asked a candidate to work a few hours on a real project for a fair hourly rate. I think this is much better for all involved. As a bonus, you get to see how they perform on a real project, rather than a contrived puzzle and they get to see what sort of work they might be doing if hired.

This is something we've struggled with. The final phase of our interviewing process is a few hours of pair programming. If folks worked on production code, we wanted to pay them.

Paying people for a few hours of work is difficult: if we pay them as an employee then we have to do employee paperwork and deal with the payroll company. If we pay them as a contractor then they have to sign a lot of contractor paperwork, including a confidentiality and intellectual property assignment agreement. It's the kind of thing I wouldn't sign without my lawyer's advice. It just seems like too much trouble.

Instead, we'll either work on a throwaway toy project or an open-source project. Both of those are working well so far, and people seem happy to actually ship some open-source code at the end of the interview.

"I get what you're saying, but I really don't think it's fair to ask people to do work on their own time -- for free -- in order to be considered for a job."

Bravo.

I can't stand when companies do this. Whether it's design or development, it's basically spec work. It's one thing if it's a general question, but if they ask you to do work related to their service, why not just pay them for a few hours or a few days?

Is your reasoning that other good programmers have nothing better to do than solve puzzles for a few hours?

I have so little time to myself that I can't spend hours solving each little puzzle a HR department comes up with...

I honestly don't know what the masses expect companies that hire programmers to do. We're told that we're not as good of a company if programmers don't program in the interview. But then the next thing we're told is that nobody programs on a whiteboard and/or with someone watching. To help, we come up with take home exercises that are custom to us so we know the answers are real. Now this article and the parent are saying we're wasting time with these "puzzles".

When I hire, I do a phone screen before asking the candidates to complete the code exercise. If it isn't going to be a fit from either of our perspectives, then they didn't spend time doing it.

It would be nice if companies simply asked for a code sample, and then asked the programmer to explain what it does, their reasoning for doing so, etc.

I have a major open source project under my belt, but I've never had an interviewer simply ask me about my code. Instead, they ask me to sort an array.

As an interviewer, I didn't see the value in asking candidates to complete FizzBuzz until one of them was unable to do it. Since then, I've had a half dozen or so candidates make it through the resume and phone screen process and still not be able to complete FizzBuzz.

In regards to discussing existing code, I'd be more than happy to do so, but my experience has been that about one person per stack of resumes has quality existing code available to share.

Well, my experience was that I wasn't interviewed at all, instead I was just asked to code up this blog system, even after demonstrating extensive knowledge of the area in my CV. The way you're doing it sounds better, but it also depends on the coding exercise. If it's an interesting problem, I'm much more inclined to work on it, rather than a simple model when I've already told you I launched dozens of projects using the technology you're using.

I think the key is that there are crappy puzzles (and coding a blog system is not a "puzzle") and there are decent puzzles. I've been giving applicants a simple word search puzzle for over five years and it has been great at differentiating candidates.

The biggest plus for me as the hiring manager is that it allows me to be much more confident in taking flyers on people without that picture perfect resume.

I agree, puzzles are interesting and actually show you how the person thinks. What they had me do sounded like getting free work done.

I can certainly understand that. I've definitely taken care to make sure that all of our examples couldn't be construed as free work. Code katas, like the bowling kata, are good for this.

I've never been asked to solve a puzzle by an HR department, but I have always been asked to solve a puzzle. Have you been asked to solve puzzles that were written by HR, and how could you tell?

I meant it in the broader sense of "the people who are interviewing me". I have been asked to program a simple blog system with various features, which seemed like a rather bad use of my time.

That same system was implemented on the company's website later on, which didn't make me feel any better. To top it all off, they never even replied.

What is your preferred way of determining whether a candidate is a good programmer?

I talk to them, ask them to show me some code samples they've written or projects they've developed in their spare time. If someone tells me they've written and launched an entire product with thousands of users by themselves, it's a bit counterproductive for me to ask them to code up a blog.

How would that work for someone who has a job where their code is proprietary and, in their spare time, they like gardening? Or do you just automatically exclude folks who don't develop their own sites with 1000s of users?

Ugh, why does everyone miss the point? If they can't show me any code, I'll talk to them and see if they know what they're talking about. I've found that you can tell whether or not someone is technically competent from a five-minute chat.

Thanks for that clarification - as someone whose code is doubly unshareable, like healsdata I'm a bit sensitive to claims of screening by github.

A) How many of those people who run their own products with thousands of users come looking for a job with you? (or, perhaps, 'ran' in the past tense)

B) How do you know they programmed that app with thousands of users even remotely well? Did they store passwords in plaintext? Does it need to be reboot every 5 mins? Is it slow as molasses, but hidden behind load balancing?

Someone could have written awesome sites with 1000s of users and loads of revenue, but it might still have been done like crap, and doesn't belong anywhere on your network.

A) I was illustrating a point, but I will clarify it as it didn't come across: If someone demonstrates extraordinary ability in projects before the interview, I will not ask them to spend four hours demonstrating rudimentary ability.

B) I ask them questions about the implementation.

Thank you for the clarification. It read like you'd give someone a pass based on stated achievements, rather than demonstrable knowledge and skills.

Oh no, I was mostly commenting on my past experience. If someone shows past achievements, I'm going to adjust the interview to their level, rather than ask them rudimentary questions or ask them to implement rudimentary and time-consuming functionality.

You can get a feel for whether the candidate can program a simple blog by asking them how they'd do it, you don't have to ask them to spend hours actually doing the nitty-gritty...

So little time for yourself yet reading and commenting on hn...just saying...

That's not even an ad hominem, I don't even know what this is.

Equivocation: http://en.wikipedia.org/wiki/Equivocation

"Time I'm willing to dedicate to your interview problems" and "time I'm willing to dedicate to reading and writing on HN" are not freely interchangeable; you can (and presumably do) have radically different expectations of the costs and benefits that make them incomparable.

Reply on news.ycombinator.com