Comment by hackinthebochs | Hacker News Reader

Comment by hackinthebochs | Hacker News Reader

Parent Full thread

> It's that they are irritated by tests which don't measure what they're supposed to

I disagree that programming puzzles don't measure what they're supposed to. Programming puzzles are a microcosm of what programming entails day-to-day. They test the same exact mental faculties. Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved in orchestrating the various components when handling a web request. Doing these type of "low level" tests then allow you to include components that do measure one's mental flexibility and creativity, i.e. intelligence.

Sure, we can give a candidate a test that exactly measures what they'll be doing on the job. But what if the job changes? What if we need them to use a language or a framework outside of their comfort zone? This is the reason these tests are not specific to particular tools. You want a programmer that has the intelligence and command of computer science concepts to quickly jump between various tools with little effort. Comparing strings and reversing linked lists do absolutely measure this capability. No, its not testing whether you memorized how to do these things, its testing whether you have the mental flexibility to figure it out on the spot.

Comparing strings and reversing linked lists do absolutely measure this capability.

This depends entirely on the quality if the test. I suspect for many of these ad-hoc tests thrown together for an interview, the quality will be low and the overlap with other tests high, meaning they can easily be passed by someone who googled 'top 100 programming interview questions' and read through them.

Comparing strings or reversing linked lists are not actually things that most programmers would/should ever do themselves or even nowadays bother to learn or remember outside of a CS course, because the code has already been written in every standard library, but they are things that programmers might still be required to learn in order to pass interview tests, and you would thus be testing at many your candidates on whether they had memorised a few of the problems likely to come up, not on if they could work them out on the spot.

I suspect for many of these ad-hoc tests thrown together for an interview

If you assume the process is going to be done in a stupid manner, it doesn't matter what process you use.

"Oh, I looked through your open source code on github, but there only 10% of it was Ruby. We are an all-Ruby shop, not a 10% Ruby shop."

Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved in orchestrating the various components when handling a web request.

I don't know what strcmp is in the way that you're using it. Does that make me a bad web developer?

Something orthogonal to this came up recently on Reddit, and it was observed that in the real world (anecdotally), 95% of professional programmers don't know what the Lyskov Substitution Principle is.

I think that most interviewers will happily give you the definition of strcmp if you don't already know it. If you're not a bad web developer, you'll happily come up with some code on a whiteboard that meets the definition.

Anecdotally, perhaps, 95% of professional programmers don't know the definition of the words, "Lyskov Substitution Principle". That's not the same as not knowing what it is.

Two weeks ago I interviewed at a subsidiary of a major web property, and "[w]hat is the Lyskov Substitution Principle?" was on a written test they gave me.

I would have told them that I had no idea what that was, but then told them what the "Liskov Substitution Principle" (named after Barbara Liskov of MIT) was. I mean seriously, if a company can't spell, do you want to work there? :-)

Reply on news.ycombinator.com