My company, Trilogy Software, just recently hired our fifth employee. In the process of doing so, I made a few notes about how hiring your first few employees impact your workplace...
Hiring in the early days of any new company has a much greater impact than your future hires. The third employee, for instance, increases the staff level by 50%, and comprises 33% of the staff total until the fourth employee joins. Employee number three will have a significant impact on productivity and the mood of the office in those early days.
When we hire our "Customer Service Manager" at Trilogy Software, we will hire someone not only to "set the direction and policies" for Customer Service Department, but also to do Customer Service. It will be a one-person department, at least for a few months. That means we need to find someone that can manage a department of 5 or 10 people at some time in the future, and who is also willing to answer the phone, write email responses, process refunds and adjust invoices now.
The process of hiring is one that is difficult to codify. It requires a judgment call and "gut instincts". As a software engineer, just about everything else I do at work has a verifiably correct answer, and I can confirm that I'm right within a few minutes. My SQL query, my XAML layout and my C# formulas can all be tested and verified as correct or incorrect within a few minutes of completing my work. Hiring, unfortunately, is not that way. Our hiring team will make a judgment call, and we may not know if we've made the right choice for a few months.
To be sure to make the best judgment call and the most accurate "gut instinct" possible we follow these guidelines:
Prospects should be interviewed by at least two peers, and no more than two managers.
Ideally, interviews will be conducted by the hiring manager and a few members from the team where the prospect will be working. The composition of the interview team should roughly reflect the composition of the future employee's working day. Typically, an employee will be spent most of their time with their teammates, and a relatively small amount of time with their manager. The composition of the interview team should reflect that.
Interviewers should prepare their interview plan in advance, and ask questions that invite a story.
I've probably done a few hundred interviews by now, and I still spend at least fifteen minutes in advance of the interviews preparing some questions. The questions don't have to be exhaustive, and I can go off script when I need to, but I've always found it useful. I ask open-ended questions, ones that will allow the prospect to tell me a story. A good way to do this is to ask questions that start with the words "tell me about", or "tell me about a time" and then fill in the blanks:
"Tell me about a time when your work was criticised."
"Tell me about a time when you went above and beyond the call of duty to help a customer"
"Tell me about a time you missed a deadline"
Then, your applicants should describe a Situation or Task, what they did (the Action) and the Result of the action. (This is commonly called the STAR model of interviewing).
Don't *ever* ask questions like "What would you like to change about yourself?" or "What is your biggest weakness". I asked questions like this in my early days of interviewing and never once got a useful answer. In fact, I think 9 out of 10 applicants would say something like "I'm too much of a perfectionist", or "I sometimes work too hard". Whatever.
Basically, avoid questions that start with the word "What", because they invite your candidate to provide an unqualified list. For example the question, "What accounting software have you used?" will invite the applicant to list off all the software he or she has used. It will tell you nothing about how your applicant solves problems and get things done. By contrast, a question like "Tell me about a time when you were given a problem you didn't know how to solve in QuickBooks?" should give you some insight into the way your candidate thinks.
The "technical" portion of the interview doesn't necessarily need to follow this format, but I would caution interviewers against "trick" questions or questions about some obscure aspect of the tools you are using. In real life, your employees don't have to memorize these things because we have the Internet. In my GreenPoint days, we asked the trick question, "Why are manhole covers round?” which was allegedly common when applying at Microsoft. It always made for an interesting discussion, but I don't think we ever hired anyone based on his or her answer to this question. (The answer we were expecting was "So the cover can't fall through the hole", but there are some other good answers like "so they are easier to move.")
Sometimes I'll change the format for a few moments when faced with an overly nervous applicant. In this situation, a few questions about hobbies or other interests can help your prospect feel more comfortable so they can give better answers to the difficult questions.
Prospects should get a chance to ask questions.
Somewhere in middle of the interview, ask something like "Do you have any questions for me?". This will give you a bit of a break, and its another great way to learn more about your applicant. Don't leave this question until the end, when your candidate may feel rushed or tired. Ask it earlier, because it will provide insights into what motivates your applicant.
For instance, too many questions about the benefits plan or the salary may signal an applicant that's all about the money. Conversely, questions about your product plans or long term opportunities in the business show more interest in a long term relationship.
In the software business, questions like "Tell me about your agile process?" or "Tell me about your build system?" are a great signal that this applicant is interested in making a contribution, and not just collecting a paycheque. And if your candidate asks questions that start with "Tell me about", that's another sign that he or she can adopt well to new environments!