Live data from Hacker News

Hire-to-fire at Amazon India?

leetcode.com

351–360 of 589 posts

Re: Hire-to-fire at Amazon India?

#351
Current Amazon engineer.

As others have said, management at Amazon will only direct focus on the development of new features or new services, at the complete detriment of improving existing services, or even the overall architectural design of a particular space of the business. The definition of completing a service or feature is only that a customer is using it without complaint. Management has no interest in technical reasoning, which causes the design decisions that rest at their level to be unreasonable. This leads to a few problems:

1. Services are only ever about 50% complete. Unit tests typically exist to some degree, but integration tests, documentation, complete monitoring and operational automation are rarely done. Services typically have numerous obvious bugs, grossly bad optimization, hideous over engineering, and sometimes design issues. Because the customer cannot detect these things when the first use the service (maybe it will reflect the second time as a bug, or as slow performance later down the line, or long times to develop new features), there is no interest in fixing them.

2. The graph of service dependencies is entirely unmanaged. Any service can depend on any other service, for any reason. This results in a massive, undesigned spaghetti of a system. Something like s3 or whatever will usually be supported in some way by a spaghetti built for s3, and if s3 fails, it is usually not immediately obvious which service in the spaghetti is responsible. It makes adding something new to the overall system take a very long time.

3. Even if a customer is encountering an acute problem, and management is asking for it to be fixed, if the problem is rooted at a system level outside the boundaries of a single service, thus at the level of management, management is unable to engage with any reasoning as to how it should be solved. Only management holds the keys to assigning work (senior or principal devs hold basically zero sway) and thus management must have the technical reasoning ability to make these decisions.

4. Management will sometimes intrude in service level problems and make unreasonable decisions. Examples:

  4.1 I was told python is not performant (despite my history at the company having me deploy python code to every single physical host in the fleet) and asked to research and explain why it isn't scalable and we should switch off it. I declined to work on the issue

  4.2 Management had an issue raised to them where a single user had sev2ed us because they couldn't paste into a field on our service. Investigation quickly revealed the user was trying to paste text with a space into a numerical field, and the browser was preventing it. The issue already had two solutions suggested: add highlighting to invalid inputs, and strip spaces from inputs. Despite this management decided a formal review was required, where somehow we would have to dig deeper than the existing explanation and explain how this happened and what should be done.

Re: Hire-to-fire at Amazon India?

#352
Not in India, but a good opportunity to share my experience interviewing for a Software Engineer role with a team in AWS that was part of a recent acquisition (CloudEndure):

After the interview was scheduled, I had some questions but up to this point, I didn't have any human interaction with the interviewer. It took almost two weeks to schedule a call with my recruiter (mostly because she wasn't great at responding to emails). During that, she explained that this specific team (CloudEndure) had a different hiring process: I was to have two 90 (!) minutes interviews on separate days, after which it'll be decided whether they'd like to continue my interview process within that team, recycle me with another team or reject me. The content of each interview, she told me, was to include Amazon Leadership Principles, algorithms/data structures and possibly some system design (the main SDI interview is only in a later stage).

While I was preparing for the LP principles and the more standard parts of the interview, another Amazon recruiter contacted me and scheduled an interview to another group. Few days later he told me that since I already had an interview with Cloudendure schedule, and sinc "all interviews in amazon are uniform and have the same 45 minutes format", he'll cancel the interview that he scheduled and we can talk after my interview with Cloudendure. I reached back and asked whether anything has changed regarding Cloudendure's interview format and he apologized, explaining that he didn't knew they had a different format.

The interview itself: as the interview started I learned that the guy who was interviewing me wasn't the guy I thought was going to interview me but someone from his team who filled in for him (later I learned that day US-East had a major outage which I guess was the reason for this). The 2nd thing he mentioned was "we won't do any leadership principles on this interview things". At that point I realized I just spend few days working on my stories, linking them back with each LP, but I let it pass.

He dedicated 30-40 min to explain what the team is doing, then 5-10 more minutes where I went over my experience with him.

Then came the technical part:

