> Postgres was a "it exists" database back in the early 2000's.
If we're really nitpicking it's not saying Postgres is the most popular database since the early 2000's. If you base it of off install counts as the metric, I would assume the statement is true since I'd think it's either Postgres or MySQL today.
I'm still trying to understand the scaling story better. When we say serverless it mentions automatically scaling when it detects some sense of resource pressure. If I have a "hot tenant-database", does that mean this shard will be scaled automatically without impact to existing queries? Or would there be some "blip". I suppose it's unavoidable in edge cases but curious about the regular ones as well.
It's an incredibly cool CX you have here with the automated query routing/tenancy story though, looking forward to what happens in this space.
> Rebuilding a cluster from the last-known-good backup should not take that long
It's not even clear if that's the right thing to do as a service provider.
Let's say you host a database on some database service, and the entire host is lost. I don't think you want the service provider to restore automatically from the last backup because it makes assumptions about what data loss you're tolerant to. If it just works from the last backup, suddenly you're potentially missing a day of transactions that you thought were there that magically disappears as opposed to knowing they disappeared from a hard break.
Restoring from backup doesn't mean you actually have to use it - just prepare it in case you need it. Since this can take time, starting such a restore early would be an insurance policy, if needed. If there are snapshots to apply after the last-known-good backup, all the better.
Sure, but isn't this more about risk tolerance at this point and how much your customers care about? Where the responsibility should be on customer's end. Running on EBS/RDS doesn't guarantee you won't lose data. If you care about it, you enable backups and test recovery.
Just because some customers are less fault tolerant than others, doesn't mean we shouldn't offer those options where people don't have the same requirements or are willing to work around it.
That at least doesn't work at all in my situation. I'm based in Seattle and I collaborate regularly with folks in probably 3-4 other geographic locations, ironically no one actually in Seattle.
If anything getting the video conferencing to work in a meeting room is more of a hassle/friction and a poorer experience when you still have to accommodate someone remote.
I am not at Amazon, but at another FAANG, also am in Seattle, and it is the same thing for us. If we were hit with RTO, it would make exactly zero sense for my team/org.
Out of people I work with, one of them is also in Seattle, another one is in Toronto area, the team lead is in SF, the manager is in SD, and the skip level manager is in MTV. I am not even gonna talk about people on the partner teams that we gotta work with, as they are all spread out all over the place. RTO would be an absolute net negative for every single person on my team, as we aren't going to see the people we work with in our local offices regardless.
And don't even get me started on trying to find available meeting rooms in the office for meetings that were not scheduled way ahead of time. If someone wants to hop on a call with me for a debugging session or has anything to discuss impromptu, being available for that in the office is rather difficult. All while I can hop on a meeting call on a minute's notice when WFH.
For the record I'd prefer a work environment that's closer to maybe 1-2 times a month in the office.
> Most developers are self learners (that's how most people learn to code anyway)
I don't think that's true. If you poll the vast majority of people in intro to CS class, most people never coded before. I recall it being a small minority at least back when I was in school (> 10 years ago).
There's also stats comparing before WFH and after of how long long it takes someone to onboard properly/be productive (forget the exact stat/KPI, mix of survey/commit stats?) and it's extended by a few months. Now that might be due to bad on-boarding since it wasn't a remote-first, but if that still exists years later it is interesting
> People collaborate better in person: Bullshit, a lot of developers collaborate better through text
Agree with that. I really wish we would write better docs and have more of an async setup
I do genuinely think there's aspect/learning that is lost/slower in the last few years, but that might be because we haven't really thought about accepting "remote-first" and trying to shoehorn what we already had into WFH model.
> I don't think that's true. If you poll the vast majority of people in intro to CS class, most people never coded before. I recall it being a small minority at least back when I was in school (> 10 years ago).
I remember my time in college. From my experience, many of my peers there also didn't know how to code after taking classes. The ones that learned were the ones that invested the time to learn. The classes were there to speed it up things only.
Data point of one and all that, but I got a decent bump in base and have been with the company for more than a few years. I assume that's true for almost everyone else based off the Blind posts.
Data point of one and all but I chatted with a Meta recruiter a month ago and asked specifically about the hiring freeze that was on-going at the time. They mentioned they were still hiring for more senior engineers so YMMV.
Recruiters' whole primary job is to recruit, and they don't get a lot of top secret information about what's coming next, either. It's in their best interest to always say they are hiring, otherwise why are they even employed by Señor Zuckerberg? They don't get a two month vacation during a hiring freeze.
And yeah, if you are top, top egghead talent it's possible there is always at job for you at Meta. It might just save that recruiters job if they source you and you pan out.
Think about it like this: earlier this year the bar to get an offer was that you need to be hot, like a 6/10 before. In this new climate, you need to be more like a 9.5/10 to make it through their little hiring game.
With that said..
Don't let some random on the Internet stop or discourage you; go get that job if you are up to the task and actually want to work at Meta! Have fun.. yeah.
My original comment was more about the non-Bigco job postings, a lot of times they may just be testing the waters to see what they can dredge up. If it looks appealing, they might bite. It's mostly a huge waste of time for the poor candidates, though.
> Postgres was a "it exists" database back in the early 2000's.
If we're really nitpicking it's not saying Postgres is the most popular database since the early 2000's. If you base it of off install counts as the metric, I would assume the statement is true since I'd think it's either Postgres or MySQL today.