salil999

> Our architecture isn't fully based on serverless because we like to get work done

What do you mean by this?

> Having static fields and state is to be avoided.

This is totally false. It will always depend on the use case.

You don't interview to get "programming experience". You're interviewing to get a job. Definitely not a win.

AWS support has historically been pretty good about removing these charges. Just be careful next time.

I racked up a $8k AWS bill for my university when I was leading a club. A few emails to AWS support and it was all resolved. Although there might've been more leniency since I was a student.

Where would this be useful? I am not trying to bring the article down but I'm genuinely interested in knowing where/how people would use this. It seems like just locally modifying a payload would be more efficient?

I'm surprised you say the Apple ecosystem is terrible. It's arguably the best, most complete and integrated ecosystem out there currently.

Of course it's not going to work well with Windows. Apple wants you to buy a Mac.

Exactly this. I was too young at the time to grasp this idea.

I can't say in risk of violating some NDA but a lot of it is internal stuff that customers will never even be aware of or it would require too much effort for them to break.

There are times when bad deployments happen and customers were impacted.

I can safely say that the team members working in DynamoDB are very skilled and they care deeply about the product. They really work hard and think of interesting solutions to a lot of problems that their biggest customers face which is great from a product standpoint. There are some pretty smart people working there.

Engineering, however, was a disaster story. Code is horribly written and very few tests are maintained to make sure deployments go without issues. There was too much emphasis on deployment and getting fixes/features out over making sure it won't break anything else. It was a common scenario to release a new feature and put duct tape all around it to make sure it "works". And way too many operational issues. There are a lot of ways to break DynamoDB :)

Overall, though, the product is very solid and it's one of the few database that you can say "just works" when it comes to scalability and reliability (as most AWS services are)

I worked at DynamoDB for over 2 years.

Some people just want a paycheck with low minimal work required. I worked at a FAANG and I can guarantee you that many people do not care much about growth and development. A lot are just there for big pay and less work.

I used to work at Amazon. The internal processes are absolutely horrible for employees in almost every aspect (tech, HR, recruiting, etc). Looks like not much has changed.

I like exa. Been using it for a couple months now.

And how exactly is that a problem?

Why would they need AWS to do so? Engineers in companies don't know every line of code in their product - many of them are siloed in their own teams.

A team can easily just dedicate an hour or two a week and do their own bug bash, right?

Sounds like free training for AWS CodeGuru. And the rewards aren't that great.

What's the incentive for people to actually do this?

I didn't reveal my team to maintain some form of anonymity. If you're an L8 or above then you may have some power to do what you said. Otherwise I don't think it'll make a difference.

If you're brand new to the industry I'd say stay for at least 2 years. I worked on a service which operates an enormous scale and while I'm thankful for the opportunity it takes several months to ramp up (I'd say about 6-8 months for my team). But obviously YMMV.

Totally agree. My experience is my own and definitely not reflective of everyone else who works at Amazon. They employ tens of thousands of engineers and many of them are happy. I just wanted to share my story - not trying to generalize this for all of Amazon.

But I wouldn't say it's a minute exception with so much of it being revealed. For every story that's revealed you can assume that there are others in a similar situation who do not publicly share their story.

I think one thing I learned from AWS is that there's so much hidden away from the customer. There definitely were (and probably still are) many issues which the customers won't actively experience. Reliability doesn't necessarily equate to good standards and good practice.

But yes, from a customer point of view, AWS is pretty nice.

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 pretty bad (40-60 tickets a week) and there was very little investment being put in to improve it. We had a lot of little scripts here and there which would solve extremely specific situations but no focus was ever put on in building a general framework or trying to reduce the ticket count. This often led to engineers taking the day off after their on-call due to the load and honestly it made people quite grumpy. And upper management was always much more interested in feature delivery since the focus was always on promotions and the more you delivered the better it looked for your manager. So now you have engineers with such a terrible on-call load along with pressure to deliver new features and projects within the atrocious tight deadlines that would be set. It was, to be blunt, a shit show.

Code quality was atrocious. We had one enormous Java method (>1000 lines) which would take care of nearly every single request coming into our service... With only about 7-8 unit tests. It was so difficult to get even basic things done to the point where any ticket that needed to be done would take a minimum of 4-5 days regardless of complexity. And of course managers and senior engineers would estimate small tickets to take around 1-2 days and then be shocked when 2 days later it's not even close to being finished. I will give Amazon credit that they do grill design reviews pretty harshly so those are done well in general. But code reviewers didn't care about quality or best practice. If it works then ship it.

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 fresh college grad, making them do work for 6-12 months and then just randomly putting them on PIP. Sad but I've seen it happen a few times in my time there.

I'm glad I got the Amazon stamp on my resume and left. When I left, more than half my team and my manager quit around the same time too. It was definitely a wild experience.

> But they are so close to FSD.

No, they are not. I own a Tesla with the FSD package and I've seen many of the videos with FSD beta. FSD is definitely a remarkable technology but they are nowhere near close to FSD.

> But if the work becomes smaller, and they pay bigger, doesn't that mean you now have more time on your hands and more financial security to do something that piques your interest?

I actually used to think similarly. I might have worded it badly but when I mean the work becomes smaller I am talking about scope and impact - not necessarily the effort required. The example I can give is what I described above: config changes. At a high level it sounds pretty simple but when you delve deeper into how your company/team works with such technologies then there are many barriers in place which hinder you from getting work done efficiently. And processes are slow. In my old team it used to take ~a month to deploy our software world-wide.

You are correct about financial security. At least for me, I am not comfortable enough taking a risk to start something on my own or make a big career change.

I think the overall goal is that you SHOULD be told what to do - up to a certain extent. I am a software engineer so an example for me would sound like "design me a system that does this" or "a customer is asking for this feature request" and that's it. Everything else can and should be left upon the engineers to figure out. Good engineers will design a good system with respect to time for delivery and feature request compatibility.

Their GitHub profile has more than 3 projects - you might have only looked at the pinned ones.

But overall, I somewhat agree with Francesco. I used to work at a large corporation where majority of the work was minor config changes and rolling out deployments for handsome pay (somewhat KTLO work). I left because I wasn't growing my career. As companies get bigger the money gets bigger as well but the interesting work gets much smaller. At the end of the day, once you have a solid product in place you need a lot more people to just keep it running vs. work on some very interesting technical work. I think applied research is the best way to go for very interesting technical work but I think the bar is pretty high for that.

I work at AWS. I can tell you surely enough it's not pretty or easy to work with. Design and architecture are great here but implementation of that is pretty crap...

I think Bezos gets a lot of flack for anything he does. That being said, I'm not defending the man. I think his response to things as the CEO can be much better.

Transparency is very important from employees at the bottom - and given a lot of the recent stuff that happened recently (like the strikes and all), I don't think upper management is particularly good at showing visibility. I understand that company is huge - but that's why you hire smart people. They should have ways to address issue like this. Asides from one email that was sent company wide, I haven't heard zip from him. However, Amazon is known to not take great care of its employees. So I'm not too surprised here either.

I'm a software engineer, btw. My thoughts are my own and do not of my employer.

I applied to 3 positions about a month ago and still no response :/