[CharlieDigital]

> ...the problem is maintainability is something that can really only be measured over a long time frame.

I think here are certain heuristics that can be used to examine this.

  - Review GitHub repos if the have them; see how they structure code in actual projects.  Yes, not everyone has a GH profile or spends time writing side projects, but if it is there, that's a great starting point.
  - Focus coding interviews on writing testable code and test cases
  - Observe how the candidate structures classes, functions, parameters; many simple decisions can affect maintainability; we even have standard measures like cyclomatic complexity that are objective indicators of maintainability.
  - Have them write something simple but meaningfully complete as take home and see how they comment, document, organize, and explain their code

> So there isn't an easy way to really determine whether or not some produces lasting good work in a reasonable way in an interview, and you don't really need rockstar

Is writing maintainable code a hallmark of rockstars?

[gus_massa]

> Observe how the candidate structures classes, functions, parameters;

How long must be a project to be able to see how good is the interviewed choosing classes, functions, parameters?

For a two hours project, I may write it in a single pass. Perhaps some small auxiliary functions. Do I have to add docstrings? Make it a three hour project. For test cases give me another hour.