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...
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.
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.
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.
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.
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.
>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.
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.
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.
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.
> 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.
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.
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".
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.
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.
I just looked up Cheryl's Birthday. The wording is designed to obfuscate and confuse. The sentence, "Cheryl then tells Albert and Bernard separately the month and the day of her birthday respectively" is so dense and confusing. It would be much clearer to simply state, "Cheryl tells Albert the month and tells Bernard the day of her birthday separately."
I have no problem with puzzle. I have problem with puzzles the use word to confuse and obfuscate. Fuck you, I'm here to solve a puzzle, not playing word game.
Cheryl's Birthday is just a case of using known facts to eliminate impossibility, like the single day 6/18, progressively.
Yes, it's always obfuscated and confusing. That's usually because the users don't even know what they want or what the actual problem is. It takes time to prompt them to formulate what the actual problem is and what the correct expected outcome is. It's not like they know what the problem is and deliberately hiding it. And I got days or weeks to extract the correct information from people. Didn't have to do it under 15 minutes, as in an interview.
Interview is a time limited process to discover what the candidate's ability and knowledge are. You want to remove any fluff that is a waste of time. Ask any garbage question and you'll get garbage answer.
"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.
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.
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".
>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.
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.
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!
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.
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.
> 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.
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.
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.
I think we - and by that I mean "most programmers, on average" - have a pretty good idea how common or uncommon it is in real life programming in a variety of programming jobs to encounter an actual algorithmic problem. One that you are better off solving yourself instead of just googling or asking (yes, on horrible SO). The last sentence does not advocate copy&paste programming, I myself in particular actually have hardly any external dependencies because I try hard to avoid them, and when I do I actually do look through the source code, mostly because I need to adapt it to my needs.
Even if I were to do something like machine learning I'm much better off just using something made by others, simply because developing the actual algorithms requires people completely immersed in just that and a big love of math (and the Ph.D. to go with it) much more so than programming.
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.
I once failed a Microsoft interview where the biggest strike against me was a question which was just simple algebra, and one that I later saw in some programming interview book and realized it was actually a fairly simple one.
However, my brain froze at the time of the interview. Because I was furious. Because the interviewer kept asking me "Are you sure you have not seen this question before already?" and I kept saying I hadn't. So here is what she was actually conveying a) she does not trust the candidate b) actually having seen the problem before would have made the solution much easier (does it mean not having seen it before would make it that much harder?). Most interestingly, I later saw that the solution basically hinged around a specific insight, in other words it was a fairly binary outcome: you either figured out that little insight, or you didn't. It was not exactly a question which could have been progressively solved, and of course this brilliant interviewer was not moving on to another question either. I should have given the interviewer a piece of my mind, but unfortunately I was brought in for the round of interviews by referral from a friend.
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.
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 :)
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.
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.
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.
> 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.
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.
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".
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.
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.
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."
Why not just ask them directly what their memorable debugging session was? And have an in-depth discussion about that experience. Using puzzles is a round about way to guess whether the candidates are good at debugging or not, and it certainly is not an accurate way to gauge debugging ability.
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.
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.
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...
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.
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.
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.
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."
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
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.
77 comments
[ 3.3 ms ] story [ 143 ms ] threadNot 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...
Jigsaw Puzzles: Not so much.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I have no problem with puzzle. I have problem with puzzles the use word to confuse and obfuscate. Fuck you, I'm here to solve a puzzle, not playing word game.
Cheryl's Birthday is just a case of using known facts to eliminate impossibility, like the single day 6/18, progressively.
Yep. have you ever worked with a software development process that used formal specification documents? : )
Interview is a time limited process to discover what the candidate's ability and knowledge are. You want to remove any fluff that is a waste of time. Ask any garbage question and you'll get garbage answer.
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.
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.
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.
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.
[1] https://en.m.wikipedia.org/wiki/Sum_and_Product_Puzzle
Using brain-teasers to evaluate coding ability is like using lockpicking to evaluate orienteering ability.
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.
https://youtu.be/Pz5xvVwr9Ds
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.
"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/03167784...
which discusses the use of these types of puzzles and the expectation that they are good interview questions.
Or maybe it is totally failing at that, I have no idea. But I wouldn't dismiss it out of hand.
Even if I were to do something like machine learning I'm much better off just using something made by others, simply because developing the actual algorithms requires people completely immersed in just that and a big love of math (and the Ph.D. to go with it) much more so than programming.
However, my brain froze at the time of the interview. Because I was furious. Because the interviewer kept asking me "Are you sure you have not seen this question before already?" and I kept saying I hadn't. So here is what she was actually conveying a) she does not trust the candidate b) actually having seen the problem before would have made the solution much easier (does it mean not having seen it before would make it that much harder?). Most interestingly, I later saw that the solution basically hinged around a specific insight, in other words it was a fairly binary outcome: you either figured out that little insight, or you didn't. It was not exactly a question which could have been progressively solved, and of course this brilliant interviewer was not moving on to another question either. I should have given the interviewer a piece of my mind, but unfortunately I was brought in for the round of interviews by referral from a friend.
Nah, who am I kidding. I just don't like to build stuff for some internal emotional reason.
All this means that (since I'm pretty one-dimensional and all I do is hack) I need my side project to stay sane :)
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.
:)
[1] http://www.npr.org/2016/06/07/480976042/how-googles-laszlo-b...
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.
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.
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.
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".
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.
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."
Relevant Gary Larson cartoon: [1]
[1] http://www.log24.com/log/pix15/150413-Gary_Larson-Heart_of_M...
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.
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...
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.
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."
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.