17 ms·

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

76 points by manaskarekar 10y ago

newobj 10y ago
Jigsaw puzzles? They're awful.
eatbitseveryday 10y ago
Laszlo Bock was interviewed on NPR last month[1] and part of the interview discussed the hiring process. They know they have created really unpleasant interviews for candidates. Starts around 14m25s. [1] http://www.npr.org/2016/06/07/480976042/how-googles-laszlo-bock-is-making-work-better http://www.npr.org/2016/06/07/480976042/how-googles-laszlo-b...
kaspm 10y ago
Even at the companies (both big and small) that utilize this method for interviewing/hiring, generally aren't having their engineers work on these types of problems day-to-day. You utilize tools to solve business or technology issues and advance the company, it's much more satisfying than a puzzle (for those who don't like puzzles). If you'd like to solve real business challenges, practice and get good at this kind of puzzle, algorithmic interviews, decomposing technical problems. Approach them in the spirit they are intended: to showcase your skill. Get past the interviews and work on real problems. Then when you're in a position to influence how your company hires, switch to a interview style that works for you. I prefer 1:1 real-world pair coding exercises on a computer with Google and I specifically test for the ability to look things up on SO.
deleted 10y ago
[deleted]
ljoshua 10y ago
> I’ve been programming for 18 years now. Only very rarely have I had to come up with a complex algorithm. This. I am sure it is dependent on the type of work you do, and that Tesla and Google Search engineers probably need to excel at algorithms, but very rarely do I come across any need to solve those types of problems while developing software. I would much prefer to see problems that resemble "You have Service A, which needs to grab data from Service B and feed it to Service C. Show how you could integrate them." That would be much more representative of a larger body of typical work. Some companies out there like Starfighter do this, I wish more did.
- michaelcampbell 10y ago
  The whole thing boils down to companies wanting the people to be able to do these incredibly complex and creative things, when real world problems (by and large) are not these. Sure, I'd like my car to be ABLE to do 205 MPH, even though I rarely get above 70. But it's not realistic.
  - ljoshua 10y ago
    Whew, I'm pretty sure I only want to be able to do 205 MPH if I'm in the sky! ;)
    - michaelcampbell 10y ago
      Fastest I've gone is 130MPH (on a proper track), and that's sphincter-puckering enough for me.
pklausler 10y ago
If you hate problem solving in general (as opposed to stupid puzzles), then there's a risk that you may not have an aptitude for debugging. When posed correctly, some interview problems can be a gauge of problem-solving ability and aptitude. The test of a puzzle problem's relevance is the extent to which it might expose a strength or weakness in real-world problem-solving. So stupid puzzles about, say, manhole cover shapes are obviously bogus. But there's some overlap between legitimate programming / debugging challenges that are small and self-contained enough to be useful in a 45 minute technical interview, and the set of problems that one might characterize as "puzzles".
- vikiomega9 10y ago
  I agree, but I'm wondering if you can give me an example and walk me through what check boxes you would look for in a self-contained example?
  - pklausler 10y ago
    Given two closed intervals [a,b] and [c,d], write a simple predicate in any programming language that evaluates to TRUE if and only if the intervals overlap.
    - Joof 10y ago
      Match on interval [a, c] and [b, d]?
- nraynaud 10y ago
  frankly, it only becomes a puzzle when google failed me. On a side note I'm really looking forward to having questions about manhole covers in interviews, the interviewer might get a little more than what she bargained for on Reuleaux triangles and statics.
  - kafkaesq 10y ago
    The interviewer might get a little more than what she bargained for on Reuleaux triangles and statics. But who has time or interest for pointless show-off-ery like that, even? It's 2016. The only answer you need to give to a questions of that sort is (with a mildly bemused expression): "You guys are still asking questions like that? ... I'm sorry, but this just isn't the right place for me."
