wondered the same thing, are your remote roles location based for visa and salary purposes? I was always super interested to apply but I'm based in Asia.
But I find the whole discussion not strange but rather dishonest. I realize I'm biased towards thinking that the blog posts condemning some special sort of interviewing come from the "losers", the people that didn't get the job. That isn't true in general, but there is still this aura of entitlement: "I am a good programmer! I have other skills than leetcode! I demand an interview process that is tailored to my specific skills!"
I don't believe the claims that the current style of interviews is not working. This claim usually is made in the blog posts and in the interview horror stories, but I haven't seen it any of the FAANGs I worked in. Sure, some questions give more signal than others, but that's the company's problem, not the candidate's. If anything, large companies realize that lack of diversity is a larger problem and are trying to combat that directly (not with changing the hiring process for the general case though).
What it feels like is the blog posts try to solve a different problem ("how can I get a FAANG job") under the disguise of making the world a better place. Meanwhile, companies try to solve a completely different problem altogether ("how do we weed out candidates that might not be a good fit for what we value at scale with low latency?").
As a hiring manager, I'm interested in applicants that are (among others) good at leetcode-style questions without having had to train a lot on leetcode: Technical problems that are not easy to understand (cognitive and communication abilities), have a simple and easy trivial solution (higher level view on problems and customer orientation) and have high technical depth at scale (specific technical knowledge). So that's where the post is right: don't spend so much time on leetcode. But also don't try to change how companies interview. It's unbecoming.
Lol almost all Leetcode is memorized, most of the algorithms developed tool years for researchers to understand, someone isn’t going to figure it out in 45 minutes without having seen it before
I guess it is strange to me, as you usually only hear about bad stories. So I was expecting it to be much worse.
I agree, as long as companies evaluate candidates by a combination of different tests, this should be the best for everybody.
Two companies for which I went through the whole interview process had 5-7 different interviews, and only one of them was leetcode-style problem. So even if somebody fails at leetcode problem they should excel at something else.
This is wrong. SRE is an engineering org, NOT an ops or support org.
While it's common practice for SRE teams to share some of the operational burden, it's for the purpose to find risks and vulnerabilities and then engineer solutions to those. I have never seen SRE do support.
SREs should know how to build and run reliable and maintainable systems. Architecture and design are the best tools for that.
Registered account to reply here, because your complaints feel one sided to me.
Most of what you described i felt as well _sometimes_ for security related stuff, like dedicated machines in that one cluster or an ISE review on short notice--but security related is also somewhat out of the norm and considering that is, Google does a great job.
For "normal" services what you described does not match my experience at all. Even for medium sized infrastructure services mostly everything just works (IME).
Never had a GUTS ticket that was not answered within a business day, but obviously just n=1 sample--imo support staff is mostly amazing.
