Likely no-show.
By far the best part of Epic is the coworkers. You are almost without exception working with competent people who are trying to do the right thing, where office politics are minimal.
The company has a pretty strong ethical backbone. Aside from various charitable works and being a good member of the community we're based in, Epic does not exploit the government or its customers to try to earn more money. The focus is on improving healthcare in a fair and financially sustainable way.
Management has a positive attitude towards professional growth for developers. My team, for example, has a "book club" wherein we spend company time and money reading books about software development, such as "Clean Code", and how to integrate such practices into our own software.
More generally, there's a culture of improvement. Best practices turn into processes, and processes that outlive their usefulness are summarily killed. Employees are encouraged to speak up and call out problems. As just one of a couple thousand rank-and-file developers, I've spoken with upper management multiple times about opportunities to improve various processes or to offer feedback about a recent company decision. There's very little "inertia" to maintain bad ideas. It provides a sense that, if something's truly bothering you, you can do something to fix it.
We develop a lot of our own tools and otherwise use a lot of things that are not industry standard. For example, one of the languages we use extensively is an older language without any automated testing support, so we wrote our own unit testing and integration testing frameworks for it. People were spending too much time submitting receipts to Accounting for their trip expenses, so we developed a mobile app to expedite the process.
This is either a pro or a con depending on context. In most cases, it means we have automated tools that work the way we need them to work, and we can change them if that need ever changes (we're generally willing to put in the work to maintain them). There are some cases, though, where there's a better industry-standard tool it would be nice to use.
As mentioned above, sometimes working on an older tech stack is frustrating. Our custom tools make this a lot better, though, when maintained.
Work at Epic is generally fairly self-directed. Management controls overall priorities and project lists, but you have a substantial amount of freedom in design and development. If everything's working out OK, this is fantastic and gives you the feeling that you are self-directed. However, there are a couple of notable scenarios where this can fail.
Managing this freedom in a way that makes everything work OK is hard. Given this freedom, you need to be able to strongly advocate for your work, plan ahead, and communicate those plans effectively. In some cases, this means, for example, telling a manager that they need to choose between cutting scope or pushing out deadlines. It means looking at your workload of ~6 distinct things and figuring out which will be done in what order and how to communicate to the stakeholders of those lower-priority projects. You also need to be able to decide when it's time to stop working and go home.
I've seen developers push themselves too hard and quit under deadline pressure. I've seen developers push through trash code because they felt pressure to get it done fast. I've also seen developers cause problems by waiting until a deadline was past to let anyone know about it. Unfortunately, Epic doesn't do a lot to help people learn those skills, which is particularly problematic since they hire so many people fresh out of college.
The second failure scenario is management. By and large, Epic management is quite good, and I think upper management is generally doing a good job. However, sometimes they drop the ball when selecting mid- and lower-level management. Some lower-level managers don't know how to manage developers; they ascribe too much value to deadlines and too much value to ticking off a set of requirements. This is exacerbated by the lack of a good process to contest these issues. The current process (escalating to mid- to upper management) is bad and requires way too much sticking your neck out.
In most cases, Epic is very transparent about its motives, processes, and direction. However, in any scenario involving employee benefits or pay, they get really opaque. Pay is of course hidden, and you're actively discouraged from discussing salary with your coworkers. Raises are determined by having various managers get in a room together and rank people on a scale. These ranks get fed into some mystical HR algorithm that spits out a raise on the other side. Managers are not allowed to tell you what your rank is (though they are supposed to tell you, in more vague terms, whether they think you're doing well or not). Bonuses are determined through similarly opaque means.
Management really needs to establish clearer guidelines on things that are currently left to the employee to figure out. Things like how to talk to dev management about deadlines, when it's expected to stay late, and what to do if you have a problem with your direct manager.
Aside from those being important professional skills that people need to learn, it would also help with lower-level management. If a bad lower-level manager demands the whole team stay late week after week, for example, team members would have real recourse.
I don't think just promoting fewer bad managers is a real option; unfortunately, you don't really know how someone will do in the role until you put them in it.
I submitted my resume through Handshake, completed an online assessment, and then had a brief phone interview. The phone interview was mostly behavioral, with some questions about topics on my resume.
Phone behavioral and online assessment followed by a Zoom interview with live coding and system design questions. The first parts were done at the same time, and the next round was dependent on those results.
Received an initial phone interview with a developer at Epic. It was a standard kind of screening phone call to verify credentials and go through the job requirements and such. Then came a skills assessment, which consisted of four parts: programmin
I submitted my resume through Handshake, completed an online assessment, and then had a brief phone interview. The phone interview was mostly behavioral, with some questions about topics on my resume.
Phone behavioral and online assessment followed by a Zoom interview with live coding and system design questions. The first parts were done at the same time, and the next round was dependent on those results.
Received an initial phone interview with a developer at Epic. It was a standard kind of screening phone call to verify credentials and go through the job requirements and such. Then came a skills assessment, which consisted of four parts: programmin