Live data from Hacker News

AWS's us-east-1 region is experiencing issues

health.aws.amazon.com

161–168 of 168 posts

Re: AWS's us-east-1 region is experiencing issues

#161

Earlier quoted context omitted.

It was unpleasant but at the end of the day it was just one guy. What gets me is that every recruiter who reaches out (hundreds by now I estimate) wants me to complete their timed coding test to qualify to interview again. I found Google’s interview process comparatively much more respectful (although more demanding), and have been happy working there instead.

Do you mean AWS recruiters are asking you to take timed coding tests? Or in general? This is a thing for people with experience? What value or skills do recruiters actually bring? It's a wonder anyone gets hired at all with these jokers as gate keepers. Good on you for getting a better gig. Congrats.

Yes it’s a standard part of the interview cycle at Amazon. Usually two questions in an hour or something, and you code solutions which the test platform grades. They’re on par with leetcode easy IME, but I just find it to be a pain so I won’t do it again.

I’m sure it’s helpful to weed out applicants who actually cannot code, but what’s the point in doing it twice?

Thank you!

Re: AWS's us-east-1 region is experiencing issues

#162
post #58
post #45

Earlier quoted context omitted.

That's the problem we're out to solve with robusta.dev. We're slowly but surely converting the world's institutional technical knowledge into re-usable and automated runbooks.

I’m just going to have to spend all day fixing the runbooks as well as the technology ;)

I could make the same argument for why dockerfiles are bad and you should install infrastructure manually instead of automating it!

Re: AWS's us-east-1 region is experiencing issues

#163
post #99

Earlier quoted context omitted.

> Why involve a human at all? To make a judgement call on whether the issue is severe enough to warrant the legal/financial risk of admitting your service is broken, potentially breaking customer SLAs.

If you're just going to lie, why have an SLA at all? It's like doing a clinical trial for a drug; a bunch of your patients die and you say "well they were going to die anyway it has nothing to do with the drug." If it's one person, maybe you can get away with that. When it's everyone in the experimental group, people start to wonder. I have two arguments in favor of honest SLAs. One is, if customers expect that somet…

It's not just a hard problem, it's impossible to go from metrics to automatic announcements. Give me a detected scenario and I'll give you an explanation for seeing errors which are unrelated to the service health as seen by customers. From basic "our tests have bugs", to "reflected DDoS on internal systems causes rate limit on test endpoint", to "deprecated instance type removal caused a spike in failed creations", to "bgp issues cause test endpoints failures, but not customer visible ones", to...

You can't go from a metric to diagnosis for a customer - there's just no 1:1 mapping possible, with errors going both ways. AWS sucks with their status delays, but it's better than seeing their internal monitoring.

Re: AWS's us-east-1 region is experiencing issues

#164

Earlier quoted context omitted.

If you're just going to lie, why have an SLA at all? It's like doing a clinical trial for a drug; a bunch of your patients die and you say "well they were going to die anyway it has nothing to do with the drug." If it's one person, maybe you can get away with that. When it's everyone in the experimental group, people start to wonder. I have two arguments in favor of honest SLAs. One is, if customers expect that somet…

It's not just a hard problem, it's impossible to go from metrics to automatic announcements. Give me a detected scenario and I'll give you an explanation for seeing errors which are unrelated to the service health as seen by customers. From basic "our tests have bugs", to "reflected DDoS on internal systems causes rate limit on test endpoint", to "deprecated instance type removal caused a spike in failed creations",…

I don't agree. I'm perfectly happy seeing their internal metrics.

I remember one night a long time ago while working at Google, I was trying a new approach for loading some data involving an external system. To get the performance I needed, I was going to be making a lot of requests to that service, and I was a little concerned about overloading it. I ran my job and opened up that service's monitoring console, poked around, and determined that I was in fact overloading it. I sent them an email and they added some additional replicas for me.

Now I live in the world of the cloud where I pay $100 per X requests to some service, and they won't even tell me if the errors it's returning are their fault or my fault? Not acceptable.

Re: AWS's us-east-1 region is experiencing issues

#165

Earlier quoted context omitted.

There is nothing cultish about the way Amazon interviews. If you are a good engineer with a relevant background who can speak english you will have no problem passing these interviews. I'm not sure why you are framing it as cultish.

