Programmer interviews and coding tests

Jeff Atwood has another blog post up about how "the vast majority of programmers can't program at interview".

Having interviewed programmers, and having thought about this problem from a human factors perspective, I've usually come to the conclusion that coding tests at interview are, in the end, almost useless.

Let's describe this using a slightly different story...

Suppose I was interviewing someone -- let's call him Bert -- for a human factors job. I ask him:

"Bert, why do you think programming interview candidates usually fail simple coding tests, even when all the other empirical evidence (their career thus far, references, and degree from a top rated university) suggests they should be competent?"

And Bert responds:

"Because they're just all that dumb; top tier university professors are fools who can't assess students; the exam results are all fake; and programmers' bosses are all just bozos that can't see whether any code is being produced even if they are programmers themselves. The empirical evidence from the rest of their careers is wrong and my toy interview question asked by an untrained interviewer over the telephone is right!"

Bert would not be getting the job. (However much the grumpy misanthrope in me might want to cheer him on in railing against the world!)

Like it or not, coding at interview is very different from coding on a job. To use a loose analogy: a great many people struggle at public speaking -- shove a microphone in front of them and ask them to talk for a minute about rain, and they say "Um, er, um... Mummy can I go home now?". That does not mean they don't know English or what rain is. Dumbing the question down to "Ok, just talk about water then" doesn't solve the problem - because it wasn't the topic that was the problem in the first place.

In an interview, we have a fake task (nobody wants to use the code), in a fake setting (an interview), via a false interaction (over the telephone!), with a false assessment (one interviewer whose word is final, no compiler, no user, no sales, no code metrics or unit tests), a fake timeframe (a few minutes on each 'project'), false pressures (your job depends on the next ten lines of code), and somehow we expect to have valid results. Speaking as a scientist, that's just nuts.

At this point, most people reply "Sure, but we don't care about missing out on good candidates, only not hiring bad ones." I have worse news for you. You are probably still hiring as many bad candidates as if you selected your candidates by rolling dice. Most interview coding tasks are so over-simplified that they no longer select for programming or thinking skills at all -- the "programming on stage" skill dominates completely. The irony is that by selecting for "skill at interview coding tasks" you might find yourself effectively selecting for people who have done a lot of interviews and honed that skill -- but you actually want to hire the person who has hardly done any interviews because no company ever wants to let him leave.

JavaFX initialisation order (solved?)

The semantics of JavaFX's initialisation order can be hard to find, and in a previous post, I was finding it gave some odd effects. Having looked on the JavaFX bug tracker, it turns out it the issue is fairly simple, but needs trumpeting from the hills because it is still unexpected.



B.one will be null. How is that possible? Because of what override means -- it changes the definition but not the "order of declaration".

A naive person might think that B.one would first be set to 1 (in the initialisation of A) and then to 2 (in the initialisation of B). Or they might think that B.two will be set before B.one because it comes first in B's script. But that's not how JavaFX does it. The variable one is initialised first because it is declared first (in A's class declaration, which comes before B's.) But it is set to B.two because only the override initialiser takes place. Unfortunately, this means it is set to B.two before B.two has actually been defined -- so it gets set to null.

The moral of the story: Don't use override var if you want to set the variable to refer to another member variable. It's a forward reference. Even if the member variable you want to refernce also comes from a superclass, it could still be a forward reference (because you don't know what the order of declaration was in the superclass).

If in doubt, set it in the init block. That always happens in the order that you specify in the block, after everything else has happened. It's boring and more Java-like, but at least you can even step through it with a debugger and put log messages in if you need to!

JavaFX initialisation craziness

UPDATE: Another post describes the solution.

JavaFX is Sun/Oracle's new user interface platform for Java. It has many features that are quite nice. But it has a few oddments that are hair-pullingly irritating.



The naïve among us might think that pushing the mouse button would indeed be wired through to MyBehaviour.onMousePressed, and "MOUSE PRESSED" would be printed. Apparently not.

In the language reference, there is this irritating line when it describes the initialisation order:

The values of the object literal's instance variable initializers are computed (but not set).

"but not set". Of all the evil villainous schemes... The MySkin and MyBehaviour objects are created, but MyControl.skin isn't actually assigned until later, so the following line wiring the mouse events to it breaks.

I keep finding that JavaFX is wonderfully concise, but really tricky to debug, and irritatingly fragile as many of its conventions don't do what you'd expect (like let you refer to an assignment you made in the previous line during initialisation, as in this example).

Australian Internet Filter

Senator Kate Lundy has made an alternative proposal for an Australian internet filter, bringing it back into the news again. However, her suggested opt-outs have not appeased everyone who is opposed to there being a government filter at all.

However, another kind of internet filter -- one that already exists and seeks to restrict access to sites -- has been remarkably successful and has not had the same kind of fuss made about it. That is the filter that modern browsers have built into them to block phishing and other fraudulent sites. Many browsers check a blacklist of URLs and if you try to visit a page on the blacklist, you'll have to click through a very serious warning first.

However, surely this also makes the gradual introduction of an optional government filter rather easy. If the government simply maintains a database of sites and the social or legal reasons why they might be inadvisable, the browser manufacturers could be nudged into showing appropriate warning boxes for them too. The rationale would be that if a person visited a site that had been officially declared a source of illegal material they'd find it hard to argue that they didn't know it was a bad site. So the browser publishers might start to feel they should protect their users from legal trouble just as they currently protect them from fraud.

I suspect a warning along the lines of "keep visiting this site and the police will be after you" is one that few people would ignore.

The problem with cricket

The Ashes have been on, and, while I don't often watch cricket, I couldn't pass up the chance to watch at least some of the series, given I'm a citizen of both countries involved. It's been tight and entertaining, but I can't help feel that too much of it comes down to the luck of the umpiring decision. In the match England won, at Lords, three Australian batsmen were incorrectly given out in their last innings when replays showed they shouldn't have been. And in this deciding match at The Oval, two of England's top order (Strauss and Bell) have been given out off what should have been no-balls. In a game where there can be fifty or a hundred runs between wicket-taking balls, that potentially makes a match-changing difference.

There's just that irritating sense of pointlessness behind the game when umpiring mistakes are as likely to decide the game as the skill of any of the players.

Ponting not happy (again)

It seems our Australian cricket captain isn't happy again. In 2005, he hit the papers complaining about England using substitute fielders (especially when he was run out by one). This year, he's stepped things up a gear. It's only the first test of the series and already he's complained about Cardiff hosting the first test, wides being called wide, and James Anderson changing his glove a second time after he spilt his drink on the first fresh one.

Punter, Australia is a country whose cricketers are (sadly) famous for sledging and shoulder-barging, and you're angry that changing a wet glove isn't in the spirit of the game? I think you might just be having a bit of a whinge. And in most of the newspaper coverage, you're reported as saying:

"I won't be saying anything about it."

Well, maybe not to the match referee, but if you've been quoted in all the newspapers on both sides of the planet, I think you've said something about it.

A selfish reason for liking Bing.com

Every now and then a new search engine comes out, and (I suspect like everyone else) the first thing I try searching for is my own name. And, woohoo, the top link using Microsoft's new bing.com is my own website. I'm only second and third in the search results on Google. I like Bing :)

Well, at least until it finds out about that much more famous pottery-painting William Billingsley and, quite rightly, dethrones me from the listings the way Google did!