Recommendations for evaluating potential employees?

Question

I have the task to interview and hire a new web programmer for the company I work fo. Apart from the usual questions about previous employment and education, I've been using a SQL evaluation test to evaluate the candidate's technical abilities. For junior developers I ask them to code a simple CRUD page.

What do you use as a fast test to evaluate candidates? Do you have any advice for me? I think SQL is a good test because it implies a logical thinking to solve complex queries.

Other thoughts and opinions welcome.

Answer 1

I have had potential employers evaluate my skills using Brainbench

Answer 2

It depends what kind of programming they'll be doing: User Interface, Services, Database. It also depends at what skill level I expect them to be at.

The questions I would ask range vastly in complexity and functon.

One thing: Whatever programming question I ask them to whiteboard, I would never expect them to write compilable code on the whiteboard. Pseudo code (language independent) is perfectly fine for me.

Answer 3

Employee Grid is a great CRUD exercise and it's pretty common.

Given:

Employee Table Employee ID, Manager ID, Employee Name, Department ID

Department Table Department ID, Department Name

Write a page that can: 1) Insert, Update, Delete employees 2) Show all employees under a manager 3) Show the employee details 4) sort by all fields.

Optional: 5) Use asynchronous javascript to refresh the page during execution utilizing either MSAJAX, jQuery, or other technology.

EDIT: This single page covers:

1) Simple Crud functionality of a Grid display. SQL INSERT, UPDATE, and DELETE statements are required.

2) Joins are required for Department Name and a Self Join is required to get the manager's name for an employee.

3) AJAX knowledge is evaluated.

If any developer can execute this reasonably, -- an hour or so -- then they can perform most functions I require of them. This is easily done, doesn't have to be pretty and requires VERY little setup from you.

Answer 4

I find a question that I've found interesting enough to answer on my own separately, and I ask them that. It's interesting, because since it's a question I've found interesting, I'm (obviously) interested in it, and it's interesting to see other people's take on how to solve it. I've been very pleasantly surprised! One thing I avoid, though, is specific technologies; I want to see how they think, not necessarily how well they've memorized syntax.

Answer 5

Make sure you get a picture of the way the candidate thinks: how he approaches new problems, unexpected situations, and difficult bugs.

I helped in an interviewing process once, and we chose the guy that had done the most similar work. That ended up being a big mistake. We should have chosen the guy that was the most excited and interested in the work even though he had less experience.

There are lots of articles out there, some of them from the JoelOnSoftware blog.

Answer 6

Check out their rep on http://stackoverflow.com. That's where all the good coders hang.

Answer 7

As the interviewee, I can tell you what my favorite type of question to answer is during an interview. Maybe it will be of some help to you.

I love to talk about the side projects that I work on. I start by giving a general overview and from there I get into more specifics: what technologies I use, why I use them, what I learned from the entire process. I also go into some of the specific challenges I faced and how I overcame them.

I enjoy these types questions for a couple reasons:

1. I am explaining something I am passionate about and it shows through to the interviewer. This usually has the effect of the interview turning into more of a discussion than a traditional question/answer interview.
2. The interviewer gets to evaluate my communication skills. Communication is very important, more important than most of us would like to admit. We will be working with other people, so we have to communicate effectively not only through code, but verbally as well.

Answer 8

First step, go read Joel's guide to interviewing.

Secondly, I like to give candidates a single, simple method with specific inputs and outputs to write even before inviting them in. FizzBuzz or the equivalent is fine. Take a good look at how they write their loops, do they name variables reasonably, etc. In my experience, a very large number of applicants can't even write a single method or understand a method in isolation. Add in something with recursion and you'll learn an awful lot about how somebody thinks.

Personally, I really don't like things like simple CRUD pages. Most decent frameworks will do almost all of that for you automatically these days. And so it's hard to avoid evaluating things that really shouldn't matter (like the colors and graphics, for example).

Whether to look at specific technologies or not really depends on what position you're hiring for. If I really did need someone short-term who knew, say, .NET very well I wouldn't ask specific questions, rather I'd ask the candidate to elaborate at length on a generic topic such as, say, Garbage Collection or the WebForm life cycle. If you're hiring for long-term though, just ignore that stuff and get the smartest programmer you can. They'll learn whatever platform you need them to learn.

Answer 9

We ended up going for a three-stage process.

1, we sent them out a basic test. Originally, this was a 3-page address book (add, list, search). We eventually decided this involved too much boilerplate and switched it to a choice of a couple of programming contest questions. Much less boilerplate, more fun, faster and interesting to see how they approach the problem.

This was a interesting filter - it proved they could write basic code, but also provided a check for their CV. If they said they were passionate about TDD, for example, they'd better have provided tests with their solution.

2, we had a technical phone interview. We split this into three parts - they tell us about themselves, we ask technical questions, then we tell them about us. About 30 minutes all up. We ended up with a set of question from which we'd choose a subset ... examples include 'what's polymorphism', 'what excites you about software dev at present' and the perennial favourite - 'design a OO chicken'. We did have someone design a chicken that subclasses Carnivore, a terrifying prospect.

3, if we liked them and they liked us, we got them onsite. This was the point we asked the more in-depth questions, and tried to get a feel for them personally. We also planned to implement a pair-programming exercise at this point, but we were stuck with a hiring freeze before having a chance to try it out.

We did, however, get all the bits together to do it. And what we ended up with was a simple task - import an existing CSV file into an existing DB. We planned to offer them the internet, the DB connection details, the CSV file and Eclipse, and work with them to see how they approached the problem. It's relatively simple, but it offers a lot as to whether they code from scratch, look for libraries or find something even crazier to fill the gaps.

It all gave us pretty good results, although it filtered out a lot of people. No doubt, we missed some good people. But I'm pretty sure we also managed to skip a lot of rubbish candidates as well.

Answer 10

One thing our company got burnt on was assuming that someone who can throw a web page together (i.e. a "web developer") can think logically and write decent code behind it. For that reason we do logic programming tasks as others have suggested. If you're hiring a non-senior member of staff, simple questions like:

Write a fragment of code to write a triangle to the console out of asterisk. Eg./

n=5

*
**
***
****
*****

where the size N can be specified.

There are tonnes of these kind of questions that require incrementally more thought but can be achieved with relatively little time for someone that knows what they're doing. In reality a first year uni student should be able to do them, but from my experience you'd be surprised the number of grads that can't.

Answer 11

Three things to consider:

1) I found this recently: link text and use it to evaluate myself. It is very in-depth, so I doubt it would be a quick evaluation metric, but you could certainly use it after the interview is over to gauge overall knowledge across the numerable realms of programming knowledge.

2) ReadySquid mentioned asking what their side-projects are. I completely agree. When you discover what an interviewee is passionate about, he or she will usually open up and let loose a wealth of enthusiasm about the project. I feel this alone landed me my current internship. Especially when so many stack up comparitively on a technical side, passion is important.

3) Since coming across a few impossible questions, I cannot help but be fascinated by them. The one that sticks in my mind is: How many piano tuners are in Seattle? An interviewee that is quick to say "who cares?" or "I don't know" lacks the ability to think critically about an unfamiliar situation. Those that make wild but rational guesses as to piano's per 1000 residents, the efficiency of a piano tuner's schedules, etc, show promise. Have fun with this one. Always wanted to create that Northwest Passage? Ask your interviewee how they would create it!

Answer 12

Please stay away from any of the so-called, skill exams like Brainbench or Prove-IT, they are not only worthless, but may hinder your search to find the right candidate... Please read..

Brainbench, Prove-IT and others