Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

37signals.com

Post reply on HN
Print view View original

351–360 of 460 posts

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

#351

Post by grey-area »

danielweber wrote: post #338
grey-area wrote: post #330

Earlier quoted context omitted.

This is where I find questions like this a little confusing. To define better (at least in real world situations) the question requires more context. How many records? How are they stored? What are the characteristics of the storage? Which libraries are we using to store it and how do they behave (and in the real world there might be a few)? What are the other constraints? If we request a sort (say in a remote db) wi…

I think "do better" is a pretty obvious description, but if the candidate is having trouble with it, I'd say "you have a few million records, and your current mechanism is too slow." I have patience for candidates, but not an infinite amount. If they keep on trying to come with reasons why they don't need to improve their answer, or try to drown me in a sea of bullshit, that's a no-hire. I'm screening out assholes an…

Ok, I think that clarifies your intent, the question is purely hypothetical (many records, infinite resources) and designed to elicit the platonic algorithm given no constraints save time. You surely recognise though that 'improving' depends on the constraints which were not given? I find it curious that you characterise questions attempting to relate your problem to real world constraints as 'a sea of bullshit' :) Surely no one tries to avoid answering by asking for clarification of the constraints, wouldn't you normally face this problem with records in a db, not all in memory directly accessed? I'm not sure this interviewing game would suit me.

If sort first was too slow and it had to be done in memory, I would have iterated once and kept the results in an ordered list but not sorted the records during iteration as you have suggested, didn't think of that. Thanks for clarifying.

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

#352

Post by robomartin »

cletus wrote: 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 get it. That said, isn't there concern about candidates just cramming on the top 100 programming puzzles just to be able to ace such interviews?

I take a bit of a different approach. I want to know how they think. Pose a problem and collaboratively work through it on a white board. No code. Just state diagrams, flow charts, whatever.

Not looking for a solution. Looking for the thought process.

Then put up a piece of code. Ask the candidate to explain it and critique the code. How would you improve it? I'd expect them to ask questions like 'How do you define "improve"?'

I tend to be skeptical of the top 100 programming puzzles because I have no way of knowing if they spent the last two weeks training for just that or not.

You can even take the approach of posing a problem that has, on first inspection, nothing whatsoever to do with their job description. A seat-of-the-pants example would be to ask someone being hired for back-end web development work how they would go about designing a small multi-tasking OS for an small 8 bit micro-controller.

Crazy? Maybe. If the candidate launches into a description without prompt you know that this guy (or gal) either has experience outside of the web realm or is inquisitive enough to read and get into other stuff. If they do not, then you get to see how they go about stepping into something they know nothing about. Do they ask you questions or do they cave?

I don't think there's a single answer to this problem. If you need to hire programmers by the hundreds then, by all means, puzzles are almost a must. If you are after a few uniques, I am not sure they are worth it.

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

#353

Post by doktrin »

mamcx wrote: post #142
kamaal wrote: post #103

This is something to think about. The interview process is so badly gamed that these days its kind of a ceremony. In a recent interview, I gave a candidate a practical problem. He was allowed to use the sed man page, and then I gave him a file and search/replace problem. Nothing much! The candidate fails! Instead he asks me if there is going to be a algorithm/data structure interview. I told him, I don't know but as…

I do something like that. My first test is ask to reverse a string (not using the reverse function!) in any language and/or pseudocode. Is incredible how badly the test goes with the people! I interview for myself or others more than 100 people (of any background, including university, tech schols...) and I think only 10/12 people do it correctly - barely- To make it more fair, I always let them alone. And give inter…

Reversing a string is actually an incredibly common interview question. It's a bit like FizzBuzz (IME even more common, but I can't really speak about the world at large).

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

#354

Post by doktrin »

hackinthebochs wrote: post #297
doktrin wrote: post #274

Earlier quoted context omitted.

> most people (even around here) are insecure about their programming skill, and more-so their intelligence. > Instead of writing endless blog posts and internet comments about how useless these tests are ... just get better at them! You'll be better off for it. This doesn't hang together. Will getting "better" at programming tests & logic puzzles make you a better programmer? Make you more intelligent? If not, doesn…

