5 ms·

There seems to be a growing and vocal subgroup of programmers who think solving algorithm problems is about memorization. That worries me. Don't they understand

There seems to be a growing and vocal subgroup of programmers who think solving algorithm problems is about memorization. That worries me. Don't they understand that problems can be solved by thinking? That they're being asked about the most timeless and beautiful parts of programming, which don't depend on the technology of the day, and whose beauty is that you can figure out everything from scratch? Or that solving such problems gave us computers and the internet in the first place? ...I must be getting old. I have nothing but ugly things to say about that attitude. Sorry, HN.

viraptor 10y ago
Unless you specifically work in a scientific environment, when do you ever solve problems using a novel, non trivial algorithm designed by yourself? An amazing amount of programmers are simply doing CRUD, batch processing, and mapping data from one format to another. It's not rocket science. I'd bet that ~99% of programmers never created a new algorithm, or needed to. And that's fine. (where by new algorithm I mean an actual, unique solution lowering the bounds on some operation which is usually done in a simpler way) Outside of what's happening in ML research, I can't even think of recent known examples.
- deleted 10y ago
  [deleted]
oftenwrong 10y ago
If a candidate doesn't know what "bubble sort" is, they cannot implement it without having it described to them first. If you have to describe the algorithm to the candidate, then what is the point of them asking for an implementation? The implementation is the description in code form. A better test might be to give the candidate a bubble sort implementation, and ask questions about that specific code, like what the "big O" is.
chis 10y ago
Current interviews don't really encourage critical thinking. If 2 candidates are given a question, and one can regurgitate a memorized algorithm immediately, he's probably the one to get the job. Plus, nerves and time pressure make it nearly impossible to solve algorithms on the spot. I found it infuriating at my google interview when I tried to pause for a minute to reason through the question (out loud) and my interviewer started prompting me with hints and pieces of the answer. It was obvious that I was losing points because I hadn't seen the question before. It seems like companies are okay with this system anyways. MIT literally offers a course called "Hacking a Google Interview", and yet Google still hasn't changed their internship interview problems.
flukus 10y ago
How many times do you think bubble sort was independently invented?
imode 10y ago
you aren't alone. recently, I was constructing a small query engine based off of Prolog, a language which I have never delved into the internals of. the rewarding moments were when it worked. I didn't work off of any documentation, only by thinking how I'd design something similar. going "from scratch" is incredibly rewarding because you start realizing that some parts of your thought are based on well-trodden ground. things start to light up. I'll never get tired of that style of work.
apricot 10y ago
Also see Keith Devlin's essay: In math you have to remember, in other subjects you can think about it at http://www.maa.org/external_archive/devlin/devlin_06_10.html http://www.maa.org/external_archive/devlin/devlin_06_10.html

viraptor 10y ago

Unless you specifically work in a scientific environment, when do you ever solve problems using a novel, non trivial algorithm designed by yourself? An amazing amount of programmers are simply doing CRUD, batch processing, and mapping data from one format to another. It's not rocket science. I'd bet that ~99% of programmers never created a new algorithm, or needed to. And that's fine. (where by new algorithm I mean an actual, unique solution lowering the bounds on some operation which is usually done in a simpler way) Outside of what's happening in ML research, I can't even think of recent known examples.

deleted 10y ago
[deleted]

oftenwrong 10y ago

If a candidate doesn't know what "bubble sort" is, they cannot implement it without having it described to them first. If you have to describe the algorithm to the candidate, then what is the point of them asking for an implementation? The implementation is the description in code form. A better test might be to give the candidate a bubble sort implementation, and ask questions about that specific code, like what the "big O" is.

chis 10y ago

Current interviews don't really encourage critical thinking. If 2 candidates are given a question, and one can regurgitate a memorized algorithm immediately, he's probably the one to get the job. Plus, nerves and time pressure make it nearly impossible to solve algorithms on the spot. I found it infuriating at my google interview when I tried to pause for a minute to reason through the question (out loud) and my interviewer started prompting me with hints and pieces of the answer. It was obvious that I was losing points because I hadn't seen the question before. It seems like companies are okay with this system anyways. MIT literally offers a course called "Hacking a Google Interview", and yet Google still hasn't changed their internship interview problems.

flukus 10y ago

How many times do you think bubble sort was independently invented?

imode 10y ago

you aren't alone. recently, I was constructing a small query engine based off of Prolog, a language which I have never delved into the internals of. the rewarding moments were when it worked. I didn't work off of any documentation, only by thinking how I'd design something similar. going "from scratch" is incredibly rewarding because you start realizing that some parts of your thought are based on well-trodden ground. things start to light up. I'll never get tired of that style of work.

apricot 10y ago

Also see Keith Devlin's essay: In math you have to remember, in other subjects you can think about it at http://www.maa.org/external_archive/devlin/devlin_06_10.html http://www.maa.org/external_archive/devlin/devlin_06_10.html