I Hate Puzzles: Am I Still a Programmer? (2011) | Hacker News Reader

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

zef.me

436 pointslordbusiness255 comments

> I’ve been programming for 18 years now.

Then congratulations, you are a programmer!

Despite what you'll hear from people peddling various flavors of Kool-Aid, "programmer" isn't a personality type. It's a job description. If you program, you are a programmer, end of line, full stop. Don't let anyone convince you otherwise.

This. So much this.

I'm a programmer who loves 'building the brain'. I've been coding professionally for about 16 years.

I've written some code I'm really proud of. A couple of specific pieces of code are actually used in a LOT of major websites you probably use. Like almost every health care site or major retailer site. I actually find most code written by 'whiz' startups - even successful ones - to be incredibly simplistic. Not a knock on them, just stating this for reference - I have even written some encryption code that gave me headaches to understand but is still in use by a few major financial corporations years after I wrote it. I know I can write some serious code. I studied and work with AI programming in my spare time.

I don't have a GitHub page, nor do I have an interest in having one. I barely have a StackOverflow profile. I post on Hacker News now and again but that's about it.

I don't care about hackathons or solving puzzles.

I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting. I'm just smart and I like to code. I am not socially awkward. I'm introverted, but I'm not shy. I played football and basketball and I played chess. These concepts are not mutually exclusive.

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" and other hipster name floating around these days to your list. I hate it too.

I've been doing programming for 3 years on and off. I program for fun, as a hobby and I can't see myself programming to meet unrealistic deadlines year in year out for someone, that's my personal opinion. I grew up in an athletic environment so I also play rugby and sprint for fun too. The most I would do is to program small projects at my own pace and share them to people or keep it to myself. I hate rushing into things which I feel hackathons encourage.I like to think, research, think and then create.

I program because I generally like making things, not just programs but also technical drawing, house designs (architectural and interior) and custom-modded computer builds , it has no correlation to solving puzzles or cramming algorithms I probably will never use.

Edit: There is this insanely think barrier filled with confusion in Human Resources, as a recent Computer Science graduate, some of the job descriptions have unimaginably high expectations for entry positions I actually think you have no place here if you don't know 4+ languages, 2+ trendy frameworks, and 1-2 years of experience from a fresh graduate.

I wish programming culture didn't scare away people who enjoy athletics. I love playing basketball and sometimes it's hard to find other programmers who enjoy the same.

When I see "Ninja", "rockstar", etc. I run. Can't stand that.

We need more of this. I played baseball and basketball and yes, I also played chess. I'm not an introvert (although I do love alone time). This narrow idea of what traits a good programmer has is the fault of Eric Raymond who when describing what kind of person is a good hacker was clearly just describing himself (interested in martial arts, plays a musical instrument and speaks a foreign language, all perfectly great interests but what makes them better than cooking or chess or painting?). While it's great to have hobbies that involve critical thinking, nothing about the going stereotype of a programmer is necessary to be a good programmer or good thinker.

Imagine if there was an equally narrow stereotype about what kind of person is a good doctor or lawyer. Doesn't that seem ridiculous? What about programming is different? Nothing. It seems so absurd to me that as an industry we're telling interested parties that diverse interests are a bad thing if you're a programmer and you should just stick to a short list of approved interests. No wonder there's no diversity in our field.

I wish I had more than one upvote to give.

I work with a bunch of smart programmers who would, by the "if you aren't a 12 year old coder and you don't spend all your free time buffing your github profile" metric that pops up on HN, be unemployable. They are deeply, deeply clever people who speak assembler like a second language (or understand the bits of the JVM that most people don't think about, or what have you). They have lives outside their job.

Exactly this

This also applies to:

- Having a Github page

- Contributing to Open Source Projects

- Knowing (or not) a certain language

- Knowing (or not) a certain technology

- Knowing one of the latest fads

Of course, this affects whether you can work on certain projects or not, but not that "every programmer knows that" is a fallacy (except for something really fundamental)

Many companies have a hiring process that favors hiring very similar engineers. Hiring different types of programmers would increase their diversity, which for me is a great quality of a team. The challenge here is to identify the competent engineers when you can't use cookie cutter assessment tactics.

Diversity is a strength, and I have learned this managing several teams of varying sizes over the years for different companies, as well as for myself.

I have heard many start up advisers tell people to 'hire people you like to hang out with'. This isn't the best advice. Personality is extremely important, and you don't want to hire people who will be incredibly difficult or toxic or adversarial. But you need different people in different roles, with different viewpoints, to make a strong team.

I agree with you.

Suffices to see how several founders (of successful startups) were rejected or quit big companies. I believe Google is one of the worse offenders there.

Once upon a time I was a programmer, building CRUD apps for enterprises. I hated puzzles, too.

Then I discovered quicksort, and graph search, and Bayesian inference, and Dijkstra, and Karatsuba.

I'm still a programmer, but now I love puzzles, too.

> 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 perhaps an interesting secondary effect. CS concepts become useful not just because they are useful (and they are) but also because recruiters at many companies think they are. If tomorrow juggling skills somehow become popular during Google interviews. You'd see a lot of juggling programmers out there.

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 world, where, as Feyrabend told us, "Anything goes."

Puzzle-style interviews are 99.9% human made, and one of the features of human-made puzzles is: the answer is known and very nearly unique. This makes them almost completely unlike the real problems programmers encounter, where there is no known answer (if there was, the programmer would find it on Stackoverflow or similar) and amongst the potential answers there is no obvious winner.

So it's really easy to be good at puzzles and terrible at problems, which require taste and good judgment to navigate through the combinatoric explosion of approaches and parameters (and no, design-of-experiments won't do more than give you a little assist on genuinely hard problems.) Problems also require one to know when to stop, when a solution is "good enough" for the given domain. Even problems that are nominally non-statistical in nature require decent statistical knowledge to evaluate potential solutions.

So as someone who designed algorithms for a living for quite a long time, and still does for fun and profit now and then, I'm as strongly against puzzles as the OP. I'm actually slightly biased against people who love puzzles because it looks to me like they are spending way too much time playing with nice, neat pebbles on the beach, when the ocean of ugly, intractable problems lays unexamined before them.

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.

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.

I agree so much and I'm going to adopt your terminology :)

I think this explains why I hated school.

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 can crank through the stuff in that book in a week or two and be solid for the types of silly questions they will be asked in those interviews.

Honestly the best interview I ever had was one where I interviewed with a highly technical IT director and it was just very conversational. We spent about two hours of just chatting about the different types of technologies we had been working with and kept diving deeper and deeper into knowledge areas. At the end of it he just says, "Ok, you are obviously a smart guy; I'm going to send you over to see the VP now so you two can discuss salary requirements."

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.

Gayle,

Don't get me wrong. I made it through the Amazon interviews thanks to your book. I spent a week reading through and cranking out examples before the interview. Then I spewed out all of the desirable answers at each step of the interview process.

Now I'm a highly experienced developer with 15+ years experience across a variety of technologies. I contribute to open source, answer questions on Stack Overflow, present at technical meet ups. I solve problems that need solving even when no one else will step up.

Despite all of my experience, implementing hashes and sorting linked lists in place, as well as many of the other questions asked by these companies just don't come up on a daily basis. A good developer isn't someone who can explain those things in an interview, it is someone that can examine the problem and design a solution. They should have an idea of the tools necessary and then reach for the right book or use a healthy dose of google searching some api docs to build the solution.

The current interviewing techniques are broken. I would like to offer the solution, but quite frankly I've spent plenty of time interviewing people and we haven't gotten it down yet either.

-------

The ideas Malcolm Gladwell discusses in, "Blink: The Power of Thinking Without Thinking", applies here. Some of the most experienced developers will have an intuition for how best to implement a solution, this does not necessarily translate to them being able to well articulate the why and how.

So, you're a good developer who is smart and passed the interviews with some studying. That's exactly how it's supposed to work :).

You're right that the problems that some up in interviews typically aren't real life problems. But that's not necessarily an issue. Are the skills they test (developing good algorithms) important for real life?

An interviewer doesn't ask you to develop an algorithm to return a random node from a binary tree because they particularly care if you know THAT algorithm. They're asking as a way of evaluating your skills developing solutions to problems you haven't seen before.

I believe that is the most common argument made, but also therein lies the fallacy.

I'm not developing anything new when I implement a quicksort algorithm; Tony Hoare certainly was back in 1960 when he created it. The same goes for the hash; someone at IBM made a big leap when they first used hashes back in the early 1950s.

Since that time numerous people have made some improvements to these (and other algorithms of course), but by and large companies are just testing is the developer interviewing able to code existing algorithms and explain their Big-O notation.

I think you end up with 4 subsets that the interviewees fall into.

I = {interviewees}

