3 ms·

Would it be the worst thing ever if you hired someone who was capable of memorizing the solutions to common problems?

robomartin 14y ago
The best example I have against this goes back to physics and calculus classes. I have to try to be very sensitive here. There was a certain ethnic group who overwhelmingly aced calculus tests. I mean, they were machines. Got it done faster than everyone and just aced the tests. No contest. The amazing thing was what happened in Physics class, both tests and labs. They were completely lost. It was really an odd and unbelievable thing to behold. Some of them would get tripped-up by the simplest things. I won't venture to guess as to why and how this happens. I'll just say that, in my experience, mechanical memorization of anything isn't learning at all. It's just memorization with no value whatsoever beyond that. I am trying to think about a CS example. Let's say that someone memorizes the implementation of a binary GA algorithm or a NN. Great. They can type it out in an instant when asked. Do they really understand what's going on? Do they understand when to apply it, how and why? Do they understand how to optimize it? Do they know how to make good chromosome encoding decisions? Or how about dealing with cases where the GA is lost looking for a solution? Do they know how to fix it? Or how to deal with it? Or how about the choice between writing a class with a bunch of methods and properties vs. a simple routine with lookup table to solve a problem? I've seen people who think that every solution requires a class and a bunch of objects. You end-up with code that is fifty times slower and ten times larger than it needs to be. Some of this only comes from experience, of course. If available, I like to look at code that the candidate wrote and explore it. It's hard for someone to bullshit you if it isn't their code. Another interesting thing to do is to put code in front of them and see how they go about understanding what's going on. After all, if you are hiring them to plug into an existing project that is precisely what they'll have to do. Someone who can't code will not ask intelligent questions about the code they are looking at. They will have a hard time getting into it and understanding what's going on. Now, I do understand from other posts that there seems to be a failure in the system in that schools are graduating people who can't write a program that prints numbers from 1 to 100. I can't figure out how someone can come out of a reputable university with a CS degree and not be able to write that program, but that's besides the point. If this is true, then, well, I hate to say this, puzzle testing may be a necessary evil. The problem is that this isn't enough because you don't know if you have a memorization machine in front of you or someone who really understands the topic. EDIT: I should say that I couldn't imagine being a company like Google or similar and trying to hire large numbers of developers on a regular basis. I would imagine that at that level you don't really have an option but to apply puzzle type filters as a first line of defense.

The best example I have against this goes back to physics and calculus classes. I have to try to be very sensitive here. There was a certain ethnic group who overwhelmingly aced calculus tests. I mean, they were machines. Got it done faster than everyone and just aced the tests. No contest. The amazing thing was what happened in Physics class, both tests and labs. They were completely lost. It was really an odd and unbelievable thing to behold. Some of them would get tripped-up by the simplest things. I won't venture to guess as to why and how this happens. I'll just say that, in my experience, mechanical memorization of anything isn't learning at all. It's just memorization with no value whatsoever beyond that. I am trying to think about a CS example. Let's say that someone memorizes the implementation of a binary GA algorithm or a NN. Great. They can type it out in an instant when asked. Do they really understand what's going on? Do they understand when to apply it, how and why? Do they understand how to optimize it? Do they know how to make good chromosome encoding decisions? Or how about dealing with cases where the GA is lost looking for a solution? Do they know how to fix it? Or how to deal with it? Or how about the choice between writing a class with a bunch of methods and properties vs. a simple routine with lookup table to solve a problem? I've seen people who think that every solution requires a class and a bunch of objects. You end-up with code that is fifty times slower and ten times larger than it needs to be. Some of this only comes from experience, of course. If available, I like to look at code that the candidate wrote and explore it. It's hard for someone to bullshit you if it isn't their code. Another interesting thing to do is to put code in front of them and see how they go about understanding what's going on. After all, if you are hiring them to plug into an existing project that is precisely what they'll have to do. Someone who can't code will not ask intelligent questions about the code they are looking at. They will have a hard time getting into it and understanding what's going on. Now, I do understand from other posts that there seems to be a failure in the system in that schools are graduating people who can't write a program that prints numbers from 1 to 100. I can't figure out how someone can come out of a reputable university with a CS degree and not be able to write that program, but that's besides the point. If this is true, then, well, I hate to say this, puzzle testing may be a necessary evil. The problem is that this isn't enough because you don't know if you have a memorization machine in front of you or someone who really understands the topic. EDIT: I should say that I couldn't imagine being a company like Google or similar and trying to hire large numbers of developers on a regular basis. I would imagine that at that level you don't really have an option but to apply puzzle type filters as a first line of defense.