Quite frankly understated.

When I interview someone, I will usually ask if they've seen the question before, so that I can skip it -- is there something wrong with that?

I suspect that this was meant to refer to interview questions with an "Aha!" answer, that are unlikely to be answered correctly by people who don't already know the answer.

For example, I think, "How would you detect a cycle in a linked list?" is a bad question because, if the candidate implements Floyd's algorithm on the whiteboard, the likely assumption is that they remembered it, not that they came up with it on the spot.

In general I think there are two kinds of coding questions that are worth asking. Straightforward implementation based questions that should be solved basically as fast as the candidate can write, assuming they're familiar with the basic techniques. These are in the same vein as fizzbuzz and generally just give you a sense of the techniques the candidate has mastered (basic programming, bit-wise operations, recursion, etc.) The other kind are open ended questions that help show problem solving skills, knowledge of different algorithms and data structures, etc. These sorts of questions don't have the same variance as the secret puzzle questions. The amount of time to throw up a fizzbuzz implementation if you've seen the problem before should be about the same as if you haven't. And the same goes for open ended questions that are more about design, thinking, etc.

And of course you always want to factor in the problem of dealing with candidates who are nervous, in an unfamiliar and uncomfortable situation, and not operating at peak performance. You shouldn't expect production quality code for complex problems in those situations, you should be looking for code that gives you data.

1. If they're not aware of an existing algorithm, it's good to see what they come up with isn't terrible. It's insane the number of times I've seen unbounded time shuffle algorithms in production code. (Repeatedly pick a random element from src, linear scan of dst, and append to dst if not found.)

2. If they know a few famous algorithms, it's much more likely they're aware of the existence of lots of algorithms and are much more likely to Google for the pre-existing algorithm instead of making up something terrible on the spot.

3. A lot of these famous algorithms aren't as difficult to come up with as you'd think. When I first heard of the key schedule biases in RC-4, I thought about it for half an hour and came up with something identical to Fischer-Yates, using the unbalanced Feistel cipher at the core of MD5 (unfortunately, killing the speed advantages of RC4). Years later, when I heard there was a name for the algorithm, I checked Google to see if they had included the back-to-front optimization, and sure enough, what I had come up with was identical to Fischer-Yates.

This area has a high density of people who conflate academic computer science with software engineering, or who think the latter is some easily learned demi-skill to be looked down on, etc.

Which is mind boggling. I took an introductory "software engineering" class in (a reasonably prestigious) university ~15 yrs ago which was ostensibly about learning how to use the right tool for the right job, and one of the assignments was to build a web application in C++!

Perhaps the intent of that assignment was to show that it wasn't the right tool, but that was certainly never communicated by the professor.

I didn't really learn any software engineering until I got my first job and had to build software, with a team, that people actually used.

As an aside, we were doing this in the mid-late 90s (NSAPI) and we were running rings around Perl/CGI shops. Why? Because what took them a whole rack of machines took us a single box, and we simply skipped all the issues of syncing data, accessing a shared database with locking etc etc etc that they had to deal with.

Right tool for the job ;-)

Edit - There a quite a few frameworks out there. This one seemed quite nice: https://github.com/ipkn/crow

1. There isn't a low-level performance bottleneck within most web-dev code. It's almost all occurring at levels slightly above that(disk access, network bandwidth, database queries, horizontal scaling). The stuff that needs to eke out another 50% in an inner loop through optimizing cache access or careful use of hardware parallelism tends to be a single algorithm or batch process that can be developed independently of the larger application.

2. For eliminating whole categories of errors, there is a bounty of options out there that can claim to improve on C++ through better tools, type systems, and compiler technologies. Even Java, as maligned as it is, can constitute a credible step forward.

3. Good C++ developers aren't that common. There are plenty of junior developers who are eager and ignorant of the potential dangers, though - they will make a mess in any environment, but they'll make a bigger one when given power tools. (This is the argument for Go, and w/r to the case of low-pass-filtering junior devs it definitely makes sense.)

1. There are a number of reasons one might choose C++ that aren't related to low-level performance in almost any application. For a particular web application it may or may not be a good choice, but I wouldn't categorically reject it, even for a class project or assignment web app.

2. Any language or suite of them has whole categories of errors, deficiencies in tooling and other issues that can make it suitable or not in the hands of a given team. C++ has more or fewer of these than other languages depending on the context.

3. This seems to be hurling a pretty broad insult at many C++ developers, and "good" requires context.

The requirements were specifically to build a game, any game, and as long as it was playable (and your code was readable) you'd get an A.

So, annoyed as I was at the requirement that the backend be built in C++, I decided go above and beyond the requirements and built a single page Othello game, complete with a strong and fast AI (I happened to take this class much later in my studies than the standard curriculum called for, so I had already taken an AI class and had learned how to build a minimax tree with alpha beta pruning, though up until that point I'd only ever done it in Lisp).

So, by changing the actual requirements of the project, I actually made C++ a more appropriate choice of tools for this project and was able to build a very responsive single page Othello game with a strong AI capable of running pretty fast on the hardware we were tasked with using.

I was the only one who used Ajax to make it a single page app, and the only person to build an AI. Needless to say, I got the best grade in the class, but I suppose I had an unfair advantage.

I've often wondered about this. c++ has a tendency to fail fast and hard whereas higher level languages can lead to a false sense of security/understanding. Blowing your foot off isn't necessarily a bad thing.