Ok, so let me see...you rely on an interpreted language to do your reads and writes to your database. Why not use C/C++ and interface with it thru your engine for the most used algorithms? Python has an excellent method to access C routines, and much of the access routines are written there anyway. I haven't worked much in Ruby, but I'm guessing there's a way as well. It's the same damn thing with games, or any speed critical system. The access speed has nothing to do with the processing of the data, and optimization is about more than just the algorithm. If the underlying disk/db read takes 10x longer because you're using some wrapper, then why not look at that? Or is it too hard? Your server side code doesn't need to be cross platform anyway...

and you can't tell from talking talking to the person about the code they wrote that they didn't write it, something is seriously wrong. I know there are BS folks out there, but if you ask the right questions, you can tell what they wrote and what they cribbed.

But explain how having an introvert stand at a white board and work on an algorithm in a vacuum is anywhere close to coding an optimal algorithm. We're not robbing banks here, we're writing code. We have a few minutes to check what has been done and why.

But it's not the *only* thing, and yeah, that's doable with some profiling. In that case, it's already screwed, and you're going in to optimize. That doesn't involved walking in in 2 seconds and seeing the solution. While companies want that, there's usually a reason the code got that crufty. The young bucks are the ones who walk in smashing everything in sight, assuming everyone is dumb but them, and when they remove the wrong strut and the whole room comes collapsing around them, that's when you wish you had someone with a bit of experience.

I have yet to see it. It's used far more as a quantitative judge of someone's ability, when it's barely a sliver of what happens in coding. Heck, I spend most of my time handling exceptions, checking corner cases, and refactoring classes to make sure someone else can use the code someday.
To me, the way to go is to have some sample code, whether it be some previously written or requested by the company. Then, that code is brought in and the team can do a defacto code review in person or online. It's much more representative of a real world situation, and code reviews are much more about discussing methods than simply judging the efficiency of an algorithm implementation.
List of skills that are completely ignored by the academic quiz method: error handling; class design, including planning on later improvements/changes; code documentation; ability to read other people's code; refactoring skills; test automation
All of these are huge towards working in a company, and I have yet to run into an interview process that even addresses any of those. It's all about the simple CS test.

But I've been on 3 interviews so far where showing your work merited a "sorry, that's not fast enough" with nary a discussion on thought process, coding style, etc. I even explained my thinking with the dataset and worst cases.
It'd be one thing if it was used as a way to glean a thought process, but when the bottom line is merely O(n) vs. O(log n), you're not looking for candidates who can find a way through a problem. You're using specific knowledge as a sieve. And that's where the age bias comes in. The experienced programmer knows that the answer is rarely X or Y, it...depends. And sometimes that "depends" and the design around it is the key to scaling later or blowing your leg off. I'm not saying every experience programmer knows it, but the young ones rarely do. But they're sure up on their mergesort implementation.
I've yet to have someone give the version of that test where the hard coded array or hash is the solution, because that's what you get to from experience: knowing when to be fancy and when to be specific. The academic solution seems to be built in from the start. And that favors the recent grad, period.

But my point above about interview questions is that the bias is built in. The interview process, involving pointless tests and white board coding, seems geared towards the recent graduate. It's inherently biased against the experienced coder, because most of that academic stuff is long in the past by the time they interview.
I can't speak to whether or not it's intentional, but it's there, and it's very different than other industries.

No.
But the games biz has a ton of legacy engines all over the place. And most of the work on them isn't getting it to run more efficiently. It's adding features; it's testing user input; it's gathering data; it's keeping things from blowing up. And these problems aren't unique to the game industry.
There is plenty of work to go around adding features and improving/bug fixing that don't involve simply finding algorithmic solutions.
It's always been a peeve of mine that programming courses have been, for my experience, devoid of two real world aspects: error handling and user interface. Neither of those has a tinker's cuss to do with O(n) solutions, and if you look at many, many of the problems companies are facing, it has to do with those. Experience seems to be the teacher of those, as universities seem to have fallen short of any semblance of lessons in those areas.
It's one thing to do an exercise with a single command line function that has a clearly delineated in/out and a simple dataset. It's another when you're interfacing with legacy code, trying to fish a line thru to a class that doesn't want to expose it's members for some undocumented reason. Plus, the program has a real tendency to assume data validity, and changes makes crap blow up real good. That's real world company stuff, not whether or not quicksort or bubblesort is the best choice.