The algorithmic problem was rather easy and I was familiar with it so I let him know of the latter, allowing him to choose whether he want to hear the gist and switch to another question or let me solve it as if I never saw it before. He chose neither and instead questioned me as to who told me about this question, which was an awkward way to ask where I met this problem, regardless of the problem itself which is rather common (easy LC question). As per his instruction, I continued to solve that question, where the tricky part are the possible inputs for parsing a string, so I went over all the edge cases prior to writing any code, proceeded by explaining my idea of how I'd solve it, then coding it while explaining what I was doing, and finally traced an example input by hand.

The interviewer then proceeded to the 2nd question which was more vague and consisted of a system given as a synchronous single machine, single threaded black box, on top of which I had to implement undo/redo. I won't go into all the details here but I went from a naive space inefficient solution to an optimal solution, making sure I don't cause any infinite feedback loops.

The interviewer and I were discussing the possible solutions through out the 2nd question. He did provide me with hints seemed happy with my solution and by the end asked me if I could allocate few more minutes where we continued discussing different designs.

The interview in total took 2 hours and 5 minutes (!!), 35 minutes over time and I thought I did great, the interviewer seemed to like my approach to problem solving.

Two days later I got an email that they "have decided to continue with other candidates". I was confused since the recruiter clearly mentioned that such decision was to be taken only after the 2nd interview, and so I emailed her, asking to schedule a call sometime that week. She didn't answer my (two) emails nor my two phone calls.

I contacted the other group recruiter too. He answered promptly and told me that he'll try to check if he can see whether he can schedule another interview for me, but few days later he apologized, saying that he can't nor does he have access to anything within the team that I was interviewing with.

I was very frustrated with that experience, most of all, by not knowing why I failed the interview. I have interviewed successfully and unsuccessfully with FAANG in the past, but never got zero feedback and complete ghosting from the recruiter.

Re: Hire-to-fire at Amazon India?

#353
post #337
post #209

Earlier quoted context omitted.

I'm in non-AWS and things aren't any better here. It is very much dependent on the manager and team, and I've been optimistic (~3 years now), but it gets harder as time goes on. > I'm just not 100% sure about the whole PIP scene. Our service was extremely critical and we were extremely understaffed. So I don't think it applied to anyone in our org but I know of other teams who would have no issues in taking in a fres…

Amazon has a lot of money to waste. It is cheaper to hire someone so they can fire them in a few months to keep the rest of the staff scared enough to overwork themselves so they can understaff. They play a good game.

> Amazon has a lot of money to waste. It is cheaper to hire someone so they can fire them [...]

So... Amazon has a lot of money therefore they have to resort to money-saving practices? Or is the causality the other way around? How do these two sentences fit together?

Re: Hire-to-fire at Amazon India?

#354

Former AWS engineer here. I worked on a pretty critical product in AWS (big AWS service with lots of traffic) and I can safely say that it's totally up to your manager and pre-existing conditions which make up the job. My manager was great as a person but would always lack in my career-oriented goals (bigger projects, promotions, etc) But what really sucked for me was the pre-existing conditions. Our on-call was pret…

This jives with what I observed as an intern some on an AWS team some years ago. The oncall rotations seemed absolutely brutal and the engineers were so busy and stressed out fighting fires that they barely noticed my existence (which I was okay with) and the tech debt kept accumulating between because between new feature launches and firefighting there wasn't much scope for anything else.

My intern project was a fairly no brainer tech debt item that automated a lot of the deployment process and saved our lead engineer several hours a week in babysitting deploys. I resolved to never work on a cloud infra team after that -- while the internship was fine, being a full time engineer seemed absolutely miserable.

Re: Hire-to-fire at Amazon India?

#355

Earlier quoted context omitted.

Current Amazon engineer: it's far and away the most incompetently run bureaucracy with self-defeating dysfunctions forced on the huge number of layers. The recent "leaks" to Business Insider, pointed out to me by coworkers, are exactly what we see. Everything the parent comment mentioned is exactly what we see. Laughably, our middle manager berates us as incapable noobs, entirely unaware that some of us at least actu…

well the good news (for amazon) is that I used to work at a place where I was trying to build a cloud. And management suffered from EXACTLY THE SAME PROBLEMS (though for different structural reasons, there was no "build a feature" incentive). And then we hired someone who used to work on amazon cloud who came with rave reviews, even though he completely failed my interview, which basically tested "do you read the spe…