A = {I | bad programmer and can't solve algorithms}

B = {I | good programmer and knows the algorithms}

C = {I | bad programmer but knows the algorithms}

D = {I | good programmer, doesn't know the algorithms}

It is subsets C and D that concern me.

In subset C we have someone that studied the algorithms really hard, but just can't write good code and solve real original problems. One approach to this is the "hire fast/fire fast" mentality, but in some organizations "fire fast" is not an option; so you would rather not hire them in the first place.

In subset D we end up missing out on good developers. In a bad job market there isn't much need to worry about this; if we miss a good developer easily enough we'll find another. Right now though developers are in such high demand I see this loss as a bigger deal.

I also think that this type of interviewing technique works better for the tech giants (MS, GOOG, FB, etc...) than it would for a lot of smaller organizations. A good set of programmers will self select out of interviewing at these companies because they don't believe they are "good enough" for MS(or alt). Additionally a good set of developers that do believe they are high caliber enough for these organizations will do some research about the interview process before hand and end up studying up on the right things before going in.

With smaller companies or businesses with non centralized hiring processes for developers interview candidates may just not know what to prepare for in the interview and while an algorithm may seem obvious in hindsight; there is a reason nobody was using it until it was "discovered". I can't reasonably expect someone to devise the answer to that type of question when I interview.

Honestly I would love to hear some ideas on this; as it has been a pretty major concern for me for the last couple of years.

I suspected that this is true, thanks for confirming.

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.

That's great if you're a game AI programmer (an incredibly small group) or you're creating Yet Another Dependency Loader (hey, I guess <language that becomes super popular next year> will only have 100 frameworks to manage modules, you'd better create your own as well).

You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.

> You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.

IME, programmers that write readable, maintanable code and those that have a solid grasp of algorithms and theory as it applicable to the problem domain tend to overlap considerably. Having a clear analytical mental model of the approach to the solution leads to clearer and cleaner code -- and, where necessary, clearer and more useful comments -- than hacking your way to something that works. (And I'd say thats as true of my own code -- where I've done work on both extremes of the clear model to hacking-my-way-through axis -- as of others' code I've seen.)

>>>learning to write readable, maintainable code.

Which is why I love python. Have you seen some poorly written JavaScript that's poorly indented and has no comments? Until there is a universal guideline for JavaScript and that developers follow, I won't have a go at it again.

Indentation is pretty low on the list of things that make code maintainable or not. (If it bothers you, just pass the code through a pretty-printer.)

Much more important is to pay attention to system-level measures such as modularity, abstraction, (de)coupling, and documentation. 99% of maintenance nightmares are due to code that is not modular (and thus not easily replaced), is abstracted too much or too little (leading respectively to obtuse or repetitive code), highly coupled (causing brittleness when assumptions are broken), or poorly documented.

(There are probably others, but these are the first to come to my head. These measures are also not necessarily orthogonal.)

Your comment comes across as bitter and sarcastic. It doesn't sound like you like being a programmer.

Agreed. Some people say you'll only use it in games or AI or something fancier, but that's not entirely true. I work with what would be considered pretty boring enterprise software, and yet I once solved a pretty big problem using graph algorithms. That actually earned me a good reputation among my coworkers.

I don't think the primary complaint about these types of skills is that they are never useful. It's just that they are treated as disproportionately important, i.e. interviews consist of 80% CS knowledge but the real job only requires it 1% of the time on average.

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.

This is very similar to the behaviour that Keynes described in the equity markets: http://en.wikipedia.org/wiki/Keynesian_beauty_contest

I don't get why people tend to think that computer science is something different from "actual programming". In the end everything you can program can be expressed formally and vice-versa, the only thing that changes is how much you abstract from the actual implementation, which is handy in order to catch defects in the approach you are taking to certain problem.

It's not the subject matter per se, it's the difference in habits and typical incentives for people who identify more with one description or the other.

For many products and businesses, it's not really necessary to avoid long-term dead-ends (say 3-5 years) if you can be much more effective in the short-term (say 3-12 months). So a high up-front cost (required knowledge and planning / research experience) approach often loses out to simply banging out more code, which requires little CS knowledge.

Because everybody can do "actual progrmaming." Especially in grad school.

Computer Science is broad (even AI is different), but I'd say it's more about Turing's academic papers, and computational mathematics. Programming, and computers, aren't even needed, they're just models which either can or cannot derive solutions, or in a reasonable time. Such as the halting problem, P, NP, NP-complete.

In a way it's mathematical logic, but with more rigorous proofs.

Everybody else can learn a generic language with some external libraries and make almost anything they want. But that's not more academic than it is to do woodworking, or sewing. Comp Sci is academic, and one of the more important ones because it determines a lot of research other disciplines do. I.e physicists and mathematicians do comp sci, while the softer sciences run models without understanding why they work.

As Knuth pointed out, "computer science is no more about computers than astronomy is about telescopes"

Dijkstra

Thanks I knew that didn't sound righht

The difference between computer science and programming is analogous to the difference between physics and architecture.

I'd say fluid-dynamics and plumbing. Most businesses really just want us to connect this to that and not have the shit back up. If you can deliver that quickly, without much analysis, and without fuss than you're very effective for many business and product types.

I would say engineering

Algorithms and puzzles are different things.

If I asked someone what is an algorithm and they replied 'it's a puzzle where you solve...", I would laugh my ass off.

Algorithms are not puzzles, they are solutions to puzzles.

OK, so it would be ok if an interview someone replied "algorithms are solutions to puzzles" ?

I don't think they are. They are solutions to problems in computer programming. Solving computer programming problems has nothing to do with your aptitude in solving puzzles and brain teasers.

Unfortunately in today's climate it might be realistic to say "algorithms are solutions to interview questions" Although I do believe the more tools you have in your toolbox the better. Knowing algorithms can be incredibly helpful. Same goes for design patterns, language design, etc.

It just seems like a fad to drill people with algorithm questions in interviews even if that skill will never be required for the job. I suppose it reveals to a certain degree whether that person has formal CS training or a personal interest in algorithms.

Algorithms are independent of both puzzles and computer programming. I learned plenty of algorithms in my EE undergrad that were used with a pencil and paper.

Would you disqualify a candidate based on that one data point? If so, I think you're missing good hires, and not in some false-negative preferred to false-positive way.

By discovering puzzles you are still a programmer, and you are a better programmer for it. Make no mistake. Yes you don't need to know algorithms to be a programmer, but you are better programmer for knowing the algorithms.

As long it is

>>I'm still a programmer, but now I love puzzles, too.

Its perfectly alright. But this generally becomes.

I'm still a programmer, but now every one should love puzzles, too.

As a self-professed "boring" programmer, I think a lot times I'm extra useful on a team because I don't expect my work to be a fun puzzle and I'm willing to take on things that aren't much like a puzzle, but are still important.

Yes. We need to stop thinking of programmers as artists and more as artisans. This is not a devaluation, this is exactly what it is and a very necessary job. Each shoemaker used to be proud of his shoes, even though there are not so many different ways to make them. Less so in the early modern ages.

I think there are categories, and we haven't figured out what to call them yet or how to define them. I see archetypes emerging over the years, and patterns. I've worked with career programmers that are done at 5:00pm, and never crack a book. They work fine in their niche, and when layoff come, they're working tech support. I know others that love problems but can't seem to make their ideas become manifest, yet kludge snippets from StackOverflow to create a product. I personally live for challenge, I learn new languages and tech as a hobby, and lead growth and change in every org I've worked for. Often at the cost of health, and relationships. We're all programmers, but we're not all the same.

> We're all programmers, but we're not all the same

Which is a rebuttal to something I didn't actually say, but OK.

Look, obviously there are all different kinds of programmers. Millions and millions of people program computers today, so there's no end to the ways you can slice them apart. There are kernel programmers and GUI programmers, mainframe programmers and mobile programmers, Lisp programmers and BASIC programmers, elite programmers and n00b programmers.

But they are all programmers, was my point. They all do the work of wrestling with, as one of the people in Tracy Kidder's classic The Soul of a New Machine (http://www.amazon.com/The-Soul-A-New-Machine/dp/0316491977) called it, "La Machine."

In this respect, being a programmer is a lot like being a coal miner: you become one by doing the work. Sure, some miners are handier with a pickaxe than others, and some can stand being down in a dark hole for longer. But regardless of that, everyone who puts on a hard hat with a lamp on it and goes into the mountain is a coal miner. The only thing you have to do to earn the designation is show up and do the work.

Now for the part of my comment where I (respectfully) challenge your conclusions.

You want to divide "programmers" further, into (essentially) "programmers," who are lazy 9-to-5 stumblebums, and "REAL programmers," who code with burning fury 23.5 hours a day (the other .5 hours they spend on HN). And then tell the people outside the "REAL programmers" category that, sure, they're "programmers," but they're not programmer programmers.

But that has a value judgment embedded in it, namely that 23.5-hour-a-day Burning Fury programming is Good Programming, and 9-to-5 programming is Bad Programming. But those positions aren't good or bad, they're just embraces of different sets of tradeoffs. You note yourself that the Burning Fury programmer sacrifices her health and relationships to get to that level. The 9-to-5 person is just someone who has decided against making that sacrifice. Maybe that limits their career growth, but it lets them hold on to those things. Maybe you've decided to let those things go in order to accomplish more in your work.

And both those decisions are fine! I'm not here to tell you how to live your life. I'm just saying that your way of being a programmer is not the only way of being a programmer. There are lots of ways to be a programmer. The only thing they all require is that you do the work.

Without calling one group "REAL", it would be nice to have different words for different tiers of programmers.

And I can't comment on the poster above, but when I do think of programming skill tiers, it's not at all about number of hours put in.

Yes, if you're passionate about a problem it can mean you end up putting in extra time to solve it. But it's not about the time. It's about the passion.

Similarly, it's not calling the leave-at-5pm programmers lazy. To them it's a job, and maybe even a job they're good at. I spend a lot of time living life outside of work, and I (usually) end up quitting after only about a normal day's work.

But I also get more done in my work day than 98% of "programmers". And the reason is that I've had a consuming passion to learn about programming techniques, tools, algorithms, and even logic puzzles, ever since I can remember. So some of that free time involves reading about programming; if I enjoy it, then it certainly counts as living my life. When I don't feel like learning something about coding, I do something else in my varied set of hobbies and interests.

The reason it would be nice to have different words for different tiers of programmers is that what I do is qualitatively different than what the copy-and-paste JavaScript writer is doing. I can certainly call myself a software engineer, or a game developer, or a graphics engineer, or a low-level programmer, but none of those really encapsulate it all; I also hit high performance server development, database optimization, networking, encryption/security, video streaming, and petal-to-the-metal assembly language optimization when necessary (though that's a skill that's less and less useful these days). And on top of that I write tools that help optimize the software development process for myself and my team.

When I look at what I do vs. what a junior front-end web developer does, calling what I do the "same" as what the junior developer does is somewhat akin to calling an assistant handyman and an engineer who designs skyscrapers or rockets or nuclear reactors "both engineers, because they both help build things!". All that extra work the engineer puts in to learn and hone his trade should be worth something, and having a title for it does help.

Something that bothers me about your coal miner analogy: The best possible coal miner is likely not more than 2x-3x better than the worst. Brooks' famous 10x performance difference only captures a small part of the real difference: There are things that I can do that a JavaScript developer simply can't do, no matter how much time they put in. Brooks was only measuring people trying to accomplish similar tasks, after all. And I'm not talking about domain expertise; I also follow and keep up with JavaScript and front-end development, and it's just orders-of-magnitude simpler than what I code on a weekly basis.

And I do find that puzzle solving (though not the physical kind) does correlate pretty well with the ability to do the high-end, hard-core programming that I do. I certainly am good at both, and it would be hard to imagine how I could solve the complex algorithmic issues that I solve on a daily basis if I couldn't think clearly about logic puzzles.

I take offense at your gross misconceptions. JavaScript is by no means an "easy" language, certainly not orders of magnitude easier than whatever it is you do. The skills of a "JavaScript developer" include combining object-oriented and functional design patterns to organize a codebase, efficiently managing asynchronous communication and state, profiling and optimizing rendering and execution performance across the CPU and graphics card, designing and implementing for network security (including testing for HTTP headers, XSS, CSRF, etc.). What is it you do again?

JavaScript can be used to do complex things.

A "copy-and-paste JavaScript" developer, as I referenced above, is someone who can create web pages that have simple actions, but who doesn't do much original development.

The language certainly doesn't define the programmer. I also use JavaScript on occasion; I wasn't trying to paint all JavaScript developers with the same brush.

It sounds like what you do is NOT what I'm talking about, so please don't take offense.

I write games, and tools to make games, and tools to stream interactive applications over the Internet. And apps. And the occasional web site.

Fair enough. I think what we do is probably pretty similar, the difference being that I do it mostly in JavaScript.

Perhaps there is something to your point -- I doubt there are nearly as many successful "copy and paste C++ developers" (although I have met at least one). It might be harder to cobble together even a barely-working piece of software from StackOverflow C++ posts.

I've met a copy-and-paste C++ developer myself, though he ended up losing the job eventually.

Blew me away to discover this when I sat down to help him debug an algorithm that he had, in fact (correctly) copied from somewhere else, but then he'd slaughtered it trying to "make it work." Most of the fixes involved reverting his changes, and then making a couple minor modifications that WERE actually necessary.

He'd been fighting with it for a couple days. I had it streaming sound in about 15 minutes. Based on his words to me after the fact, he was really just not understanding what the code was doing. Pretty much at all.

That said, he did have some good insight into user interface design. I could see that he did have some important skill sets, but understanding how to manipulate memory in C was not one of them. Whether he was a "successful" developer is debatable, since he didn't hold the position, though.

I'm sure that "copy and paste" developers exist for most common languages. I've heard from several sources that finding a non-copy-and-paste developer who uses JavaScript is a real rarity. I've also been told that Google in particular is looking for that skill set. Sounds like you could write you own ticket. :)

Hopefully I'm not contributing to the "schism" here, but:

I tend to divide programmers into "drones" and "meta-drones" (for want of better words).

First, "meta-drones" consider the "meta" level of programming, i.e. "could I program more reliably if I were using a different language?" or "how can I prevent myself from making similar mistakes in the future". Surprisingly few programmers actually fall into this category. This is obviously IME, so the usual observer/survivor biases may apply.

In contrast, a "drone" will just "get the job done" without any further thought.

As far as I've been able to ascertain, code maintainability/quality is entirely orthogonal to the "archetype", but there's a clear tendency that the "meta-drone" tends to improve by orders of magnitude over time.

The number of hours of work put in has no significant effect when you account for those orders of magnitude.

The best programmer I've ever worked with is done at 5. He has lots of other hobbies. But at work he's incredible efficient and solves really hard problems in brilliant ways. You don't have to give up your whole life to be a good programmer, contrary to what many people on HN seem to think. This mentality drives me crazy.

Agreed. I don't understand why we are so obsessed with putting in the hours.Its not just in programming, but also other sectors of the economy.I value my health, family and personal life, I'm competing with myself not against the clock. The clock will always win, no matter who you are or how great you are at programming. Work smart, not long.

> done at 5:00pm

I really don't like this euphemism. When I read this I know what you mean[0] but I wish this meaning wasn't tied to leaving the office at 5pm. If someone's effective in their role, why should they be judged on what time they leave? This mentality doesn't encourage people to work harder or be better employees, it only encourages them to stay later. That eats into their free time every day, giving them less opportunity to relax and recharge and probably causing them to become less productive and more prone to burnout in the long run.

If I can get my job done by 4pm every day then don't force me to sit at my desk until 6pm to keep up appearances. Either let me go home or help me fill my time by offering me more work (and if I'm highly productive, more compensation).

