Pros
Very approachable senior management team. Regardless of your level, you can stop in most of the senior exec’s offices and have a discussion for fun, or about something that you need to get off your chest about a project that is annoying you (or even something completely unrelated to work). You 100% will not get this everywhere you go. This is a major plus. Digressing from senior management, the overall team is above average nice and easy to navigate. There are not many (if any) disgruntled “hermit” employees here. People are tipping the scale on more often than not willing to help you even if it results them staying late to finish up what was actually a major deliverable that day. Across all tiers Exec, Senior, Middle, and Junior (regardless of job function), no one will likely tell you they are “too busy, can you come back tomorrow? It would be more convenient for me”. Enough of the non-senior level staff is incredibly hard working too to the point it’s relatively easily to connect with anyone regardless of job title/role/function. Interviews on the tech side are HIGHLY selective to the point where team fit is more important than technical capability. This can be both good or bad but I’d lean on the side of good. You can’t teach someone to get their act together as an adult. You can, however, teach someone to approach a problem better. Remote work is rarely (if ever) an issue as long as there are continued results and you establish trust with your team and those higher up.
Cons
The focus here is very clearly getting logos on the website. As a developer you have absolutely no input on timelines as they are completely sales-driven (read: aggressive and more often than not, impossible and just construed to make a deal with a high-profile client). Feedback is never integrated up or downstream in the company and there is a very clear “if you aren’t happy, you are the problem” mentality. This most often manifests itself as suggestions of projects that should be avoided in the future, but continue to come through the pipeline. Thus, sending a clear message of “It’s your problem now, just get it over the finish line”. Because the development team is dedicated, this unfortunate paradigm persists. Expect to attend “agile” stand up meetings while in a complete discovery phase of a project with nothing to report on, but being asked why it is not done yet. There is nothing that fits into the agile methodology here. Projects are completely waterfall and you will likely have lots of rework due to internally taken on and approved scope creep and or promises just to keep the client happy rather than standing firm and protecting your resources. Facts and data to support your projected completion date mean little to nothing as upper management will promise the client that you (the developer) can do it faster (without you there) even if it is quite literally not possible due to a variety of reasons (broken hardware, antiquated hardware, no one to ensure the system is up 24/7 etc). As a result, the amount of flailing is high due to inability to understand complex data and network/computing issues as well as interconnected and dependent systems. This ultimately ends up in make you look like you are incompetent and sets a bad precedent for any phone calls you have to join with the client (they already are not on your side). Ultimately you will have to because they will become tired of being lied to and ask to talk to the technical team to understand the real issue. The platform is an entire black box with no standard returns from the plugins you will use, thus you need to spend a LOT of time smoke testing your “code” so you can ensure you hit every condition. This isn’t a huge deal if you have and IDE and can set breakpoints and step through. There is really no stepping through and the “code” is more of putting puzzle pieces together. If what you like is writing code, (even if you consider javascript code), I would ultimately suggest avoiding this as an employment option/consideration. Making this a bit more challenging is the product development team’s lack of interest in fixing bugs that affect your ability to complete your work. Expect to receive no updates on bug tickets for about 6 months or so (if ever) regardless if it is marked as a production blocking issue. The reporting structure for this group is also completely unclear so it is hard to get someone to put pressure on them to fix things that only they can fix (since the source code is not readable by the entire company which is another major issue). There is also zero transparency as to what they are ACTUALLY working on so you are more or less stuck just waiting and hoping what you need fixed will be fixed. Additionally, there is next to no sense of urgency in general unfortunately which trickles down to people either getting extremely frustrated, or just jumping on this train and not caring. Further expanding on this, is the heavily coupled interconnection and dependency on what you use. APIs are not isolated. Plugins are not isolated. Database connections are not isolated. Any UI/UX is not isolated. I’ll stop here, but what this end up resulting in is numerous ways to completely freeze your ENTIRE system by something you wouldn’t expect, and relying on someone else (definitely not you as the developer) to fix it (aka restart tomcat and or the VM the stack is running on). This is beyond frustrating when you have a promised deliverable by Monday and you are unable to fix it over the weekend because someone else wasn’t checking their email like you were expected to. If you can not trust your dev team to have admin to simply restart a server, I am not sure why you hired them in the first place for a job that may touch sensitive patient, financial, or confidential IP data for a client. There is little respect for your time outside of work and more importantly PTO. You shouldn’t be surprised to be heavily suggested to check your projects daily and fix issues and or take calls to address “critical issues”. Furthermore, expect calls and or texts from project managers outside of work hours at least twice a week that may take 20-30 minutes. When everything becomes a critical issue, there is either a major infrastructural issue or it’s really just not that big of a deal. I am personally under under the impression these are both true. Regardless of the “product” or “deliverable” you have, you should expect to report directly to someone who does not write code. This is highly frustrating because no mater what amount of data you have to support the problem, the sales mentality takes over, and you are not only wrong, but incompetent, and the customer is always right. This issue tends to manifest itself in the form of projects that continue to drag on with no end in sight and you being told what the original timeline was (though you had no input on it). The timeline is your contract here and it will always be your fault. Another issue with this methodology is the complete inability of your supervisor to assess your actual technical skill and competency. The result here is obvious. You could be the smartest person and given and impossible task… But it is still your fault and you will be questioned on your capability while others who are carried over the finish line by a support team get praise. Finally, performance issues (mainly personnel, but certainly technologically) are rarely (if ever) addressed in any remotely timely manner. You’d expect this “speed” with a large corporation, but that is not the case when you have under 100 employees. Expect to receive “well, this a team and you need to help your team” rather than addressing the actual issue. Also, expect to be listened to, but never heard.
