Live data from Hacker News

Why we don't hire programmers based on puzzles and tricks

37signals.com

411–420 of 460 posts

Re: Why we don't hire programmers based on puzzles and tricks

#411
post #403

Earlier quoted context omitted.

It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se. You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could…

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge: 1) That a string is implemented as an array of characters. 2) How to reverse an array. The implementation is straightforward and should be trivial for just about anyone who's done much development. I don't know that the question is…

Fair enough.

Here's my solution:

def reverse() {

    def a = "Can a fella get a job?"
    StringBuilder b = new StringBuilder()

    for (int i = a.length(); i > 0; i--) {
        b.append(a.charAt(i-1))
    }
    print b.toString()
}

But it doesn't use arrays because quite frankly, I haven't used an array in years. I despise the noise of the brackets. :-)

Seriously, I use ArrayLists instead of arrays. But even on this FizzBuzz lite exercise, I got tripped up. My "i > 0" was off by one. And I started down the path of a.substring, but that was a bad move. I quickly switched to charAt.

But about the only relevant piece of this: on an IDE, I was able to place a breakpoint, see where I'm at, what my variables look like, and make adjustments.

That's real life. My original cut of this would have disqualified me. Actually, even the cut above would disqualify me since I didn't use arrays.

But I need to confess. What you see above is literally the first time I've ever reversed a string in this manner. It's just not something I do. And it didn't roll off the tongue so to speak. I knew I had to process the string from the end and work backwards, but it still felt like trivia and not a substantive inquisition into my skills or experience.

Trivial? A bit. It took me about 5 min. The off by one was killing me. It hits you in two places: the i > 0 and the charAt(i-1).

Re: Why we don't hire programmers based on puzzles and tricks

#412
post #403

Earlier quoted context omitted.

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge: 1) That a string is implemented as an array of characters. 2) How to reverse an array. The implementation is straightforward and should be trivial for just about anyone who's done much development. I don't know that the question is…

Fair enough. Here's my solution: def reverse() { def a = "Can a fella get a job?" StringBuilder b = new StringBuilder() for (int i = a.length(); i > 0; i--) { b.append(a.charAt(i-1)) } print b.toString() } But it doesn't use arrays because quite frankly, I haven't used an array in years. I despise the noise of the brackets. :-) Seriously, I use ArrayLists instead of arrays. But even on this FizzBuzz lite exercise, I…

That isn't a bad solution. You obviously hope that someone you're interviewing can come up with something like that fairly quickly, but I certainly wouldn't disqualify you based on your method of solving it or an initial off-by-one error.

> What you see above is literally the first time I've ever reversed a string in this manner. It's just not something I do.

There is a certain amount of value in that - seeing how someone reacts to and solves something they've never seen before. Can you come up with a reasonable plan for attacking the problem, implement it, test it to see if it works in a bunch of cases, and make the necessary adjustments?

To be fair, the coding you do in an interview is a bit artificial - the problems may not be typical and you are without the environment you are usually coding in. The good news is that it is a skill that you can work on and become better at, and it is usually worth doing so if you are pursuing a job and you know these kinds of things will come up. I don't think it is wasted effort either - I've been trying to work on my algorithm/data structure skills by solving interview-type problems, and I've noticed that the work I've been doing to learn to solve them better has been beneficial in my daily programming as well.

Re: Why we don't hire programmers based on puzzles and tricks

#413
post #365

Earlier quoted context omitted.

Work is social. What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! If you want to work for a web services company: what are you g…

You're just lumping two different things together. Everyone has performance anxiety at times - whether rare, mild, common, or occasionally overwhelming it's something everyone deals with. Something like public speaking to a room of strangers or flirting with a super model really doesn't share many physiological triggers with diagnosing code you wrote while people you're friends with look on anxiously. Assuming that b…

> solve programming puzzles

Your argument all comes down to dismissing the content of the interview. Since you clearly assume the interview is worthless, you aren't even discussing this in good faith, so I'm just ignoring this post.

Re: Why we don't hire programmers based on puzzles and tricks

#414
post #403

Earlier quoted context omitted.

It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se. You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could…

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge: 1) That a string is implemented as an array of characters. 2) How to reverse an array. The implementation is straightforward and should be trivial for just about anyone who's done much development. I don't know that the question is…

Dood....I checked your HN profile which led me to your blog. You're talking about decompiling Java code and bytecode diffing. That's hot. See, now that is dev stuff. That's hardcore. Love it.

Re: Why we don't hire programmers based on puzzles and tricks

#415
post #403

Earlier quoted context omitted.

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge: 1) That a string is implemented as an array of characters. 2) How to reverse an array. The implementation is straightforward and should be trivial for just about anyone who's done much development. I don't know that the question is…

Dood....I checked your HN profile which led me to your blog. You're talking about decompiling Java code and bytecode diffing. That's hot. See, now that is dev stuff. That's hardcore. Love it.

Now, that was a puzzle :) It was pretty fun to diagnose, even if the knowledge isn't incredibly useful and probably a lot less impressive than it might look at fist glance. Figuring out how stuff works (and why it doesn't work like you think it should) is pretty fun - I wish I had more opportunities to do it.

Re: Why we don't hire programmers based on puzzles and tricks

#416
post #167

Earlier quoted context omitted.

A job interview is going to take at least a day of your time anyway. What does it matter if that time is spent programming, talking over coffee, sketching on a whiteboard, or whatever?

Pretend it's not tech, and Starbucks interview consisted of you working as a barista for a day, or Goldman Sachs wanted you to trade stocks for a day, etc...

Starbucks isn't going to bother to fly a potential barista to their location, have several managers assess their ability to perform as a barista, and buy them lunch. As someone looking for a job in the tech industry right now, if a company was willing to pay my transportation costs to interview with them and buy me lunch, I would consider that a fair deal. Even if I didn't get the job, I would be out a day or two of my time (during which I'd be able to scope out the city they were located in anyway) and they'd be out anywhere from hundreds to a few thousand dollars. If they got any value from my work while being assessed, I imagine they would want me on their team.

Re: Why we don't hire programmers based on puzzles and tricks

#418
post #44

Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…

I'm sorry but writing code on a write board, ever, is stupid. I'm happy to write out architectures on a whiteboard, but code, never. Asking someone to write code on a whiteboard is the equivalent to asking a UI designer to chisel wood to demonstrate their ability to develop a web UI. It's rediculous.

Re: Why we don't hire programmers based on puzzles and tricks

#419
post #418
post #44

Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…

I'm sorry but writing code on a write board, ever, is stupid. I'm happy to write out architectures on a whiteboard, but code, never. Asking someone to write code on a whiteboard is the equivalent to asking a UI designer to chisel wood to demonstrate their ability to develop a web UI. It's rediculous.

I'm sorry but you are incorrect. It is not equivalent. It would make perfect sense to ask UI designer to draft a design on a white board. Same applies to coding. You don't get the point. It's about seeing how the applicant thinks and communicates under pressure. The thinking out aloud part is more important than the white board part. Everyone knows this, except you?
Post reply on HN