Animats 10y ago
I've never been into puzzles, yet I did years of algorithmic development. I've worked on automatic theorem provers and written a physics engine for animation. I've done congestion control algorithms for networking and automatic driving algorithms for vehicles. But I never found puzzles interesting. I can do them if I have to, but rarely bother. I'd rather go out and ride my horse. Relevant Gary Larson cartoon: [1] [1] http://www.log24.com/log/pix15/150413-Gary_Larson-Heart_of_Mathematics.jpg http://www.log24.com/log/pix15/150413-Gary_Larson-Heart_of_M...
ovt 10y ago
My take on it is that puzzles and games are doing things by hand, and the point of programming in general is to do things once and for all and save humanity the trouble of doing things by hand. Not that there's anything wrong with doing whatever you enjoy doing by hand. Or perhaps it's that if we apply our ingenuity to a computer program, we have something and the rest of humanity can have it as well. If we apply our ingenuity to a puzzle, we don't have anything in the end. Here I start wondering why different people react differently to gamification, but I don't know. I did see earlier where people were going on about getting stars from github...
RodericDay 10y ago
Project Euler style puzzles: Yes. Jigsaw Puzzles: Not so much.
- iamcreasy 10y ago
  Yes, I find it a little weird that the author tried to reconcile two different things. Finding the perfect grey piece among hundreds of other similarly sized grey pieces isn't equivalent to finding/optimizing a math problem.
  - VLM 10y ago
    Perhaps an analogy with cryptographic one way functions would help. The point being that in both scenarios the highly ordered single one correct answer is easily transformed into a pile of obfuscation yet the conversion back "solving it" is extremely hard and mostly measures patience, experience, and memorization skills more so than raw mental horsepower. Take for example the first project euler "puzzle". There is exactly one bit of memorized information being tested for... do you, or do you not, already know that its possible to solve "sum of a sequence (of multiples or whatever)" using a simple formula, Gauss style, not by manually adding all the numbers? Then apply it by adding the multiples of 3 and the multiples of 5 and subtract the double counts (aka the mults of 15). Its just testing for memorization of one concept, maybe verifying you can plug and chug apply a simple rule. Its not testing sheer mental horsepower or ability to do math, but have you memorized a possibly apocryphal anecdote about young Mr Gauss's early education? There's nothing wrong with hiring plodders IF that fits the workload.
- michaelcampbell 10y ago
  Eh, sometimes. Euler relies on a lot of math, or math tricks, that is simply not necessary for a vast majority of today's computing. It used to be that programmers were needed for a lot of number crunchy things, but I've found at least in the "business world" (as opposed to academia, or perhaps startup), most computing is simply moving data around, and storage and retrieval.
mixmastamyk 10y ago
I do enjoy tackling hard problems in the real world, there are enough to fill many lifetimes. Brain-teasers to kill time? No thank you.
paulrpotts 10y ago
I think there are two issues here: whether you enjoy solving real problems, or whether you enjoy solving toy problems. Personally I get bored with toy problems. Sometimes I might write up a program to solve one. For example, I played around with writing a Sudoku solver when Sudoku was getting popular, but I got bored with it after a while and didn't put much effort into optimizing it. But I'm usually more interested in solving real problems. For example, I just wrote some code to read an encoder knob reliably on an Atmel ATtiny104 microcontroller, which is a chip that has 32 bytes (not kilobytes, bytes) of SRAM. A solution I found online uses 16 bytes for a lookup table. I got it working using two constants that are loaded into registers and so my solution actually uses no RAM at all. I enjoy that kind of puzzle. I had a student contact me a while ago to ask me whether I thought she should change majors to computer science. I scheduled a call and told her that before we talked I wanted her to take a crack at the "Cheryl's Birthday" puzzle that was going around -- see if she could solve it. I had solved it and I was not actually so concerned whether she could solve it, but I wanted to hear her talk about the process of trying to solve it -- did she approach it in any kind of systematic way. I think that may be an indicator of whether someone can do well at programming. Someone who just draws a complete blank when faced with decomposing a problem like that into parts may not be suited for programming.
- Noseshine 10y ago
  I agree with your last paragraph in principle, but I think that the pressure of the situation is very different from pressure during the actual work - even if the latter can be higher if one could give a value to "pressure". Interview pressure seems to me to be much more debilitating and destructive to people's problem solving abilities. I'm happy I do reasonable well and have little fear of interviews (which is good since I'm a freelancer), and yet looking at myself I can cope with normal job pressure, no matter how much, far better than with that during interviews. I miss so much obvious stuff that I'd never miss on the job. So I disagree that the interview pressure can be rationalized with "it tests if you can cope with work pressure". I take any amount of the latter over the former with pleasure.
- HiroshiSan 10y ago
  >Someone who just draws a complete blank when faced with decomposing a problem like that into parts may not be suited for programming. I feel like the above statement contradicts what you said. Mainly because this person may just not like toy problems but like you enjoys "real" problems. Also if it were true that a systematic way of solving a problem couldn't be learned then perhaps they might not be suited for programming. That being said there are books that do teach a systematic way such as How to Solve it by Polya.
yarrel 10y ago
I hate puzzles. Using brain-teasers to evaluate coding ability is like using lockpicking to evaluate orienteering ability.
- pavlov 10y ago
  Or like using 3D jigsaw puzzles to evaluate potential architecture students.
  - elcapitan 10y ago
    That's a better test to evaluate future users of modern architecture.
Someone 10y ago
So, where's the augmented reality smartphone app that makes solving such puzzles a snap? I imagine an app that, when pointed at puzzle pieces, first highlights a corner piece and then highlights candidates (ideally one, but four or five would already be a big win) that fit next to it, based on matching both the shape of the edge and the image on the pieces. Cheating? Yes. Way more work than putting one puzzle together? Yes. But it replaces fairly dumb puzzle-solving by programming.
- AndrewKemendo 10y ago
  Right here: https://youtu.be/Pz5xvVwr9Ds https://youtu.be/Pz5xvVwr9Ds
Xyik 10y ago
programming isn't just about solving problems. One of the reasons I'm drawn to programming and software engineering in general is because it grants me the power to create things and impact others. Of course, sometimes to create those things you will have to solve problems, but I think if you want to create something badly enough and a technical problem is stopping you, you'll find a way around it.
tomg 10y ago
> A few weeks ago I was contacted by a recruiter from a fairly high-profile San Francisco-based startup — if I was interested in joining their team. Sure! Great! Could you please solve this algorithmic puzzle within half an hour? I failed. Hiring decision made. End of story. I didn't realize how bad this Google/Facebook cargo-culting had gotten until looking for a new job the last few months (I'm approaching my 9th year in the industry). It's quite pervasive.
- drjasonharrison 10y ago
  It started a long time ago. See the 2004 book "How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle -- How the World's Smartest Companies Select the Most Creative Thinkers" https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/0316778494 https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/03167784... which discusses the use of these types of puzzles and the expectation that they are good interview questions.
  - hocuspocus 10y ago
    It's not new indeed, and there's been a shift from Microsoft's "How much would you charge to clean every window in Seattle?" type to Google's "Reverse a binary tree" kind of questions. I could be wrong but I believe the former wasn't as ubiquitous as whiteboard algorithmic questions have become.
