>I.e. they are not playing the anthem of Cambodia on a toy recorder in order to be hired as a death metal band drummer.

Think about it this way: they are not playing a full playlist on an actual stage with a soundcheck and live audience either. Compared to the real gig they are performing a smaller task in an artificially simplified environment. It is actually very similar to a coding interview.

People often forget that puzzles are not a thing into itself, it's a tool for discovering candidate's style and a springboard for further discussion. I'm not interested in a solution itself as much as in an ability to discuss it, explain it & improve it -- because those are the things that are being done in a workplace on a daily basis.

People also forget the goal of the hiring process - finding somebody who can get the work done. I am in the game industry and, luckily, not everybody is doing whiteboard coding and puzzles here, but, out of my anecdotal experience, studios that do it also release pretty crappy games. It could be that springboarding discussion is not selecting very good programmers. It could also be that the management who enforces these practices is not competent to run the studio. I cannot tell either way, just my experience.

You can flip this around.

Do you want to work for a company that does what everyone else does without a clear well-defined rationale for it, or do you want to work for a company that has a deep understanding of what it needs from its employees, and has worked out the most efficient way to get it?

Good companies run a continuous improvement cycle on hiring practices. Bad companies do the same shit over and over and make the same mistakes again and again.

So I would be surprised if poor hiring didn't correlate with poor results in other areas.

Out of curiosity, what do the studios that don't release crappy games do?

Math and general CS (in the sense of "What is IEEE representation of 1.f?" not "The difference between Red-Black and B- trees?") questions. Past experience questions.

Why are so many of them given as take home / pre interview screens then?

Actually, many firms do set puzzles, normally by asking the candidate to create a brief based on materials provided. It takes far more than a couple hours. Bar exams, depending on where you are, also sometimes incorporate this sort of thing.

The California bar exam includes two separate performance tests of (IIRC) two- to three hours each. You're given a packet of "facts" and legal-reference materials. Your assignment is to write a motion for a court case; a memo to the client; etc. (Starting in July 2017 it'll be cut to one performance test of 90 minutes [0].)

[0] http://abovethelaw.com/2015/07/california-bar-exam-cut-from-...

In my day, the multistate also had a "practical" exam option that involved creating a brief from a small pile of evidences. It only took a few hours.

In those other jobs get hired a lot :

    1 - by social networking;
    2 - on diploma.

For 1, The problem is, programmers will be recruited either by:

    - non programmers. And dev will likely not be found in the same social circles than those people;
    - programmers. Which tend to use a technical solution to all problems.

For 2, we all know now that you got as many good and bad dev, no matter the diploma, so people have given up.

And yes, dev are spoiled in the US, so recruiting technics move fast, trying to adapt. But in France, they are not, and we have the same old recruiting technics. And it's not better. Lot of bad dev are recruited.

When I freelance, they just ask if I can get the job done.

When I get hired, they want me to do dumb tests.

The only difference for them is that they can stop paying me right away when I freelance, but when I'm an employee they have to pay me for at least 2 weeks to go (at least in Germany were we have 6 months probation time on new jobs, where you can be fired easily)

I made many people I worked for happy, but many people who gave me tests wouldn't even consider me as employee.

I don't know if I would have been a bad employee for the testing-companies, but I never had issues with employers or customers who hired me, so I have the feeling the companies who didn't hire me were missing out.

Lawyers do not investigate crimes; solving a whodunnit is a terrible comparison.

Plumbers, unlike computer programmers, are typically hired purely by referral or a small amount of marketing. Again, you make a terrible analogy.

A plumber got hired because

A) The risk of a bad plumber is less threatening than the leaking faucet I have right now.

B) a friend said they were a good plumber.

Since JavaScript refactoring is not as pressing as a leaking tap the hirer can take their time and subject you to a rigour out process in order to ensure that the millions of pounds of intellectual property you have access to will be handled in the correct manner.

I agree with the top voted response; the perception is engineers are beginning to whine about everything.

Not you fault, you are just one part of the sum but that sum is sounding more like a spoiled brat than ever before.

By your complains about my terrible analogies (which they are, intentionally) I am guessing you are one of the few programmers who actually does all the stuff from the interviews on the job?

No. I freelance and don't have to do any of that.

However, when I was seeking permanent employment I understood that it was not my circus and not my monkey's. I had to jump through the hoops. The same for coding as it was product management as it was for consultancy.

Rather than complain, why not invent a startup that acts as a universal badge of coding ability and is widely accepted as the industry standard for benchmarking technological ability...

The post just screams (once again) "I am a coder you should simply accept my genius and leave me in peace to work."

Law of averages just tells you that there is a bell curve of ability...at least some of the individuals on Hacker News are precisely the individuals that white boarding and puzzles are designed to catch.

The issue is that many people already have a substantial proof of their coding ability in form of completed work. The rational approach would be to evaluate that work and, as safety, test that they have actually performed it. Whiteboarding them catches nothing other than inability to perform unusual tasks under stress.

As as we know, engineers are never in stressful situations so no point testing it.

Production never goes down, critical errors don't arise and time-pressure tasks are rare.

People do not behave consistently under stress so such a testing value is close to 0. It's a fight or flight response. If "fight" rolled up on the interview there is no guarantee it will roll up next time your production goes down. You can just as well toss a coin.

...and yet soldiers in WW1 and WW2 were subjected to stressful situations lasting years, some of which manifested in mental trauma but many of which actually behaved in the manner required.

My point is; you are neither psychologist nor professional human resources executive search.

Your reasoning for not conducting testing interviews is flawed and can be challenged at every juncture precisely because this is not your area of expertise.

It's not mine either but I am not advocating sweeping policy changes across an entire professional landscape.

If you feel there is a better route; then write up, test it, get it peer reviewed and implement it.

You can certainly challenge anybody's reasoning just as well as you can challenge anybody in court over any matter. But it requires more than typing first thing that comes into your mind for such a challenge to stick, jfyi.

But not in this case, the first thing that came to mind was a sufficient rebuttal.

Since you are constantly referencing the legal system you should remember it is the prosecutors role to prove the hypothesis. It is not on the defence to disprove it.

Merely rebutt sufficiently.

You have not made a single compelling argument for not testing coders with the current model.