Live data from Hacker News

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

zef.me

221–230 of 268 posts

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

#221

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…

> but fails to reach the "cool" solution

I think it is rare for an interviewer to have a "cool" solution in mind and reject a better (or as good) solution. If they did I would be suspicious of the quality of the company.

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

#222
post #190

Earlier quoted context omitted.

I agree. >>> I don't have a GitHub page, nor do I have an interest in having one. Glad I'm not the only one. >>> I don't care about hackathons or solving puzzles. Couldn't have been said any better. I never produce anything good when its tightly timed, under pressure, when people are watching over you. >>> I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting. Add "ninja", "guru", "rockstar" a…

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?

I just say they are world class programmers. Or excellent. There is no problem. How do you describe doctors who are very good at what they do? Do you call them ninjas? "Med nerds"?

You're claiming there is a problem here that doesn't exist. We have words to describe people who are good at what they do.

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

#223
post #216

Earlier quoted context omitted.

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.

There is no need for those terms. They are marketing names dreamed up by people who think they can neuro-linguistically trick developers into thinking working for them (usually for less money than they are worth), then they can get over on them.

Again, what is the difference between a doctor who is one of the best in the world versus a doctor who is just 'decent'? What is the term that is necessary to describe that doctor that doesn't exist? Why would any profession be any different?

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

#225
post #190

Earlier quoted context omitted.

I agree. >>> I don't have a GitHub page, nor do I have an interest in having one. Glad I'm not the only one. >>> I don't care about hackathons or solving puzzles. Couldn't have been said any better. I never produce anything good when its tightly timed, under pressure, when people are watching over you. >>> I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting. Add "ninja", "guru", "rockstar" a…

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?

What's wrong with "excellent programmer"?

Other fields seem to have managed to solve this problem without resorting to sophomoric faux-titles. It just reeks of childishness and the sort of tomfoolery that tends to get our profession laughed at.

When I see these words, it screams either "bunch of young kiddies" or "a bunch of olds desperately trying to seem cool" and neither are situations that I want to get involved with.

And all of this isn't even getting into the problem that 99.9% of people want rockstars, ninjas, jedi and superheroes but only about 0.1% really need them.

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

#226

>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…

I think the purpose of the puzzle is one of resource management. It's not a hard puzzle, and I think that it's too easy to try to overthink it to sound smart, like you've done. The reasonable assumption is that the four people are on one side of the bridge, and you want to have them all on the other side of the bridge. The simple answer is that the person that takes 1 minute to cross goes with all of the other people…

"The reasonable assumption is that ..."

Sometimes these questions are explicitly asked to see if the candidate will check the assumptions when there can be more than one, even if one is fairly obvious.

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

#227

Earlier quoted context omitted.

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.

I suspected that this is true, thanks for confirming.

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

#228

Earlier quoted context omitted.

Start using regex in your text searches while programming. It will make you more productive (especially when you start using it with search-and-replace) and you'll learn regex properly. Please don't parrot that Jeff-Atwood-nonsense. EDIT: I don't care if you ever actually use regex in a program. You should learn regex just as a part of using a text editor. For example, suppose I want to write a bit of repetitive code…

I do, if it will actually save me something. Usually, I don't need anything that actually requires me looking up or constructing a super complicated regular expression. Per your example, I code in a functional language. I'm even less likely to make a mistake if I just reuse the function, than I am to apply a regex.

You don't have to look up how to use regex if you know how to use regex. If you just learn how to use the tool already--which isn't very hard, the syntax is quite limited and the salient points are nearly universal between all regex engines--then the stuff isn't "complex". It's as complex as C or Javascript or Scheme was on your first day of learning it. Less so, because there is less to learn.

The example is arbitrary. The point is, sometimes you end up writing repetitive code. Yes, even in functional languages.

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

#229
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…

Actually I think graph theory is pretty important. For example many programming contexts have to deal with dependencies, and often dependencies form a directed acyclic graph. Understanding that will aid in writing better, more reliable code. Path finding is also pretty important, especially if you want to make a game.

I used some super simple graph theory recently to write a Java tool that spit out data from multiple tables on a database into SQL files, with statements in the right order so that foreign key relationships were preserved. And this was for a CRUD-ish web app.

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

#230
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…

An interesting heuristic difference between the two types of, lets call it, challenges, is how you define success.

In a puzzle, you achieve success as a well defined solution, or (in a lot of the theoretical cases) by showing no such solution exists.

In a problem, there is many goals to balance (simplicity, efficiency, cost, implementation time, etc). Often, the best solution is not needed, or the "optimal" one is too complex or takes too long to implement. Often, the perfect solution is not possible, and you have to think about how to change the definition of the problem to get something acceptable.

Post reply on HN