5 ms·

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

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.
- jxramos 10y ago
  I was just thinking about Polya's suggestion in this context about solving a simpler problem, where toy is the simpler problem, even if just simpler by clearing out all the "cruft" like hackinthebochs mentions.
- paulrpotts 10y ago
  Well, yeah, I suppose it was a little contradictory. I was not really evaluating her ability to do a real-world programming task (which, note, is not _entirely_ related to some of the stuff one might have to do for a CS degree). With only an e-mail and a phone call to get to know her, I was casting about for some way to evaluate, and ask her to evaluate, whether she had the basics of a systematic approach to problem-solving, or even enjoyed it.
splintercell 10y ago
> I think there are two issues here: whether you enjoy solving real problems, or whether you enjoy solving toy problems. This is so true for me. I am a lot more interested in solving real problems. I just don't get people who are interested in solving toy problems.
- hackinthebochs 10y ago
  As someone who prefers toy problems to real problems I'll tell you why: toy problems are distilled down to the algorithm or the "interesting" parts. Whereas real problems the cruft to "interesting" ratio is severely out of whack. As someone who used to love programming but is entirely bored of it now, its because to get the interesting part of most real world problems you have to wade through a mountain of cruft: piles and piles of APIs that have nothing interesting about them but are necessary to do anything at all. I think the difference can be boiled down to the fact that there are two types of programmers: those who mainly enjoy solving problems and those who mainly enjoy building useful things. If the enjoyment is from the problem solving then real world concerns just get in the way.
  - deleted 10y ago
    [deleted]
  - splintercell 10y ago
    > Whereas real problems the cruft to "interesting" ratio is severely out of whack. Which is why the real world problems are so much more interesting. Sure they are not interesting when the cruft is still there, but they become wildly more interesting once the cruft is removed. What makes a toy problem boring for me is the fact that even if I figure out the solution, it's not something new, others have already figured out the solution before me, so I feel like I'm wasting my time.
nsxwolf 10y ago
I've been programming professionally for 15 years. I read the "Cheryl's Birthday" problem and instantly said "Dear God, I want nothing to do with this". I don't think I could get the motivation to attempt to solve that unless my boss told me to do it and there was a threat of being canned.
- pklausler 10y ago
  Hm. I've been programming professionally for 36 years, just looked up the "Cheryl's Birthday" problem, and really enjoyed figuring out the solution. I wouldn't ask this sort of thing as an interview question, though, because of the odds of a "false negative".
  - doktrin 10y ago
    I too program professionally (shock of shocks), and I also enjoyed solving the problem. However, I'm torn on how informative this question would be in an interview setting. On the one hand, I kind of abhor gimmicky interview questions. On the other, it could provide some valuable insight into the candidate's thought process & reasoning. Also, I honestly feel like any competent engineer should be able to narrow the solution down to 3 possible dates with some thought and effort - even while in the interview hotseat. It would be unfair to deny someone a position solely on the basis of a logic / word puzzle, but if someone really is incapable (with some light guidance) of tackling at least part of 'cheryl's birthday' then I would want to dig a little deeper to figure out what's going on.
  - paulrpotts 10y ago
    I would not ask it as an interview question either, and in fact I dislike interview puzzles unless they are directly related to the task at hand. I did ask this student to look at it, though. Without knowing anything about her I thought it might give me at least a little insight into whether I thought she was suited to a CS program, or not. Basically, I was hoping that _she_ would use her own reaction to the puzzle to make that judgment about herself. I know CS isn't really directly related to this kind of toy puzzle, but like I mentioned, because solving it requires systematic thinking along the lines of making a mathematical proof.
