Things move extremely slow at this company and instead of the company taking ownership of it, managers blame their employees for not doing a better job at executing in a timely manner. Because of the multiple rounds of layoffs at this company over the past few years, resources have become extremely limited. As a result, when features and sprint goals aren't met, all eyes are initially at the developers assigned to the tickets, instead of looking at the entire process to see where the bottlenecks were. If you haven't been an engineer at this company for over 3+ years, it's quite difficult to get acclimated to their codebase. On that note, getting pull request reviews has always been a problem. From an outsider looking in, this would seem like a trivial issue with a trivial solution, but it's not. I understand that engineers at a higher level have their hands full with meetings, but it's not helpful when the sprint is about to come to an end and a comment is left on the pull request that derails the entire feature. On one hand there's some saying, "it's fine if a ticket carries over to the next sprint, let's do it right the first time" and there's some saying "let's do this the right way, but let's also get it finished by this sprint". In other words, there's this constant stalemate and the developers are stuck between in it. One last major gripe I have is with the deployment process. I've been at other companies where the team has been able to fail fast, but also come up with solutions even quicker. This is not the case at ChowNow. Sometimes, bugs are caught right after deployment and it's easy to rollback, but more often than not, these issues are found later on. So far it sounds like any other company right? Well here's the kicker. Release a bug into production and get ready to hear about it for the next few weeks or even months about how you were the one responsible for releasing an issue. I've never been at a company where you'll get reprimanded like a parent would reprimand their child for dropping their food at the dinner table. What's worse is that in order to make sure it doesn't happen again, instead of trusting their employees to do their job and learn from their mistakes, they want to put up "rail guards" to see if it'll fix the issue. Not everyone's experience here is the same, so take everything with a grain of salt, but if you're an experienced engineer that doesn't make mistakes and is an AWS guru, you should apply here.