- jackmott 10y ago
  Do we know that their approach isn't working? Like yes there are people who can be very productive programmers who can't do those puzzles. But maybe google isn't interested in those people. They have plenty of people who can do very good work already. Maybe the puzzles actually weed out the real geniuses, which is what they need? Or maybe it is totally failing at that, I have no idea. But I wouldn't dismiss it out of hand.
  - vonmoltke 10y ago
    The problem isn't Google per se. They have have a really deep hiring pipeline and could probably succeed in spite of severe deficiencies in the process. The problem is the numerous companies without Google's deep pipeline that have cargo-culted the process without understanding the context, then whine about not being able to hire anyone.
scotty79 10y ago
I hate building stuff. Am I still a programmer? I like puzzles and fixing things though.
- hackinthebochs 10y ago
  I'm with you. Real world concerns just get in the way of solving interesting problems.
  - scotty79 10y ago
    Stuff not working is a real world concern. I like to address such concerns. I just don't like building stuff that produces more of such concerns. There's plenty of those already for me to address for the rest of my life and lots of other peoples lives. Nah, who am I kidding. I just don't like to build stuff for some internal emotional reason.
akkartik 10y ago
Lately I've taken to call myself a "code plumber" at work. Mostly I work in the depths of infrastructure doing things that are invisible to users, usually involving thick pipes transferring petabytes from place A to place B, then place B to place C.. I rarely create anything new from whole cloth, most of what I do is maintenance and monitoring. Even the large projects involve migrations of various sorts. On the rare occasions I build something new and user-visible, 99% of it lies submerged in the backend. All this means that (since I'm pretty one-dimensional and all I do is hack) I need my side project to stay sane :)
- abstractbeliefs 10y ago
  despite the downvotes, I think this is a pretty apt analogy. Just the same as in house building, there are few architects who designed the master plan, there are some managers and skilled laborers who lead groups, and many less exciting roles that are still vitally important and knowledgeable in their trade. 99% of work where I am is connecting up a GUI to the hardware control subsystem of a medical product. The hardware control was relatively small work but interesting. Correctly managing the flow of data in a way that it's easy and safe for users to operate is not at all sexy, but vitally important, and ultimately, what sells our product.
- whamlastxmas 10y ago
  "Computer Janitor" is my favorite. Though plumber is also nice, because on some level it's all about turning fresh input into complete shit.
  - akkartik 10y ago
    Janitor = low status, which doesn't reflect reality. Plumber = Mario, which can be aspirational in a Tom Sawyer sort of way. :)
lukaslalinsky 10y ago
I also hate puzzles and I never understood why so many programmers find them interesting. I think much of real-world problem solving is about understanding. Understanding the situation. Understanding the history of the problem, what has been tried, what didn't work, etc. Asking a lot of questions and analyzing the answers. That's what I think should be called problem solving and I think there is very little overlap between this and puzzle solving. Puzzle solving is generally about finding the trick that the creator of the puzzle used, or in the case of job interviews, fitting your solution to what the creator imagined. Real-world problems don't work like that.
- VLM 10y ago
  Agree and extend with the addition of troubleshoot the failed solutions and try to figure out how to verify or prove the solution works. There are rail games where you have to progress exactly as the designer specified in the one true way. Then there are games where its a sandbox, minecraft style. I can't stand the former type of game and immensely enjoy the latter. Bad puzzles remind me of rail games. You're trapped on the worlds most boring path and now its a boring ESP test to see if you can guess the exact one true path the puzzle designer baked into the cake. Once you realize anything can be baked into the cake, how incredibly boring it becomes! Lets say you need to hire a navigator. You know, map reading, dead reckoning, digital tools like GPS, domain specific knowledge, all that stuff. Surely it takes great spatial awareness to be a navigator. I know, at interviews we'll hire navigators based on how well they solve those annoying string and rope puzzles. Now be a good little monkey and untangle the ring from the puzzle and we'll give you a job...
