[potatolicious]

Would it be though? Amazon spends a lot of time on the traveling salesman problem too, but only the extreme high end architect level people, on a very tiny number of teams.

99.9% of engineers at Amazon are writing, well, downright normal code.

It seems silly to test someone on something they will never, ever run across in the course of their duties, and which you reserve for only a tiny, select portion of your workforce.

It'd be like requiring all the waiters in a restaurant to also be qualified chefs. Yeah, cooking is the core of your business and highly relevant to the organization as a whole - but not to this position.

[opendais]

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 other people.

Think of it as a more relevant FizzBuzz.

> It seems silly to test someone on something they will never, ever run across in the course of their duties, and which you reserve for only a tiny, select portion of your workforce. > It'd be like requiring all the waiters in a restaurant to also be qualified chefs. Yeah, cooking is the core of your business and highly relevant to the organization as a whole - but not to this position.

Is a naive solution to TSP really that hard?

[potatolicious]

> "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?