16 ms·

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

• sp332 12y ago
  https://news.ycombinator.com/item?id=6583580 https://news.ycombinator.com/item?id=6583580 Dear startups: stop asking me math puzzles to figure out if I can code
• kjjw 12y ago
  I don't know but where can I get that jigsaw?
  • jerf 12y ago
    ~5 seconds: http://www.amazon.com/Buffalo-Games-M-C-Escher-Portrait/dp/B00BNUPTDY/ref=sr_1_2?ie=UTF8&qid=1413908497&sr=8-2&keywords=escher+puzzle http://www.amazon.com/Buffalo-Games-M-C-Escher-Portrait/dp/B...
    • willis77 12y ago
      Apparently a web search is not the kind of puzzle he wanted to solve.
      • eric_h 12y ago
        He's better at jigsaws.
• nemo1618 12y ago
  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)
  • fredsted 12y ago
    Here you go: http://mu.ms/f/pxYcdb.png http://mu.ms/f/pxYcdb.png
    • TallboyOne 12y ago
      Lol, this made me laugh out loud.
    • computerjunkie 12y ago
      This made my day. Quite weird how that's the case with programming.
    • userbinator 12y ago
      People who feel that way in their day job should really try participating in the demoscene.
• emotionalcode 12y ago
  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.
• valas 12y ago
  Google and Facebook long ago stopped asking (or at least now they discourage their interviewers from asking) puzzle-like questions in their SWE interviews.
  • jeffreyrogers 12y ago
    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.
  • foobarqux 12y ago
    They stopped asking brainteasers, they didn't stop asking algorithmic puzzles (some of which are arguably brainteasers)
    • SomeCallMeTim 12y ago
      ...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-Questions/dp/098478280X http://www.amazon.com/Cracking-Coding-Interview-Programming-...
• bguthrie 12y ago
  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.
  • am391 12y ago
    > 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.
• smacktoward 12y ago
  > 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.
  • fullofcrap 12y ago
    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.
    • smacktoward 12y ago
      > 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 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.
• darkFunction 12y ago
  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.
  • dntrkv 12y ago
    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?
  • innguest 12y ago
    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).
• delecti 12y ago
  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.
  • raverbashing 12y ago
    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.
    • philangist 12y ago
      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.
    • arenaninja 12y ago
      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
    • klibertp 12y ago
      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.
• area51org 12y ago
  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.
  • Kluny 12y ago
    Has he got a blog?
• deleted 12y ago
  [deleted]
• the_cat_kittles 12y ago
  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.
• brandonmenc 12y ago
  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.
  • daddykotex 12y ago
    Same thing for me, I could recognize me while reading your post... The definition of a "programmer" is very subjective.
• karl_gluck 12y ago
  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.
  • mod 12y ago
    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).
• j_baker 12y ago
  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.
• ww520 12y ago
  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.
• chavesn 12y ago
  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.
  • bentcorner 12y ago
    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.
• deleted 12y ago
  [deleted]
• yawn 12y ago
  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.
• chrisdone 12y ago
  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.
• kstenerud 12y ago
  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.
  • gaylemcd 12y ago
    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.)
• chasing 12y ago
  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.
• kakakiki 12y ago
  My life story! Relieved to see similar people :)
  • zigizag2014 12y ago
    can you invite me please to INBOX oren.shachaf@gmail.com
  • zigizag2014 12y ago
    can you invite me please to INBOX oren.shachaf@gmail.com
• incanus77 12y ago
  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.
• skybrian 12y ago
  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?
• pmelendez 12y ago
  Correlation is not causation :)
• alecbenzer 12y ago
  > 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?
• FrankenPC 12y ago
  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.
• CapitalistCartr 12y ago
  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.
• dead10ck 12y ago
  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.
• DigitalSea 12y ago
  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.
• yarrel 12y ago
  Optimizing out inefficiency and waste is part of good programming. So yes.
• nathanb 12y ago
  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.
• hangonhn 12y ago
  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.
  • titanomachy 12y ago
    > ... 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.
• lostcolony 12y ago
  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.
  • rdtsc 12y ago
    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.
• nemo 12y ago
  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.
• jbaskette 12y ago
  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.
• danschumann 12y ago
  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?
  • general_failure 12y ago
    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.
    • danschumann 12y ago
      Lol.. How can you say I am wrong when you don't understand what I am saying?
      • general_failure 12y ago
        Mm, I asked a question before that sentence. I guess I should have preceded it with "if you are, then". Sorry about that.
    • crimsonalucard 12y ago
      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.
