[daviddever23box]

For developers, coding tests that include deployment / infrastructure components (i.e., deploy your solution to a cloud container, or, build and compile your solution for desktop platform testing) are uniformly consistent with long-term impact / success. Problem solving at the algorithmic layer may be inversely correlated to success, if a candidate lacks a production skill set.

Unless one's focus is research and development, there is a non-zero cost to training for production skills, so it's best to start with someone who understands the delivery process.

Linear metrics are probably less useful, inasmuch as it will become rather obvious as to which employees are self-starting and work well with others, versus those that require motivation or are staunch individualists.

[chaosharmonic]

As a developer with an arts background (studied music, happened into tech work after college through years of mostly self-taught hobbyist tendencies) I'd agree that the design of these tests themselves is a factor that's thoroughly understated.

Timed algo challenges encompass a slew of antipatterns in terms of how good code is actually written and shipped. To begin with, pitting someone against a clock and hidden test cases (and a foreign editor) is actively optimizing against solutions that are readable to other human beings -- or to the person writing them, a year from now. The nature of running them in a browser means that it can't evaluate a person's capacity to actually use tools outside of core language functionality. Never mind that building the entire exercise around predetermined test cases precludes any way to gauge whether the person taking it has an understanding of writing tests.

And that's assuming your test environment doesn't add obnoxious and arbitrary restrictions of its own. Like telling you that using documentation is cheating. (Btw imagine listening for ctrl+t here, but not ctrl+n.) Or offering you "the language of your choice," but then throwing API call exercises at you while limiting your choice of JavaScript runtimes to a bare installation of Node -- the only one still in active development, out of a list that also includes every browser you would use to actually access the test -- that doesn't support Fetch.

[necovek]

With the original question being about measuring correlation between interview performance and actual long-term performance on a job, I'd love to see the numbers you are basing your opinion on regarding testing for "production skills" and long-term job performance.

[daviddever23box]

Go ahead, show me how team interaction and declared responsibility can be measured unambiguously.

[necovek]

Here's a couple simple examples:

- Boolean yes/no qualification by a manager at 2 years of tenure compared to a boolean yes/no qualification upon performing the interview task (yes, they showed skills that relate to deployment)

- Performance review ratings over time (I would assume those cover "team interaction" and "declared reponsibility")

- Length of tenure ("lasted more than 6 months", ..., "lasted more than 5 years", "quit themselves"...).

...

None of these are perfect, but they are pretty unambiguous even if sometimes subjective.

As long as you measure while fully understanding that you're unlikely to achieve statistical significance soon, you can still measure stuff! And while you should not take trends that show up as gospel, they could still influence your interviewing.

Or, you could simply decide not to measure anything since you'll never get perfect results. But at least don't put your opinion out as fact, at least not in a thread about measuring stuff.

[presidentender]

Are you saying this because you measured it, because you have anecdotal evidence that it is true, or because it is something that you believe?