A lot of the time they are left out to see how experienced the individual is working in the environment. What do they think is the most important (outside of the outlined criteria)? Treat it as if they are testing your experience, not your literal skill in pumping out code. Anyone can pump out code.

The issue there is the problem starts to become unbounded for the candidate; they can't tell what you're looking for, so they don't know how to prioritize their time.

That's a problem even if you have reasonable expectations yourself, because the candidate probably has experienced some tests where the expectations haven't been reasonable. For a (real) example: marking candidates down for not having an analytics integration.

How does your candidate know that's not important to you, even though it was important to the last company?

> testing your experience, not your literal skill in pumping out code

Past a certain point, it gets much more efficient to discuss experience in an interview setting. Good coding tests should be designed to test the skills you care about most to produce a strong hiring signal for the next phase - it's difficult to showcase a full decade's worth of experience in 4-8 hours' worth of coding challenge.

> Anyone can pump out code

I've found that to be depressingly untrue amongst a significant percentage of engineering applicants.