randcraw 10y ago
IMHO, scheduling four people to cross a bridge with one torch is not a puzzle; it's a simple constraint satisfaction problem, one that any competent engineer should be able to solve in less than 5 minutes. If you hate problems like this or can't solve them, then as a developer, you won't be useful to your employer as more than a grunt coder. And unfortunately, most coder jobs are being outsourced rapidly. But if algorithms are not your cup of tea, consider an alternative role where you can add value in solving problems that you like better -- like process management, data curation, UI / UX design, product development, user support, testing, etc. Not everyone who works in software has to solve math problems.
- elsurudo 10y ago
  Should be able to when required, yes. But not necessarily enjoy it. There are all sorts of problems. In many cases, finding the problem is more difficult that solving it, and IMO that requires a totally different skillset altogether.
fapjacks 10y ago
Just to add another perspective, I really enjoy puzzles. I've been a programmer for about twenty years professionally in one form or another. However, while I find my puzzle-solving passion is helpful in a lot of programming situations, I do not find those skills per se necessary to programming. I should also add here that I do not like puzzles which have an excessively "tricky" answer. I like puzzles that make me think in strange ways. But for example I have an awful puzzle ("kuku ball") which is kind of a moderately complex lock-type puzzle. That in and of itself I find enjoyable. But for the Kuku ball, you've actually got to apply an enormous amount of pressure to get the locking mechanism to open. Literally people have needed to hit it with a hammer.
blastrat 10y ago
This topic always comes back, and it attracts a bunch of people from one side of the issue who come out of the "would work" (on real problems only, ha ha) to disclaim puzzle solving as a measure of anything. I think it's because of the natural human tendency to wish to discount any criticism of one's self, and they perceive this type of aptitude used as a metric to be an implied criticism. Also, it's hard to see what you can't see, so it's hard to see the value of it too for people who can't see it. So, to argue the other side but still make a fresh, pleasing, and palatable comment, I will defend the side that says "puzzle solving is a rare and useful skill" but I will include a criticism of my side so you can all join in and say "see, your side does suck!" and everybody will be happy. I love solving puzzles, real or artificial, I'm really good at it, and there are plenty of real world problems that use the same skills (in my case I'm particularly "spatial", I conceptual the birthday problem as graphs of the attributes of the numbers), and elements of the same graphs occur in hashing algorithms, joins, simplex method, discrete math digital filters, modular arithmetic, sieves... The problem with being me is, I'm so attracted to puzzles, I can get distracted from the task at hand if it does not involve a puzzle. I will insert or find puzzles to solve where perhaps none exist. I will procrastinate a lot of the "uninteresting" (to me) but necessary parts of a project in favor of puzzle solving. Thankfully, projects tend to include a mix of people with different skillsets. But it can be annoying to have one's own skillset discounted as valuable, which is what you do to me when you say "I don't have this tendency and I'm a good worker" and what "they" are doing to you when they say "you don't have this tendency so you don't get the job."
- swalsh 10y ago
  Nice humblebrag.
  - blastrat 10y ago
    nice humbleinsult
ww520 10y ago
I love puzzles. It's a power trip watching other people struggling with them under pressure with the secret pleasure that I had solved them before (in leisure) and that I am smarter than them. /s
daly 10y ago
Love puzzles? What does this do? rootRadius(p,errorQuotient) == errorQuotient <= 1$R => error "rootRadius: second Parameter must be greater than 1" pp : UP := p rho : R := calculateScale makeMonic pp rR : R := rho pp := makeMonic scale(pp,complex(rho,0$R)) expo : NNI := 1 d : NNI := degree p currentError: R := nthRoot(2::R, 2) currentError := d20currentError while nthRoot(currentError, expo) >= errorQuotient repeat pp := graeffe pp rho := calculateScale pp expo := 2 * expo rR := nthRoot(rho, expo) * rR pp := makeMonic scale(pp,complex(rho,0$R)) rR That's my kind of puzzle.
- m_samuel_l 10y ago
  The answer is 42
paulmooreparks 10y ago
Using puzzles for interview questions has never made any sense to me. I have a pile of actual programming problems that I use for interviews, and they tell me more about a candidate than some contrived malarkey about getting some foxes and chickens across a river.