swalsh 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." People are motivated by different things, which is convenient because programming is a diverse set of issues. if I solve that puzzle, none of my own personal motivations are massaged. There are more than technical issues a programmer must address.
gregmac 10y ago
I think Cheryl's Birthday puzzle is exactly an example of a terrible problem to evaluate a programmer with. If I was given a real-world problem similar in nature to that, my first question would be "why? what are you trying to accomplish?" with my focus looking for a way to fix the absolutely terrible input parameters. Secondly, what's the general case? I don't generally like to solve one-off problems where my code is scrapped after a single execution. So I will ask questions to figure out how to generalize this problem so my code can find the answer to the general case. Seeing as this is a puzzle problem -- convoluted for the sake of being a puzzle -- there's likely no good answers to my questions. The ironic part is the idea of puzzle questions are presumably to find critical thinkers, but the nature of being a puzzle means you can't be too much of a critical thinker. I've many times seen developers go down deep paths solving complex problems like this (especially for data interchange). While technically impressive, the better way is to avoid the complex problem by changing process at a higher level. If everyone blindly stays within the lines, you can end up with the sending side doing extra work to push out data in a complex format (thinking it's what the receiving side needs or wants), while the receiving side then does extra work to parse out the crazy format the sending side is using. The truly critical thinker steps back and asks "Why doesn't Cheryl just tell us her exact birthday?" and doesn't back down until they get a reasonable answer.
- clifanatic 10y ago
  I think it was Scott Adams (Dilbert creator) who said something along the lines of "interview puzzles are an excellent way to determine if the interviewee has seen this particular problem before".
- paulrpotts 10y ago
  >I think Cheryl's Birthday puzzle is exactly an example of a terrible problem to evaluate a programmer with. All true, but please note I was not interviewing her for a job, just trying to give her advice on whether I thought she would even want to _start_ a CS major.
mrighele 10y ago
I never heard about "Cheryl's Birthday" puzzle until today, but back when I was at the university I heard about a different (and in my opinion, more elegant) version: Instead of day and month the two person involved must guess two natural numbers. One knows only the sum of the two numbers, the other only the product, but the dialog between them is exactly the same. It's been a number of years so I'm not sure about the details; I think the numbers were strictly positive, but I don't know if the first to talk was the one knowing the sum or the one knowing the product.
- paulrpotts 10y ago
  Interesting -- if you can find that puzzle, I'd like to see the original.
  - mrighele 10y ago
    I feel ashamed answering after more than two days, but I never notice when people answer to me on HN. Anyway, you can find a description of the puzzle on Wikipedia [1]. It is almost 50 years old! [1] https://en.m.wikipedia.org/wiki/Sum_and_Product_Puzzle https://en.m.wikipedia.org/wiki/Sum_and_Product_Puzzle

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.

jxramos 10y ago
I was just thinking about Polya's suggestion in this context about solving a simpler problem, where toy is the simpler problem, even if just simpler by clearing out all the "cruft" like hackinthebochs mentions.
paulrpotts 10y ago
Well, yeah, I suppose it was a little contradictory. I was not really evaluating her ability to do a real-world programming task (which, note, is not _entirely_ related to some of the stuff one might have to do for a CS degree). With only an e-mail and a phone call to get to know her, I was casting about for some way to evaluate, and ask her to evaluate, whether she had the basics of a systematic approach to problem-solving, or even enjoyed it.

splintercell 10y ago

> I think there are two issues here: whether you enjoy solving real problems, or whether you enjoy solving toy problems. This is so true for me. I am a lot more interested in solving real problems. I just don't get people who are interested in solving toy problems.

hackinthebochs 10y ago
As someone who prefers toy problems to real problems I'll tell you why: toy problems are distilled down to the algorithm or the "interesting" parts. Whereas real problems the cruft to "interesting" ratio is severely out of whack. As someone who used to love programming but is entirely bored of it now, its because to get the interesting part of most real world problems you have to wade through a mountain of cruft: piles and piles of APIs that have nothing interesting about them but are necessary to do anything at all. I think the difference can be boiled down to the fact that there are two types of programmers: those who mainly enjoy solving problems and those who mainly enjoy building useful things. If the enjoyment is from the problem solving then real world concerns just get in the way.
- deleted 10y ago
  [deleted]
- splintercell 10y ago
  > Whereas real problems the cruft to "interesting" ratio is severely out of whack. Which is why the real world problems are so much more interesting. Sure they are not interesting when the cruft is still there, but they become wildly more interesting once the cruft is removed. What makes a toy problem boring for me is the fact that even if I figure out the solution, it's not something new, others have already figured out the solution before me, so I feel like I'm wasting my time.

nsxwolf 10y ago

I've been programming professionally for 15 years. I read the "Cheryl's Birthday" problem and instantly said "Dear God, I want nothing to do with this". I don't think I could get the motivation to attempt to solve that unless my boss told me to do it and there was a threat of being canned.

pklausler 10y ago
Hm. I've been programming professionally for 36 years, just looked up the "Cheryl's Birthday" problem, and really enjoyed figuring out the solution. I wouldn't ask this sort of thing as an interview question, though, because of the odds of a "false negative".
- doktrin 10y ago
  I too program professionally (shock of shocks), and I also enjoyed solving the problem. However, I'm torn on how informative this question would be in an interview setting. On the one hand, I kind of abhor gimmicky interview questions. On the other, it could provide some valuable insight into the candidate's thought process & reasoning. Also, I honestly feel like any competent engineer should be able to narrow the solution down to 3 possible dates with some thought and effort - even while in the interview hotseat. It would be unfair to deny someone a position solely on the basis of a logic / word puzzle, but if someone really is incapable (with some light guidance) of tackling at least part of 'cheryl's birthday' then I would want to dig a little deeper to figure out what's going on.
- paulrpotts 10y ago
  I would not ask it as an interview question either, and in fact I dislike interview puzzles unless they are directly related to the task at hand. I did ask this student to look at it, though. Without knowing anything about her I thought it might give me at least a little insight into whether I thought she was suited to a CS program, or not. Basically, I was hoping that _she_ would use her own reaction to the puzzle to make that judgment about herself. I know CS isn't really directly related to this kind of toy puzzle, but like I mentioned, because solving it requires systematic thinking along the lines of making a mathematical proof.

swalsh 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." People are motivated by different things, which is convenient because programming is a diverse set of issues. if I solve that puzzle, none of my own personal motivations are massaged. There are more than technical issues a programmer must address.

gregmac 10y ago

I think Cheryl's Birthday puzzle is exactly an example of a terrible problem to evaluate a programmer with. If I was given a real-world problem similar in nature to that, my first question would be "why? what are you trying to accomplish?" with my focus looking for a way to fix the absolutely terrible input parameters. Secondly, what's the general case? I don't generally like to solve one-off problems where my code is scrapped after a single execution. So I will ask questions to figure out how to generalize this problem so my code can find the answer to the general case. Seeing as this is a puzzle problem -- convoluted for the sake of being a puzzle -- there's likely no good answers to my questions. The ironic part is the idea of puzzle questions are presumably to find critical thinkers, but the nature of being a puzzle means you can't be too much of a critical thinker. I've many times seen developers go down deep paths solving complex problems like this (especially for data interchange). While technically impressive, the better way is to avoid the complex problem by changing process at a higher level. If everyone blindly stays within the lines, you can end up with the sending side doing extra work to push out data in a complex format (thinking it's what the receiving side needs or wants), while the receiving side then does extra work to parse out the crazy format the sending side is using. The truly critical thinker steps back and asks "Why doesn't Cheryl just tell us her exact birthday?" and doesn't back down until they get a reasonable answer.

clifanatic 10y ago
I think it was Scott Adams (Dilbert creator) who said something along the lines of "interview puzzles are an excellent way to determine if the interviewee has seen this particular problem before".
paulrpotts 10y ago
>I think Cheryl's Birthday puzzle is exactly an example of a terrible problem to evaluate a programmer with. All true, but please note I was not interviewing her for a job, just trying to give her advice on whether I thought she would even want to _start_ a CS major.

mrighele 10y ago

I never heard about "Cheryl's Birthday" puzzle until today, but back when I was at the university I heard about a different (and in my opinion, more elegant) version: Instead of day and month the two person involved must guess two natural numbers. One knows only the sum of the two numbers, the other only the product, but the dialog between them is exactly the same. It's been a number of years so I'm not sure about the details; I think the numbers were strictly positive, but I don't know if the first to talk was the one knowing the sum or the one knowing the product.

paulrpotts 10y ago
Interesting -- if you can find that puzzle, I'd like to see the original.
- mrighele 10y ago
  I feel ashamed answering after more than two days, but I never notice when people answer to me on HN. Anyway, you can find a description of the puzzle on Wikipedia [1]. It is almost 50 years old! [1] https://en.m.wikipedia.org/wiki/Sum_and_Product_Puzzle https://en.m.wikipedia.org/wiki/Sum_and_Product_Puzzle