1) Who cares if they've exaggerated their resume? The question is supposed to be whether they can contribute well to your code base/business right? I see this as a point towards getting rid of resumes -- maybe companies can stop bullshitting on what they "require" from candidates, and test more literally for what they want.
Don't take my resume, but if it's a backend position where the focus is erlang and postgres, test as specifically as you can for that, with fizzbuzz-like business requirements mixed in, for the best of both worlds.
2) I often wonder if there's anyway to lessen the costs of employee turnover. Obviously there's less you can do about time spent interviewing, but there's gotta be some cheaper way to figure out if someone is going to be a good employee while on the job? I mean that's the best test you could possibly have. Is it just the legal/logistical framework that's missing?
Also, I often wonder if running a company where it's hard for newcomers to ramp up and easy for newcomers to break things is a failing of the CTO and executives/managers all the way down to the newcomer (of course the newcomer is to blame as well if it's flagrant but I also think top-of-the-line tech orgs have (mostly) bulletproof process that evolved with them and got them to where they are (i.e. newcomer can't break your build if commits to shared branches/environments are gated by automated testing to begin with).
1) Who cares if they've exaggerated their resume? The question is supposed to be whether they can contribute well to your code base/business right? I see this as a point towards getting rid of resumes -- maybe companies can stop bullshitting on what they "require" from candidates, and test more literally for what they want.
Don't take my resume, but if it's a backend position where the focus is erlang and postgres, test as specifically as you can for that, with fizzbuzz-like business requirements mixed in, for the best of both worlds.
2) I often wonder if there's anyway to lessen the costs of employee turnover. Obviously there's less you can do about time spent interviewing, but there's gotta be some cheaper way to figure out if someone is going to be a good employee while on the job? I mean that's the best test you could possibly have. Is it just the legal/logistical framework that's missing?
Also, I often wonder if running a company where it's hard for newcomers to ramp up and easy for newcomers to break things is a failing of the CTO and executives/managers all the way down to the newcomer (of course the newcomer is to blame as well if it's flagrant but I also think top-of-the-line tech orgs have (mostly) bulletproof process that evolved with them and got them to where they are (i.e. newcomer can't break your build if commits to shared branches/environments are gated by automated testing to begin with).