Live data from Hacker News

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

37signals.com

441–450 of 460 posts

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

#441
post #435

Earlier quoted context omitted.

And at 1), you went wrong, in any language where strings are in unicode. Combining characters, byte order markers, surrogate pairs... And this is why I dislike the 'reversing a string' question. Because if you actually know anything about real world string handling, you know that correctly reversing a string is impossible, because there just isn't any logical way to reverse some constructs. How do you reverse a strin…

That is a really good point and it complicates a lot of string-based questions, which is why they are almost always constrained (either implicitly or explicitly) by assuming that the string is ASCII only, which seems reasonable to me. There are probably better filter questions to use that don't require as many artificial constraints.

Of course, in ASCII you can just reverse the bytes. Oh, until you come across a CRLF... Or a backspace... and it still makes no sense to even do it.

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

#442

As someone that just went through a whole slew of interviews I would say I agree with this to some extent. I'm a frontend developer and while CS principals are important, asking questions that are not practical to everyday development, are counter-productive and do not give you a view into how that person tackles a real problem. Things like "write a function that performs merge sort", are bullshit because you would n…

Merge sort is a bad example - it can actually be useful in real life, because the library sort functions are limited to what will fit in memory while merge sort is not. It's also simple enough to keep in your head without needing to look it up. I've had to code it up on the job more than once.

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

#443
post #407
post #399

Earlier quoted context omitted.

And you would have gotten an instant fail on the "cultural fit" criteria.

Good!

Just as a logic puzzle might be a bad predictor of how you'll perform on the job, it's probably also a bad predictor of the quality of the company doing the asking.

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

#444
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…

> whiteboarding code by itself is not a great filter. It should be used in conjunction with a multi-faceted interviewing approach that involves testing fundamentals, the ability to construct a relatively simple algorithm, the issues of working on a team and on a production code base and systems design.

This I can heartily applaud. However, I take issue with this:

> tests like the FizzBuzz test [1] are, in my experience, remarkably effective [...]

I'd never heard of the FizzBuzz test before, just tried it.

You may as well have asked me to sing the solution out loud. It was that bad.

Paper turned out to be a completely unfamiliar medium for coding, despite years of whiteboarding solutions with colleagues. I instantly felt like I was using a totally different part of my brain. I practically lost the ability to write with a pen and significantly lost the ability to code. My heart rate rose substantially with fear of the unfamiliar. This tiny test took me ten minutes, and when I checked it later I found a syntax error.

And that was in my favourite chair, at my desk, at home on a quiet sunny Sunday morning, working in a language I know inside out. Under pressure, with strangers, in an unfamiliar job interview room? I'd have just fallen apart completely.

Back at the command-line? 30sec in a one-liner in a language I'm still learning.

I will not be adopting this method to filter hires, having self-identified myself as a false negative. I am never out to embarrass someone in a job interview - I want them to show me their strengths! If they prefer it (they usually do), I'll give them a real computer and ask them to shine using that.

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

#445
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…

Reversing a string was initially a good interview question because in C you can keep probing multiple levels of knowledge with it. You learn if the interviewee knows the algorithm, then if they understand how to do it in place with a pointer, then if they understand the XOR pointer trick. It's not a very interesting problem in a language like Ruby or Python.

For that kind of language, what simple question do you suggest? My objective is test if the candidate have basic coding skills...

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

#446
post #243

Earlier quoted context omitted.

Actually, yes...they do. I work in a building with an elevator control system designed by an internal engineer. More importantly, the elevator control system uses mathematical expertise that is normally used solving variants of the multi-commodity flow problem, used extensively in the Supply Chain.

Heh, that's pretty cool. How does it compare to the average elevator?

Sib has it about right. It is an NP complete problem, and I'm pretty sure the solution is using a Heuristic, but it does seem to be pretty suboptimal during lunch time. Then again, maybe it just seems worse because you wait longer as a tradeoff to having a faster ride to your floor.

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

#447
post #250

Earlier quoted context omitted.

You mean ' '.join(the_string.split()[::-1]). Which is a totally reasonable thing to do, but doesn't exercise the same kind of thinking as doing it letter by letter. Can you solve it letter by letter, even now that you're not in an interview?

Doesn't exercise the same kind of thinking as doing it letter by letter? So what? Solving this problem in haskell doesn't show the same kind of thinking as solving it in PHP, whats your point? You basically saying you have to solve this problem they way I say you have to. Thats a sure-fire way to tell if the company is worth working for or not.

My point is that there's a difference between the knowledge of how to call a library function and the knowledge of how to write one. It appears that you lack both.

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

#448
post #253

I've been interviewing pretty much non-stop since last April. I feel like I've become somewhat of an expert when it comes to interviewing processes. First off, as I've become a better programmer, I feel this fact is best shown in my opinions. When I first started out, if you had asked me my opinion of PHP vs Python, I would not have been able to say anything coherent. Now that I've worked with both technologies, my o…

The question is not hard if you are allowed to use extra memory: just tokenize into words, put them into array and reverse, then join them back into a new string. It is harder to do it in place. I actually did not believe it was possible until looking up the answer on StackExchange. That solution involves a "trick" which one might not figure out under pressure.

I think you can do it in place with four pointers. The "trick" is somewhat generally applicable.

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

#449
post #3

I think in addition to the measures he says, if you're hiring for a web position, it's good to make sure they understand how the stuff they're using functions. If they don't have a good grasp of how http works / url parameters / that kind of thing, then they can have some nice looking code which seems to work, but has faulty assumptions that can be security and bug nightmares down the road. Of course, you could alway…

Of course, you could always take smart people and train them - but seriously, who does that anymore? The sad truth about this is that I think many companies are afraid an employee will leave shortly after receiving training. They fear that a competitor will entice away the employee without incurring the training cost. Of course, one way to avoid this is to make the work environment desirable enough so that no one wan…

This imply that the job market has given in to the consumerism habit of the rest of society. We all want to have everything right now, but the gratification of earning last longer with learning than with "being given". If that all makes sense.

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

#450
post #204

Earlier quoted context omitted.

"What is the big O time of heap sort?" vs "Would you mind writing a function that returns true if any two numbers in the list sum to zero? For example, it would return false for [2,3,5] and true for [-3,5,3]" Are completely different questions. The first is useless: It tests if someone remembers how a heap sort works, and whether or not they use the term "worst case" in the answer. The second one is much better. Some…

Very good illustration, I must say. I strongly disagreed with the GP's rant about knowing O-notation, but I realized he might have faced the first type of questions a lot (e.g tell me the O-complexity of X algorithm). My experience with Amazon was actually the opposite, but I might have been lucky. All the interviewers were very friendly and started from simple questions and went on to more complex ones. Never a "do…

That mirrors my experience with Amazon too. Although it was 3.5hrs of full-on whiteboard coding, I really enjoyed the process and felt like I learned a lot. 3 of the 4 interviewers were excellent.
Post reply on HN