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

31–40 of 460 posts

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

#31

Post by RyanZAG »

hippee-lee wrote: post #18
RyanZAG wrote: 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 companies who get tired of whining that there is no tech talent to hire.

I've never actually seen that happen. This is what happens:

1) Large companies will import H1Bs and/or open development offices in India and similar.

2) Startups will have the founders learn to code (this often ends well), or they will outsource the development work (this often ends badly).

3) Companies will hang outside universities at graduation/trade shows and try to grab promising students (this is mainly restricted to top tier universities)

You may have good examples of it happening though?

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

#33

Post by elliottcarlson »

notimetorelax wrote: post #22
elliottcarlson wrote: post #16

I've been on both sides of the hiring process - and most recently was going through the interview process again as I sought out my next opportunity. One thing that stood out to me was the way companies would approach the white boarding or coding challenges. While I agree with the articles issue with coding up a specific question (especially when it is yet another fizz-buzz - even if it has a twist to it) - the puzzle…

Do you think you can elaborate a little more on the exercise that you find interesting?

On one hand I would love to - and on the other hand I don't want to give this companies interview question away out in the open. If you want, you can email me (email is in my profile) and I would be more than happy to share it directly!

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

#34

Post by dcope »

thesis wrote: post #4

Ok... I was under the impression that 37Signals hired mainly remote workers. Could this account for the lack of a white board? Personally, I use a whiteboard when hiring. It's not the deciding factor... but it's a part of the bigger picture. As part of a small start up I need to know right then and there if they know what I need them to know.

Even though there are plenty of online whiteboarding tools, I'm pretty sure 37signals can afford to fly someone in for an interview. To say the lack of asking whiteboarding questions because they work remotely is absurd.

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

#35

Post by rdtsc »

csmatt wrote: post #13

I remember when I was prepping for my Microsoft interview. There was so much lore online as to the types of questions they'd ask and how to prepare. I even found 'How Would You Move Mount Fuji?' in the library and started reading through it. It was an absolute waste of time as I, fortunately, learned weeks before the interview. As an example, one of the questions I was asked was 'how would you write the C function st…

> and a lot of the more academic questions

It is on purpose. A recruiter confessed. He said they are specifically targeting recent grads. So plenty of questions are of that type.

I guess they want to indoctrinate and take advantage of them while they are "fresh".

> did like the question I was asked about how I'd design an elevator system and then asked how my solution would scale. That's not too far off from what I'd be doing, albeit in an abstract form.

That would piss me off though too. "So does Amazon write algorithms for its elevators?". Why not just simplify a problem they solve. "So you have key value storage and you want to make it distributed". Why even talk about elevators?

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

#37

Post by andrewvc »

csmatt wrote: post #13

I remember when I was prepping for my Microsoft interview. There was so much lore online as to the types of questions they'd ask and how to prepare. I even found 'How Would You Move Mount Fuji?' in the library and started reading through it. It was an absolute waste of time as I, fortunately, learned weeks before the interview. As an example, one of the questions I was asked was 'how would you write the C function st…

I generally agree, most logic questions are useless, but Big-O notation I use every day. Programmers who don't understand the performance difference between Array#include? and Set#include? in ruby are dangerous!

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

#38

Post by rallison »

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

Anecdotal, yes, but I have actually been asked the manhole cover question in an interview. Even if it started out as an urban legend, it does appear to be in use in the wild now.

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

#39

Post by buro9 »

The question I always like to ask and reserve a good chunk of time for is along the lines of "What non-technical hobby or interest do you have?" and then "If you had all the technical resources you could dream of, how would you now bring something new to your hobby?" and once we've gone through that the real question is:

"Given that when you're duck hunting the key is to shoot ahead of where the duck is, and that a lot of the suggestions have been the next iteration applied to the hobby/pastime... what's the third or fourth iteration?".

Basically I want to see the excitement and passion about technology, their pastime, and how they think, how they identify problems, solve them in numerous ways, go beyond just today's solution. And I get wrapped up in it too, I also get excited by some of the stuff that comes up.

With a great candidate... the interview ends with us both inspired and a thousand new thoughts floating around the room.

The vast majority of candidates cannot leap beyond the first iteration, and some struggle to even see how anything within their hobby could ever change.

Post reply on HN