[reallydontask]

you can also think about them another way, namely: How long it took somebody else in your team to solve the same problem

Making allowances for interview conditions, namely high stress levels, etc ...

Not perfect but an idea worth exploring.

I speak as a former smug interviewer that while didn't ask DP questions, did have a set of favourite questions

[nosianu]

> How long it took somebody else in your team to solve the same problem

I don't think that is useful. Variance is too great, even for a constant single person.

I think that anything that attempts to cast this issue as some objectifiable measurement problem is on the wrong track. Measurements work - on a statistical scale. Even then its hit or miss depending on how good the chosen values to be measured are. Just like public health issues. As soon as you try those approaches that work just fine on a large scale on individual problems you are toast. The results of those individual decisions can be measured using statistical methods, but don't try them on individuals.

[JustSomeNobody]

> How long it took somebody else in your team to solve the same problem

I don't think that is a good measure. I know many developers who want to solve everything fast because fast is productive in their eyes. The problem is they end up having a bug or three and spend some back and forth time with QA. So, now they didn't actually solve the problem fast and they wasted QAs time. I prefer to get a more holistic understanding of the code before fixing the issue and not get any bugs back from QA. In retro, when the QA tells the team how many bugs there were, I am proud when I'm not a part of that count.