We’ve launched a big campaign today to expand the Guardian Unlimited technical team even further — software, systems, project management, and more. You can see the online ad at http://www.guardian.co.uk/joinus. I won’t tell you that the reason you should seriously think about joining us that GU is packed full of friendly, intelligent and dedicated people. But I will tell you one small thing about how I’ll be conducting those of the interviews that I’ll be in.
The GU software team is a little different to many others. Like most teams our developers spend a lot of time understanding requirements, sketching out solutions, implementing, bug fixing, and so on. But unlike many teams our developers don’t spend any time at all surveying petrol stations, weighing pills, or being held in weird prisons run by pathological prison governors.
I’m sure that news will surprise a lot of people, because I know a vast number of developers are very focused daily on the old petrol station/pharmacy/solitary confinement side of software. And I know this because these are the questions they get asked in interviews.
I once attended an interview for a role where I was asked the pill-weighing question, set out on techinterview.org, for example:
[…] the queen gives the assassin 12 pills which are all completely identical in shape, smell, texture, size, except 1 pill has a different weight. the queen gives the man a balance and tells him that all the pills are deadly poison except for the pill of a different weight. the assassin can make three weighings and then must swallow the pill of his choice. if he lives, he will be sent back to the bad king’s kingdom. if he dies, well, thats what you get for being an assassin.
only one pill is not poison and it is the pill which has a different weight. the assassin does not know if it weighs more or less than the other pills. how can he save his skin?
I was able to answer the question only because I’d read it the previous month. Fortunately they decided to change the job spec and withdrew the role, and I was spared a working life of having to deal with royal assassins. Or brainteasers. I hope no-one’s going to tell me this wasn’t what the job was about, though. After all, what else could the interviewer have been trying to learn about me?
I’ve also met someone who likes to ask potential candidates “how many petrol stations are there in London?” I was keen to know why he asked this, since I was pretty sure he didn’t work in a company that audited petrol stations. “I want to know if they’re a good problem-solver,” he replied.
Here’s my tip for testing problem-solving skills: make the problem as realistic as you can.
Interviewing is a difficult and artificial thing. I’m sure I’m not the world’s best interviewer, but I do know that honesty and transparency are important, because without that you and the candidate can’t make the right assessment of each other. So when it comes to creating scenarios you’ll find out an awful lot more if you make the scenario as close as possible to what really happens in the job.
If you think your team members spend important time solving problems it’s a good idea to take a moment to consider some situations where that skill was important. And if you can’t think of any, then maybe problem-solving isn’t such an important skill after all.
Here are some problems I can think of right now that we’ve faced recently:
- A really important person in the business wants something done really quickly, but they’re so important they don’t have time to explain it properly to you.
- We need to get a particular data feed into a particular system. What are our options? And which should we choose?
- A particular piece of code keeps throwing up far too many bugs than is reasonable. Why might that be? And what should we do about it?
- We need to change a bit of code, but it was build 5 years ago by someone who’s no longer here. Where do you start?
- We want to add a new feature somewhere, and although it seems like a naturally intuitive extension it’s actually disproportionately difficult to do — what’s gone wrong there?
No pills, no prisoners, no petrol stations, no foxes crossing rivers with geese. There are issues with using these situations, of course. We’d need to make a bit of an effort to work them into something that’s solvable in the confines of an interview situation. And I don’t get to show off some kind of pseudo-cleverness in front of the candidate. But I’d say both the interviewer and the candidate get much more out of the ensuing discussion. Because it does involve a discussion, not a simple one-way answer; we don’t force people to solve problems in isolation.
And one more thing about life here at GU. We do an awful lot of Java programming, so it’s not usually terribly useful for us to test someone’s use of pointers, either.
But if you do want to use pointers — or weigh pills — then it seems there are plenty of other opportunities for you.
2 thoughts on “Interview tips for that tricky developer-pharmacist role”
i’m reminded of this: http://www.codeslate.com/2007/01/you-dont-bury-survivors.html
Comments are closed.