Live data from Hacker News

I Hate Puzzles: Am I Still a Programmer? (2011)

zef.me

211–220 of 268 posts

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#211

>Four people need to cross a rickety bridge at night. Unfortunately, they have only one torch and the bridge is too dangerous to cross without one. The bridge is only strong enough to support two people at a time. Not all people take the same time to cross the bridge. Times for each person: 1 min, 2 mins, 7 mins and 10 mins. What is the shortest time needed for all four of them to cross the bridge? 17 minutes, if you…

In the real world, a light source has a useful radius of illumination. This could be exploited. If the useful radius is greater than half the span of the bridge, everyone can cross the bridge in exactly 10 minutes.

If the useful radius of the torch is 25% the bridge length, the bridge can be crossed in 15 minutes.

So the correct answer to the puzzle question is "how much of the bridge does the torch illuminate?"

Then the questioner gets flustered, and you can suggest, "Maybe you should have given them one set of night-vision goggles instead."

If you solve the puzzle as written, you can only be as clever as the puzzle-maker. If you can break the puzzle and then fix it, you must be cleverer.

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#212
post #174

Earlier quoted context omitted.

> Those people complaining about Google caring so much about their engineers being able to deal with basic algorithmic, instead, should wonder why every Google service is so fast. I imagine it has little to do with algorithms and everything to do with infrastructure. Most Google services (and even outside of Google - most services, websites, mobile applications, etc) are simple store data/retrieve data services. When…

Data in the magnitude that Google, Amazon, and Facebook handle doesn't work in standard databases. They have to develop their own data stores to manage it. Check out AWS's offerings, there's a lot of special-purpose services there.

That's great, but we're talking about a very small fraction of engineers who write DB systems. I have used some of AWS's DB offerings, and I didn't have to write complex algorithms to do it.

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#213
post #68

Earlier quoted context omitted.

> Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba. I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory". It it is p…

I distinguish between two types of puzzles: human-made (which I call puzzles) and everything else (which I call problems.) In those terms, I hate puzzles and love problems. Puzzles are contrived by humans and are generally as much psychology problems as anything else. They basically require you to think like the human who created them, and they have bizarre and arbitrary constraints that are totally unlike the real w…

Totally agree! Puzzles are just one way of studying human (or animal) behaviour in a controlled environment. It's absurd to be used as the main tool to evaluate a person's competence.

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#214
I hate puzzles. I hate puzzle/trick questions. I have been programming for more than 10 years.

Usually when I interview with a company, I am upfront with them when they present me with a puzzle as part of the interview process, and tell them that I don't do puzzles. If that pisses them off and thats the end of the interview, fine.

At least, I'm not wasting time acting like I love solving the puzzle, which the interviewer got to know online and wants to show off who's the boss.

On the flip side, if someone gave me a really tough coding assignment, and I failed to even get the basics right, I'll accept it gracefully, go back home and figure out what I need to improve at solving that problem.

Often, I have noticed that these tough interview questions are a way to satisfy the interviewer's ego, more than finding the right candidate for the position needed.

Those who ask puzzles for s/w engineering jobs don't really know how to interview a prospective candidate or what exactly to look for.

Unless you are interviewing for job which involves you being a Sherlock Holmes, there's no way your ability of solving puzzles indicates how capable you are with programming.

Really glad this is getting more visibility. Thanks Google for starting the Puzzle craze. (glad that they are trying to put an end to it)

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#215
post #132