It depends on your strategy for "getting better at these types of problems". You can cram and memorize all the algorithms you can, and that may allow you to pass some filters that you otherwise would not have. This strategy has its uses: besides being offered more jobs, you now have knowledge of these algorithms in your head and thus more tools in your toolbox. Ideally, the candidate would learn about these "exotic"…

Fair.

Speaking for myself, I have purposely avoided studying specifically for interviews. My reasoning was that by relying on my existing knowledge + logic, I would give my interviewers better insight into my thought process and approach to problem solving.

If the benefits of spending time with this material are as significant as you say, perhaps I will revise my strategy (or, lack thereof).

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

#355

Post by crazygringo »

dyno12345 wrote: post #334
crazygringo wrote: post #331

Earlier quoted context omitted.

I will tell you, back when I bartended in New York (10 years ago), it was pretty common to spend a day or two being "tested" as you made drinks for customers, until they decided you were worth hiring. You wouldn't even keep tips, since they'd test you out just on drinks made for tables, or whatnot.

Yes, but during a trial period don't you get paid?

Nope. No wage, no tips. In my case it lasted two nights only, and was paid the third night (and making the big bucks on weekend nights within a couple of months), but I'd heard of it being as long as a week at other places.

The worst part was, you wouldn't even know how long the trial period was -- they'd just ask you, last minute, if you could come in again for another trial. If it's a place you wanted to work at eventually, you'd say yes.

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

#356

Post by Aloisius »

tiziano88 wrote: post #15
potatolicious wrote: post #12

Damn right. Even worse than whiteboarding random algorithms are logic puzzles. I can sort of see how implementing my own hash table fits into a dev job, but I why manhole covers are round, or light bulbs in a room has absolutely nothing to do with anything relevant in our field. People who use logic puzzles as proxies for anything in an interview have my everlasting scorn.

I think that question about why manhole covers are round is more of a urban legend than anything else. Or it might be a question asked to someone applying for a non-technical role, to see how they reason about the issue (though it is most definitely not the best question to achieve so).

The question never made any sense. Lots of manhole covers are rectangular. As long as the lip of the manhole is round and small enough, it still won't fall through.

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

#357

Post by jervisfm »

michaelfairley wrote: post #277
steveklabnik wrote: post #265

Earlier quoted context omitted.

Also, it depends on which language you're using... $ irb irb(main):001:0> a = 1 => 1 irb(main):002:0> b = 2 => 2 irb(main):003:0> b, a = a, b => [1, 2] irb(main):004:0> puts "#{a} #{b}" 2 1 => nil (obviously this has the same flaw you mention, the interpreter is doing stuff for you. It follows the letter of the 'no intermediate variables' only.)

You can also follow the letter in C, Java, etc.: a ^= b b ^= a a ^= b

What does that do?

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

#358

Post by lucian303 »

pc86 wrote: post #114
donw wrote: post #80

Earlier quoted context omitted.

I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…

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.

Coding exercises (before even going in for an interview) waste an engineer's valuable time and in some cases a deceitful way for a company to solve problems it can't on its own. Asking people to work for free is ridiculous.

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

#360

Post by dmbaggett »

mds wrote: post #152
dmbaggett wrote: post #5

At ITA Software, we found in-person quizzing to be a lot less useful an indicator than looking at puzzle (or other) code someone had written "offline". We also found puzzles to be a useful talent magnet. If you're Google (or perhaps 37Signals) you don't need a talent magnet. If you're a small company nobody's heard of, one can be quite helpful.

Not that it matters anymore since this was pre-Google, but I swear to god, someone actually asked me the manhole cover question when I interviewed at ITA in 2010. This was for a DevOps type role, so maybe they were less well organized on that side of the house. At first I laughed because I thought he was joking until he I saw he was serious. He followed that up with something about stacking weights on a seesaw.

Not my fault -- that was after I was gone. :)
Post reply on HN