Gnarly Programming Challenges Help Recruit Coders

Hugh Pickens writes "George Anders writes that companies like Facebook are finding that old-fashioned hiring channels aren't paying off fast enough and are publishing gnarly programming challenges and inviting engineers anywhere to solve them. 'We developed this theory that occasionally there were these brilliant people out there who hadn't found their way to Silicon Valley,' says Facebook engineer Yishan Wong who volunteered to draft puzzles so hard that he couldn't solve them. The problems aren't the superficial brainteasers that some companies use, like estimating the number of basketballs sold every year or why are manhole covers round, but developing sophisticated algorithms — like ways of automatically seating a clique of people in a movie theater, given that best friends want to be side by side and rivals need to be far apart. David Eisenstat has compiled an unofficial guide to the Facebook Engineering Puzzles. Our favorite: 'Liar, Lair,' seems particularly applicable to slashdot: 'As a newbie on a particular internet discussion board, you notice a distinct trend among its veteran members; everyone seems to be either unfailingly honest or compulsively deceptive,' says the description of the problem. 'You must write a program to determine, given all the information you've collected from the discussion board members, which members have the same attitude toward telling the truth.'"

Real world.

[clinko]

Given the number of comments take each post and divide by....

Got an email Hold on...

Management has now changed the comments to votes...

Given the number of votes FOR a post...

Email again, 1 sec...

We're now on a new project making a "facebook for insurance policies"?

An this way they again get non-engineer coders

[gweihir]

Quite frankly, solving these problems today should not be hard. At most a literature search should bring you the algorithmics. But what is hard is doing good, maintainable interfaces, writing high quality code, having a good design and a good architecture, having working defense-in-depth against attacks, etc. None of which a brilliant person without in-depth CS education and significant experience can do. This just keeps up the atrocious code quality responsible for so many data leaks and successful attacks. It also explains the high cost of software.

This is the wrong approach on so many levels...

(facepalm time)

[Quiet_Desperation]

'We developed this theory that occasionally there were these brilliant people out there who hadn't found their way to Silicon Valley/

Douche comment of the week right there. And I want to work with someone who has *that* limited of a horizon why, exactly?

what I hate about interviews

[TheGratefulNet]

is that they expect 'real time' answers to problems that sometimes need a bit of thought. its also ageist, as younger people can think faster (I sure did 30 yrs ago when I was fresh out of school) and are more familiar with classic compsci algorithms and problems. the more time you are away from those 'classic' problems and their cute solutions, the more time it will take you to re-invent them on their on. asking for that real-time while you watch is just too much to ask, for many of us.

this does NOT mean we can't solve the problem. but it does mean that realtime 'solve whilst I watch' is pure bullshit and a really stupid way to judge programming talent and problem solving ability.

Don't be too clever! :)

[Danny Rathjens]

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian W. Kernighan

That's Not What I'm Looking For

[Greyfox]

When I'm interviewing people, I'm looking for someone who will gather requirements before he starts trying to crap code out and a person who will get along well in my team. I'm looking for someone who's enthusiastic to talk to me as a potential future team mate and doesn't view me as an impediment to a fat paycheck. The questions aren't about whether or not you know the answer to every question. They're to determine if you meet the technical competence level to perform at the job and to see how you respond to being asked to perform under pressure.

In interviews I've conducted, I've had VERY few people who didn't view me as an impediment to a fat paycheck, who didn't think the questions I was asking them were bullshit and who actually tried to find out more about what I wanted when I asked them to design a function for me. Those people got hired. Some of the others did too, but always against my advice.

You want to do well in an interview? Try ENJOYING yourself there. If you're excited to be there and excited to talk to future team mates, they will sense that. If you don't want to be there and hate everything about the process, they'll sense that too. You can refine your technique all you want after that, but you'll always get more job offers just enjoying an interview than you will if you hate it.

PHP

[Weezul]

We're talking about a company who writes all their code in PHP. Nuff said.