[buscoquadnary]

I've been working on a blog post about that subject but basically. The most important feature of code in general is maintainability, the problem is maintainability is something that can really only be measured over a long time frame.

The other challenge is that most jobs don't need you to be that great of a developer they need you to be a decent developer and then it wouldn't matter if your Donald Knuth or Donald Rumsfeld you can perform within expectations.

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 so much as you need people that can perform the minimum.

So you get crazy ideas that certain companies use and can use because they are making money hand over fist,and everyone assumes since that company is making so much money and hire people like that, that must be why they are making so much money, so they copy it in a cargo cult management fashion.

And if you think the leetcode is bad it at least has a tangential relation to development. You should've seen things back in the MS years when you'd have people ask you with a straight face "how many ice cream shops are in San Francisco?" "How many marbles can I fit in a bus?" "How many fields could our team fertilize using only what is produced in staff meetings?"

Stuff like that is even more annoying.

[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.