-4

How do you create a baseline standard across your team for how to conduct interviews?

We have done some research into the actual interview techniques (#, #, #, #, #). What I'm looking for is to see how others have inculcated these habits into the entire team, so that the recruiting process is consistent and effective.

Background: A big pain point of my IT team's interview process is that there are no standards. One developer may conduct a 30-minute informal interview, while another may do hour-long deep dives into their favorite technology. So far we've done okay because we have recruited through personal referrals... but we're now growing and interviewing unknown candidates a lot. Some bad apples were hired, that has led to introspection on our part. We don't want to stifle our developers' interview styles by "mandating" a standard set of questions, but we do want a consistent level of rigor and a consistent evaluation method.

|improve this question

closed as off-topic by Mark C. Wallace, Todd A. Jacobs♦, jmort253 Feb 15 '14 at 22:32

  • This question does not appear to be about the practice or profession of project management within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    "How do you create a baseline standard across your team for how to conduct interviews?" is a valid question. Polling for opinions on the subject is off-topic. Please edit the question to make it less of an opinion poll. – Todd A. Jacobs♦ Oct 19 '13 at 16:50
  • 1
    Besides, interviewing isn't always a PM practice. Maybe more on-topic @ workplace.SE? – Tiago Cardoso♦ Oct 19 '13 at 23:01
  • 2
    This question appears to be off-topic because it is about interviewing, not about project management; might be a better fit for Workplace:SE. "The Workplace Stack Exchange is a question and answer site about the workplace and other career-related topics. It is for members of the workforce to get answers on topics such as the job hunting process, interviewing, salary negotiation, and professionalism within the Workplace." – Mark C. Wallace Jan 15 '14 at 14:33
2

I've been on both sides of the desk, and find the interview process not terribly helpful. I've yet to be through an interview that tested much of my skill set, not that I would appreciate one that did. When interviewing, I try to ask questions that give me a quick understanding of the candidate's skill level. I consider the interview a chance to see if a candidate will fit in the organization.

It is only recently, I have seen any references to studies on the effectiveness of interview in hiring. The comments I have seen don't indicate interview are effective in finding good candidates.

Resumes help in determining if the candidate has the desired training and experience. Unfortunately, they can be misleading. In larger organizations or when dealing with recruiting organizations, it can be difficult to get the right resumes presented to match the job. Keyword matching can be a pretty poor indicator of the skill set, or even experience.

Think hard about what you want from your interview process. Then consider whether an interview is the best way meet your requirement. You may find that what an interview is best for is determining if this is someone you want to work with. Consider whether your receptionist can provide some input to this.

Document what you want from the interview process and provide that information to the interviewers. This may help your interviewers focus on those areas. From your question I gather that your interviewers likely don't have a lot of experience, and are unlikely to gain a lot.

Consider tracking rankings on various impressions, and comparing them to future success. You may also want to track which interviewers do the best job of selecting candidates. It will take time, but you may develop an interview process that works for your organization.

|improve this answer
3

First thing: in the past I've found interviews more useful than resumes. Old studies from IBM showed a factor 25 productivity difference between developers on the same project (uhh, yeah, that is 25...) The last 15 years I've been on the interview side and within the organisation I've worked for we have always used an interview combined with short assessments. I've found it amazing how many candidates do not know how to handle even show the simplest cases of their skills. For example, for database technology we use "write a non-join query" or for C# we use "Fibonacci function". For non-IT functions in my current company we do the same, like for finance: "Generate general ledger postings for correcting the intercompany ledgers."

To ensure making it an organizational habit, I recommend using a simple form with "STAR" (Situation Target Action Result) questions on past life and a few (2 or 3) standard questions for the vacancy being filled. The HR manager can request the form to have been filled out and returned before providing an offer.

|improve this answer
2

Interviews are very low in validity. There is some improvement with increasing structure but you need to understand that results are marginal at best. Your odds at a good hire are not much better than a coin toss.

Creating structure is easy. Standard questions, behavioral and scenario interviews, group interviews, easy research to uncover some ideas. Choose the path you want to go then train your interviewers.

Your issue will be to validate whether your new structure is worth anything and for that you need a ton of time with many hires measuring results over quite some time. Otherwise, you don't really know if you built anything of value.

|improve this answer
  • There may be no way around this; but we'd prefer not to go down the "standard questions" route because it becomes easy for recruiters to game the system. We want our process to have an element of unexpectedness for the candidate, while still testing a standard base of skills. – Vishal Bardoloi Oct 18 '13 at 19:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.