ayberk

I'm sure you're more than enough smart to be at Google :) It's just practice and luck.

I completely agree that people who prefer to ship fast would be happier at AWS. I've heard all the horror stories about how slow Google is, but I think GCP has a great balance between speed and quality. I'm definitely happier here, but I understand why some people would be happier at AWS.

Before you withdraw your point, I guess I have to say my experience is limited to my org and maybe one or two more. Google is a big company, so I can see that happening. I'd still presume it's not the general attitude towards SREs, though.

re: Oncall, we have two rotations:

- one manned (personed?) by SWEs, 9-5, responsible for dealing with customer issues and mandatory.

- one is mix of SREs and SWEs, 24/7, responsible for prod issues

I believe SREs also have their own rotation, but that's 9am-9pm because they are always spread among two timezones. Overall, this is muuuuuch better for everyone involved compared to the AWS oncalls. I remember barely sleeping for a week being the norm on one of the teams I worked at. Our cries for another team in a different timezone, similar to Google SREs, were shut down every single time. "Customer obsession" at AWS means delivering stuff as fast as possible and then throwing the engineers under the bus. I still remember the days I had to wake up multiple times a night to run a command manually (literally 5 minutes) because engineers couldn't take the extra 4 months to do it right.

Thanks, but no thanks. I was at a great team at AWS for ~2 years with great engineering culture and little operational load, but unlike Google, that's rare.

It really isn't.

It's just the cultural difference between the two companies. I have been told that GCP oncalls are a lot busier than rest of the Google, but it's still nowhere close to the suffering I had at AWS. It's an organizational pain and comes from the mindset AWS has towards software development and their engineers.

> "Real engineers"? This is a Googleism and their caste system of "real engineers" and "software reliability engineers". The rest of the industry doesn't coddle their precious "real engineers".

There's no such caste system at Google. SREs have the same bar as the SWEs, and plenty of people switch roles from one to other. SREs are also well-respected and I don't think anyone would consider them as _not_ real engineers.

> Designing a resilient, scalable, frugal, operateable architecture of load balancers, servers, caches, queues, dead letter queues, and all their associated metrics and alarms is absolutely "real engineering" and worth the time and attention of the same engineers that are building the core business value of their company.

You are absolutely right and that's why having people focusing on that is _really_ important. Having worked at AWS previously, I can tell you that when you force your software engineers to do everything and promote them based on _what_ they deliver without caring about the operational load, you end up with crazy oncalls and poorly-designed software. There's a reason why AWS oncalls are infamous whereas Google's are not.

WA has similar fees for electric vehicles and the main problem is the fact that it's a flat fee. With gas taxes you inherently pay more if you drive more, whereas EV owners pay the same regardless of how much they drive. Moreover, it's a $225 fee which is what a 30mpg gas car would pay for driving ~15k miles or so.

This TX bill seems to have a flat fee + another fee based on mileage, which sounds more reasonable.

I am an AWS employee as well, and I'm definitely one of the biggest critics of the company. That being said, AWS is definitely still customer obsessed.

I feel dirty defending AWS, but this is one case I'd give them the benefit of the doubt. There must be _a_ reason they haven't implemented this yet and that reason must be somehow protecting the customer. "Customers want this" ends the discussion around here. You must have a really good reason to disagree.

I interviewed with Apple once and I promised myself to never go through it again.

They must have no training for their interviewers or maybe a training specifically to make them hostile gatekeepers?

> They also assume collaborative interviewer, which has never happened in my experience.

As a FAANG interviewer myself, this is very sad to me. System design interviews are inherently collaborative and they can provide a pretty good signal on "do I want to work with this person". I thoroughly enjoy conducting system design interviews -- It's always a joy to talk through the problem with the candidate and sometimes I even get to learn something new myself!

We really need to fix the tech interviews.

Disclaimer: I work for AWS, but I have no ties to Kinesis. Opinions are my own.

AWS has more than enough learnings to avoid these "events". The problem is the whole culture is focused on delivering new stuff instead of preventing problems and improving existing systems.

Some folks made these decisions with best intentions. I'm pretty sure they all got promoted and then moved on. Now, people who inherited these systems have no incentive to fix these, because at most you'll receive a pat in the back. I'm also pretty sure that those teams talked about the shortcomings of the current architecture. TODOs must be present somewhere in the backlog.

I don't think this is an AWS specific problem, but we have to start treating people who prevent problems like the heroes they are. Everyone congratulates when you put out a fire. No one gives a damn if you prevent the fire in the first place.

This is complete opposite of my experience at AWS. I'm one of the biggest critics of how we do "software" (just ask any of my managers), but in none of the orgs I've worked at COEs were ever used against you. On the contrary, a good COE is usually applauded.

Please don't even consider Fragomen. Ask any Amazon engineer and they'll tell you the same thing: do not ever work with Fragomen.

I personally had to talk to my manager and hire my own lawyer instead of working with Fragomen after countless delays and mistakes. They don't care about you or your case at all and the paralegals are outright incompetent. You don't really get to talk to the lawyer a lot anyway.

