Never really understood the folks pushing for RPC-over-HTTP. RPC is for systems that are close together (ie intra-DC). These simple rules work well:
1. JSON-over-HTTP for over the web
2. RPC (pick your flavor) for internal service-to-service
I will say that Amazon's flavor (Coral-RPC) works well and doesn't come with a ton of headache, its mostly "add ${ServiceName}Client to build" and incorporate into the code. Never mind its really odd config files
Related note, I've never understood why Avro didn't take off over GRPC, I've used Avro for one project and it seems much easier to use (no weird id/enumerations required for fields) while maintaining all the code-gen/byte-shaving
So literally gRPC[1]? You make it sound like there is a difference. There isn't, really.
What gRPC tried to bring to the table was establishing conventions around the details neither HTTP or JSON define, where otherwise people just make things up haphazardly with no consistency from service to service.
What gRPC failed on in particular was in trying to establish those conventions on HTTP/2. It was designed beside HTTP/2 with a misguided sense of optimism that browsers would offer support for HTTP/2 once finalized. Of course, that never happened (we only got half-assed support), rendering those conventions effectively unusable there.
[1] I'll grant you that protobufs are more popular in that context, but it is payload agnostic. You can use JSON if you wish. gRPC doesn't care. That is outside of its concern.
Northrop Grumman had a lot of folks from Crenshaw/Hawthorne/Carson when I was there, due to a partnership program with the local Cal State (Long Beach). All of the security staff was from that area too. Good folks, would 100% work with them again.
On the other hand, I've seen exactly 1 guy at the FANG I work at. What's the difference? I think it's companies like Northrop realizing that folks from under-represented communities have great value and prioritize that instead of whatever the current HackerRank-based interview process selects for
Sort of. The main issue is that AMZ/AWS doesn't differentiate (by title) between someone recently promoted to L6 (generally ~8-10 YOE) and someone deep in to L6 (~12-15 YOE). Other companies solve this with the Staff Engineer title, but AMZ doesn't have that. If you're an L6 who reports to an L7 Sr. Manager then you're functionally a Staff Engineer and supposed to be on the Principal track. Mileage varies across orgs/teams.
Gist: "junior" L6 SDE is more like Google L5, "senior" L6 SDE tracks mostly with Google L6 (or even L7 in rare cases).
Before you accept any offer from FANG/MANG/hot startup, *make sure* you understand the on-call expectations. Example: at Amazon, *even data scientists* do on-call. Practically all SWEs before Principal do. In AWS, first-line managers do on-call (they typically don't in Devices/Consumer). In places like Alexa, you can expect to have shitty 5-6 week on-call rotations and extra helpings for holidays. AWS at least advertises this in their job postings, other orgs (cough Alexa) do not. So buyer beware.
FAANGs/large companies in general have a ton of accidental complexity. A lot of the work devolves into "make this work in our complicated environment". Its just more pronounced at FAANG due to the scale.
Amazon's vest structure is 5/15/40/40. Every vest after the first two years is bi-yearly ie every six months (including additional grants). Amazon makes up the difference with cash in the first two years. The Target Compensation limit is another story entirely...
I will say that Amazon's flavor (Coral-RPC) works well and doesn't come with a ton of headache, its mostly "add ${ServiceName}Client to build" and incorporate into the code. Never mind its really odd config files
Related note, I've never understood why Avro didn't take off over GRPC, I've used Avro for one project and it seems much easier to use (no weird id/enumerations required for fields) while maintaining all the code-gen/byte-shaving