Pros
- The company's product has a very complex architecture, making work at ShiftKey both challenging and enjoyable, especially when things are finally working as they should. - The company's product remains profitable despite its overcomplicated user flow. - The company has received significant investments in recent years. - Many talented engineers work there, and I personally learned many interesting things from my colleagues. - Competitive compensation and benefits. - Option to work fully remotely or in a hybrid setup from the office. - A great office space. - No strict time pressure. Tasks just need to be completed. Nobody tracks your hours, and there's no requirement to work at specific times. Overtime is rare.
Cons
- After receiving investments, the company hired too many engineers without a clear plan for their roles, leading to some engineers focusing excessively on refactoring rather than business tasks. - The company hired numerous managers, shifting its focus to a manager-driven culture. Code quality and stability became less important, with an emphasis on being proactive in meetings. If your coding skills are average or below but you excel in communication, you can expect quick promotion by managers. - There were numerous unnecessary meetings, with some days nearly entirely dedicated to them. - Overengineering with A/B tests. I worked in a squad responsible for two different versions of a highly complex flow. Engineers had to support these two versions for years, despite discussions about the need to make a decision and move forward. This lack of resolution led to various problems at different levels (design, code, product, etc.). - Overengineering with analytics. Managers decided to track everything everywhere at once, resulting in chaotic and unstructured implementation of analytics in the code. The data team didn't even have a list of the events being tracked. - The company fired 15% of its employees because it wanted to go public on the stock market. This happened at the same time the company was celebrating a headcount increase and expressing its intention to hire more employees. Many highly skilled engineers were laid off, some of whom hadn't even worked for the company for a year. - There was a data leak on the backend side, and C-level managers placed blame on the entire team while simultaneously promoting a "no-blame" mentality among the engineers. - Incompetent and arrogant principals. There was an instance when a principal product owner attempted to assign new tasks to our team with the mindset of "getting them done as soon as possible." However, other managers were emphasizing that we should follow proper Scrum sprint planning and not work under a waterfall approach. The principal product owner accused our team of incompetence because we insisted on proper planning. Eventually, it became clear that the new tasks were not properly defined because the principal product owner was unaware of our various workflows. As a result, the tickets needed a complete redesign due to the product owner's lack of understanding about how the application works. Our team was blamed for the situation. - Some principal engineers imposed their views on code architecture without considering the opinions of other engineers. It turned out that many of these decisions were based on their experiences in previous jobs. This became especially problematic when iOS architectural decisions became mandatory for Android code. Some individuals expressed their concerns, but they were all let go during the massive 15% layoffs.
