Live data from Hacker News

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

37signals.com

251–260 of 460 posts

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

#251
I'm going to avoid the cultural flamewar around whether companies should do this.

I don't mind it. I've interviewed for enough jobs and had enough acceptances and rejections to learn something: it's not a big deal. If you don't know an API function, you don't know it. The likelihood that you won't get the job because you didn't know that one question is unlikely.

In fact, part of the evaluation is whether you can handle not knowing the answer with grace. The fail-outs are the ones who use their cool or seem to think the question is stupid, not the ones who get it wrong.

Once you realize that you don't need to get all of the answers to pass an interview, it gets easier.

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

#252
post #222

To change it up a little bit, has anyone here been asked simple debugging questions? I've interviewed at numerous places and I've never been asked the question why a certain piece of code is breaking or how to fix it. The questions could be designed to be self-contained and just complex enough to get a feel for how the candidate thinks. My consulting job usually takes me to places where a project is in trouble or fai…

I tend to think debugging is a pretty useful indicator of how well someone will do - the best developers I've known were really good at debugging, and I've seen very few people be good at debugging and bad at programming - so I usually try to incorporate a debugging question or two into my interviews.

I like to ask debugging type questions in sort of a role-play format. Usually I'll start with a symptom that an end-user might see and then allow the candidate to ask me for any additional information (as either the end user or a system admin giving them log files and other things) to help them narrow down what the problem might be.

It is a little tricky to make it possible for them to make progress without knowing anything about the hypothetical code base, but I like it because I think troubleshooting problems is a decent indicator of someone's skill and knowledge: Do they have a good approach to narrowing down where the problem is? Do they know what kind of information to ask for (for Java devs, I like to ask questions that lead them towards asking for thread dumps or heap dumps), which shows mastery of a language/platform? Do they ask good questions in general?

I've also seen people use printed stack traces and ask the candidate walk through what the stack trace is telling them and what the possible root causes might be - this is more useful when you want to test someone's knowledge of a specific framework.

Handing someone an application in a broken state and watching them work through the process of debugging it would seem like it would be interesting, but I've never had the time to prepare this for an interview.

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

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

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

#254
post #114

Earlier quoted context omitted.

I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. That being said, I've never done any pairing so maybe it would work better in that type of environment.

>I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. Yep. That basically amounts to an application fee.

Which is strictly forbidden in most jurisdictions.

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

#255
One of my career goals is to get a programming job without having to show that I can add a leaf to a binary tree through recursion (again).

I don't mean this as flippantly as it might sound. I used to think it was kind of fun and exciting to be at the whiteboard, thinking on my feat, dealing with various curveball data structures and algorithms questions. I certainly always read up on this stuff prior to interviews, and from what I've heard, I'd be advised to do it again if I get an interview at google or something.

But the last time I did this left me depressed. I realized that I've done so much of my work in obscurity that people are still asking me about binary trees. I want to be very clear that I don't blame them! I also started to realize that I have a lot more to offer than my ability to traverse various tree structures, and that the interviewers seem unaware of this. But it's up to me to show them, not on them to just take me at my word.

The last time I went through a massive, all day technical interview, I didn't get the job, partly because I didn't review my data structures and algorithms book (again), but probably also because I came off as cranky and irritated. I was busy that week, probably should have put it off.

Just earlier that week, I had taken several clients from pharma and semiconductor companies through some beta testing of our software, refining the model, getting feedback on use, optimizing the code base so it could give answers more quickly. The company I was interviewing for created supply planning, forecasting, and inventory management software for various large businesses. As a math major with an MS in Industrial Engineering and a background writing software, it was right up my alley.

My interviewers showed no interest in anything other than my ability to code or a couple branches of math. In fact, some of them seemed so inexperienced that I'm not sure they were aware that this kind of experience even exists to be asked about (Oh, you work with clients? Our project managers do that). At lunch, one guy asked me how to swap two integers without creating a third integer. This is after a full morning of technical grilling on math and programming, with a lengthy afternoon to follow.

Fortunately, I'm now in a job where I am encouraged, not just allowed, to contribute to open source, do presentations at conferences, try to build communities, and so forth. I would not consider any job that did not have this element (and now that I have a job like this, I'm not looking anyway). But if I were to look around, I would vastly prefer to be hired for my known and widely used code base than for my ability to detect cycles in linked lists, implement a hashing function, or print out all possible permutations of a string (with no duplicates!).

I'm not there yet, but that's my career goal.

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

#256

Earlier quoted context omitted.

The entire point of FizzBuzz is to filter out the people that say they can code but clearly cannot. This is a surprisingly high number of applicants, unfortunately.

I agree, I think FizzBuzz has this property, but I think it also has the property of filtering obsessive people as well. You might not want obsessive people either, in which case fizzbuzz is clearly a good choice.

I have sometimes in the past been obsessive to the degree you're describing, and the consequence was that, practically speaking, I couldn't do the thing I was obsessing about.

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

#257
post #241

Earlier quoted context omitted.

If you think it costs you something to be interviewed (thus your suggestion about an application fee) it certainly costs the company at least that much if not more. They are paying their staff to work with you on something that likely will not produce direct value for the company (usually a throwaway project or trivial task) Plus they will spend time before and after the interview discussing your qualifications, perf…

By this logic the candidate should pay half of travel and hotel too.

Usually the candidate pays all of it.

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

#258
post #162
post #124

Earlier quoted context omitted.

I really don't understand why manhole covers or stars in the universe puzzles are considered "logic puzzles". Logic questions are not of the form "why?" and "how?". Their structure boils down to "is this statement true or not?"

It is a poor choice of word. I'd suggest the reason for calling them "logic" is that the process by which you explain what you're thinking and why to the interview gives them an insight into your ability to use logic. The puzzles themselves are categorically NOT logic puzzles.

Yes, you need a little logic. But for those puzzles it is (arguably more) important to know some key facts about the world which form a basis for your reasoning. I don't know, maybe reasoning based on wrong facts will satisfy some interviewers. Say, I can assume that half the stars in the universe are visible from earth and that there is only one galaxy and reason from that. The basis is clearly false, but I will be able to show off my "logic".

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

#259
post #233
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…

> 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) Says who? My side project that I do on my own time doesn't use the same language as my day job nor does it tackle the same problem domain. How can this be construed as an intellectual property issue?

That depends on the agreement you signed. It's common for the invention assignment agreement you sign when you start working at a software company to cover anything you do, even on your own time with your own equipment, if it "relates to the Company's business, or actual or demonstrably anticipated research or development of the Company", or similar language. If your employer is a large company with its fingers in many pies, this could apply even if the work has nothing to do with what you yourself do for them.

California is unusual in that it has a statutory protection against the most expansive assignment provisions, but even it allows that provision. http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&#3...

Post reply on HN