76 points by manaskarekar 10y ago

Jigsaw puzzles? They're awful.

Laszlo Bock was interviewed on NPR last month[1] and part of the interview discussed the hiring process. They know they have created really unpleasant interviews for candidates. Starts around 14m25s. [1] http://www.npr.org/2016/06/07/480976042/how-googles-laszlo-bock-is-making-work-better http://www.npr.org/2016/06/07/480976042/how-googles-laszlo-b...

kaspm 10y ago

Even at the companies (both big and small) that utilize this method for interviewing/hiring, generally aren't having their engineers work on these types of problems day-to-day. You utilize tools to solve business or technology issues and advance the company, it's much more satisfying than a puzzle (for those who don't like puzzles). If you'd like to solve real business challenges, practice and get good at this kind of puzzle, algorithmic interviews, decomposing technical problems. Approach them in the spirit they are intended: to showcase your skill. Get past the interviews and work on real problems. Then when you're in a position to influence how your company hires, switch to a interview style that works for you. I prefer 1:1 real-world pair coding exercises on a computer with Google and I specifically test for the ability to look things up on SO.

deleted 10y ago

[deleted]

ljoshua 10y ago

> I’ve been programming for 18 years now. Only very rarely have I had to come up with a complex algorithm. This. I am sure it is dependent on the type of work you do, and that Tesla and Google Search engineers probably need to excel at algorithms, but very rarely do I come across any need to solve those types of problems while developing software. I would much prefer to see problems that resemble "You have Service A, which needs to grab data from Service B and feed it to Service C. Show how you could integrate them." That would be much more representative of a larger body of typical work. Some companies out there like Starfighter do this, I wish more did.

michaelcampbell 10y ago
The whole thing boils down to companies wanting the people to be able to do these incredibly complex and creative things, when real world problems (by and large) are not these. Sure, I'd like my car to be ABLE to do 205 MPH, even though I rarely get above 70. But it's not realistic.
- ljoshua 10y ago
  Whew, I'm pretty sure I only want to be able to do 205 MPH if I'm in the sky! ;)
  - michaelcampbell 10y ago
    Fastest I've gone is 130MPH (on a proper track), and that's sphincter-puckering enough for me.

pklausler 10y ago

If you hate problem solving in general (as opposed to stupid puzzles), then there's a risk that you may not have an aptitude for debugging. When posed correctly, some interview problems can be a gauge of problem-solving ability and aptitude. The test of a puzzle problem's relevance is the extent to which it might expose a strength or weakness in real-world problem-solving. So stupid puzzles about, say, manhole cover shapes are obviously bogus. But there's some overlap between legitimate programming / debugging challenges that are small and self-contained enough to be useful in a 45 minute technical interview, and the set of problems that one might characterize as "puzzles".

vikiomega9 10y ago
I agree, but I'm wondering if you can give me an example and walk me through what check boxes you would look for in a self-contained example?
- pklausler 10y ago
  Given two closed intervals [a,b] and [c,d], write a simple predicate in any programming language that evaluates to TRUE if and only if the intervals overlap.
  - Joof 10y ago
    Match on interval [a, c] and [b, d]?
nraynaud 10y ago
frankly, it only becomes a puzzle when google failed me. On a side note I'm really looking forward to having questions about manhole covers in interviews, the interviewer might get a little more than what she bargained for on Reuleaux triangles and statics.
- kafkaesq 10y ago
  The interviewer might get a little more than what she bargained for on Reuleaux triangles and statics. But who has time or interest for pointless show-off-ery like that, even? It's 2016. The only answer you need to give to a questions of that sort is (with a mildly bemused expression): "You guys are still asking questions like that? ... I'm sorry, but this just isn't the right place for me."

Animats 10y ago

I've never been into puzzles, yet I did years of algorithmic development. I've worked on automatic theorem provers and written a physics engine for animation. I've done congestion control algorithms for networking and automatic driving algorithms for vehicles. But I never found puzzles interesting. I can do them if I have to, but rarely bother. I'd rather go out and ride my horse. Relevant Gary Larson cartoon: [1] [1] http://www.log24.com/log/pix15/150413-Gary_Larson-Heart_of_Mathematics.jpg http://www.log24.com/log/pix15/150413-Gary_Larson-Heart_of_M...

ovt 10y ago

My take on it is that puzzles and games are doing things by hand, and the point of programming in general is to do things once and for all and save humanity the trouble of doing things by hand. Not that there's anything wrong with doing whatever you enjoy doing by hand. Or perhaps it's that if we apply our ingenuity to a computer program, we have something and the rest of humanity can have it as well. If we apply our ingenuity to a puzzle, we don't have anything in the end. Here I start wondering why different people react differently to gamification, but I don't know. I did see earlier where people were going on about getting stars from github...

