Pros: Work with smart people. Challenging, exciting work that varies day to day. Many opportunities to get "training". You do not have to decide on a career until after you work here for a while, so there is flexibility. Career opportunities, though not as many as advertised during the hiring process, they are still there.

Cons: Management for the "Engineering Development Group" should not be managing a development group. They are basically technical support managers, and generally good at that, but do not have any clear mandate to focus at all on the non-support side of this group. This is clear as they continually make decisions that sacrifice engineers' long-term career development at MathWorks for short-term technical support goals. The work culture of the Engineering Development Group is not in line with the principles and values of the rest of the company. The dual demand for our time, coupled with homework assignments (yes, there is homework in EDG), routinely makes working after work hours or on the weekends necessary. The common complaint for this position is simply that the 50/50 support/project time split, which is repeated all throughout the hiring process and at career fairs, is simply not true. 70/30 is more accurate.

Pros: NOTE: This review is for the application support engineering role ONLY and does not reflect the rest of the company or other departments. Pros would include: * A safe haven for foreign nationals looking for a long-term career path and eventual citizenship in the US. They will do all the immigration paperwork for you. * Many social gatherings/events, generally positive work environment. * An opportunity to explore other departments within Mathworks and learn the tools.

Cons: Your experience in EDG may vary depending on your manager. Some managers are very by-the-book, while others are more laid back. * You're no longer an "engineer". Any notion or aspirations you once had of actually designing something cool is kind of thrown out the window. Instead, the focus lately has been transferring people to the "quality engineering" team where you will be doing software testing once you're done with EDG. To maximize the benefits of a future career path, choose your team wisely. However, most look for an easy opportunity to transfer out without any serious thought or consideration, while others are much more definitive about what they want (you’ll see senior EDG members who have been here for 3 years or more in this category). If you’re willing to work a little harder and brush up on C++, joining development instead of QE is a better career path (both pay and experience). * The company as a whole is obsessed with quantifiable metrics, more so with the EDG group. Tech support cases take more priority over projects for the sake of customer satisfaction. Example: Didn’t contact a customer for more than 1 business day? Send them an email explaining your progress, even if you have no progress to report. Long weekends are usually followed by putting extra people on tech support for the flood of email cases that comes in. Projects are the key to transferring out of EDG, but the irony is that sometimes tech support over-rules this, and you're forced to task-switch. * A member in EDG is expected to "contribute" to the team; however, the sudden growth of this department’s headcount has led to a deprivation of any sort of needed contribution. This usually leads to people coming up with very niche/useless "EDG-projects" that have little impact on actually helping anyone. Many meetings will be had, and usually nothing will come of it. Ideas spawned by managers might turn into a “pilot project” where they may test a new procedure out. Some of these projects are useful and can benefit the team, but it has been noted that a large majority of them just haven’t gone anywhere at all and are eventually killed because the idea was not-so-great to begin with. * Process. Oh, and a ton of meetings, many of which can be skipped, especially for more senior members of the team. * Try not to stick around for more than a year and a half in EDG. You’ll eventually have doubts about staying with the company over-all and wanting to do something else. Generally, your level of involvement in answering tech support questions will stagnate, and you’re encouraged to focus more on career development (picking up projects); however, you’ll still get blind-sided by tasks in contributing to the EDG team.

Pros: Great colleagues. Most I met were great to work with. If you're looking to move from a non-CS background to software engineering, it can provide you with a good transition, as they actively hire non-CS grads.

Cons: There are a lot of reasons why I would highly advise against joining EDG, and I have highlighted the main ones. * There is a high probability that you will not get the position you want once you transfer out of EDG. You can end up waiting years for a position to open up in your preferred team. Most people choose to transfer to whatever position is available rather than wait for their preferred position because the technical support (in theory 50% of the work, but often higher) aspect of the work ends up being so unbearable after around 9-12 months. * The department is constantly understaffed, and we are put under a lot of pressure to satisfy the department KPIs of resolving support tickets. This in practice meant pulling a lot of extra work to deal with the workload, and for a long time, even being asked to work on cases during weeks allocated to projects. * The managers are clueless and have limited experience with technical support. They do not seem to understand the challenges of technical support or the fact that most of our challenges stem from being understaffed. If it wasn't for our full-time Technical Support Engineer colleagues with their high-value experience and knowledge, we would be screwed. The managers just blame us for being overwhelmed with cases on "team efficiency." They would constantly come up with terrible ideas that don't work and create an atmosphere where short-term fixes and taking shortcuts (e.g., spending less time per case to resolve it) were encouraged implicitly. When these shortcuts would inevitably backfire and engineers receive low customer satisfaction surveys, the manager would act all surprised that it happened and chastise them. * Work-life balance can be a hit or miss. I had no issues and managed to get work done without working overtime, but I know a lot of people who had to work many extra hours. The main culprit of this was getting new responsibilities without adequate training or support to take on that responsibility. A common situation was when EDGers would be given the rotational team lead role and would work extra hours due to the high volume of tech support cases and the high pressure put on them to deal with it. * A lot of useless/outdated training and processes (which you often need to do during your project weeks). What ends up happening is that, in frustration, answers get copied from more senior staff who have already completed them. * EDG is an afterthought in the company, and it is seen as less important than other roles. An example is that for orientation in pre-COVID times, EDGers are put in the back of the line and can end up waiting over 10 months to complete their BPO (company orientation), while staff from other departments often have the option to do it in the first few weeks/months. * The way that management gets around their failures to hit KPIs is by deflecting the failings to the EDGer. Every year, a certain percentage of EDGers worldwide are laid off due to "performance reasons" (similar to the "hire to fire" policy that other companies use).