This, plus not using much memory or CPU also suggests to me few (if any) of the tests are run with async: true. Note: you can’t just enable that if the tests and/or codebase is full of global data mutation. All this suggests a rather … junior team.

At this point, I’d start making a case based on economics – or time specifically. How many hours of the department’s time is lost per week vs. a more reasonable target of test execution time (plus the delayed feedback in case developers don’t run the tests locally). Then make the case to allocate a certain number of developer hours to improve the tests (and/or core code). This is tech debt that needs to be paid down.

This can be reduced if the migrations are squashed into a single DB structure file and just load that instead. It’s healthy for any project to do this every now and then.

Are there any *seeds*.exs files in the project? If so, somebody should take a look for bottlenecks there. It’s amazing how awful code a lot of Elixir programmers allow in there.

This is an extreme anti-pattern and shouldn’t happen. Has any of the programmers explained why they opted for this, let’s be generous and not savage for a minute here, ahem, suboptimal practice?

Good job tracking those down and, you guessed it, another bad pattern.

I’d say enlist at least one programmer from the team and have them improve the code. Cliche advice but there’s nothing else you can do. Allocating more system resources will never help code in any language if it just sits around waiting for stuff.

Alternatively, and if that’s an option, you can show us some code and we can try to help.