I led the engineering team at Fauna and this is false - we had a performance culture and performance managed/exited people when they did not meet expectations. I've managed some outstanding teams/organizations at Microsoft, Amazon, and Riot Games and the team behind Fauna was world-class; on par with the best teams that I have seen or been a part of. There are plenty of reasons that the company didn't succeed, some in our control and some out of our control, but the caliber of people at the company and the company culture are not on that list.
League sharded players to geographic regions and didn't allow matches between players in different regions. Geographic location wasn't a consideration in matchmaking otherwise AFAIK. I left Riot when Valorant was still under development and can't speak to how matchmaking works, unfortunately.
Nice catch! I investigated this today with the team and we realized that metrics from a dev environment (which isn't representative of our production topology) were being included in our status page internal latency graphs for the US/EU Region Groups. We addressed the issue - you can see the clean data on status.fauna.com.
To add a bit of color from the author, the content in the article was informed by my experience building distributed systems at Microsoft, Amazon, and Riot Games. At Riot we sharded our playerbase for a number of reasons (including complexity of matchmaking), but we may have chosen a different approach if we had a service like Fauna that could push data closer to players at the edge. With centralized relational databases, cross-region calls to load account info, entitlements, etc. would have been a very jarring experience in the client.
I've seen a number of database companies publish blog posts and put out tweets offering a competing point of view: that single-region is enough and multi-region doesn't matter. Would love to engage with that crowd here and get their perspective on the content in the blog post.
That's fair. I actually think that learning to gamify things is a valuable skill of it's own (and a very effective one if you're a gamer like you or I!).
Example: I bike to work down a very busy path that goes up and down Santa Monica/Venice beach. The path is supposed to be for bikes only, but on a sunny day it's totally packed with pedestrians being idiots, taking selfies, and nearly wrecking me at every turn. I used to get really annoyed with that until I decided to turn it into a game - see how many people doing dumb things you can spot on a commute in any given day. It didn't really fix the problem, but it at least made me grin instead of being cranky when I have to swerve to dodge a rogue selfie stick.
There's also the possibility that it's time for you to explore other job opportunities if you're not stoked about what you're doing. We're always hiring at Riot! :)
I actually agree with you, if done well I think that coding questions are fun too. At the same time, I also happen to know a lot of very strong developers who hate them. I think the reasons vary, but some are called out in the article (lack of a familiar environment/IDE, the contrived nature of questions). The answer to a coding question is also impossible to "fake", at the end of the day you get it or you don't (whereas some situational/behavior questions have more of a fudge factor).
Whether you hate 'em or love 'em, the main point of the post is to advocate approaching coding questions with a strategy that you've practiced and can repeat over and over again.
Love the Yegge posts on interviewing, and I completely agree. There are all kinds of things on the technical side that would be interviewers should brush up on, I'm just preaching having a strategy to run thru when actually answering the question instead of haphazardly diving into code.
Please, please, please do not hand the development of new drugs over to the government.
Also, if you're going to make an odd blanket statement that ends up being a lynchpin of your argument like "patents in software are trivial" at least try to unpack it or back it up somehow. Microsoft (for example, via MSR) dumps a sh ton of $ into research to come up with some ideas that end up being software, so how is that different than the biotech scenario?
As a former Software Development Lead @ Microsoft who went through calibration multiple times and no longer works there or has skin in the game, the article is just plain old factually incorrect.
Yes there is a 20/70/10 curve with both the old/new systems, but managers aren't held to the curve until the org size is around 30-50 people so exceptions can be made in either direction for strong/weak teams. Also the claim that only 1/2's can transfer is bogus, plenty of managers are happy to take 3's and 4's can move in most situations (I know of a person who got multiple U-10/5's and he still found a job). Finally the claim that calibration takes a ton of time is way over hyped, I probably spent less than a week on year end calibration (bit more than that including writing reviews, which is hugely important).
As a Software Development Manager at Amazon I can also attest to the fact that calibration isn't unique to Microsoft, Amazon just calls it OLR's. It's not a perfect system, but I have yet to hear great suggestions on how to improve it. I'm also not advocating the Microsoft system, but the facts in the article are just out of whack.
Besides working with engineers to define the technical direction of our products, my job as an software development manager includes things like: sourcing/hiring, long range planning (including owning P&L for my team), customer engagement, and helping to grow the careers of my engineers (among a million other things). I'm not really clear on how agile or outsourcing make any of these things irrelevant. If the point of the article is that "non technical engineering management is dying" then I think I mostly agree, but the title is misleading.
My Apple fanboi buddies are telling me that the Surface is ugly. I don't really get that... seems like every tablet is just a border + glass at this point, and mostly indistinguishable from the others. If the delta is just the kickstand + keyboard, I'm a fan. Given that I own an iPhone, Kindle Fire, and X-Box I claim brand neutrality in the religious war. :)
On the plus side, the level of transparency that AWS displays and the detail that they provide seems above and beyond the call of duty. I find it refreshing and I hope that other companies follow suit so that customers can understand the details of operational issues, calibrate expectations appropriately, and make informed decisions.
I still think that the future of Facebook is data (not specifically picture data, that's just one piece). Advances in hardware and cloud computing have kick started an era where data mining and machine learning are pervasive in every field from pharmaceutical research to banking to sports and everywhere in between. Facebook is the single authoritative source for a whole bunch of personal data. People have started thinking about the basic applications for that data when it comes to things like online shopping (you're a 31 year old white male with an 8 month old daughter who likes rock and roll, so you probably want to buy diapers, zinfandel, and a radiohead album), but I think that lots of new interesting applications will emerge over the next several years that don't violate user privacy and will monetize well.
Agree with the other comments. Choice of programming language is in some ways tangential to concerns over vendor lock in since other people can always come along with a different implementation of the language, unless of course programming languages end up being found to be patentable (http://tech.slashdot.org/story/12/04/13/1646215/oracle-and-g...).
My team is hiring 3-4 SDE's and a Manager for a very exciting new Platform as a Service (PaaS) offering that will become a key piece of infrastructure for Amazon.com Retail Website (RCX) as well as other products like Amazon Web Services (AWS) & Kindle. If you're interested in building super large scale distributed systems, applying machine learning to scale hosting up or down to meet constantly changing traffic flows, and having a massive impact on the world's biggest online retailer... come join us!
I still don't understand the value add of MapReduce (in it's various implementations, including Hadoop) versus Clustered SQL. I see articles like this one that seem to imply that there is a niche for MapReduce for tasks like simple string search on super large data sets: http://gigaom.com/2009/04/14/mapreduce-vs-sql-its-not-one-or.... It just seems odd that people are so quick to throw away 40+ years of research on how to structure relational data and how to optimize queries against large data sets.
If you're like me and you haven't played with S3 and are wondering what an object is, here's a relevant excerpt from the Wikipedia entry on S3 to add some context:
"S3 stores arbitrary objects (computer files) up to 5 terabytes in size, each accompanied by up to 2 kilobytes of metadata. Objects are organized into buckets (each owned by an Amazon Web Services or AWS account), and identified within each bucket by a unique, user-assigned key. Amazon Machine Images (AMIs) which are modified in the Elastic Compute Cloud (EC2) can be exported to S3 as bundles."