I'd go with a local smaller firm if I were you. If you're in Seattle area, I can recommend "MacDonald Hoague & Bayless". I personally worked with "Lola Zakharova" and she was amazing.

It's just marketing. It's getting better, but still far from an actual "self-drive".

Autopilot is Level-2[1] and FSD is somewhere between Level-2 and Level-3.

[1]: https://www.caranddriver.com/features/a15079828/autonomous-s...

+1 to this. I've developed the habit of reviewing my PRs before publishing them. When you assume the role of a reviewer, you end up catching a lot of little (and sometimes big!) stuff, reducing the total turnaround time.

They have a FAQ at the bottom: https://www.hbomax.com/

> The biggest difference is what you can stream. HBO Max is a stand-alone streaming platform where you can stream all of HBO together with even more of your favorite series and blockbuster movies, plus new and exclusive Max Originals for everyone in the family.

> HBO NOW and HBO GO are your options for streaming all of your HBO favorite series, plus hit movies, specials, and more. HBO GO is a streaming service included with your paid HBO subscription through a TV or mobile provider. And HBO NOW is a stand-alone streaming service that lets you stream all of HBO without a TV or mobile package.

That's still crazy. I live 10-min walk away from downtown and SLU (where Amazon campus is) in Seattle and pay a friction of that for a nice 1bd (and still think it's too expensive).

SF is crazy.

> Isn't that the point? You say it like it's a problem, but it screens for someone who's reasonably prepared, which is probably what Google wants to do because they really start looking for the super-world-tier people they employ, because I guess that takes more time and resources.

Definitely. That's why it makes a good question for the initial screening. If you can't come up with the O(N) solution, there's very little chance you'll pass the on-site interviews.

> Doesn't the blog post already include a single-pass solution that works on a small alphabet?

It's actually two passes: one to create the set, and one more again to find the character. There's a solution you can do in only one pass through the string and one through the alphabet. Complexity is the same, but it's far fewer operations for the specific example given.

I used to use this question before it became too common. Any reasonably-well-prepared candidate should be able come up with the O(N) solution and the follow-up is always good for a discussion: "what if the string is huge but the alphabet is small? Eg, a DNA sequence."

There's a single pass solution that's left as an exercise for the reader.

Great stuff, thanks a lot!

May I ask where you get the data from?

IANAL.

This is not correct. If you leave/lose your job, you have a 60-day grace period where you're not considered out of status. You need to find a new employer willing to petition a new I-129 for you.

Please check the specifics with a lawyer. Immigrations laws keep changing in very subtle ways.

Citation on that?

This applies to H1B holders. Basically if you have a non-immigrant visa, you can assume this rule applies to you.

The rule only excludes US citizens, green card holders and their immediate families.

To answer your first question, AFAIK, standalone services that can be used on their own are prefixed with Amazon (eg S3, EC2, DDB), whereas services that are deeply integrated into AWS ecosystem are prefixed with AWS.

Disclaimer: I work for AWS, but this is not an official answer. What I said is correct to my best knowledge, but I cannot guarantee its correctness/accuracy.

FWIW, I've been using Amazon Go stores regularly for a while and have never had any issues.

There's a link to dispute the receipt should something happen, right on the receipt itself. Now this is specifically Amazon Go app, but I would expect it to be same for other retailers.

Edit: I see that this is a little bit different than Go stores. It's far less convenient, but you can still get the receipt in your email by visiting a kiosk it seems.

Well, if all these Go stores popping up are any indication, Seattle does indeed allow non-cash stores.

> I ask myself, would a FAANG company hire someone who doesn't actively tweet? Somehow, I doubt it.

Yes, they do. Actually I'll go ahead and claim that majority of SDEs in those companies aren't active social media users.

These are all super nice and I really wish more developers made use of these, but my main complain is not having username and password fields on the same page :/

I learned enough Python for the interview questions specifically for this. Based on my (obviously anecdotal) experience, candidates I interview spend considerably less time on actual coding when using Python.

That being said, Scala makes design questions much easier thanks to its type system.

Used Scala in production for two years and have been writing Kotlin for a year now.

I'd still prefer Scala to Kotlin any day as I still think it's a stronger language. We had to use arrow library to make Kotlin more like Scala. Especially if you're leaning more functional, standard Kotlin will be lacking.

That being said, Kotlin's entry point is much much lower for Java programmers. Kotlin is a better Java, so I can understand the appeal. I'd never start a new project in Java when Kotlin is available.

I can't even be mad at people blocking the intersections anymore. I know it's not a valid argument, but if they don't do it, other people will and they'll be stuck there not moving at all.

Seattle is a good example of how bad design can create incredibly bad traffic despite the fact that number of cars are actually not that high. Assign a cop to certain intersections would relief most of the traffic I presume.

I don't think this is true. USCIS is mostly unaffected by this, because applications are fee-based: https://www.fragomen.com/insights/alerts/immigration-impact-...