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.
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.
I can't speak to whether or not it's intentional, but it's there, and it's very different than other industries.
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.
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.
But you're right, there's some fear of every writing compiled code these days. Heaven forbid you even directly interface with hardware, either.
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.
“A new image of urban America is in the making,” HuffPo quotes William H. Frey, a demographer at Brookings who co-wrote the report, as saying. “What used to be white flight to the suburbs is turning into ‘bright flight’ to cities that have become magnets for aspiring young adults who see access to knowledge-based jobs, public transportation and a new city ambiance as an attraction.”
And recently, it has started to become the norm, not just a trend amongst young.
Big cities surpassed the rate of growth of their surrounding suburbs at an even faster clip, a sign of America's continuing preference for urban living after the economic downturn quelled enthusiasm for less-crowded expanses.
And, the trend lines up with the younger crowd driving & buying cars less.
The Times notes that less than half of potential drivers age 19 or younger had a license in 2008, down from nearly two-thirds in 1998. The fraction of 20-to-24-year-olds with a license has also dropped. And according to CNW research, adults between the ages of 21 and 34 buy just 27 percent of all new vehicles sold in America, a far cry from the peak of 38 percent in 1985.
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?