Enough with the Programming Puzzles

Do people applying for other roles get treated to tests like this? Seems peculiar to IT afaict. Having worked in IT for > 25 years, I would have thought my track record would speak for itself, but still I'm treated as though I've been lying and cheating my way through my career. It's not like just asking questions, either: it's a test of basic aptitude and (like the author) I'm at the stage of refusing to do them.

It seems that other professions have solved this. Nobody is asking lawyers to run a trial on a whiteboard or solve a whodunit mystery in 2 hours. And I don't think that licensing process for lawyers guarantees anything other than the right to practice law (there are pretty bad licensed lawyers out there). Do construction workers draw diagrams of installing drywall in their hiring process? Do plumbers get challenged with the back of cereal box trace-the-pipe puzzle?

There are jobs, which have a similar hiring process. Performance artists actually need to perform to get hired but they do perform their actual work. 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.

If you want to find out if a programmer can actually do the job, then it seems to me that the way forward is to have them do something that actually resembles the job.

In the high-end cooking world, it's not uncommon to do one of two things when looking to hire a new cook:

1) Make me a dish. Present the chef with the kitchen, and possibly a specific main ingredient(s), and have them make the best dish they can with that ingredient. Sometimes this is also under some kind of time constraint, to test pressure under fire, but doesn't have to be (great chefs might take weeks to develop a new recipe after all).

2) The "stage". The kitchen takes on the chef temporarily for a short period, where they will actually work on different portions of the line, so that the employer can see both how they perform in real time and where their strengths lie. This can be as little as a single shift, or up to a month or more at some very, very high end kitchens like Thomas Keller's. Crucially as well, this is generally paid (it'd actually be illegal otherwise), so the prospective hiree can actually afford to dedicate that kind of time.

Now some of this is similar to stuff that some tech companies do already. But I think they often miss crucial elements that makes this actually work in a way that's not painful for both parties.

The "make me a dish" method for instance, superficially resembles the infamous "sit down at our computer and code a thing" tests I've read of many times. But there are key differences. Tooling is a pain point in programming that doesn't so much exist in cooking (in fact part of this test can be making sure the prospective cook is familiar with all the basic tools). Sitting in at a foreign editor/IDE/language etc. is likely to be more stressful than is really accurate to how one can expect a new coder to perform in the real world. The simple solution is "bring your own knives." Let the coder use their own machine, or at least give them time to set up a basic version of their favorite tools.

The other thing about "make me a dish" that's missing from programming equivalents that is I think most important is creativity. "Make me a dish" isn't about just proving you can cook, it's about proving you can create. And isn't that something we want from great programmers as well? Generally when I see and read about these tasks their very proscribed: there's a specific spec/demand/puzzle, and often with the expectation it will be solved in a particular way. One test task I was given once actually even specified what data format I was supposed to use to communicate between back and front ends. What about a mini-hackathon/jam approach instead? Give me a subject or a data source and a bit of time, and see what I can come with?

The "stage" as well is something I think is underconsidered with tech companies. Companies spend thousands of dollars on hiring practices and recruiters and advertising, but they can't just do a paid trial period instead? It makes no sense. If you think you've got a promising candidate, just take them on for a couple weeks, point them at a relatively low-hanging fruit task on the issues board, and see how they do.

Alternately, maybe just accept a fucking risk now and again. If the candidate seems to know what they're talking about in the interview, maybe just hire the fucking person, and if they suck, fire them. This is the same stricture and risk 90% of hiring practices are under, and somehow the economy hasn't collapsed yet so I am gonna tentatively suggest it seems to work.

Sometimes the path of least resistance is the easier, cheaper way.

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.

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