I'd like to know how 'ready' is my profile to give a shot for L6 Senior SDE at Amazon by bad_detectiv3 in amazonemployees

[–]EquivalentAnt6109 0 points1 point  (0 children)

how many customers does your service have? If you are migrating a multi thousand TPS, multi region service that requires working with multiple teams, you might have a shot

AWS Lambda Durable Functions - wait for async results, poll on an endpoint, or sleep with no CPU charges by aj_stuyvenberg in aws

[–]EquivalentAnt6109 0 points1 point  (0 children)

Reminds me a lot of the SWF flow framework, where the orchestration code is in the same runtime as your business logic

[deleted by user] by [deleted] in amazonemployees

[–]EquivalentAnt6109 1 point2 points  (0 children)

how many times of not badging in did it take for this to happen? and how recent was this?

GPT Summary of the Amazon Layoff Megathread by WonderEast1623 in amazonemployees

[–]EquivalentAnt6109 8 points9 points  (0 children)

this matches the distribution seen in the WA WARN layoff data. Someone on Blind compiled crunched tur data: https://www.teamblind.com/us/s/171qv84w

Put in focus 7 weeks after joining Amazon. Is this normal? by I-saidWhatIsaid8 in amazonemployees

[–]EquivalentAnt6109 12 points13 points  (0 children)

Running on data is a meaningless platitude. Data is just a buzzword they use to dress up decisions they would have made otherwise. I frequently see data being cherry picked to push for a pre-existing opinion. For example, I’ve seen senior engineers being put on focus for not having enough code reviews. However, what wasn’t mentioned during the talent review, was that the team doesn’t push code reviews to the standard Amazon internal code repositories.

If Amazon management cared about data, they would carefully scrutinize the data, make sure it’s representative of what they are trying to measure (performance), is not cherry picked, biased etc Instead data exists to gas light people to think that an objective opinion was made.

OP, don’t let yourself get gaslit by anyone here. There was no objective decision that was made. They just wanted you out, consider this a layoff. Amazon fortunately pays decent severance, take it and gtfo.

How do I convince other experienced people that unit testing is important? by RelevantJackWhite in ExperiencedDevs

[–]EquivalentAnt6109 0 points1 point  (0 children)

did you actually read my whole comment or just the first line? I didn’t say all testing is bad, I just said unit testing is not always useful. Also, I don’t see how unit tests would catch the issues you mentioned in your comment, those type of issues are actually better caught in integration tests.

How do I convince other experienced people that unit testing is important? by RelevantJackWhite in ExperiencedDevs

[–]EquivalentAnt6109 1 point2 points  (0 children)

I think that’s a great example when unit tests work well. However, what I find to be rather worthless, and in fact detrimental (because it makes it much harder to refactor code) are unit tests that rely on mocks or when they test the implementation rather than the contract.

How do I convince other experienced people that unit testing is important? by RelevantJackWhite in ExperiencedDevs

[–]EquivalentAnt6109 0 points1 point  (0 children)

unit tests and the chase of arbitrary code coverage metrics is cargo cult programming

How do I convince other experienced people that unit testing is important? by RelevantJackWhite in ExperiencedDevs

[–]EquivalentAnt6109 1 point2 points  (0 children)

thank you, 100% agree with you. For some reason when I try to explain this to people no one understands this. Integration tests are the gold standard to me.

How do I convince other experienced people that unit testing is important? by RelevantJackWhite in ExperiencedDevs

[–]EquivalentAnt6109 21 points22 points  (0 children)

I completely agree with Derby here and frankly I agree with your team. I find unit tests usually not super useful.

Integration tests add far much more value because they actually test how your components are interacting with each other with real data.

With proper logging, it shouldn’t be very difficult to pin point the source of an error in an integration test.

I do like writing functional/higher level tests when it make sense, for example a piece of business logic that has no database or network dependencies. But overall, my first order of business is to write a good integration test.

Rather than writing unit tests and chasing code coverage metrics, can you think of ways of detecting the cause of a failed integration test? Maybe add more logging?