That does not match up with my own experience at all. Maybe the service teams are less heavy on LPs due to not being customer-facing?

What doesn't match up?

Re: AWS's us-east-1 region is experiencing issues

#166

Earlier quoted context omitted.

Native English speaker here. I was denied for unspecified reasons a couple years ago. At the time it was perplexing, as I had pretty good answers for all their questions. Now I work at one of the slightly more sane FANMAG (to include $ms) companies. Pretty sure I dodged a bullet, maybe the engineering manager spared me because he liked me more than I realized.

I would be curious to know which one is considered more sane these days. I feel like I've heard enough negative things about the culture at all of them at this point.

Presently, Apple, Microsoft, Oracle can all be okay as an employee IME. Depends entirely on the division and team you're joining.

Ones I'd never consider, even for a cushy VP role- FB, Goggle.

Ymmv.

Re: AWS's us-east-1 region is experiencing issues

#167

Earlier quoted context omitted.

> What is the "cultish LP dance" here that is weeding good people out? The "culture fit" interview process focuses on leadership principles, so lots of questions like " tell me about a time when you went above and beyond for a customer". Being yourself will get you nowhere, you need to research the questions and the script that is expected of you. > What service does your team work on? I'm a partner-focused SA, so no…

I interviewed with AWS about a year ago. Knocked the programming/system design interviews out of the park, but it was clear the LP interviewer simply didn’t believe I was being truthful about the example I gave (included a period where my team had no direct manager, which is abnormal). He also had a programming question for me but we didn’t have time for him to explain it. No offer, recruiter emphasized that they wer…

When I interviewed, the instructions I was given by the recruiter were very explicit. For the Leadership Principles, I did my hardest to come up with at least two items for each LP, and of course they had to be in STAR format -- Situation, Task, Action, Result. To that, I added a URL to back up my story for all of the cases where I could.

So, when I used the example of designing and starting to build the replacement e-mail system for ASML for literally zero additional cost [0], I pointed them at the URL for the Invited Talk that I gave based on that work. And when I used the example of when I broke all e-mail across the entire Internet, I pointed them at the URL for the article that was published in The Register. When I talked about what I had learned about Chef and DevOps, I pointed them at the invited talk I gave in Edinburgh entitled "From zero to cloud in 90 days" and the accompanying tutorial I taught called "Just enough Ruby for Chef". And so on.

I really feel that having the URLs to backstop my stories helped me sail through that part of the interview.

In my case, I wasn't being hired as an SDE, so there wasn't much programming tests they wanted me to take -- one of their senior developers did connect me to a shared coding platform, which we really just used as a shared whiteboard. He asked me some questions on how I would solve some problems, and I used my 30+ years of experience with Bourne shell and bash to show him stupid first order solutions to those problems and then we talked about what some of the second and third order solutions might be.

The longer I work at AWS, the more convinced I am that everything depends on the people you're working with. There are good teams and bad teams. There are good managers and bad managers. And if you can find a good team with good managers, then you're golden.

In this respect, I don't think AWS is materially different from any other employer I've known.

[0] They had already bought all the hardware, including some stuff I scavenged from a closet where they had been sitting new-in-the-box for a couple of years; the OS was covered under their site license; all the application software was open source; and my time was free because I was already there under another contract)

Re: AWS's us-east-1 region is experiencing issues

#168

Earlier quoted context omitted.

I interviewed with AWS about a year ago. Knocked the programming/system design interviews out of the park, but it was clear the LP interviewer simply didn’t believe I was being truthful about the example I gave (included a period where my team had no direct manager, which is abnormal). He also had a programming question for me but we didn’t have time for him to explain it. No offer, recruiter emphasized that they wer…

When I interviewed, the instructions I was given by the recruiter were very explicit. For the Leadership Principles, I did my hardest to come up with at least two items for each LP, and of course they had to be in STAR format -- Situation, Task, Action, Result. To that, I added a URL to back up my story for all of the cases where I could. So, when I used the example of designing and starting to build the replacement…

Can I ask what role were your interviewing for where you weren't asked to solve Leetcode style problems on a whiteboard? I thought that was standard for AWS. You mentioned it wasn't SDE but I'm assuming it's still a DevOps/Technical role you have based on your STAR examples.
Post reply on HN