Pros: Working on a project by yourself. Flexible schedule.

Cons: Expected work time is high.

Pros: The company's goals (provide good customer service, improve health care) are easy to get behind. They're generally acknowledged as the best in the health IT field. The pay is competitive, and the atmosphere is casual. They seem to hire, or at least intend to hire, based on ability rather than quantity of resume buzzwords.

Cons: You aren't likely to acquire trendy skills while working here. Though some people do web/mobile development, depending on your team (and/or customer, if you're in a customer-facing role), you might work long hours. I don't, and that obviously affects the rating I'm giving. The company has a rather controversial reputation due to a number of outspoken former employees and competitors. You'll frequently be asked about your job.

Pros: The work is interesting from time to time. Most employees have either a single or double office; there are no "open office" layouts. There are lots of food choices in the cafeterias. The campus is nice.

Cons: There is no technical vision in management. Promotion has nothing to do with merit; sycophantic yes men get ahead, and people who actually know what they're doing stay put. Management is obsessed with metrics about bugs. A good metric is supposed to be a means to achieve the end of producing quality software, but at Epic, the metrics are the end. No matter how severe a problem is, TLs close or deprioritize bug reports about it to make their numbers look better. If customers complain, TLs make up excuses to shift the blame onto something else (e.g., the customer's hardware, their network, Windows, or anything but Epic) or convince the customer that the problem is impossible to fix. When underlings point out that the problem is, in fact, quite easily solvable, their proposals are stonewalled. Meanwhile, TLs invest thousands of man-hours in pet projects that accomplish nothing (and frequently make the software worse). The TLs have so little technical knowledge that they often don't have a clue how much damage they're causing to our customers. But even when they do know, they don't care. There are no consequences for poor decision-making by employees. As I mentioned above, most customer complaints are suppressed by TLs in order to keep quality metrics looking good. So, there is no feedback mechanism to expose bad employees; people who slap together mountains of garbage code are praised for their productivity, while those who take the time necessary to build high-quality, high-performance systems are criticized for their low output. Much of the software is based on obsolete technology like Visual Basic. The amount of time a developer spends on such unpleasant languages is highly dependent on their team; a lucky developer might work mostly in C#, while an unlucky one could spend their days wading through unbelievably bad M and VB code. On a related note, because the software is so large, there exists a huge body of Epic-specific knowledge. Some people fall down the rabbit hole of trying to learn as much as they can about our software, but that expertise is unlikely to be of much use outside of Epic. Spending years writing VB code and getting certified in 10 Epic applications probably won't look very good on a resume. Of course, some TLs are better than others, and some teams are better than others. With luck, you can work with intelligent people on challenging problems and really improve the software. But one day, your luck might run out.