RodericDay 10y ago

Project Euler style puzzles: Yes. Jigsaw Puzzles: Not so much.

iamcreasy 10y ago
Yes, I find it a little weird that the author tried to reconcile two different things. Finding the perfect grey piece among hundreds of other similarly sized grey pieces isn't equivalent to finding/optimizing a math problem.
- VLM 10y ago
  Perhaps an analogy with cryptographic one way functions would help. The point being that in both scenarios the highly ordered single one correct answer is easily transformed into a pile of obfuscation yet the conversion back "solving it" is extremely hard and mostly measures patience, experience, and memorization skills more so than raw mental horsepower. Take for example the first project euler "puzzle". There is exactly one bit of memorized information being tested for... do you, or do you not, already know that its possible to solve "sum of a sequence (of multiples or whatever)" using a simple formula, Gauss style, not by manually adding all the numbers? Then apply it by adding the multiples of 3 and the multiples of 5 and subtract the double counts (aka the mults of 15). Its just testing for memorization of one concept, maybe verifying you can plug and chug apply a simple rule. Its not testing sheer mental horsepower or ability to do math, but have you memorized a possibly apocryphal anecdote about young Mr Gauss's early education? There's nothing wrong with hiring plodders IF that fits the workload.
michaelcampbell 10y ago
Eh, sometimes. Euler relies on a lot of math, or math tricks, that is simply not necessary for a vast majority of today's computing. It used to be that programmers were needed for a lot of number crunchy things, but I've found at least in the "business world" (as opposed to academia, or perhaps startup), most computing is simply moving data around, and storage and retrieval.

mixmastamyk 10y ago

I do enjoy tackling hard problems in the real world, there are enough to fill many lifetimes. Brain-teasers to kill time? No thank you.

paulrpotts 10y ago

I think there are two issues here: whether you enjoy solving real problems, or whether you enjoy solving toy problems. Personally I get bored with toy problems. Sometimes I might write up a program to solve one. For example, I played around with writing a Sudoku solver when Sudoku was getting popular, but I got bored with it after a while and didn't put much effort into optimizing it. But I'm usually more interested in solving real problems. For example, I just wrote some code to read an encoder knob reliably on an Atmel ATtiny104 microcontroller, which is a chip that has 32 bytes (not kilobytes, bytes) of SRAM. A solution I found online uses 16 bytes for a lookup table. I got it working using two constants that are loaded into registers and so my solution actually uses no RAM at all. I enjoy that kind of puzzle. I had a student contact me a while ago to ask me whether I thought she should change majors to computer science. I scheduled a call and told her that before we talked I wanted her to take a crack at the "Cheryl's Birthday" puzzle that was going around -- see if she could solve it. I had solved it and I was not actually so concerned whether she could solve it, but I wanted to hear her talk about the process of trying to solve it -- did she approach it in any kind of systematic way. I think that may be an indicator of whether someone can do well at programming. Someone who just draws a complete blank when faced with decomposing a problem like that into parts may not be suited for programming.

Noseshine 10y ago
I agree with your last paragraph in principle, but I think that the pressure of the situation is very different from pressure during the actual work - even if the latter can be higher if one could give a value to "pressure". Interview pressure seems to me to be much more debilitating and destructive to people's problem solving abilities. I'm happy I do reasonable well and have little fear of interviews (which is good since I'm a freelancer), and yet looking at myself I can cope with normal job pressure, no matter how much, far better than with that during interviews. I miss so much obvious stuff that I'd never miss on the job. So I disagree that the interview pressure can be rationalized with "it tests if you can cope with work pressure". I take any amount of the latter over the former with pleasure.
HiroshiSan 10y ago
>Someone who just draws a complete blank when faced with decomposing a problem like that into parts may not be suited for programming. I feel like the above statement contradicts what you said. Mainly because this person may just not like toy problems but like you enjoys "real" problems. Also if it were true that a systematic way of solving a problem couldn't be learned then perhaps they might not be suited for programming. That being said there are books that do teach a systematic way such as How to Solve it by Polya.

yarrel 10y ago

I hate puzzles. Using brain-teasers to evaluate coding ability is like using lockpicking to evaluate orienteering ability.

pavlov 10y ago
Or like using 3D jigsaw puzzles to evaluate potential architecture students.
- elcapitan 10y ago
  That's a better test to evaluate future users of modern architecture.

Someone 10y ago

So, where's the augmented reality smartphone app that makes solving such puzzles a snap? I imagine an app that, when pointed at puzzle pieces, first highlights a corner piece and then highlights candidates (ideally one, but four or five would already be a big win) that fit next to it, based on matching both the shape of the edge and the image on the pieces. Cheating? Yes. Way more work than putting one puzzle together? Yes. But it replaces fairly dumb puzzle-solving by programming.

AndrewKemendo 10y ago
Right here: https://youtu.be/Pz5xvVwr9Ds https://youtu.be/Pz5xvVwr9Ds

Xyik 10y ago

programming isn't just about solving problems. One of the reasons I'm drawn to programming and software engineering in general is because it grants me the power to create things and impact others. Of course, sometimes to create those things you will have to solve problems, but I think if you want to create something badly enough and a technical problem is stopping you, you'll find a way around it.

tomg 10y ago

> A few weeks ago I was contacted by a recruiter from a fairly high-profile San Francisco-based startup — if I was interested in joining their team. Sure! Great! Could you please solve this algorithmic puzzle within half an hour? I failed. Hiring decision made. End of story. I didn't realize how bad this Google/Facebook cargo-culting had gotten until looking for a new job the last few months (I'm approaching my 9th year in the industry). It's quite pervasive.

