| > "Is a naive solution to TSP really that hard?" Why do we want a naive solution to TSP? The naive solution to TSP has no applicability to anything - it's purely a thought exercise in the same vein as "why are manhole covers round" and "how many jelly beans are in this jar". Remember that 10 years ago we thought those questions were "predictors" of programmer ability. Turns out that was full of crap. So your notion of testing someone's suitability for a job is to ask them to solve a problem unlike any they will encounter in the job, expecting them to generate a solution that would be wildly insufficient even if the problem was relevant to their job? In the mean time I rarely see companies testing for abilities that are used on a regular basis in these jobs: the ability to architect, knowledge and familiarity with best practices and design patterns, writing testable code, etc etc. All of these skills are far from universal, but yet we spend no time ensuring they're there. No, we blow the valuable 45-60 minutes we have with candidates twiddling around with TSP. We ask candidates simplified things from what goes in IRL, because we don't have all day. That can't be helped - the least we can do is make sure what we ask is actually a simplified version of what the candidate will be responsible for, instead of simplified versions of things the candidate will never touch, ever. > "Proving people know how to implement an algorithm [even one that is a pretty bad solution to TSP] seems relevant to me." It doesn't to me. More accurately, it doesn't seem relevant to the majority of coding jobs out there. In reality the number of jobs that ever involve implementing real algorithms is really low. Even in research-heavy companies like Google it's limited to a small subset of employees in a small subset of teams. The vast majority of everyone will not write a substantial algorithm from scratch in their day job. Ever. So why are we testing for this ability? |