Dijkstra commented on this multiple times (e.g., https://www.google.com/search?q=dijkstra+puzzle+minded+ewd+s... ). "I still often hear that a successful programmer should be 'puzzle-minded' whereas I have the feeling that a clear and systematic mind is more essential. A modern, competent programmer should not be puzzle-minded, he should not revel in tricks, he should be humble and avoid clever solutions like the pla…

Having seen people banning list comprehensions from Python because they are "too clever", I am wary of people who instinctively avoid "clever solutions".

For me something like list comprehensions is simply a matter of learning and expertise, not cleverness. Somebody banning them for "cleverness" reasons should be called out for what they are really doing: setting a (sadly low) knowledge ceiling.

The real problem of cleverness is when people are bored of being code monkeys and start inventing things that complexify their project without any legitimate justification. Like "a cron job and a two line shell script would do but why don't I design my own multi-tier scheduling cluster"

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#216
post #190

Earlier quoted context omitted.

I see this comment about "nerd", "geek", "ninja", etc. crop up a lot. These are solutions to the problem of "what term do we used to describe an excellent programmer, that both excellent programmers will identify with and other managers will emotionally relate to"? How would you solve that problem?

Why do we need to give programmers such punchy titles? I haven't heard anyone doing this in any other craft. In my view, calling someone a good, great, excellent, skilled, or top programmer as appropriate is more than adequate.

I am not arguing that programmers need to have "punchy" titles at all. However, others clearly that some sort of term beyond those you listed is necessary, and these names are evidence of that.

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#218

If you program, you are a programmer. By definition. I suspect what you're really asking is: why do so many companies thinking programming == solving puzzles? The answer is that: (1) Based on what you're defining as a puzzle, they don't. (2) It is valuable skill (but it's also not the only skill). -- (1) -- While there are stupid companies that ask "puzzles", this is not the norm at Google, Facebook, and similar comp…

First off, I've read most of your books. Great job with them! Now, your response seems fair enough and I completely understand what your trying to say. However, without going into specifics. How does an interviewee handle/convince an interviewer with a preconceived solution? For example, Interviewer A has an interview tomorrow and plans on asking this really slick problem that has one way of being solved well. A look…

Eh... it depends.

You could have a question that can really only be solved optimally one way but that still provides adequate room to demonstrate problem-solving skills (even without knowing the "slick trick"). Such a question could still be a reasonable question.

Of course, many questions with slick tricks aren't like that. The interviewers who ask these questions also tend to be worse, which exasperates the problem.

In the situation you described - the candidate might still be considered a good candidate. It depends what the interviewer is looking for.

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#219

If you program, you are a programmer. By definition. I suspect what you're really asking is: why do so many companies thinking programming == solving puzzles? The answer is that: (1) Based on what you're defining as a puzzle, they don't. (2) It is valuable skill (but it's also not the only skill). -- (1) -- While there are stupid companies that ask "puzzles", this is not the norm at Google, Facebook, and similar comp…

> He would be terrible at a company like Google. I don't think you can adequately back up that statement. Google is a massive company with very broad needs in each engineering discipline they hire for. My most significant criticism of Google's hiring practices is that they feed every software engineer through the same sieve. The sieve is calibrated as you describe, and that calibration is appropriate for many of thei…

I'm sure there is periodic work that you could tear off that fits the description of tedious and simple. That doesn't mean you'd want this particular person. Are you going to have him be a traveling coder, hoping in on only the tedious boring word? Are you going to have him travel with warning that he shouldn't be trusted to have to think about a problem because he'll do poor work?

I agree that Google doesn't make enough room for truly specialist skills. They should loosen up a bit.

You should also recognize that there are advantages to keeping the bar consistent. You essentially know that everyone you work with is smart and able to solve a problem well.

Hiring someone fairly unintelligent without any specialist knowledge into a company too big to allocate appropriate work wouldn't be a good idea. It works better in a smaller environment where you can ensure that he's getting appropriate work.

Re: I Hate Puzzles: Am I Still a Programmer? (2011)

#220
post #68

Earlier quoted context omitted.

> Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba. I would guess most "discovered" those because they had to interview. The % of programmers who need to Karatsuba or Bayesian inference to finish their project is very much smaller than the % of programmers who thought "oh shit, I better learn this because Google and Facebook keep asking about graph theory". It it is p…

So true; the Google, Facebook, Microsoft, Fill in Here puzzle interviews are pretty silly. Rather than splitting people into groups of "good developers" and "bad developers" they can really be split up into these two categories. 1) People who read Cracking the Coding Interview 2) People who haven't heard of this book. http://www.amazon.com/Cracking-Coding-Interview-Programming-... Seriously; any competent programmer…

As the author of said book who has coached MANY people, I can assure you that many - heck, most developers - could not pass a Google interview regardless of how much they prepared. They'll get better with preparation, but it doesn't just fix all issues.
Post reply on HN