Yeah it’s surprising that despite the negative comments in this thread, AWS works almost flawlessly for stuff that matters (uptime, reliability etc.). Of course it’s painful to work with sometimes, but so are other cloud vendors. There’s literally zero incentive to change things internally until external KPIs start turning red.

Re: Hire-to-fire at Amazon India?

#356

Earlier quoted context omitted.

Because changing jobs is really fucking difficult. I'm probably one of the biggest proponents of "quit your job, you deserve better" that you'll ever find, but even I have to admit that finding a new job is ridiculously hard. Even in "this market", even if you're a top engineer, it's still ridiculously hard to even get an interview, let alone get hired. There is only a limited amount of companies that will pay at the…

It sounds like the real reason is that the money is worth it.

The money is probably the thing that keeps most people in the job, but it's not like willingness to take a pay cut magically makes jobs fall into your lap, either. It expands the pool of companies you could possibly work for, sure, but everything else above that I said still applies.

There's also rarely a guarantee that the new company you're trying to join is significantly better, and companies intentionally make it difficult to get the inside scoop on work-life balance/on-call responsibilities until after you're hired. Personally, I would love to find a new company to join... but my experience interviewing is that it takes months of effort for a potential pay cut and no guarantee that I won't just end up in another shitty situation and paid less, so I struggle deciding if it's actually worth it.

Re: Hire-to-fire at Amazon India?

#357
post #311

Earlier quoted context omitted.

Current Amazon engineer: it's far and away the most incompetently run bureaucracy with self-defeating dysfunctions forced on the huge number of layers. The recent "leaks" to Business Insider, pointed out to me by coworkers, are exactly what we see. Everything the parent comment mentioned is exactly what we see. Laughably, our middle manager berates us as incapable noobs, entirely unaware that some of us at least actu…

> I contrast it with excellent experiences at Sun, Motorola, Apple and others over the past 20+ years, where in some cases I had very high engineering ranks with fabulous results, in very well run and just healthy orgs. I can understand how junior devs end up in these positions for a while and stay on the ride, but what is making someone with your level of experience you stick to Amazon? Is the compensation that good…

"Unique technical challenges"

Some of the problems you can work on in such an environment are interesting.

Combine that with the fact that you don't see this before joining and that some.manager s might be able to shield some of it you are where you are.

And then throwing hands in the air and leaving is a step, as most other companies have "smaller" problems to solve and "also bad management" ...

Re: Hire-to-fire at Amazon India?

#358
post #329

Earlier quoted context omitted.

Current Amazon engineer: it's far and away the most incompetently run bureaucracy with self-defeating dysfunctions forced on the huge number of layers. The recent "leaks" to Business Insider, pointed out to me by coworkers, are exactly what we see. Everything the parent comment mentioned is exactly what we see. Laughably, our middle manager berates us as incapable noobs, entirely unaware that some of us at least actu…

Only Apple is on Amazon's tier of technical success, and half of Apple's tech success is from non software. So on what basis ia Amazon incompetent at software? It sounds like Amazon is results driven, and pretty well-unit-tested code isn't critical for that.

OP made no mention of software and mentioned Sun and Motorola, so I don't think they made any point specifically about software.

It may also be relevant to point out that Amazon is first and foremost a retailer, unlike the other companies mentioned.

Re: Hire-to-fire at Amazon India?

#359
post #94

Earlier quoted context omitted.

Where did you read this? That's important context.

There were a number of recent articles. Here's one: https://www.businessinsider.com/amazon-polices-based-jeff-be...

Business insider is a lying trash rag.

Re: Hire-to-fire at Amazon India?

#360
post #353
post #337

Earlier quoted context omitted.

Amazon has a lot of money to waste. It is cheaper to hire someone so they can fire them in a few months to keep the rest of the staff scared enough to overwork themselves so they can understaff. They play a good game.

> Amazon has a lot of money to waste. It is cheaper to hire someone so they can fire them [...] So... Amazon has a lot of money therefore they have to resort to money-saving practices? Or is the causality the other way around? How do these two sentences fit together?

I don’t think they do, but it’s a way to smear and make all Amazon engineers unemployable by proxy. I already have difficulties finding interviews at good companies because the Amazon name implies IBM level talent instead of Google level talent.
Post reply on HN