- The management on multiple occasions crams a lot of work in a short period of time. On one instance it was roughly 4-5 months worth of work to be done in 1 month. The other instance is 1-2 weeks worh of work crammed in 2 days. Software delivered in this fashion always lacks quality, testing, and creates heaps of technical debt. Usually the company would understand that this is a risk they have to take but ineveitably on the long run the development team gets blamed for the quality issues. Not to mention the stress that this causes the development team.
- It is usually a hit or miss with people at the company when it comes to passion around computer science and technology. Some people are driven and curious and you would have fun discussing new frameworks, libraries, technologies, programming languages with them. The rest simply want to always take the path of least resistance to acheive a task and simply have no interest in computer science as a subject. If you are a driven person who is passionate about technology this is not the place for you. This also goes against how they identify as an 'innovative company' that is driving change. The level of ambition in this company is very low. The thought of discussing the ideal implementation of a feature is greatly frowned upon and any corneres they would cut any corners they can cut to deliver a half baked feature.
- You will often find yourself stepping on other people toes when testing your work on a development environment and countless problems happen during a release. It is generally believed by the management that there is a release process that ensures quality but that could not be further from the truth. The company suffered multiple high severity bugs that reached the production environment (3-4) in a 2 months frame despite following the so called process. Calls to re-think the infrastructure and moving to a test-driven development were ignored for months by the management, to only go back and blame the tech team for quality problems.
- Product managers with no to very little technical experience are ALWAYS put in charge of approving the work. Leading to layers of difficulty and unncessary delays for rather simple work, which then eventually gets blamed on the dev.
- Transparency dwindled and hit rock bottom in 1 one 1 meetings at recent times. No transparency in regards to people getting laid off/fired because of money problems.
- Management operates with an authoritative mindset. The level of techincal knowledge that product managers have is between none to very low. This leads to a work cycle where the product manager simply makes demands and expects you to follow them to the letter. The techincal specification for 95% of work lacks detail and leads to uncountable unanswered questions (which goes without saying) leaves a lot of room for error and unnecessary delays when the work gets to the approval stage. (To be fair this has seen some improvement but for the bulk majority of the time this used to be the case and it is important to note here). Moreover, the management simply does not listen to the tech team despite the product being a tech product. The focus of your contributions is not improving the quality of the codebase by building new efficient features or re-structuring old ones to make them better. All work is simply driven by the whims of the senior management and what buttons they want to push on the website.
- The claim that they are an agile company is simply not true. The grand target of the company is to have an imaginary process followed to the letter instead of being flexible and adaptable to the changes that happen in any agile environment.
