Michaels Software Development Engineer II reviews

- All the cons in the other reviews are 100% accurate. - WLB is almost non-existent, deadlines pretty much never get postponed and there is 0 transparency into how deadlines are even set in the first place. You're expected to work as long as it takes to get the work done. Often times there are full days of meetings from morning to evening or even nighttime where you are expected to stay the entire day to work. Getting PTO approved is a PITA a lot of the time, even during/around holidays. Many times there are meetings set up on weekends or at nighttime. - Very, very few experienced engineers. Majority of SDEs are new grads or juniors and often times they are tasked with making important decisions by themselves which will obviously end in how you would expect. The existing "senior" devs at Michaels when I joined are very incompetent and are probably less knowledgeable than most new grads here. New grads and juniors get promoted to "leads" instead of hiring actual experienced lead engineers. The result is you have clueless "leads" at this company who have the experience of a junior making poor decisions and who try to sound smart even when they don't know what they are talking about. - Management and leadership get 0/5 stars. There is literally no direction and cohesion between the different teams. Many terrible decisions stem from the CIO and management is too scared to push back on those decisions, so the SDEs face the consequences. I was under a director who verbally abused the SDEs because it only looked like we were going to miss a deadline moved forward an entire month, even though the demo was successful in the end. - Turnover rate is insanely high in the SDE level and less so in the management level, the only people I know who haven't left or are planning to leave are people who either just joined or people stuck on H1Bs at Michaels. - Many times Michaels retaliates when you give you notice and doesn't even give you 2 weeks. I know multiple cases where people were terminated the same week after giving their resignation notice. - SDEs have very little autonomy for things other than writing code. You want to make a change to a database in dev? Well, get ready to have to go through a long chains of approvals before the request gets implemented. Same thing applies for CI/CD processes and infrastructure related requests. Often times teams are blocked for multiple days at a time and must implement a temporary band-aid for demos. - Crazy amount of micro-management: Teams sometimes have demos every day or multiple demos in 1 day to management so that management can ensure the teams are working as hard as management wants. - Management and leadership ignores feedback completely. - We started following Agile development but this quickly devolved to a waterfall like approach with the steps out of order. Many times we get actual requirements after the design and implementation have already been completed. Also, requirements change all the time and there is absolutely 0 chance to extend a deadline. - The system architecture is absolutely horrendous, and I'm wondering who even approved of it in the first place. A new grad who just finished Grokking would be able to design a way better system than the existing system. Because teams are given 0 time to do any else but code, we have had to work with it, which will just make any eventual architecture update that much more difficult.