I didn't mean to indicate that lower level programming = the way to go. My point was that most of these tests miss the forest for the trees.
Sure, you're munging data. But either a) your dataset is known and your company has mostly solved this problem, or b) you're engineering new solutions which don't fit the way before.
You profile, find the parts that need optimizing, and optimize. That should be done regardless of the situation. In addition, the new "fuck it, ship it" mantra that seems to be all the rage would say get something working, then you make it work well. Not "you'd better do it exactly right the first time or it's worthless."
Data requirements shift. Focus of target moves. These all have to be addressed. A good programmer will plan for the changes as best can be so that if a new algorithm has to be used sometime, it can be swapped out as quickly and as painlessly as possible. Therein lies the experience. Not on whether you hit on the local maxima first try.

Sure, I used it. It totally has its uses. But I'm not being old fart about it. I actually love working in Python for many, many things. It just seems totally bizarre to me to be trying to cycle optimize what is ostensibly an interpreted language. It's kinda like hypermiling SUV hybrids.
But you're right, there's some fear of every writing compiled code these days. Heaven forbid you even directly interface with hardware, either.

I can say the difference between now and the last time I had to do this (~12 years) is stark.
Seriously...if I have to take another test checking my ability to O(N) a problem, I'm gonna scream. I've been living in ginormous game engines for 6 years, and the amount of times I've had to, in the span of a timed half an hour, optimize a routine to make sure it was running in the optimal time has been....zero.
I'm sure it comes up, and I'm sure it's useful, but this all reminds me of the older assembly guys who used to put in all kinds of wonky tricks that eventually got optimized out by the compiler. Bubblesort has been solved. If your company has to implement it again, you're doing it wrong. There's a routine lying around somewhere in the company. Really.
I don't know what the solution is for evaluating tech talent, but this doesn't seem like it.
Also, web guys...if you're really concerned about speed, maybe you should consider writing some of this code in a lower level language. Plus, if your ad server takes 5-10 seconds to respond, then all of your optimization is for nothing anyway. But hey, you got the O(log N) solution. Bully for you.

Except he isn't. First, your study is out of date. Young people were seen to be moving to urban areas years ago:
http://blogs.wsj.com/juggle/2010/05/11/bright-flight-affluent-leaving-suburbs-moving-to-cities/

And recently, it has started to become the norm, not just a trend amongst young.
http://usnews.nbcnews.com/_news/2013/05/23/18441345-urban-renewal-census-figures-show-cities-surging?lite

And, the trend lines up with the younger crowd driving & buying cars less.
http://www.theatlantic.com/business/archive/2012/03/why-dont-young-americans-buy-cars/255001/
http://cars.chicagotribune.com/fuel-efficient/news/chi-cars-get-older-young-people-drive-less-20130807

Second, nowhere in the article does he mention New York. He is an urban planner from New York, yes, but he was specifically talking about the tech companies in the Bay Area bussing employees from the city to the suburbs. He's not pushing anything for New York. He's an urban planner talking about planning in an urban area other than the one he is in.

I believe he's saying, "If you're bussing your employees from the city to the suburbs, why not put the company in the city?"

If people would RTFA:
"Members of the current generation of in-demand workers wants to live in a city like San Francisco. They prefer an urban lifestyle to a suburban one. They want to be able to walk to grocery stores, restaurants, theaters, etc. They prefer traveling to work using collective transportation, rather than driving -- perhaps, in part, because they can be productive on the way."

Because, if what everyone is saying is so true ("Why be in an urban hell?"), then why are there so many buses heading *from* places like SF to the 'burbs? Clearly the employees like the amenities that the urban areas provide, otherwise they wouldn't live there, and there wouldn't be enough employees to justify a separate bus system to move them to the suburban campuses, no?

And this is exactly what Twitter just did (got a sweet deal in The Mission, not exactly a wonderful area before), but that's created a whole host of other problems. However, rents have shot up, so what he's proposing is working there. Apartments are now fetching $2000/month+ rent in what was a cheap area. These companies have power, and when they bring that power, other businesses follow. And the point of the article is: if the employees recognize this and are living in the cities, why aren't the businesses going there?

It's not bad for Netflix. It's bad for their stock, though.

Stocks, especially non-dividend paying ones, are held on the idea that you can sell them for more tomorrow than you bought them for yesterday. So, it doesn't matter if they're still in good shape...can they grow any further? The assumption therefore is that they won't be getting bigger in the future. And if they're not getting bigger, then it's a hard sell to find some other sucker to buy your share of stock for more....because the only promise for that is that they'll keep growing and some *other* sucker will by your share from you. If the growth chain is broken, the stock is worthless if it doesn't pay dividends.

Netflix was trading on the idea that they would become ubiquitous. Once they took a subscriber hit, the graph changed, and all the analysts got off the train.