drjasonharrison 10y ago
It started a long time ago. See the 2004 book "How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle -- How the World's Smartest Companies Select the Most Creative Thinkers" https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/0316778494 https://www.amazon.com/How-Would-Move-Mount-Fuji/dp/03167784... which discusses the use of these types of puzzles and the expectation that they are good interview questions.
- hocuspocus 10y ago
  It's not new indeed, and there's been a shift from Microsoft's "How much would you charge to clean every window in Seattle?" type to Google's "Reverse a binary tree" kind of questions. I could be wrong but I believe the former wasn't as ubiquitous as whiteboard algorithmic questions have become.
jackmott 10y ago
Do we know that their approach isn't working? Like yes there are people who can be very productive programmers who can't do those puzzles. But maybe google isn't interested in those people. They have plenty of people who can do very good work already. Maybe the puzzles actually weed out the real geniuses, which is what they need? Or maybe it is totally failing at that, I have no idea. But I wouldn't dismiss it out of hand.
- vonmoltke 10y ago
  The problem isn't Google per se. They have have a really deep hiring pipeline and could probably succeed in spite of severe deficiencies in the process. The problem is the numerous companies without Google's deep pipeline that have cargo-culted the process without understanding the context, then whine about not being able to hire anyone.

scotty79 10y ago

I hate building stuff. Am I still a programmer? I like puzzles and fixing things though.

hackinthebochs 10y ago
I'm with you. Real world concerns just get in the way of solving interesting problems.
- scotty79 10y ago
  Stuff not working is a real world concern. I like to address such concerns. I just don't like building stuff that produces more of such concerns. There's plenty of those already for me to address for the rest of my life and lots of other peoples lives. Nah, who am I kidding. I just don't like to build stuff for some internal emotional reason.

akkartik 10y ago

Lately I've taken to call myself a "code plumber" at work. Mostly I work in the depths of infrastructure doing things that are invisible to users, usually involving thick pipes transferring petabytes from place A to place B, then place B to place C.. I rarely create anything new from whole cloth, most of what I do is maintenance and monitoring. Even the large projects involve migrations of various sorts. On the rare occasions I build something new and user-visible, 99% of it lies submerged in the backend. All this means that (since I'm pretty one-dimensional and all I do is hack) I need my side project to stay sane :)

abstractbeliefs 10y ago
despite the downvotes, I think this is a pretty apt analogy. Just the same as in house building, there are few architects who designed the master plan, there are some managers and skilled laborers who lead groups, and many less exciting roles that are still vitally important and knowledgeable in their trade. 99% of work where I am is connecting up a GUI to the hardware control subsystem of a medical product. The hardware control was relatively small work but interesting. Correctly managing the flow of data in a way that it's easy and safe for users to operate is not at all sexy, but vitally important, and ultimately, what sells our product.
whamlastxmas 10y ago
"Computer Janitor" is my favorite. Though plumber is also nice, because on some level it's all about turning fresh input into complete shit.
- akkartik 10y ago
  Janitor = low status, which doesn't reflect reality. Plumber = Mario, which can be aspirational in a Tom Sawyer sort of way. :)

lukaslalinsky 10y ago

I also hate puzzles and I never understood why so many programmers find them interesting. I think much of real-world problem solving is about understanding. Understanding the situation. Understanding the history of the problem, what has been tried, what didn't work, etc. Asking a lot of questions and analyzing the answers. That's what I think should be called problem solving and I think there is very little overlap between this and puzzle solving. Puzzle solving is generally about finding the trick that the creator of the puzzle used, or in the case of job interviews, fitting your solution to what the creator imagined. Real-world problems don't work like that.

