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.
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.
Just clarifying - does this mean matchmaking for League had geographic affinity (for Valorant this is true I believe)? And was that driven by a desire to ensure tight matchmaking performance latency guarantees or in-game latency goals?
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.
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.
