Is there a design method for this?

August 9, 2006 9:32 AM

I need to interview someone for a Senior software developer position - what would you look for and what would you avoid? What the hell do I ask them?
posted by oh pollo! to computers & internet (17 comments total)

Are you technical or not? I'd ask them some tough questions about the language you'll be using, what Design Patterns they've used in their work and why, and ask them to comment on some actual design questions you've encountered on the project they'd be joining, to see how they reason. and what books they've read; I'd want to hear Stroustrup, Coolien, GOF, Knuth, Numerical Recipes, or whatever books are important for the project's language.
posted by orthogonality at 9:38 AM on August 9, 2006

Er, Coplien. Of course, that advice applies if you are also technical. If you're not, frankly it'd be hard for you to judge technical qualifications. I'd get a technical team member to do it, while you interview for intangibles/attitude/whatever.
posted by orthogonality at 9:47 AM on August 9, 2006

Ask them to design "the perfect house".

If they start by drawing a rectangle, they're out.

Actually, if they start by drawing anything, they're out. Although it's fun to let them doodle for a while before telling them, "oh, i forgot to mention: the house is for a family of 13 flying giraffes."

The only correct response is for them to start asking questions: who the house is for, what are their needs, what is their budget, etc. The idea is for you to be satisfied that they approach design by considering all the requirements, rather than just diving in with whatever ideal they have in their head.

This won't necessarily help you find who you SHOULD hire, but it's a very quick and useful test for who you SHOULD NOT hire.
posted by el-gregorio at 9:49 AM on August 9, 2006

Joel On Hiring. I haven't read it for a while, so apologies if I repeat some of what Joel says.

What does the job entail. Is this going to be a mainly technical job or is it going to be more people/management orientated. Is it Analysis or is it Programming. All these require completely different skillsets.

If it's a programming job though - you HAVE TO GET THEM TO WRITE SOME CODE. Give it them to work on over a weekend. There's nothing you can learn from a 20 minute lesson. (Well, you can learn if they're really bad, but that's about it.)

Look for enthusiasm and a lack of buzzwords. I don't know any programmers who use buzzwords unless they have to. You'll need to differentiate between buzzwords and actual technical words so get another programmer in with you.

If they say XML more than six times you must not hire them.

Ask them what the differences are between C++ & Ruby and Fortran and Lisp? A good answer here shows someone who's interested in the craft.

Ask them an impossible question. Programmers are more likely to say "I don't know" than people from other professions.
posted by seanyboy at 9:55 AM on August 9, 2006

I notice that so far I'm the only person who passed el-gregorio's test. Yay me.
posted by seanyboy at 9:57 AM on August 9, 2006

seanyboy writes "I notice that so far I'm the only person who passed el-gregorio's test. Yay me."


Maybe we did too, but didn't feel the need to comment about it. ;)
posted by orthogonality at 10:01 AM on August 9, 2006

What will they be expected to do? If they'll be writing device drivers you'll need to ask them different things than if they'll just be writing CGI scripts.
posted by cmonkey at 10:02 AM on August 9, 2006

"I notice that so far I'm the only person who passed el-gregorio's test. Yay me."

You already failed the Metafilter thread comprehension test. You're........... not hired.
posted by Big Fat Tycoon at 10:04 AM on August 9, 2006

I've been interviewed many times. Although a discussion of patterns is good, don't discount 'I don't know' as an acceptable answer. I'm not a CS major. I studied molecular biology and came over because the pay is nice. I don't know all the jargon, but I feel that I have better design ideas than some 'trained' developers because of my experience. Don't get me wrong understanding design patterns is very good, I've started studying them and asking the developers on my team to do it as well.

Also, nitpicky questions like 'what's the maximum size of int?' are just stupid. I don't know. If I needed to know, I could look it up.

I trust a developer who says they don't know but can do some research and try to come up with a solution more than someone who lets me know they don't know by fumbling at an answer or trying to smoke screen me with technical nonsense.