VLM 10y ago
Agree and extend with the addition of troubleshoot the failed solutions and try to figure out how to verify or prove the solution works. There are rail games where you have to progress exactly as the designer specified in the one true way. Then there are games where its a sandbox, minecraft style. I can't stand the former type of game and immensely enjoy the latter. Bad puzzles remind me of rail games. You're trapped on the worlds most boring path and now its a boring ESP test to see if you can guess the exact one true path the puzzle designer baked into the cake. Once you realize anything can be baked into the cake, how incredibly boring it becomes! Lets say you need to hire a navigator. You know, map reading, dead reckoning, digital tools like GPS, domain specific knowledge, all that stuff. Surely it takes great spatial awareness to be a navigator. I know, at interviews we'll hire navigators based on how well they solve those annoying string and rope puzzles. Now be a good little monkey and untangle the ring from the puzzle and we'll give you a job...

randcraw 10y ago

IMHO, scheduling four people to cross a bridge with one torch is not a puzzle; it's a simple constraint satisfaction problem, one that any competent engineer should be able to solve in less than 5 minutes. If you hate problems like this or can't solve them, then as a developer, you won't be useful to your employer as more than a grunt coder. And unfortunately, most coder jobs are being outsourced rapidly. But if algorithms are not your cup of tea, consider an alternative role where you can add value in solving problems that you like better -- like process management, data curation, UI / UX design, product development, user support, testing, etc. Not everyone who works in software has to solve math problems.

elsurudo 10y ago
Should be able to when required, yes. But not necessarily enjoy it. There are all sorts of problems. In many cases, finding the problem is more difficult that solving it, and IMO that requires a totally different skillset altogether.

fapjacks 10y ago

Just to add another perspective, I really enjoy puzzles. I've been a programmer for about twenty years professionally in one form or another. However, while I find my puzzle-solving passion is helpful in a lot of programming situations, I do not find those skills per se necessary to programming. I should also add here that I do not like puzzles which have an excessively "tricky" answer. I like puzzles that make me think in strange ways. But for example I have an awful puzzle ("kuku ball") which is kind of a moderately complex lock-type puzzle. That in and of itself I find enjoyable. But for the Kuku ball, you've actually got to apply an enormous amount of pressure to get the locking mechanism to open. Literally people have needed to hit it with a hammer.

blastrat 10y ago

This topic always comes back, and it attracts a bunch of people from one side of the issue who come out of the "would work" (on real problems only, ha ha) to disclaim puzzle solving as a measure of anything. I think it's because of the natural human tendency to wish to discount any criticism of one's self, and they perceive this type of aptitude used as a metric to be an implied criticism. Also, it's hard to see what you can't see, so it's hard to see the value of it too for people who can't see it. So, to argue the other side but still make a fresh, pleasing, and palatable comment, I will defend the side that says "puzzle solving is a rare and useful skill" but I will include a criticism of my side so you can all join in and say "see, your side does suck!" and everybody will be happy. I love solving puzzles, real or artificial, I'm really good at it, and there are plenty of real world problems that use the same skills (in my case I'm particularly "spatial", I conceptual the birthday problem as graphs of the attributes of the numbers), and elements of the same graphs occur in hashing algorithms, joins, simplex method, discrete math digital filters, modular arithmetic, sieves... The problem with being me is, I'm so attracted to puzzles, I can get distracted from the task at hand if it does not involve a puzzle. I will insert or find puzzles to solve where perhaps none exist. I will procrastinate a lot of the "uninteresting" (to me) but necessary parts of a project in favor of puzzle solving. Thankfully, projects tend to include a mix of people with different skillsets. But it can be annoying to have one's own skillset discounted as valuable, which is what you do to me when you say "I don't have this tendency and I'm a good worker" and what "they" are doing to you when they say "you don't have this tendency so you don't get the job."

swalsh 10y ago
Nice humblebrag.
- blastrat 10y ago
  nice humbleinsult

ww520 10y ago

I love puzzles. It's a power trip watching other people struggling with them under pressure with the secret pleasure that I had solved them before (in leisure) and that I am smarter than them. /s

daly 10y ago

Love puzzles? What does this do? rootRadius(p,errorQuotient) == errorQuotient <= 1$R => error "rootRadius: second Parameter must be greater than 1" pp : UP := p rho : R := calculateScale makeMonic pp rR : R := rho pp := makeMonic scale(pp,complex(rho,0$R)) expo : NNI := 1 d : NNI := degree p currentError: R := nthRoot(2::R, 2) currentError := d20currentError while nthRoot(currentError, expo) >= errorQuotient repeat pp := graeffe pp rho := calculateScale pp expo := 2 * expo rR := nthRoot(rho, expo) * rR pp := makeMonic scale(pp,complex(rho,0$R)) rR That's my kind of puzzle.

m_samuel_l 10y ago
The answer is 42

paulmooreparks 10y ago

Using puzzles for interview questions has never made any sense to me. I have a pile of actual programming problems that I use for interviews, and they tell me more about a candidate than some contrived malarkey about getting some foxes and chickens across a river.