Show HN: I send out a weekly CS topic overview and code interview question

It all depends on how you define "puzzle", of course. However, I find that "code writing puzzles", as you term them, tell me far more about the candidate's ideas and approaches to solving problems than abstract discussion. Even relatively simple problems (like the hash-table example from the OP) often have enough edge cases and follow-up topics (cache locality is a particular favorite of mine) to give you insight into what the person is thinking about when they solve a problem. You say that you don't want to see code, but instead "see into his/her brain." But how do you do that without looking at code? One thing I've found out when I was interviewing for my replacement at my last job is that people are very, very good at bullshitting. Asking them to actually write code strips away the bullshit and forces them to actually show you what they're thinking. Sure, prior work is great if its available, but I know of many really good programmers who don't code all that much in their free time, either due to family commitments or because they have gasp have interests other than programming.

I accept that when you're programming "for real", you have reference books, Google, StackOverflow and all sorts of other resources to help you out, and I accounted for that. I wasn't picky about syntax. I let them use whatever programming language they were most comfortable with (as long as it wasn't something terribly obscure, like Brainfuck or J) I even accepted the occassional algorithmic error (e.g. greater-than/less-than being flipped around) if it was clear that the applicant knew what they were talking about and was quick to fix the error once it was pointed out to them. But I still insisted on some code. I would be willing to bet that the programmers who you are referring to -- the ones surrounded with reference books -- would be more than able to bang out something like a quicksort or a binary tree without references. Sure, it might not be a perfect, production-ready implementation, but I'd expect something that at least resembles the correct algorithm, along with a discussion of the tradeoffs and edge conditions.

Frankly, I think memorization is, if anything, underrated in computer science. Our access to knowledge is quite similar to the memory hierarchy in a computer. Working memory is like RAM. Long term memory is like disk. Books and references are like the network. Having algorithms and data structures memorized is like having a local cached copy of a network resource. It allows you to be faster and more fluent when you're programming because you're not context switching constantly as you look things up. And just like in sports or martial arts, it doesn't matter what advanced techniques you know if you don't have solid fundamentals. Basic algorithms and data structures are the fundamentals of programming. When I ask a candidate to demonstrate their knowledge of such by writing code on a whiteboard, I'm assessing how good their fundamentals are. The rest can be taught.

EDIT: And of course, I forgot the most important fundamental of all: Big-O notation. Knowing algorithms is useless if you don't have solid basis for determining how and why one algorithm is better than another.

Looking forward to this- the last couple similar services (periodical design/coding challenges) that I've signed up for fizzled out after 1-2 weeks. Hope this one sticks around!

Oi! Seems email '+' characters were being decoded into ' ' along the way. Patched, and I'm searching for records of those addresses to send invites.

Thanks for reporting!

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.