• Blahah 12y ago
  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.
• buckbova 12y ago
  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.
• baddox 12y ago
  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.
• MrQuincle 12y ago
  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.
• MCRed 12y ago
  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.
  • vonmoltke 12y ago
    > 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.
    • MCRed 12y ago
      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.
• treehau5 12y ago
  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.
• LukaD 12y ago
  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.
• flawlessvoid 12y ago
  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!"
• stinos 12y ago
  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.
• timsco 12y ago
  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.
• bane 12y ago
  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.
• ChuckMcM 12y ago
  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.
  • chavesn 12y ago
    > 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...
• nraynaud 12y ago
  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.
• bithush 12y ago
  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.
• dlwj 12y ago
  "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.
• Rooster61 12y ago
  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.
• Smudge 12y ago
  > 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.
  • computerjunkie 12y ago
    >>>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.
    • Smudge 12y ago
      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.
• R_Edward 12y ago
  >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.
  • zheshishei 12y ago
    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
    • throwmeout 12y ago
      http://en.wikipedia.org/wiki/Bridge_and_torch_problem http://en.wikipedia.org/wiki/Bridge_and_torch_problem
  • deleted 12y ago
    [deleted]
  • triangleman83 12y ago
    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.
  • jnem 12y ago
• maxlybbert 12y ago
  Dijkstra commented on this multiple times (e.g., https://www.google.com/search?q=dijkstra+puzzle+minded+ewd+site:cs.utexas.edu 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/EWD303.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/E... ).
  • yen223 12y ago
    Having seen people banning list comprehensions from Python because they are "too clever", I am wary of people who instinctively avoid "clever solutions".
    • maxlybbert 12y ago
      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.
    • wes-exp 12y ago
      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"
  • userbinator 12y ago
• LeicaLatte 12y ago
  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.
• throwmeout 12y ago
  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.
• austinz 12y ago
  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.
  • deleted 12y ago
    [deleted]
• sriku 12y ago
  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.
  • titanomachy 12y ago
    > 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.
• lukaslalinsky 12y ago
  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.
  • computerjunkie 12y ago
    >>> 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.
• cevaris 12y ago
  > 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.
• Fando 12y ago
  No you're not, abandon ship.
• lancejpollard 12y ago
  i hate puzzles too
• thewarrior 12y ago
  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.
• clomond 12y ago
  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.
• phazmatis 12y ago
  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.
• ThomaszKrueger 12y ago
  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.
• chuck8088 12y ago
  I like puzzles a little bit, but I kinda suck at them. I am an antiprogrammer though.
• ryanchamp_ICE 12y ago
  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.
• Xyik 12y ago
  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.
• gaylemcd 12y ago
  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.
• mediumdivision 12y ago
  > What I like about programming is not problem solving — it’s design Apparently in some alternate universe where design is not considered problem solving.
• mrcactu5 12y ago
  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
• interdrift 12y ago
  I don't really want to sound off-topic but did you guys get the answer?
  • interdrift 12y ago
    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?
    • FlyingLawnmower 12y ago
      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.
      • deleted 12y ago
        [deleted]
      • interdrift 12y ago
        Oh,yeah right!
      • interdrift 12y ago
        Okay, so my best bet is that the optimal solution is 17 minutes.
• slapresta 12y ago
  Turns out 500-pieces puzzles are more like an exercise in banality and less like actual puzzles.
• beyondcompute 12y ago
  Thank you for sharing! So good to know that I'm not alone. :)
• geekam 12y ago
  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.
• vacri 12y ago
  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.
• mncolinlee 12y ago
  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?
• logfromblammo 12y ago
  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.
• iceberg 12y ago
  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.
• floating-points 12y ago
  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!
• calvinbhai 12y ago
  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)
• jjzieve 12y ago
  As someone who doesn't play video games. I can relate.
• iconjack 12y ago
  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 http://realmode.com/punch22.html
• kazagistar 12y ago
  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.
• WalterBright 12y ago
  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.
  • zura 12y ago
    > 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.
    • WalterBright 12y ago
      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!
• crimsonalucard 12y ago
  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.
• amitlan 12y ago
  Found this related article by an author I've come to respect recently "Organizational Skills Beat Algorithmic Wizardry" http://prog21.dadgum.com/177.html http://prog21.dadgum.com/177.html