This kind of thing is the worst in interviews. Like getting asked some fill-in-the-blanks question on the pillars of OOP or to define some random bit of jargon or what-have-you. That coupled with the "have you seen this question before" interviewing is just infuriating.

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.

Only recently a friend of mine narrated an interview tale. I don't exactly remember the precise question, but apparently he was asked to solve a problem in 30 mins(Two problems is what interviewer expected him to solve in an hour). One of such problem apparently he couldn't solve it in the time complexity the interviewer expected him to. Though he got some solution working in an hour.

He later on went and googled it and apparently the algorithm couldn't be solved unless you knew about Suffix Automata(http://codeforces.com/blog/entry/20861)

Long story short, these days apparently without everyday exposure competitive programming exercises(spending hours every day on sites like codeforces, SPOJ and hackerrank) there is no way you can clear interviews.

Reminds me of the Aho-Corasick string-matching algorithm.

https://en.wikipedia.org/wiki/Aho–Corasick_algorithm

Edit: in a further comment, you assert an unspoken insult being communicated in a perfectly neutral sentence. I guess what I'm saying is I bet you bring quite a bit of the negativity you experience to your interactions.

I am not convinced that your assumption about his negativity is any more valid than his interpretation of his experience.

My own experiences in SF has been positive. I've found people are generally very excited about what they are doing in life, optimistic about the future and most importantly, willing to lend a hand. (This is in huge contrast to the cut throat image of the valley in the media; while individual startups and industries within tech may be cut throat, I wouldn't describe SF tech world as "generally cut throat")

One thing to keep in mind is SF has a fair share of folks who move here for their first job. These people are just entering the workforce and are maturing more, not less, each day. I've seen some pretty radical transformations of the same people over 1-3 years. A lot of the portrayal of the Valley in the media is of a fixed non-evolving mindset, which again, is the opposite of my experience.

It was entirely certain that he did not understand that he repeated the 2nd option I gave him. Furthermore, when I tried to correct him, he behaved as if I was lying to him.

I take it you're not familiar with the wonder that is Yes, Minister?

(More broadly, and to explain the joke for the benefit of HN, a large amount of British oblique humor and especially political and civil service culture relies on the art of the indirect insult.)