[jchendy]

> They are piloting it on internal HR software which I think says a lot.

There's a tendency for people to think that HR software and other internal tools are less important than public products, but if the company is allocating employees properly, that doesn't really make sense.

The engineers working on this HR software all passed the same technical interviews that everybody else did. Amazon could have easily allocated them to some flashy consumer product, but management decided that it's important to have a team working on HR software. So either somebody made a horrible miscalculation when they decided to build the HR software, or this work is equally valuable to all the other work happening.

[nevir]

Amazon's bar is hugely variable based on the org you interview with.

[jessedhillon]

If you're working on an internal product, your work is not standing up to, or shaped by, market pressures. At least not to the level of that of your peers who are working on public-facing projects. I've seen a tendency for internal projects to develop in a way that is more academic and less practical, for exactly this reason.

[Chronic9q]

> The engineers working on this HR software all passed the same technical interviews that everybody else did.

No, they didn't. They likely were interviewed by the hiring manager. Which, a hiring manager of an internal tools team, does not face the public scrutiny of engineering detail required by a front facing mass consumer product. Therefore internal tools teams do not require as rigid software engineering rules as mass consumer products.

> Amazon could have easily allocated them to some flashy consumer product, but management decided that it's important to have a team working on HR software.

No, they couldn't. Internal HR tools usually means CRUD applications. Why would you put a SQL developer on a deep learning optimization team?

Don't try to defend Amazon here. They have messed up with the way they treat employees. 30 hour weeks doesn't change that.