What I look for in a developer to work with is someone who cares about what they do. For example, do they attend java user group meetings (I'm a java programmer). Are they in contact with their past coworkers (to exchange ideas)? What was the worst team they worked on? What was the best team? What did they do to try to help turn the worst team around? What were their suggestions for making the best team better? Some developers, with or without skills, rely on management to make things better. In my experience that doesn't work. You need a proactive development team to make the team and the product better.

You could hire a pHD developer who knows everything, but works in an office alone and develops ivory tower solutions to everything, or a developer who knows they don't know everything but uses open source code, tries to learn and get the team to exchange ideas/experiences. I would pick the latter because the team is going to come out with better skill sets, more energy twords their work and they trust each other more.
posted by kookywon at 10:33 AM on August 9, 2006

My short answer: Look for communication, common sense, and a curiousity and passion for software. Communication (verbal and written) is extremely important when hiring programmers, and often overlooked. Another experienced programmer can evaluate their "software common sense" just by chatting with them. And a passion for learning and programming will make up for any gaps in technical knowledge.

I also recommend reading Steve Yegge. Yegge is a very good writer who has programmed at Amazon, Google, etc. He writes about interviewing and the myriad ways companies screw it up:

The Truth About Interviewing
Five Essential Phone Screen Questions
What You Need to Know
His main page, with many many more essays
posted by rsanheim at 10:54 AM on August 9, 2006

A senior developer is going to be doing some project management; that's a completely different skillset from coding. They're also likely going to be your systems/design analyst; check out thewhynotgirl's thread from last week on that topic.

And listen for Fred Brooks' Mythical Man-Month -- or go read it.
posted by baylink at 11:44 AM on August 9, 2006

You may need a filter to weed out the no-hopers. I'd suggest getting together a programming test for whatever language you mainly use. Doesn't have to be super hard, but it should show their comprehension of idiosyncracies in the language.

If you've not done that before it may be hard to judge where the pass mark should be, but it will prevent you from wasting time interviewing people in depth who know nothing about development.

Apart from that, think carefully before you start interviewing about what competencies you're looking for other than coding. Analysis? Project management? Client interaction? Team leading?

As far as questions go: ask them about when they've had to use %skill. Let them talk, then drill down for more detail. If still in doubt about their skill, drill down again.
posted by crocomancer at 12:36 PM on August 9, 2006

Here are some things I would recommend:

- 'Senior' connotes leadership. Many programmers are not good with people, and so you will have to determine if your potential hire is good with people, quite apart from any technical expertise (s)he may have. Don't ask those silly questions like "How would you respond to a co-worker stealing your pencil?" type questions, but do ask questions about previous leadership experience, how they've dealt with difficult subordinates and what their general approach to managing people is.
- Ask them what Java and XML are good for. The correct answer is "nothing". Don't hold it against them if they have a little Java experience on their resume though, even the best of us hit hard times every now and then.
- Ask them what the worst/best parts about (language) are. Have someone technical review these answers. They will reveal a lot about their proficiency (for example, a total beginner will have gripes that reflect their lack of understanding of the language; whereas someone who really knows their stuff will have a different set of better-founded gripes)
- Ask them a question they couldn't possibly know the answer to and note their response. It can tell you if they are going to be full of bluster and BS or if their egos will permit them to honestly tell you "I don't know". Being able to say "I don't know" is one of the most important skills for anyone to have, I think. Bonus marks if they start telling you how they would go about finding the information they'd need to give you an intelligent response.

I was recently in the market for hiring someone like this too, so I've given it a bit of thought.
posted by kfx at 1:12 PM on August 9, 2006

Ask them what Java and XML are good for. The correct answer is "nothing"

Yeah, that's fantastic advice for weeding out canidates. Maybe we should stick to answers instead of opinions. Given the poster didn't mention whether or not the position requires them to say, use Hibernate or Struts, I think you might want to avoid such specifics.
posted by yerfatma at 3:28 PM on August 9, 2006

The all-purpose answer to "how should I interview someone?" is "get them to tell stories about stuff they've done".

That is, if you just ask them technical questions with yes or no answers, or right and wrong answers, then you're not getting the full picture.

You're supposed to ask them things like "tell us about a time when [problem with relevant language occurred] and how you got around it" and "tell us about a time when you were working to a strict deadline and [some issue caused delays]" and so on.

That way you get to see their personality and how they handle situations and problem-solving, not just "do they know the right answer to X".
posted by AmbroseChapel at 5:39 PM on August 9, 2006

Also, nitpicky questions like 'what's the maximum size of int?' are just stupid. I don't know. If I needed to know, I could look it up. —kookywon

If they're supposed to be a seasoned programmer and don't know basic stuff like this, I'd advise against hiring. It's like asking a would-be writer what letter comes after J; if they tell you they don't know but they could look it up, something's wrong...
posted by iconjack at 6:36 PM on August 9, 2006

yerfatma: I was just kidding, I just had to leave a job because my boss pulled the old switcharoo and said "Instead of programming giagantic saw-wielding robots, you will be working on web technology using Java", so I'm a little bitter.
posted by kfx at 7:15 PM on August 9, 2006