[0] The person is only putting in the bare minimum effort, has no interest in personal development, is more interested in the paycheck than craftsmanship and professionalism, etc.

In fact, Scott Adams proposed this in The Dilbert Future as a workplace scheme to improve productivity (he called it 'OA5'). He may be accurate in thinking it's up to the employer to destigmatise leaving 'early' (when in fact it's a symptom of an employee having a good work-life balance, providing his performance is sufficient).

However, I've been thinking about this recently - the logical extreme is that you should never expect the employee to turn up at work at all, provided he performs his tasks (say via telecommuting). Perhaps employers mandate 'desk time' because it's important to have regular physical access to the employee, for example in order to talk to him? I can think of HR/legal reasons where a private in-person interview is needed in order to inform the employee of something or to retrieve information from him. Consequently, if an employee only came in to work for these meetings, it would be obvious when the employee was engaged in some sort of 'serious' communication with the company. It would make mass layoffs especially conspicuous and difficult for the company to hide.

Nah you need to do a few coding boot camps and hackathons before you can call yourself one. Also, you need a git account full of forks of other projects that you haven't made any changes to.

Ditto if you don't like Star Wars, XCKD, comic books, etc.

Let's not get ahead of ourselves here. I'm pretty sure XKCD is part of the job description.

>It's a job description. Counter point: no, it's not. I coded professionally for 10 years. I'm now coding recreational for 29 years. (I'm 36, do the math) I contributed to various platforms, frameworks, libs, open source thingies. I have a shitload of code side projects. I'm the organizer of a quite popular code related meetup. I'm not a hacker, I'm a programmer. I don't code for money.

>If you program, you are a programmer I agree.

The problem isn't with him, it's with programmers who have an inflated view of how smart you have to be to be a programmer.

There are plenty of smart programmers, and there are plenty of problems that would benefit from smart programmers, but the vast majority of problems just need a spark of creativity and a lot of hard work from a person with a reasonable base of knowledge.

And then people don't know where impostor syndrome come from...

With a lot of BS being spewed on the net like "everybody needs to know how to unit test", "everybody should learn how to use Vagrant", "everybody should know Ruby", "knowing the SOLID principles is essential"

And then you ask them how to write a regular expression and they fall flat on their face. Or the basics of how to do a Fourier transform. Or how to draw something on a canvas.

Programmers SHOULD know how to write tests for their code. And how to write clean, well designed code (even if they don't call it SOLID). And they should know how to use regexps as well. These are skills that are transferrable whether you're doing frontend work for a small ad agency or crunching numbers for the NSA.

Yea I also think people mistake the tools for the trade. The fact is, two programmers can exist who know nothing of about each other's toolset, and they aren't necessarily better or worse, simply in different domains.

Vagrant is (can be) great if you need heavily spec'd out VMs, but with python I believe virtualenv would suffice. In the end, they are only tools

You realize that regexes, fft and canvas APIs can be seen as the same kind of thing - as simply tools - as unit tests, Ruby and SOLID (whatever that is)?

Some tools are usable in more contexts, but you can still lead a perfectly healthy life if you are in a domain where the ones you don't know are not needed.

Yes, that's the point.

My issue is the developers that say "true developers should know tool X" when for a large group of developers X is irrelevant.

SOLID is a set of (possibly questionable) religious principles often espoused by OOP programmers. It tends to boil down to "keep things modular and don't break abstractions", with specifics guidelines for dealing with objects and inheritance.

> SOLID is a set of (possibly questionable) religious principles often espoused by OOP programmers

Exactly my opinion

There's a good side to it, but it's mostly used for people to (in a cargo-cult way) abuse OO and replace simple computations with something spread over 5 levels of inheritance and lots of different types.

Whats more, I question the validity of equating smartness with puzzle solving abilities. It's a bit like equating quality work with having academic credential : no obvious link. Being able to discriminate the worker quality is still a non solved problem - at least not with number. Good judge of character are still way better at that - and well, they're pretty exceptional.

Definitively: Yes!

Everyone has their own preferences. Like you, I lose interest in puzzles after a few minutes. Whatever it is that gives some people great satisfaction out of finding that one missing piece, I didn't get it.

I can't speak to your experience, but for me, I like architecture. Finding the right way to glue pieces together is actually very interesting to me. I basically implemented reflection in C++ before I even knew that's what it's called because I thought it would be fun. I enjoy debugging and assembly optimizations.

What I found is that this speaks to the difference between a prototypical Software Engineer and Computer Scientist.

Engineers are interested in getting stuff done efficiently, and not just in CPU cycles--time for coding, training new coders, maintenance, extensibility, and how often the code will ever be run all must be taken into account. In my experience, grabbing someone else's solution via a package manager or using a 10-minute brute-force solution to a very hard problem can be the most "efficient". Just throw comments on it and avoid the puzzle so you can get something working. Of course, be sure to isolate the code so that if it ends up being a hotspot it's easy to fix later.

Computer Scientists, on the other hand, seek that efficient solution. Many of the PhD candidates I encountered were optimizing very specific cases of very hard problems (largely related to distributed computing). They enjoy spending time picking apart algorithms and understanding the problem so thoroughly that they can prove, confidently, that they have the most efficient solution to any given problem.

In the end, each broad category relies on its partner, and all programmers have to have some of both. Some of us just lean harder to one side than the other.

I don't think you can determine what kind of SE/CS you have by whether or not they enjoy (tabletop) puzzles.

I have always enjoyed puzzles (although I rarely do them)--I think it's a part of something greater. I like to complete all the achievements in games. I like checking off tasks in task lists. I like cleaning my plate at dinner.

They all feel the same to me, and have little to do with how I operate as a computer programmer (speaking as a web application developer).

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 plague" ( https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/E... ).

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"

The problem, of course, is that there are wildly different definitions/thresholds for clever.

Dijkstra's comment was made when assembly language was widespread, and I suspect that his idea of "clever" involved the various ways people can famously make assembly language unreadable.

In the introduction to "A Discipline of Programming," he asks if advanced language features belong to the solution set or the problem set, but he doesn't define "advanced," so I can't say where he put the threshold.

Every time I hear the "cleverness" argument I can't resist posting this counter-argument:

http://www.linusakesson.net/programming/kernighans-lever/

Puzzles are a terrifically poor way of judging whether a candidate will be good at performing the most common form of programming there is: solving meaningful problems, often business or interface ones, in a simple and readable way. Your primary audience for this type of programming is other humans. I'll take a good writer over a puzzle-solver any day. Don't get discouraged if they aren't for you.

> I'll take a good writer over a puzzle-solver any day

Absolutely agree, but I'd extended it to good communicator. Communication touches on so much of what we do as programmers, be it talking to customers, sharing ideas amongst a team or writing code in a way that's readable by others, that it should be a primary concern.

> Could you please solve this algorithmic puzzle within half an hour? I failed. Hiring decision made. End of story.

If that alone was the reason, then your interviewer did a bad job.

The point isn't to trick you. It's to see how you work under pressure when presented with a tough problem. What is your thought process? Do you dive right in or do you take time to chew on it? What parts of your background can you draw on to help you?

It certainly helps your chances if you can solve the problem, all else being equal, but I'd rather take someone who talks through their work but doesn't quite solve it over someone who solves it yet has trouble explaining how or why.

The best interview questions are layered. There should be a relatively easy solution solvable in multiple ways by anyone with experience programming. It should almost solve itself if you walk through the specifications. (Think fizz-buzz-level.)

But underneath that should one or two harder problems with very elegant solutions. And those are much more about the process -- about weeding out the people who would dive in without really thinking it through. If you make a mess of the whiteboard, get frustrated, start desperately erasing and rewriting the same things without ever stepping back to think through alternatives... well, that might be what I'd hold against you. It's not that you didn't solve it. It's that you didn't prove to me you could've given more time.

>>>If that alone was the reason, then your interviewer did a bad job.

Then most, if not all these of recruiters are bad. I like to think through things and take time solving problems. If I see myself doing something and struggling to complete it, I haven't thought it out properly or I have rushed into the problem.

Some people will call you "slow" which I find insulting. For example, When I read a book I like to read the actual sentences rather than skimming over them. I like perfecting details and that sometimes takes time.

I like taking my time too. The best solutions come to me after days or weeks of chewing on the problem in the back of my head.

Experienced interviewers know that this is how people solve problems. They know that time-boxing the problem is artificial, so they're not exactly evaluating you on how fast or slow you are within that time. The problems should be constructed in a way that lets them evaluate you based on your approach instead of on your solution.

Sometimes it's just a bad interview question, or not the right question for you, the interviewee. Which is why interviewing takes practice, time, and patience, from both sides of the hiring market. It's far from perfect, but more "puzzle"-like questions aren't entirely useless as long as the interviewer really knows what they're doing and how to guide the interviewee.

Silly question of course, anyone who has programmed for 18 years is a programmer. But the missed question is "Am I a hacker[1]?" And it is that which puzzles attempt to ferret out. Let's take the example of the 1000 piece Escher puzzle that the author uses as an excellent example. They are correct that most of the pieces are just 'shades of grey'. Impossible right? If you're a hacker you say "Challenge accepted!" if you're not you say "This is way more work than its worth." Because what the hacker mentality gets reinforcement from, is overcoming the 'impossible' (or simply the 'you can't do this') not the actual puzzle assembly.

So in the Escher puzzle a hacker says, "Hmm the picture isn't much help, its not on most of the pieces. What else can I use? Shape!" and so first will attempt to identify every piece that has a shape suggesting it is on the edge of the puzzle. Next puzzle pieces themselves have a certain symmetry, with some 'coves' and some 'penisulas' (or convex and concave curves, or 'innies' and 'outies') so unknown pieces are often sorted into the number of those features they have. Basically the hacker is looking for any piece of information that can inform on a possible way to get to the end, generally that information is non-obvious at first, more obvious once you find it. Particularly delicious puzzles will have several layers of information.

So if you don't care to figure out ways to solve a problem that is, at first glance, either really hard or nominally impossible to solve, you can still program just fine but you need a set of rules for putting together your code. And you won't find yourself asking if they are the best set of rules for the particular problem you are coding, you just make sure the problem is solved. That is a perfectly valid programming model, it gets things done.

[1] And I'm using the puzzle solving / bounds testing skill here not the application which can be applied to good or evil.

> if you're not you say "This is way more work than its worth." Because what the hacker mentality gets reinforcement from, is overcoming the 'impossible' (or simply the 'you can't do this') not the actual puzzle assembly.

Hmm, up until this, I thought I was a hacker. When I see a problem worth solving, I'll dig in and try different tools that I've never tried before and figure out a way to make it happen. I really resonate with what you said about not being deterred by the problem seeming extremely difficult or having no obvious solutions.

But I actively try not to work on things that are "more work than they are worth". Seeming "impossible" is not enough to me to make it worth. It has to actually provide some benefit.

This is not to say I don't still get carried away and attempt something which really ends up not being worth the time...

Fair enough, I see it as something of a spectrum. From full on OCD[1] on one end where once engaged a puzzle must be finished, drifting off toward zero (not sure how to compute the shape of that curve though). For the OCD person it is a compulsion, for someone just to the right of that, it is entertainment, further right its part of the job, and furthest right it is 'a waste of time and I won't do it.'

I completely agree with your point "When I see a problem worth solving,..." the only debate is computing the value. My original point is that as it takes less and less external motivation to engage someone on solving a puzzle/problem they exhibit more and more tendencies of what I associate with the moniker 'hacker.'

[1] Obsessive Compulsive Disorder

I consider myself a hacker, but I still try to manage my time and chose my fights. And I'm still way too much side tracked. There is absolutely no knowledge to be gained from completing the puzzle. You'll just train a bit your geometric pattern recognition, do you really want to invest days in that? If you're more in breadth than depth, then you can answer "no" without any shame, and just go learn something new. What if one day you need a good eye in pattern recognition? well the skill will itself increase with practice.

The only other reason could be the social aspect of intellectually interacting with is wife for long stretches of time, and it's in their couple to decide how to do that.

