Next week i'll be interviewing some contractors for a 6-month senior Dev position on a project. I'm an OK programmer myself, but nothing special, and at the moment i'm struggling to think of what questions to ask them, or what coding challenges i'd set, since the answers would likely go over my head anyway.

The project is an ASP.NET MVC application for an intranet.

My personal thought was to have them write a trivial MVC app that pulls some data from a DB during the interview, showing that they can implement a testable, loosely coupled application, but i don't know if this is too trivial. From it i would expect them to have implemented a couple of tests, set up dependency injection, and probably use a repository instead of fat controllers.

Any ideas, or is what i'm suggesting a bad idea? The coding part of the interview would likely last about 40 minutes. I timed myself doing what i'd planned and it took me just over half an hour. The candidates would have seen the requirements for the application a couple of days prior to the interview.

From thinking about it a bit more, perhaps i should start off with a tightly coupled app, and ask the candidates to refactor it instead, and implement some tests?

Edit: With respect to Rob's comments below, i'd like the answers to more focus on what i'd got planned (But all answers gratefully received)

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

It's a good shout, though i'm asking for people's opinion on what i'd got planned as well.
–
MrBlizAug 4 '11 at 18:31

1

If that is the case you might want to edit the question to focus more on that then, as it is right now most people are likely to respond more along the lines of the question that is already in the system.
–
rjziiAug 4 '11 at 18:33

You'll be surprised at how many of those candidates are not up to your level let alone senior level.
–
HLGEMAug 4 '11 at 18:35

3 Answers
3

Start with the technical questions you think are important to the project based on your current knowledge of what the project entails. Start with stuff you understand and you will be amazed at how many people who are suposed to be senior to you don't understand basics.

Consider giving them some code set up to need refactoring as well as having a bug and ask them to find the bug and explain the problem and see if they also refactor without being asked. If they do refactor, ask them to explain why the refactoring was needed. If they don't naturally refactor the code, ask them if they see a better way to perform the task.

Give them some complex concept that you don't fully understand and have them explain it to you. See who explains it best and whether you feel you understand it better after they have answered. For any who did make you feel that you better understood the concept, look it up afterwards and see if what they told you was substantially correct.

Ask them about their accomplishments. You want people who delivered not just talk. Key phrase to watch out for is "I was responsible for" - you don't know what they were responsible for, and you want to know what things they actually did. People who didn't accomplish anything are far more likey to talk about respnsiblities than accomplishments.

Ask them what they know now that they didn't know two years ago. You want people who are learning more, not ones who have one year of experience repeated ten times.

As them to describe in their own words what they did in each job on their resume. As they go through their career, look for them having an expanded role over time(are they doing design or working with BAs on requirements or doing harder tasks than in earlier jobs, etc.). Look for them to talk about mentoring junior people or taking a leadership role of some sort. Seniors are more than developers. In a senior role they should be thinking about impact to the application and sending bad requirements back, they should be thinking about the overall design and not just the tiny piece they are working, they should be thinking about training up the next generation of developers, they should be thinking of the software development process and waht they would like to see improved in it, they should be thinking of meeting deadlines and budgets and enveloping LOEs for new projects.

Good point, i'll be working on the same project, and they'll likely be mentoring me and an another dev as well. Thanks
–
MrBlizAug 4 '11 at 18:25

1

And it will show that they are continuously learning new things i guess.
–
MrBlizAug 4 '11 at 18:26

@Doozer1979 Yep. I might update my answer with some suggestions about testing their specific MVC knowledge, but your idea to have them write something is the right starting point. Maybe set up a skeleton project with some failing and/or pending tests and see how the candidate gets from red to green.
–
David RuttkaAug 4 '11 at 18:28

My suggestion would be to explain to the situation. i.e. I would then ask them to talk to you about common mistakes made by more junior colleagues. Ask them to talk to you about best practices that your team need to incorporate. I'd possibly consider sitting beside them when he's coding and ask questions and see how they respond.