I have never heard anyone claim that previously. Here is the first result I see when I search Google for FANG. It claims that A is Amazon, and that Apple was added later to make it FAANG. https://www.investopedia.com/terms/f/fang-stocks-fb-amzn.asp

I'm definitely using FANG as FAANG without Amazon. So does everyone else that I've seen use it on HN, Reddit, and Blind.

You're the first I've heard of. FANG was the original designation for the group of high-growth tech stocks, and the A stood for Amazon. This is pretty well known and verifiable.

Are you sure you didn't just assume the A was for Apple when you read it? I don't know how you could possibly know what people were referring to from the acronym.

I'm going to respond to this question with one of my own: how much time have you spent on Blind in the past few weeks?

None, I try to avoid it unless I'm scoping out a new job. Are you saying Blind users include Apple in FANG? I haven't seen it.

Im sorry but what does that have to do with anything? I would have assumed the A is Amazon too

Agreed on every one of these points. Especially with the inspirational aspect of seeing veteraned industry leaders and principal engineers come in fresh and have questions and misunderstandings. It's given me the courage to be wrong or confused and ask questions. I've also admired a few people's ability to advocate for shared principals and express how this relates to them - especially customer obsession

This hit home for me, unfortunately. I'm hoping it does for other AWSers as well.

I work for AWS, but do not speak on their behalf.

These are very basic/generalist things, not a specific mould. Refreshing your skills here and making sure you're comfortable with everything on this list will help you be confident that you can pretty much do the kinds of work available to you as a senior engineer. And if you are lacking in any of these, it almost certainly will show up when you're trying to function in the role. I run into this every day with entry level engineers - they have to rely heavily on others and also have to spend a lot of time ramping up on exactly these kinds of things.

Put another way: if you did get hired for this role and managed to keep it, you'll be a master at this stuff within a couple of years. This is because these skills are generally useful no matter what specifically you are doing.

"if you did get hired for this role and managed to keep it, you'll be a master at this stuff within a couple of years." I wholeheartedly disagree. I have a total of 14 years of experience. I've been at Google for the past 6 years. I'm an L5 (Senior Engineer) and I get good performance reviews. I interview candidates on a fairly regular basis on behalf of Google. I am fully confident that if I had to re-interview for my job today, without extensive pre-prep like the author suggests, I would have a very slim chance of passing. The fact is, these algorithm quizzes have nothing at all to do with our job. On the off chance once ever 5 years you actually do need to apply an algorithm, you would do extensive study into the possible options and solutions, write a design doc, have it peer reviewed, and then go down that path - not pull something out of your ass in 15 minutes.

> these algorithm quizzes have nothing at all to do with our job

There are no algorithm quizzes here, and it's not saying to prep for one. It says you should have a good grasp on these: arrays, heaps, linked lists, searching, etc. And it provides quality references for refreshing that knowledge and for getting practice thinking and speaking about them in human language instead of internal abstract thought. I think we agree that if you are in a senior engineering role, I don't necessarily care if you can implement a linked list in an interview time slot, but I sure as heck care that you know how it's different from an array, how it generally functions, when you would use it, in what situations alternatives might be better, and so on. When and why would you use a linear search instead of a binary search, are you aware of how hashes actually work and that hash collisions may occur and need to be handled in some way, can you identify that a particular problem is best solved by recursion or by dynamic programming even if you can't whip up a functional solution in an hour, etc, etc. Some interview candidates literally can't tell you why you would use a linked list instead of an array - it's just an ordered collection to them. That's what this is about - it's not about quizzes, its about fundamentals. These are what our systems are made of and understanding them is valuable to do the work we do.

And aside from data structures and algorithms and being able to talk and reason about them, I also need to see actual code of some kind that solves an actual problem in this interview, with appropriate questions around the presented ambiguity as well as be able to talk about its trade-offs, potential improvements, testability, maintainability observability, and so on. But these are not necessarily anything like an algorithm quiz

CLRS is a literal algorithm textbook. They recommended grinding HackerRank or LeetCode too.

I'm interested in working at the Fremont office. Do you know any ex-Amazonians that are at Google now that I can talk to? I've put an e-mail alias in my profile.

Hey, Googlers. I'm interested in working at Google and I'd like to talk to someone who left Amazon/AWS to there. I put an e-mail alias in my profile for anyone interested.

What I don't like about that is most of the entries will be old. I'd love if it had a way to show me only information from the past year.

Given that compensation in the Valley can go up 10% a year, and a significant portion can come from stock and bonus, I find data on GlassDoor to be fairly useless. The h1b database is a good source on base pay, but doesn't show stock and bonus.

This is perfect timing as Google Seattle is hiring around 1000 devs and promotions are being revealed in April.

I used a throwaway account, but I'm sure I'm identifiable by this information if my manager sees this. I'm not too concerned. I think it's in Amazon's and the employees' best interest for this stuff to be transparent. Besides that, while I like my work, I can easily get an offer from Google, Facebook or pretty much anywhere else.

Position: SysDE 2 in AWS Tenure: 1.5 years Job Level: 5 Base: $120000 Stock: 140 RSU (granted at signing, almost none vested) Bonus: $20000 + relocation at signing, $15000 will come after 2 years Gender: M Native English: yes

I was hired at L4 as SE 1, moved to SE 2/L5 after a year, and now SysDE 2. There was no raise for SE2->SysDE2.

> 140 RSU (granted at signing, almost none vested)

Is it still the ridiculous 5-10% year 1, 5-10% year 2, and then the rest spread out over years 3-4?

Yes, it's something like 5% at 1st anniversary, 15% at 2nd anniversary, then 20% every 6 months over the next two years.

Why is it so ridiculous? Isn't it trying to serve as a retention incentive?

Obviously it can back-fire on the company. If the share price drops a lot then people that were planning on staying till the 6 monthly vesting may quit.

From what I heard from people who worked at Amazon during the especially rocky years, their share compensation is tied to a monetary value - if the share value tanks significantly, they'll issue shares to compensate. If you're into gambling, this can be a -very- good thing considering Amazon has gone on to double in value over very short time periods historically. Otherwise, its a fair concession on Amazon's part