I dislike puzzles too. I guess because you're just finding the creator's predefined path, and it often feels like a pointless task. Programming is coming up with original solutions of your own, so I don't see the two as wholly related.

That is exactly how I feel about puzzles. They just feel like such a waste of time, especially jigsaw puzzles. What do you even do with them once you're done?

I came to say exactly the same thing.

A puzzle is a puzzlemaster saying "try to find the exit in this maze I devised!". But I'd rather build my own mazes that I'm more interested in, and then try to find the exits for my mazes.

If people find other people's problems interesting, then good for them. Mostly I find that my curiosity creates the most interesting puzzles, perfectly suited to what I'm interested in.

In other words, implicit in liking puzzles is the assumption that you care for what the puzzlemaster cares for. I find that double coincidence to be rare (for instance, Gardner's puzzles as discussed today here are mostly uninteresting to me).

Anyone have a not-dead link to the comic he's referencing?

(looking forward to a future where an image's URI is its hash and this problem evaporates)

Here you go: http://mu.ms/f/pxYcdb.png

People who feel that way in their day job should really try participating in the demoscene.

Lol, this made me laugh out loud.

This made my day. Quite weird how that's the case with programming.

The most challenging aspect of programming, for me, is the ability to turn something over in my head to look at it mentally. To be honest, I can only do that for any length of time on a good day. Writing stuff down is laggy and sometimes lossy, so I am only at my most productive when I can take a complex problem with a lot of little fiddly bits, ingest it mentally, and keep a holistic model in my head.

Puzzles provide a good first-order estimation of this ability. Not solving puzzles, per se, but at least analyzing them. A good puzzle requires you to use a part of your brain as "scratch space" to hold hypotheses which are applied to other parts of the puzzle. Can I solve it this way? What if I tweak this part over here? Does this assumption simplify the path to a solution, or miss out on an important subtlety? I think the thing I tried previously was more correct; can I remember how to get back to it?

I'm actually not that great at this. Many of my peers are better. Fortunately, I can compensate in other areas (I'm glad to see writing skills called out in the comments, as I like to think I'm a good communicator). I have developed some coping mechanisms (the ability to identify which details in a problem can be succinctly written down and which subset can be stored in my head -- I refer to my notebook as swap space), but I do see the value of puzzle-type questions for evaluating a candidate's ability to do this sort of thing.

Does this mean that if you can't do it, you aren't a programmer? Of course not. I happen to be a kernel developer, so I write a lot of code that communicates with other modules, doesn't have much of a UI, and has a multi-dimensional rather than flat structure. Different types of programming need different sets of skills. Find your niche, and don't fret about how you don't fit into other niches as well as you fit into yours.

(I interviewed at Google seven years ago and was rejected for being weak at algorithm design. A few years ago I had an aha! moment where I found a simple, elegant, and easy solution to the problem I completely bombed in the interview. Apparently my subconscious had been chewing away at it for literally years. I think solving a question in four years or so is sub-optimal from Google's perspective so I'm sure they were right to reject me, and my inability to do it faster speaks to the deficiencies I mention above. But in the ensuing years I have become reasonably successful in my current line of work, which I enjoy completely. My failure at Google does not keep me up at night.)

TL;DR: Puzzles only measure a single axis, so find which axis your greatness lies on and optimize for that.

I don't hate puzzles, but my brain just refuses to work on something that is not important to me. That's why I can't play go/chess well, I can't do sudoku and I can't solve algorithmic puzzles. Even when working on a real algorithmic problem, my brain just refuses to analyze whether something should be x or x+1. Those are things I can easily try and see.

I had a number of technical interviews last month and the conclusion was that because of this, I'll never work for a company that uses this kind of interview process. I just can't take the puzzle questions seriously enough to be good at them. But the experience also made me question whether I am still a programmer. Fortunately, I have written some algorithmically complex software to convince myself that I am.

>>> I don't hate puzzles, but my brain just refuses to work on something that is not important to me.

Another Human Resources blunder. I really would like to ask them, where and when am I going to use this in one of your ongoing project? If the answer is not related to the project, there is something wrong.

Google and Facebook long ago stopped asking (or at least now they discourage their interviewers from asking) puzzle-like questions in their SWE interviews.

They stopped asking brainteasers, they didn't stop asking algorithmic puzzles (some of which are arguably brainteasers)

...and which seem to largely be collected in the book Cracking the Coding Interview [1]. If you can answer all of their sample questions, you should do fine at a Google interview -- once your brain is used to the task of solving small algorithmic problems, it should get easier, even if the precise question they ask isn't in that book.

Easy for me to say, since I find problems like those easy; I cranked through a few dozen of them with only having to really think about a couple.

If you can't answer them all yet...well, now you have something specific to study.

[1] http://www.amazon.com/Cracking-Coding-Interview-Programming-...

That's true. I think the OP is talking about puzzles in the more general sense (e.g. designing novel algorithms). It seems to me that it takes a specific type of mental state to enjoy theoretical CS and math, since much of your time there is spent banging your head against things until everything clicks into place.

This discussion is going to be mostly meaningless because everyone has a different idea of what a puzzle is. Whether or not something is a puzzle depends on what you know. To a beginner, writing fizzbuzz is a puzzle. To someone with ordinary programming skill, it's not.

The question I usually ask in a job interview is an adapted version of something I actually had to solve, and if you don't know how to either use pointers or how to build and print a tree then you might think it's a puzzle. If you do then it's just applying your skills to the task at hand.

Maybe there are other questions I could ask, but it's a job interview; how else are you going to find actual programmers?

I hate "puzzle" questions where there's a single insight with which the problem becomes trivial, without which the problem is unsolvable, and it's a tossup whether or not you'll come across it in the 30-60 minutes you spend in a room with the interviewer.

I do enjoy questions where there the path to the goal isn't immediately obvious, but there are immediately a couple of approaches to consider, and even though the problem itself might be novel, the steps to get there are each something a competent person can reason about.

I don't know. I like getting close to code, because I like thinking about the people that make each symbol, establish a meaning, weave that into a language, where it is either contextually derived or explicated clearly. I like watching those things change and I like figuring out why some things stay the same. I like selecting words for new concepts, which I am never really sure of whether these things are arbitrary. When I zoom out and generalize enough, everything shares the same fuzziness, these symbols are all puzzle pieces. But when I zoom in, each puzzle piece is the puzzle itself.

I grew up enjoying puzzles, logic puzzles, logic books, math books, piece puzzles, riddles, and all the supposedly clever things to that affect. The more involved I become in the world of programming though, I can't really say.

I have the time to study the complex math and computer science theory sometimes, on the weekend, for fun, and then the code I read through ranges from deeply personalized learning to clear, uniform specifications developed over time periods I have no actual experience understanding what goes on during those time periods. I know the importance behind many theories, and I understand how to apply these things. But I don't know why or how it grew.

If you want to see a puzzle pattern in code, you will see puzzles everywhere. You can see anything you want to in code, just like every other human creation. Make your own meaning and what not. Code is more art to me than 'Art' is.

Does a lack of interest in solving (mechanical) puzzles imply you're a weak programmer?

I really don't think so: I think it all comes down to how you think - intuition versus logic. And I think people don't fall neatly into either category - it's a spectrum. Too much emphasis is placed in interviews on solving mechnicaly problems and less on problems that can be solved more suitably by itutition: design, feature improvements, re-factoring and some people (including me) I've found have to internalise the problem and can't just simply solve a problem as qucikly as those who are very mechanically minded.

And besides technically ability is part of being a professional(!) programmer working with others. The following should also carry significant weight: an ability to work with others, take criticism, lead others, be resourceful, get stuff done on time, write clean and readable code (not just solve the problem technically) and so on are from my(!!) experience not given enough weight!

Just me two cents.

This is a feature not a bug-- let me explain:

Recruiting is not necessarily easy. But you can judge a company by how they recruit people. Their hiring process-- given that talent is so critical-- tells you a great deal about the company.

If they do a terrible job, if they are arbitrary or capricious, or if they have discrimination as a policy (e.g.: I was in the room at Startup School when Zuckerberg said "don't hire anyone over 30, they just don't get it" (paraphrased).... then you know it's not a good place to waste your time interviewing.

I'd argue that the company with the puzzle saved you a lot of hassle-- you know they are arbitrary and did not put the effort into producing a competent hiring process, and this likely tells you that they won't respect you once you're on board as an employee either.

There are a great many of these "smells".

As I've gotten more experienced, and more in a position to be picky, here's my current gauntlet:

-- If they locate themselves in a place that guarantees a 2 hour commute for most employees, but don't allow working from home 3 days a week, or remote employees, that's a bad sign. Why pay for downtown office space-- as a startup, no less! -- when there's a lot of cheap offices out in the periphery where most people live? (That's the case in this town, maybe not in others.)

-- Asking for references. First off this is a legal minefield. A reference that isn't glowing is going to open themselves up to liability. Any well run business is only going to say you worked there for some period of time. And who is going to give people they think will give a bad reference? This one shows naivety.

-- Having a preference for ivy league. Google impeaches itself with this one in my mind.

-- Having a preference for ivy league. Google impeaches itself with this one in my mind.

This is one of the most common things I bump into when looking for a job, and Its not just Google. Its so disappointing because I didn't go to "insert_top_ten_university" because I couldn't afford it, competition was insanely difficult, and asking grades where so high.

I always ask myself if these companies that preach meritocracy and diversity is just lip service when all the folks mostly come from ivy/redbrick/Russell group universities. So disappointing.

> Asking for references. First off this is a legal minefield. A reference that isn't glowing is going to open themselves up to liability. Any well run business is only going to say you worked there for some period of time. And who is going to give people they think will give a bad reference? This one shows naivety.

I recently stumbled across two research-oriented companies that demanded references as a condition of reviewing your resume. I can't believe they get very many good candidates with a borderline offensive requirement like that.

Just imagine if every company did that-- your references would be overwhelmed with phone calls.

My policy, in the past, was that I'd give references after getting an offer, so that the references would only have to spend their time on a job I wanted to take.

I think some of it comes from our notion of human intelligence being universally applicable to all problems. Puzzles and chess are often used as a proxy for that. The thinking goes is that if you're smart then you'll be good at puzzle solving. If you're smart then you'll be a good programmer. It's not really something that has a lot of evidence for. One of the best career advice I've received is to interview with lots of companies but do it in the order of least wanted job first so by the time you're interviewing for the job you really want, you have had lots of practice. It works pretty well. Puzzle solving and programming are both skills that you get good at with practice.

Someone else already commented that if you program then you're a programmer. I think that's really the only definition you should use. Everything else are just proxies, mostly bad ones, for if you're a good programmer or not.

> ... if you're smart you'll be good at puzzle solving

There is some evidence in psychology that many seemingly unrelated types of intelligence are correlated with each other. For example there is correlation between verbal and spatial reasoning ability. Sure, there might be people who can solve differential geometry problems in their head but have terrible language skills, but those people are outliers.

Whether this has relevance to hiring programmers is debatable, but preferring intelligent candidates isn't an unusual idea. Law, medical, and dental schools base their selection on what is essentially a verbal reasoning test (LSAT, MCAT, DAT) though it's hard to imagine that verbal reasoning is the most important part of being a dentist. They follow the same thinking.

I really like certain types of puzzles - figuring out the causes of bugs, figuring out how to implement something in code cleanly and elegantly, figuring out how to make sure something is designed maintainably and intelligibly to spare future grief, figuring out the mysterious ways of programmers who wrote code I now maintain.

I also like figuring out and implementing the right algorithms for a problem, but it's a pretty small part of what I do at work, and if it's complex, it's something I like to take some time to think through and sometimes read up on to make sure I really understand what I'm getting into, so I really don't like playing the logic puzzle games they use in interviews at some places. Being quick with an algorithmic answer is a nice skill, but being a good programmer is a craft that involves more than cleverness with algorithms.

It is well known that the ability to solve mathematical puzzles was used as a screening tool at places like Google to screen new hires. It seems to me that this practice was based on the belief that there was an affinity or correlation between the interest and ability to solve mathematical puzzles and programming. I suspect there is such a correlation, but it is a weak one and is not useful as a screen tool for hiring which is why the practice has been dropped. But, jigsaw puzzles are not mathematical puzzles, so there may be no correlation at all there. I love mathematical puzzles, but I am bored with jigsaw puzzles.

So, since it is not the case that loving jigsaw puzzles implies "ability and desire to be a programmer", then the fact that you hate jigsaw puzzles implies nothing with respect to your status as a programmer.

Ok, but a jigsaw puzzle is sooo not the kind of puzzle that programming is at all about, even the explicit "puzzle" questions that companies like Facebook dish out.

I can't even think of one similarity between the two activities.

As far as jigsaw puzzles go, it would be interesting to see if there are unique ways to optimize your piece search.

There's the edge pieces and sorting by color. I've found that sub-sorting by pegs/holes can dramatically help - I had a "picture made up of pictures" puzzle which allowed me to correctly orient the pieces. Knowing even just two of the required slots, combined with the color, reduced the search to a reasonable brute-force search. Plus, by sorting the pieces you could actually do a brute-force without feeling like you might have missed a piece.

I personally dislike puzzles (of the toy/jigsaw variety), riddles, and so on. But I love solving problems when programming. A programming problem abstracted to a word problem is no longer fun - you've taken away half the toolset I have for tackling the problem. It's the synergy between mind and machine that gives me deep joy when programming - the fact that the tedious repetitive parts of mental gymnastics are turned into creative problem solving, which in turn leaves me more time for creative solutions to the problems that weren't repetitive.

People forget there's a distinction between Computer Scientist / Data Scientist / Software Engineer. They are not one and the same, and depending on your job you may only need to be one of those three categories. You don't need to know how quick-sort works create a CRUD web application, but you sure need to know how to write clear, maintainable code in all areas from the stack. But if that's all you know you can't expect to excel at a job like generating the Facebook news feed which actually involves theoretical knowledge.

I couldn't agree more with this article.

I pursued Computer Science in the hope of being recognized for the ability to create something NOT in the ability to regurgitate the most arcane algorithm in 45 minutes. Most interviewers KNOW they would NEVER like NEVER use it in production.

Yet, I'm not happy at my current job. What option do I have but to remember the 5th variant of the problem I saw in Cracking the coding interview? None.

Back to chugging. </rant>

EDIT: Thank you for writing this article! Till today I thought I was an idiot for not being able to solve 'that' problem.

Interview questions you don't like/fail shouldn't be viewed as reflective of you, but reflective of your fit at that company.

They asked a puzzle-y question you couldn't solve? Either their problems are puzzle-y, or they have terrible criteria for evaluating people; either way, do you really want to work there?

They asked a hard algorithmic problem, the kind that was someone's PhD thesis 30 years ago, and which you'd only get the optimal result to if you'd seen it before? Either they really do expect you to know stuff like that off the top of your head, or they expect you to behave a certain way when confronted with stuff you don't know; either way, do you really want to work in an environment with those kinds of expectations?

They asked you to code something hard withing a short time limit, and while you can code it, you failed the time limit; do you really want to work somewhere where speed is -the- criteria to optimize, rather than quality/maintainability/whatever (or at least where they're selecting for that rather than those other attributes)?

Etc.

In general, as others have said, if you program, you're a programmer. What specific roles you're a fit for is largely orthogonal to that.

If you don't pass a company's test, view it as having dodged a bullet, not having 'failed'; either they expect you to have something from day one that you don't have, or they are terrible at testing for what they really want, and so their culture, codebase, etc, is likely miserable. In neither case do you want to work for them.

You want to work for a place whose expectations for what you have on day one fits what you actually have (whatever they may be), -and- whose interview process tests for that (even if it's a little flaky), so both you and they can expect, going into the job, that you can handle it.

Remember, too, that there are false positives and false negatives even when they're testing specifically for what they want. Failure to figure out a puzzle doesn't even mean the person isn't good at figuring out puzzles; just that in this case, in this contrived, high stress set of circumstances (an interview), they were unable to come up with an answer in the time limit.

Agreed on all points.

But how would you interview a candidate? I see what not to do.

Here is what I do:

* Ask about their previous work. Dig into something they are excited or proud of.

* Try to solve a problem together. Usually a simplified version problem I am actually solving at the moment at work.

* If it is a new grad. I will ask them some simple questions about data structures, school projects.

* If there is any sample code, anywhere, I like to see it and it is a big + sometimes.

* See if and what kind of questions they ask.

Does that work? What would you add/remove?

I try not be a "dick" and take the approach of "ok, let's work on this together" approach because that is how things work here.

Another approach (which I don't like as much) is to go by the "we want to hire smart people" mantra. "smart" here is is nebulous of course. So how do you do it? IQ tests. Oh but those are illegal, so just write a tests that looks like one without calling it an "IQ test". That involves puzzles usually too. So I think that is how puzzles became popular.

Depends what you're looking for. None of the prior methods are -bad- if they're what you're looking for. I don't even object to IQ tests masquerading as not-IQ tests; it serves as a warning to me I don't want to work for you.

Depending how many applicants you get, I'd start with a screener, a basic, customized problem that they get an hour to solve, that doesn't have a hard pass/fail, but is just a "Hey, let's see how they code when given a problem". If you have constraints you want to filter for, now is the time (you want speed, see above. You want production quality, give them more time than you think a basic implementation would take, and indicate you want the thing to be production quality; see what they do, what they ask, etc).

If they pass that, yes, what you describe sounds fine, if it's what you're looking for in a hire.

If you want to favor false positives, ask a variety of fairly trivial questions; you're trying to make sure you ask questions they may not have solved before, but which any reasonably competent dev can solve. Bonus points if the person scopes them beforehand.

If you want to favor false negatives, ask harder questions, but make sure they actually are ones you deal with. If you're writing basic business CRUD apps, and your challenges are really in deployment, reliability, gathering and responding to user needs, etc, asking them to implement something from Cracking the Coding Interview is counter to your purposes. Ask them instead what it takes to build a reliable system. Are they familiar with doing that? What are some of the considerations? If they suggest distribution, are they familiar with CAP? Etc.

Really, it all depends what you're looking for. If you want someone who is keen to learn about the domain you work in, ask them if they know about things they have no reason to know about, and indicating that "it's okay if you don't"; see if they admit it. See if they respond with enthusiasm when you start to explain it, "Oh, that's cool!" when confronted with a new idea is probably someone you want, "Huh, okay", maybe not. Etc.

I readily admit, hiring is hard, extremely hit or miss, but a lot of companies seem confused about how it's supposed to work; don't borrow the interview practices of another company in a completely different industry. Google asks those questions? Google -can- ask those questions; they're trying to filter out people. You don't get 1000 applications for every job opening, you can't afford that. You also aren't dealing with the same problems; someone who fails those questions may still be a great hire for you.

"The Tao that can be spoken is not the eternal Tao The name that can be named is not the eternal name"

Once "art" becomes defined, it ceases to become art. The barista ceases to become important once a machine can replicate the exact results. The artist becomes useless once his or her method can be codified and repeated.

The method of choosing good engineers also becomes useless once it is defined because then that standard can be copied without regards to the traits it originally was trying to gauge. Pure arbitrary processes aren't great because of the lack of transparency that encourages nepotism, but neither is a purely mechanical approach that opens itself to becoming gamed.

A heuristic exchanges information for faster processing. When heuristics are passed around, the original information is lost. Almost everything we do is a heuristic though. 3 meals a day, brushing teeth everyday, etc... Is it better than nothing? Probably. Is it great? No. But everyone offering a "solution" isn't really offering a solution. They're just telling personal stories about what heuristic worked best for them.

The job interview process is quite similar to the friend making process. Not everyone is going to be your friend, and following scripts like saying hello every morning isn't going to do it either. It's just one of those things that are part of life.

This. A thousand times this. After going through the rounds of interviews at various companies as someone who's not particularly strong in the algorithm department, I've often felt frustrated. I think my strengths are in making good sensible design decisions for a given problem, and being able to manage the complexity of a system; but I've never been able to really show that in an interview. I've seen work from colleagues that solves a simple problem, but makes extensive use of obscure C++ template features. Maybe they were great at algorithms, maybe they weren't, but they certainly weren't capable of coming up with the simplest solution.

I've dedicated lots of time learning graph algorithms in order to get better at interviews: I've only had a graph problem come up once in the last 5 years of programming, and it wasn't particularly tricky (it came up at a time I knew nothing of graph problems, and kind of figured out a graph structure by myself).

When I'm at work, I find I have a knack for keeping things simple, and get a feeling for when certain solutions are a bad idea. For me, software engineering is really about the engineering (make things that meet requirements with the given resources), and from my experience is not so much about being able to implement and provide the time/space complexity of 10 different sorting algorithms (although knowing the basics is important).

It's genuinely a relief to see many other people relating to this kind of experience, sometimes it can feel like you're the only one!

Yes. I hate puzzles too, and so do most of the other programmers I actually like hanging out with.

I know this is a "me too" post, but that's kind of what you're looking for.

Same thing for me, I could recognize me while reading your post...

The definition of a "programmer" is very subjective.

I definitely agree with this sentiment. Recently someone dropped by for a job interview and revealed how much he loved to solve puzzles. Not that this influenced my decision in any way, but it made me reflect how different I felt w.r.t. this.

For me, it is not design either, it is something different.

I hate puzzles that are created by other people, where you have to follow the "hidden variable" which is in that case the brain of the maker of the puzzle. They already know the solution! I feel utterly useless solving a puzzle that has been already solved thousands of times by others. What's the point!? After 3 sudoku games I'm done with them. The same with IQ tests on national television. Why would I feel any reward in being able to crawl into the brain of a television writer concocting questions for a general audience? I think there are many much more interesting people in the world, than these guys. Their "puzzles" suck.

I also have never enjoyed solving mathematical problems in text books. I love math, and I read a lot of text books, although university is years ago. I think for people like me there should be different ways to teach them.

What makes me going is to find new things that haven't been known before. After I get some understanding of a field, I love to make up my own problems and solve these. The boundaries of such a problem are vague, it is not even known if it can be solved, but I am happy. Even if it turns out that I solve something that has been solved in the 13th century, I can't care less.

This is just a personal story, but perhaps someone can relate.

Evaluating a programmer by how well he solves a logic puzzle makes about as much sense as evaluating a race car driver by how well he rides a horse.

Then it's good that Google doesn't really ask logic puzzles. (That link to Google questions is full of fake questions. Just link bait.)

Yup. The way I like to express this is as follows -

It took Einstein about 10 years to formulate the general theory of relativity, needing no further experimental input into the work during this period. A few other scientists such as Wheeler, Schwarzschild and others, not to mention mathematicians like Riemann, put in at least as many "top scientist years" of time - about 20 TSYs in all, conservatively. The core content of this is taught in grad school these days over one semester and could be considered about 1/2 grad student years worth of intellectual effort.

So what did these people do for the remaining 19.5/20 of the time? They got hold of a problem that wouldnt let go of them, that they poorly understood, but nevertheless persevered through false starts, uglifications, and what not to arrive finally at the beautiful theory that it is.

i.e. Problem finding and perseverence through foggy days with all but a candle that seems to threaten to blow out any minute is at least 40x harder and that much more valuable than problem solving.

I believe your phd would've served you well on that front.

> needing no further experimental work

General relativity is an incredibly impressive theory, even more so when you take into account how few experimental observations were required to formulate it. Basically "the speed of light is the same in any frame of reference" and "being in a gravitational field is (locally) indistinguishable from being in an accelerated reference frame". (For the second one, think about being in a rocket ship accelerating at a constant rate... you feel a force pushing you into the floor, just like you would if you were standing on the Earth's surface.)

If those two things are true, then GR is the only logical conclusion... but we might have gone another 100 years without reaching that conclusion if it hadn't been for Einstein.

It's really sad how amateur most interviewers are. I learn a lot more from them than they do from me. I actually take advantage of the few minutes they set aside for me to ask questions to poke a bit and try to get them to go off-script. Companies: For god's sake, choose interviewers that don't need a teleprompter to conduct an interview. It's making you look bad.

>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 can stipulate that at the beginning of the problem, the 10 minute and 7 minute people are on opposite sides of the bridge, each paired with one of the other two guys.

18 minutes, if they must all start on the same side of the bridge, but there is no requirement for all of them to end up on the opposite side.

This also assumes that person who can cross the bridge in as little as one minute has no problem slowing down to accommodate someone else's slower pace; otherwise there's no real point to trying to share the torch.

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, and then brings the torch back for the rest.

So 10 minutes, 1 back, 7 minutes, 1 back, 2 minutes. Total of 20 minutes.

There isn't anything technically specifying that they have to end up on the opposite side of the bridge at the end, but you wouldn't have a situation where someone really wanted to cross the bridge and end up where they started without a torch, and it indicates that the four people have one torch, which implies that they're a party of 4, not 2 groups on opposite sides of the bridge.

I think it's a good question, because it judges the state of the person being interviewed. Are they just scared away by a simple puzzle? Do they come up with some contrivance to try and show off how smart they are? Do they just come up with a practical solution?

Personally, I'd give the practical answer and say 20 minutes, give or take a bit for transferring the torch and turning around. I'd make the assumption that they were all on one side of the bridge and want to go to the other.

When you're given a request to send a request across a network and send a confirmation across the network, you're not going to go and send the some of the requests to the server, and some of the requests to the client, and some of the responses to the server, and some to the client, just because, despite the implied context, you decided that you could make it a bit faster by doing something that didn't make sense because it technically followed the rules.

You probably think your answer is still better, and that's why it's a decent question.

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

> So 10 minutes, 1 back, 7 minutes, 1 back, 2 minutes. Total of 20 minutes.

21 minutes.

I'm the guy in the interview who says, "Only one person can make it across. The 1 min guy, realizing there is only one torch (and given that one must hold the torch to cross)makes a grab for the torch and runs. The rest get eaten by wolves in the dark".

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.

I don't think that would make the person who's interviewing you very happy.

I have interviewed enough times to know that you can't please everybody. And some interviewers like to assert their dominance during the interview. If they see you as a potential competitor rather than an underling, they won't endorse you.

I once aced an interview brainteaser, and the interviewer actually tried to derail my solution by interrupting and making misleading suggestions. When I finished, he told me that I was the only candidate so far to give the "correct" answer. He was clearly unhappy about it, which confused the heck out of me at the time.

I wasn't supposed to do that. I was supposed to give a half-assed, partially correct answer and let the other guy show off how smart and superior he was, by giving me the "real" answer.

So yes, beating the brainteaser might backfire. If it could, would you still want to work there?

Well if you're stipulating starting positions, the fastest possible would be if the 7 and 10 minute men are on one side, and the 1 and 2 minute men are on the other. Each pair would only have to cross once, passing the torch while they are all on the same side. 10 minutes + 2 minutes for 12 minutes total.

It'll take 17 minutes for all the people to cross if they all start on the same side:

  start: 1,2,7,10|
  1:     7,10|1,2  =  2 minutes
  2:     1,7,10|2  =  1 minute
  3:     1|2,7,10  = 10 minutes
  4:     1,2|7,10  =  2 minutes
  5:     |1,2,7,10 =  2 minutes
             total:  17 minutes

http://en.wikipedia.org/wiki/Bridge_and_torch_problem

I love puzzles - especially ones that are unicolor or close to it but do have weird shapes - but never related it to programmings as a whole. That just seems wrong to me so I'd say your question should be phrased otherwise as it's far from a simple yes/no question. Just depends too much on what you thing 'programmer' means.

Programming itself is such a vague and general term me and my friends tend to split it in smaller, somewhat better defined aspects when discussing about it. I'd say aspects related to creating new code/design/refactoring don't have a whole lot to do with puzzles. Lowlevel debugging of nasty problems on the other hand does have quite a lot in common with puzzles. I should check some research on this, but wouldn't be surpised if one effectively uses different areas of the brain for these aspects as well.

People tend to presume that everyone thinks the way do. In this case, everyone solves problems and thinks about programming the same way, right?

I've always had a more narrative approach to coding. Until I read some of the stuff Larry Wall (Perl) has written about how he thinks, I'd assumed I was a giant freak. Not at all.

Has he got a blog?

I can't help but think this is a perfect example of the contrast between a programmer and a hacker. When I think of those who enjoy puzzles, or more accurately the mental process to solve said puzzles, I think of hackers. A programmer is simply someone who programs.

That's not to say that you can't be a perfectly competent programmer without being a hacker. On the contrary, sometimes, though rarely, hacker traits can be detrimental to programming as a profession. A programmer bitten hard by the hacker bug may become a bit too enamored with a puzzle when going about their work on a given project, and as a result come up with a solution that effectively solves a difficult problem but is a nightmare to effectively maintain, especially when others are doing the maintenance.

I like puzzles (jigsaw or otherwise), just not as an essential criteria for getting a job. "Wow, you solved the knapsack problem using dynamic programming! Great. Now here's 2 million lines of 30-year old code, much of it crufty. You'll be a natural!"

Yes, you are. Don't be fooled by companies with hiring processes that basically say "dance for me, monkey". They have their own agenda; just because you don't look like the programmers they would hire it doesn't mean you are any less a programmer.

This isn't the only industry this happens.

In restaurants you have line cooks, prep cooks, and then occasionally if you are a "fancy" enough of a place you have a sous chef and an executive chef.

The one common thread here is, they are all cooks.

Now most line cooks will have never have actually "created" a dish, just like most of us have never "created" an algorithm, (having the vision for something new, knowing which ingredients sourced from what region will work the best, knowing how the various intricacies of spices, how they interact with each other, what temperature is optimal for meats, ect), but I am sure they know how to put something new together.

A programmer is one who programs. You are a programmer.

There are many reasons people program. For me personally, it's to make stuff and put it out there. Companies have to have methods of weeding people out, and some of them pick those puzzles.

I tend to agree, I hate riddles and puzzles, I don't like trying to debug something in an embedded system with no screen, GDB (which is a riddle in itself), and a temporal component that prevent me from using some technique (like breakpoint scripts that continue).

I just put up with them in the hope that I get stuff done past them.

Today I tried an online Mensa test (the quick stuff), I didn't recognize any patterns in the domino section (I tried 5 before giving up, vertically, diagonally, like text, nothing), I guess, some people are not made for that. I know people who love them and are good at it, I just hope to still get some respect from them.

Depends on the kind of puzzle to be honest. I enjoy puzzles (as in a physical puzzle like the author is talking about) but only ones that are not stupidly hard like his Escher puzzle. Sod that!

Programming puzzles are very different though. Do I hate programming puzzles? Sometimes. Again it depends on the puzzle at hand.

As for is he still a programmer? Well if he codes and produces something that works how he wanted it too then sure. He might be one of those programmers that hate debugging though so ends up writing more and more code to 'fix' a problem rather than actually find the real problem instead of coding around it.

Ha ! And I was feeling stupid for not being able to make headway on the puzzle on the front page that was shared from Terry Tao's page :P

On a more serious note ..

I'd like to think that raw cognitive ability would be a nice thing to have in a programmer. In a field where things change so fast we definitely need people are who are good at figuring things out and making things work.

Ofcourse its obvious that the best way to hire someone is to have them build something substantial and or go over their previous open source work. When that is always not possible then some test of cognitive ability will have to come into the picture as a proxy.

I look at puzzles as a problem-class that need to be solved, not the individual puzzles need to be solved, but the fact that there is a puzzle at all should be the thing that's being solved.

95% of software development is not solving complex algorithmic problems, it's plumbing. If the plumbing is so complex that it creates puzzles that need to be solved, then something probably went wrong somewhere along the line.

Preventing the 95% of software development that shouldn't be a puzzle from becoming one is something I'm very passionate about.

I could have written this; It's me to a T. I build things. I like building things. It's fine with me if it's not completely original. I can ride around my city and point to the parts I helped build. I like that.

When I program I bring order from chaos. I can do that best by using the discoveries of others, and building them up. I'm glad there are creative people who love mathematics enough to figure out original algorithms; I appreciate their work. I'm not one of them. It doesn't change the quality of what I build.

Jigsaw puzzles are repetitive and inefficient. They may be the antithesis of good programming. While they might be fun as a distraction, they are hardly a marker of programming ability. I don't like the idea that people have to have "smart person hobbies" to be coders. Playing music, poker, shooting pool, or racing could be equally as relevant.

The best programmers typically choose not to reimplement a solution when an existing one works just as well. Why should we love solving the same old puzzle from scratch over and over again?

This is what really irks me about the industry as a whole. Large companies like Facebook and Google have hiring processes in place that aim to weed out the strong from the weak by making them solve complex algorithmic puzzles and solve them on a whiteboard, and for larger companies like Facebook or Google who have massive troves of data, this kind of makes sense to me, but only if you're hiring a programmer to work with your data, not make things pretty or interface with existing services.

However, what does not make sense to me is the asinine requirement that a web developer needs to know or understand algorithms. A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm. In my 12 years as a developer thus far I have never needed to solve a complex math problem or write an algorithm to markup some HTML, the closest I get to math problems is simplistic operations in Javascript like calculating the scroll distance from the top of a page or mathematically moving an element around the page in a particular way and I generally use a calculator for these problems.

The problem is many startups try and replicate the likes of Google and have the attitude of, "Well, if Google require you to solve complex math puzzles on a whiteboard in 30 minutes, then that is what we will do too" - reality check: A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever. Only a developer working with data or writing an algorithm to sort it should need to know that stuff. You are not Google, so stop pretending you only hire smart developers who know how to solve unrealistic math problems that they will never encounter.

I have heard from friends and experience a couple of times myself, broken recruiting processes that ask you to solve non-realistic problems and complex math puzzles (which I always fail myself). My policy is unless I am going for a job working and sorting through data, I should not need to know how to write an algorithm on a whiteboard.

The only skill I think all developers should know regardless of whether you are a front-end developer or writing complex algorithms to sort through billions of rows of privately collected American data through a secret Government program is regular expressions. I do not know regular expressions extremely well, but I know them enough to be useful with them and I think this is one area where most developers fail. You might know the latest tools, heck, you might even know how to write an algorithm to sort through a large set of data, but if you can not write a regular expression (even for the most basic of tasks), then I think we have a problem.

The interview process for most developers should be simple like this: Can you write regular expressions? (yes) or (no) - if (yes) then write me a regular expression to get the value between two curly braces in my Node.js application and you have got the job.

There are always going to be companies out there with this unrealistic inflated image of how smart a developer should be. To be quite honest, I would not call myself an overly smart person. A lot of the problems I solve on a daily basis are merely following simplistic troubleshooting steps with a combination of Google and reading the documentation. Most of my day job is simply just common sense. Web developers in particular are over-glorified Googler's with an eye for detail and a large bottle of strong adhesive used for gluing different pieces together. And you know what? There is nothing wrong with that, it is the truth, because I am one of those people.

This idea that you have repeated several times...

> A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm.

> In my 12 years as a developer thus far I have never needed to ... write an algorithm to markup some HTML

> A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever.

> Only a developer working with data or writing an algorithm to sort it should need to know that stuff.

This is either a spectacularly narrow view of what an algorithm is or it is totally wrong.

I've done both front-end and back-end/data for years. I frequently write "algorithms" on the front-end. Several of these were recent:

- Retry method for AJAX form submission

- Distribute assorted icons evenly among primary keys in a table.

- Dependency chain to check and execute asynchronously fetched scripts in the right order

- Even CSS can be somewhat algorithmic, as when I optimized by about 100X the hiding and showing of a huge amount of table rows with cascading style rules instead of JS

I don't think I need to go on, but the point is that if you think front-end developers don't need algorithms, then you are doing something wrong. I would check your assumptions about whether hiring for this is actually helpful. The companies you are talking about are leaders in both front-end and back-end technology. How do you think that came to be?

You know the saying, "If you have a hammer, everything looks like a nail"? I think the corollary to that is "If you don't have a hammer, nothing looks like a nail".

If you have little knowledge of graph theory, algorithms, and other such "esoteric nonsense", you wouldn't recognize situations where those will be helpful, which then reinforces your belief that algorithms are useless. I have seen too many times a person saying that algorithms are useless, who then gets stuck wondering why his naive O(n!) program is running so slow.

This so much. I don't get how people can think that something so simply and straightforward as the time complexity of an algorithm is something superfluous that only belongs to some boring classes they took in university, and it has nothing to do with "real world problems".

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.

> 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 it comes down to the source, fast data access is thanks to the database, and very few developers develop database systems.

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.

A developer working with HTML, CSS and Javascript does not need to know algorithms whatsoever.

I'd only partially agree with this.

One of these things is not like the others: HTML and CSS are not programming languages; JavaScript is, and we're treating it like one now. As we move into a world of "client side applications" rather than "dynamic HTML," JS can be an order of magnitude more complex than it was just a few years ago. If you're going to use Angular or Backbone well, you're going to need to have a solid understanding of at least a few design patterns. You're probably going to need to know the difference between a queue and a stack and when you'd use one or the other (or neither), and you're going to need to be able to look at a problem and say "this is something I need recursion for." There's an awful lot of people who could make a good living as a web developer in 2004 who couldn't in 2014.

Having said all that, I think the current hiring process, particularly among Facebooks and Googles and startups that emulate them, is pretty heavily biased toward things one only learns in computer science degree programs (or when one is desperately floundering around trying to solve a "take home" interview puzzle). I don't want to claim that it's bad to know how to do directed graph cycle detection in your language of choice, but the need to do that is only going to come up in fairly specific circumstances -- and it's more important to know that someone you're hiring can find the information necessary to solve a problem and apply it than it is to know whether or not they have that information memorized.

(I'd also argue that demonstrating they can write readable, well-documented code that other people can actually work on is really important, but I almost never see that tested, oddly enough.)

>> However, what does not make sense to me is the asinine requirement that a web developer needs to know or understand algorithms. A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm. In my 12 years as a developer thus far I have never needed to solve a complex math problem or write an algorithm to markup some HTML, the closest I get to math problems is simplistic operations in Javascript like calculating the scroll distance from the top of a page or mathematically moving an element around the page in a particular way and I generally use a calculator for these problems.

Perhaps some folks want to automate your job. That's not to say you're obsolete, just that some people want the machine to do absolutely everything automatically and that often means algorithmically. That's probably more effort than its worth in many cases, but sometimes it's well worth it.

A facebook feed or Google news have a fairly consistent layout, but what content goes into it is definitely chosen by an algorithm (IMHO a poor one at facebook) and the layout is probably tweaked by algorithms.

New web frameworks are making web development a more difficult problem, and Google's biasing of their hiring process towards "puzzle-solvers" has given birth to the poster-child of such complexity: AngularJS. AngularJS takes web development from something inelegant but simple into something inelegant and convoluted. I miss the days when web developers didn't need to add "transclusion," "directives", and "providers" into their vocabulary.

The only problem is companies who think web frameworks are obligatory. (And that sites not using them are somehow not as desirable.)

RegEx is just ludicrous a general requirement to "program" as anything else. I've never particularly wanted it to write the mathematical models I work with. I can think of just a single instance where I've used one in the last year and that was to display integers as ordinal numbers (hardly a sizeable task).

Every job needs a spec. Every spec should inform the interviewer and the interviewee of the skills and competencies expected by the role, and therefore what will be brought up in the interview. Adding "everyone should be able to criteria unrelated to role" is madness

Agreed. I can write a regex the (very) few times I need one, but it generally entails me looking up a cheat sheet to get the appropriate character classes. If you were to put me in front of a whiteboard I would flub the most simple of tasks (from the original post, "{(.*)}", I think? Did we mean to include whitespace, and does . translate properly? Because that's partly language dependent when it comes to white space, newlines, etc, and how the regex parser works. Did we mean to capture empty cases? Did we intend for it to be greedy?).

Does that mean I can't program? Ha ha ha, no. Does that mean I can't manipulate strings like a boss? Ha ha ha, no. I first reach for the language's tools, before I reach for regular expressions (the OP, I would first reach for doing a string search for {, and then one for }, from the rear if you want it greedy, and substringing what is in the middle; it's far less ambiguous, and any dev will know exactly what it does). Even when something ~technically~ takes a regex, if what I'm looking for is just a literal (as it often is; does this string contain X or not?), I don't need to 'know' regexes. So there's a LOT I can do without knowing regular expressions.

Meanwhile, I -have- needed to be able to recognize that something was running in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to implement my own search and bucket sort routines.

EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc. See? Now I have two problems.

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 like this:

    x = x + vx * t + ax * t * t / 2;
    y = y + vy * t + ay * t * t / 2;
    z = z + vz * t + az * t * t / 2;

If you just copy-paste the first line and change all of the x's to y's and z's, you're extremely likely to make a mistake. There has been study in this and it's one of the most common classes of logic error.

However, with regex search and replace, I first type

    x
    y
    z

Search with the pattern: (\w)

And replace with the pattern: $1 = v$1 * t + a$1 * t * t / 2;

And now that I've been doing it for a little while, it's second nature. It's how I write lots of 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.

Clarification: I know how they work. What I -don't- bother keep in my head, is every metacharacter, character class (POSIX especially), assertions, string replacement options, etc, because I can just look those up. The example mentioned above is actually a really good case of why I don't worry about remembering all the specifics; because it's really easy to screw it up. Oh, I forgot {} were special characters, because I have -never- used them (any time I needed repetition it was always so few times, and for a single character class, I just repeated the character in the pattern), so I forgot to escape them.

And let's not forget the implementation different specifics (the need to specify multiline matching as a separate parameter into the parser, \ vs $ for string replacement, etc)

In general, if I'm writing a regex more complicated then "Hey, does this string match this literal?" I'm going to pull up a cheat sheet, because it avoids issues like that. But the number of times it makes sense to do that is really, really low.

It makes as much sense to me to say you should remember all ASCII character codes. Why? If you know how they work, and you're not using them enough to remember all of them automatically, it's not really a problem to just look them up if/when you need them.

I would agree that the minimum requirement should only include relevant data. However, you never know when a skill might be handy (especially if you don't have that skill), and having a broad base seems like it would be beneficial as well. Perhaps allow for people to demonstrate their bonus competencies, and strive for a diversity of auxiliary skills across teams?

Interestingly, my father, who is an applied mathematician, recently requested my help to understand regex and their relation to NFAs to help him with a mathematically related programming task.

I'd argue that being able to think laterally across multiple parts of the web browser is much more important for front-end development than having the typical CS background (algos, data structures, etc).

But the CS background certainly doesn't hurt. Especially when it comes to stepping back and figuring out how to do the same stuff with less code (i.e. making good architectural decisions and finding the right frameworks for the job), instead of diving straight in and producing a giant mess of code, which is quite easy to do on the front-end if you're not careful. (Especially if you throw JQuery in the mix -- at that point you have a hearty soup of DOM manipulation code.)

Normal companies shouldn't hire this way. They're trying to find the one in ten thousand genius. Most companies don't need to.

If I were hiring a developer I'd ask them to write a simple app. Then I'd ask them to explain in as much detail as possible as to what happens when you type www.google.com in your address bar and the google homepage showing up.

I expect them to mention DNS lookups , IP Addresses , HTTP Requests , HTML parsing , HTTP methods etc

A front-end developer working with HTML, CSS and Javascript will never EVER need to know how to write an algorithm.

For the kind of frontend work you're used to doing: perhaps they won't.

For the kind of frontend work Google does -- you know, things like Gmail, Google Maps -- they most definitely will.

That's why Google asks those questions.

I like making things. If I want to make something and I don't know how, I'll figure it out. Call that "solving a puzzle," but it's a very different activity than solving a literal jigsaw puzzle or answering some arbitrary question about rickety bridges.

If you enjoy making things with software, you'll be a decent programmer. If you enjoy puzzles for their own sake, go check out some Martin Gardner books. Those two enjoyments can overlap, but they're not necessarily dependent upon one another.

Puzzles: One clear solution Algorithms: "Better" solutions. "Best" solution may exist but hard to definitively prove. Often, things like cost and time are real constraints in the solution to the problem. Real world "problems"/"design": solutions are optimized for a certain set of outcomes.

I don't like puzzles either, but I think it's due to their restrictive nature and generally non-creative solution finding process. I prefer making puzzles over solving them.

I'm not going to get into the fake programmer vs real programmer thing, but I will mention the thing that most excites me about programming. For the the author it was "design," and for me it's similar: communication.

I love being able to take a fuzzy idea, decompose it into discrete (and concrete parts) and then transposing that idea into programming language in such a way that not only solves the problem, but also communicates clearly what the original intent/idea/solution is.

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 companies. The "puzzles" listed at that Google link are basically fake. Link bait. While it's possible that each of those was asked at Google, I doubt that's where the author of that blog post got them from. They are certainly not representative of Google questions.

The "puzzle" questions you're referring to are really more like: - Design an algorithm to return a random node from a binary tree - Design an algorithm to find the nth number divisible by only 9, 13, and 15

You can define "puzzle" however you'd like, and I'm not going to engage in some debate over whose definition is "right." Doesn't matter (and there probably isn't a "right") here.

In the real questions asked at companies like Google, there's typically no sudden insight you need or trick in the wording. Rather, these questions are about working through a different problem and creating optimal solution (and recognizing tradeoffs along the way).

-- (2) --

That is an important skill for a developer. It is valuable for a developer to be good at that, and even enjoy it.

Maybe you don't care about making your solution better. Get it done. Get it out the door. Even if it's not perfect.

That probably makes you a less awesome developer, but it doesn't mean that you are necessarily a bad developer. There are lots of parts of being a "perfect" developer. - Enjoying testing. - Understanding what users want. - Architecting a system. - Understanding the lower level computer architecture. - Being a perfectionist. - Not being a perfectionist and knowing when you just need to get something done. - Knowing how to scale a large system. - and so on.

There are a TON of things here. No one has all of them.

You might be missing one of them, and it's a fairly important one. But it's not the only one.

I once worked [worked = prepping the startup for acquisition interviews] with a developer who was, honestly, quite stupid. He was exceptionally poor at developing good algorithms. His code however was correct.

He would be terrible at a company like Google. But at this company, he was very good. You see, he was very detail-oriented and thorough. If you want someone to write a correct bit of code for a very tedious and boring problem, he's your guy.

Is he a good developer? In the right role, yes.

This doesn't mean that Google is flawed for doing interviews this way - not at all. Their goal is not to hire all good developers. Their goal is to hire enough good people and to not hire bad people.

Problem solving/algorithmic skills and coding skills is a decent filter for that purpose.

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 looks this way up and knows the ins and out of it. Now as an interviewee,if B were to come up with a 100 ways of handling the problem (starting from brute force) but fails to reach the "cool" solution because he has only 45 minutes of time . Do you think the interviewee would be considered a good candidate?

I'd say that the interviewer has hardly learnt anything about the candidate by asking such a problem. But then again, I could be wrong.

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.

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

> 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 their core positions. But, they need some developers like the one you describe as being a "terrible" fit as well. They need some developers who have a foot firmly planted in another engineering discipline, or various non-engineering domains. There are a whole lot of things they need that they don't test for because they spend all the available time testing for traits that are only critical to a portion of their business.

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.

> 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 would reorganize work so there is full-time tedious but necessary work to be done and put him on that. I would also use him for spec work, sort of like an in-house subcontractor. It works very well with electronic and mechanical engineers. I see no reason it would not work for software engineers.

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

Consistency can be taken too far, which I think Google does. It is one thing to only hire smart problem solvers. It is another thing to only hire people who are smart problem solvers in a specific domain and in a specific way. I feel like Google is trying to diversify their line of business but not diversify the types of problem solvers they hire.

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

I would think it would be the opposite. A small company is less likely to have sufficient appropriate work to allocate.

> A small company is less likely to have sufficient appropriate work to allocate.

Maybe so. But this isn't just any random small company. This is a specific 50-person company.

I love puzzles. I love to ask people who were just interviewed to tell me all about any puzzles they got, and try to see how long it takes me to work them out. I feel fairly confident that I have a knack for them.

But it isn't actually a good interview strategy. I don't think any company should hire me over someone else due to puzzle solving. If I were to do an interview, I would probably leave out puzzles entirely.

As many others have already said, if you've been programming for 18 years, then yes, you are a programmer. I wouldn't say you're crazy for not liking puzzles, but I would say you're crazy for not liking puzzles and pursuing a Ph.D in (what I assume is) Computer Science, since that is invariably what most research involves, and what most Ph.D level jobs are going to involve.

Never let an HR manager or recruiter's decision or feedback be a reflection of your self worth. They rarely know much about our jobs.

I have lost count of the number of job interviews where I have been asked to solve a puzzle or brainteaser. I very much enjoy it when I can tell them "I've heard that one before: the answer is X," until they run out of alternate challenges. But I also enjoy it when I actually get to solve a new one. It's like my payment for doing the interview, even if there's no offer.

This isn't really a strike against the company. This is just an indicator that they haven't had much experience at hiring people. They clearly are all copying from the same source, who was in turn copying from the books and magazines filled with puzzles and crosswords that I have been reading since I was old enough to do so.

I know from firsthand experience that the puzzles they are using are not the ones that I feel best correlate with coding ability. They are instead the ones that can be asked and solved quickly, with a single correct answer. They are generic filler, like "what's your greatest strength?" and "what's your worst weakness?" Those questions just show you that your interviewer does not know how to evaluate your fit for their job.

Programmers translate human problems into procedure-based solutions. They do not need to solve puzzles, except insofar as it can be puzzling to get stupid agents to perform complex tasks without step-by-step supervision from the principal.

Hacking is an essential part of the wider culture that formed around early programmers, but this culture is somewhat more inclusive than most. Certain activities draw forth the archetype. Safecracking, lockpicking, geocaching/orienteering, scavenger hunts, reverse engineering, deckbuilding strategy games, Rube Goldberg machines, drone photography, robotics, etc. That type of person is drawn to programming, not necessarily the other way around!

We don't need a cultural battle. I don't particularly care for "brogrammers" or "rockstars" or Nerf battles and foosball at the workplace, but I don't begrudge those types the right to call themselves programmers and to claim to work for technology companies.

But just as they should not be expected to solve brainteasers during their interviews, so too should I not be expected to play Ping Pong against a company founder during mine. I think monoculture is dangerous and foolhardy. Please, lets just judge our worth as programmers by how well we can write programs.

I don't know but where can I get that jigsaw?

~5 seconds: http://www.amazon.com/Buffalo-Games-M-C-Escher-Portrait/dp/B...

Apparently a web search is not the kind of puzzle he wanted to solve.

He's better at jigsaws.

Love this. I like puzzles (and scifi) and definitely fit the more traditional model of a programmer, though I'm entirely self-taught and didn't take CS in school. I really don't like algorithms that much. What I do enjoy is API design, writing elegant code that is maintainable, and solving the macro, human-scale problems.

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)

The author should probably at least take a stab at defining his usage of "puzzle." There's a big difference between a jigsaw puzzle and, say, the Portal games. In fact, jigsaw puzzles are a very different endeavor than logic/programming puzzles and many puzzle video games.

I don't write programs because I like solving puzzles. I write them because I like creating things, and it's a lot easier to create things with programs than with a machine shop.

I also enjoy the competition with other compiler/language vendors to produce a better product.

> I write them because I like creating things, and it's a >lot easier to create things with programs than with a machine shop.

Exactly. This is one of the main reasons for me as well - creating things without buying or manufacturing physical materials.

I designed and built a steam engine in high school in metal shop. It took forever and was beyond my machining skills. It didn't work, due to being so poorly made.

I tried again in college, with a much better design. The guy who ran the college machine shop (he built custom lab equipment for researchers) helped me a lot. It still took months. This time, it did run, but it took so much time it didn't satisfy my urge to create things - my designs ran far, far out ahead of any possibility of making them.

Not so with software!

Programming is a pyramid. Each strata building on the other. Anyone can join in on any level to contribute. I enjoy living on the framework and data levels. I really don't like front end or bare iron work. That certainly kills some job opportunities, but I'd rather be happy.

When you are young and have nothing to show, puzzle solving, like a school degree, is a way for other people to judge you. When you have experience and track record, puzzle is like meh. People still using puzzle to judge an experienced developer are not very good in evaluating others.

I love programming, but I hate puzzles.

Solving puzzles is nothing like programming to me. Programming to me means crafting your own pieces of the puzzle and being able to create something unique and beautiful.

Of course programming has some bad and boring sides. I would compare those to solving a jigsaw puzzle.

Oh lord, I could not have read this ata more apt time. I am going through such a crisis right now, professionally. I keep interviewing at these places where they just want to know if I can solve 9 ball problems or not. I almost feel like an impostor. Glad I read this.

I feel the same way about games that he feels about jigsaws. They're fun enough but they're inherently contrived and produce no real value. I read books and watch movies for narrative experiences. While there's a growing minority of games that have real emotional, sophisticated and even literature-level narratives, at the end of the day, most games require you to solve contrived puzzles to advance the narrative.

On the other end, there are games like that one where you build pieces from blocks and it's a little world, people have expressed their artistic side with whole castles with automations and calculators. These are more like LEGO, Meccano or other tool; they're a substrate, like a programming language, something you build on. I wouldn't call them games.

Although I will grant that games that pit you against or collaborate with other human beings is worth it to some degree, because you're spending time with people (which is why Chess is bloody boring and pointless to play against the computer), it's all noughts-and-crosses with bells and whistles.

Coming back to his point about jigsaws, while it is satisfying to complete one, personally, any time spent putting in active effort (as opposed to passive effort, like in the case of a novel or movie or theatre), I'd prefer to be doing something actually constructive; to produce something real, either artistically (I paint canvases), or technologically (I'm a programmer). Rather than maintaining these “farms” and cyberpet-style games, or the games where you're digging for gold and collecting resources, I'd rather maintain my bike, go grab some materials from the store and do some DIY in my apartment, plant some things in my garden, etc. Whenever one of my gamer friends explains a game to me, I'm thinking more about how I'd make that than how I'd play it. I'm not saying people who like to spend time doing these things are wasting their time, just that I don't share that desire at all.

Puzzles in a job interview are a poor idea. People don't solve puzzles on their job, with their manager watching them do it. They don't get sacked for failing to solve the puzzle (which failing a job interview is tantamount to; your career depends on it). And if they can't solve a puzzle in 15 minutes, they spend all day on it. Or all week. They ask their colleagues for help. If it's too hard, the product manager considers breaking the problem down. Asking contrived puzzles is such a silly idea that I'm biased against companies that try to ask them for job interviews.

When Google and Facebook ask if you enjoy puzzles, I'm pretty sure they're not talking about jigsaw puzzles! They mean stuff like this: http://realmode.com/punch22.html

I'd like to point out that the Google quote is not from Google's webpage and is in fact likely a banned interview question. The facebook quote on the other hand is from their webpage on a tool that is used for recruiting.

Found this related article by an author I've come to respect recently

"Organizational Skills Beat Algorithmic Wizardry" http://prog21.dadgum.com/177.html

Sure you are still a developer if you don't know algorithms or programming puzzles. You can hold a job and be competent and churn out quality code. However, you are a BETTER programmer if you do know these things.

https://news.ycombinator.com/item?id=6583580 Dear startups: stop asking me math puzzles to figure out if I can code

Optimizing out inefficiency and waste is part of good programming. So yes.

Only puzzles I enjoy are researching a bug and reading through code to find the bug and propose a fix. I enjoy this more than writing new code, even if the codebase is completely foreign to me.

> Coming up with algorithms is the programmer’s version of puzzle solving.

I'm not really seeing the connection. Are they both just things you don't like?

> What I like about programming is not problem solving — it’s design

Apparently in some alternate universe where design is not considered problem solving.

> Maybe I should refer to myself as software designer rather than programmer.

I think you should refer to yourself as an Software developer, not a Software Engineer. You can be good by referencing your previous experiences. But knowing how to solve and loving puzzles is a nice sign that this individual can solve problems quick and efficiently. This latter case is less common though. Most programmers are Software Developers, just referencing sdk's and frameworks and minor "new" development.

Turns out 500-pieces puzzles are more like an exercise in banality and less like actual puzzles.

there are a number of ways to be a good programmer: being a skilled puzzle solver / algorithmist is one of them, being good at designing apis is another, deciding what even needs to be built is another.

I don't really want to sound off-topic but did you guys get the answer?

I thought about it like that : since the one whos cost is 1 is a good roamer he should get each of the other ones? This looks too damn easy?

That's a good solution to start off with, but given the current costs, it's not the most optimal one. A lot of time is wasted by sending C and D to cross independently. If you manage to get them to cross together at one point, you will ultimately save some time.

Okay, so my best bet is that the optimal solution is 17 minutes.

Oh,yeah right!

I like puzzles a little bit, but I kinda suck at them.

I am an antiprogrammer though.

Thank you for sharing! So good to know that I'm not alone. :)

Weird interview puzzles are out. If you or your community continues to lazily fallback on "puzzles", you must quit your job now.

It is worth solving the problems we solve, however boring and straightforward the solutions can sometime be.

As someone who doesn't play video games. I can relate.

My life story! Relieved to see similar people :)

you're a programmer, but you're certainly not a computer scientist.

you like design! design a puzzle where the game is to optimize features for your end users.

how many wonderful algorithms have shitty interfaces? i know because I have written them - and nobody uses them because the interfaces suck.

i promise to keep an open mind to design, if you try a jigsaw once in a while

Correlation is not causation :)

i hate puzzles too

The discussion here is far more interesting than the article. "I don't like jigsaw puzzles, therefore I'm not supposed to be good as a programmer"? "Facebook and Google aren't looking for people like me, therefore I'm not supposed to be good as a programmer"? It seems to be intentionally narrowing the definition in order to make a somewhat whiny point.

What I like about programming is not problem solving — it’s design. How do I design an application in such a way that people will understand it?

Or, to put it another way, 'what I like about programming is not problem solving, it's problem solving'. The author somehow distorted the term 'problem solving' into 'puzzle solving'. Improving the usability of something is solving a problem. The author is tilting at windmills.

No you're not, abandon ship.

Best stick to the shallow end of the pool if you can't swim.

Do you program? Then you are a programmer. However, in some circles, where extremely complex problems need to be solved, they would say, " No ", because you can't do any of the programming required, and you'd be as useful to them as a rock, only less useful because you take air and food.

I play volleyball occasionally, but if I went to the olympic men's team, they would tell me I don't really play volleyball, I've not yet earned the right to say that I have.

It's a matter of skills and standards. In the right context I can call myself a car mechanic.. like if my car needs air the tires, but beyond that I'm not.

If you can program simple things on the web you can get away with calling yourself a programmer until you run into problems that make you realize you're not, like complex graphics algorithms.

I can cook food at home, but if I walk into a 3 michelin star restaurant and try to get a job, it's not like I'm going to write an article if they don't like my food. Boo hoo, they made me cook for them, how dare they? Whatever they're doing, it's working, so why knock the process that produces success when you can mimic it?

It would greatly surprise me if a member of the Olympic men's volleyball team said "you don't really play volleyball." People at the top of their field are way more likely to say "that's great! Keep it up!" The same applies in our field. The really great programmers I have known don't play the "you are not a real programmer" game.

Correct, that would be rude. However, they wouldn't put me on their team. It's their right to have tryouts however they want to. As arbitrary as entrance exams seem, they are part of the culture, and if you don't fit in, you don't fit in. Move on, start your own company.

It's like putting an entrance requirement of must use vim. Are all vim users better than non-vim users? No. Would a company gain some sort of productive advantage if everyone used vim? Yes. They would share tips, tricks, and everyone would be faster. Why are people knocking a company's right to arbitrarily poll for employees however they want to?

Fact: Having a specific culture increases productivity at a company, it doesn't even matter what that culture is, as long as everyone is on the same page.

So, no matter how arbitrary and unfair it may seem, it builds cohesion within an organization.

I have to admit, I don't understand what you are trying to say.

Are you saying puzzles are somehow the higher level of programming? You are completely wrong.

I don't think puzzles is a higher level of programming anymore then running is a higher form of walking.

However if I see that you can run chances are you can likely walk as well.

Lol.. How can you say I am wrong when you don't understand what I am saying?

Mm, I asked a question before that sentence. I guess I should have preceded it with "if you are, then". Sorry about that.

Reply on news.ycombinator.com