Our HR (Human Resources) dept. is training us to use behavioral interviewing techniques, in which we focus on asking candidates for software engineering positions how they handled different situations in their past positions. However, they have also banned us from doing anything that seems like a "test", such as asking candidates to read code, write code, or answer direct technical questions. I have never heard of such a policy, and the reasons for it seem vague.

Is this a standard policy that other companies are using?

  • Hey JMB, and welcome to the Workplace! Questions here should be practical, answerable questions based on actual problems that you face. It sounds like the problem is you don't understand HR's motivation, which is most easily solved by asking them directly. Even if we can explain their motivation, it won't help you solve the issue (that you have difficulty evaluating candidates without skill-testing), so perhaps you should ask, "How can I evaluate candidates without skill testing?" to get better answers? – jmac Sep 11 '13 at 7:09
  • I have edited your question so that invites less opinion and more facts. – user8036 Sep 11 '13 at 7:13
  • 4
    The obvious thing to do would be to talk to HR, no? – AakashM Sep 11 '13 at 8:33
  • 2
    My guess is that HR is trying to apply a standard interviewing technique across a number of unrelated disciplines. – DJClayworth Sep 11 '13 at 17:17
  • 1
    My concern is that we have a policy that might harm our ability to both select good candidates, and to recruit them (some software developers have turned down jobs because they weren't technically interviewed). I think what we're doing is in opposition to industry standards, and my Google searches have come up with no examples of a similar policy. However, if there were other examples I might change my mind and be more accepting of the situation. To date: no similar examples have been found. – JMB Sep 11 '13 at 23:03

Has anyone else ever heard of such a policy? Can you explain the reasoning behind such a policy?

I don't really understand how screening candidates on the most objective and job-related criteria possible could increase the risk of lawsuits.

I have never heard of such a policy. In fact, virtually every place I have ever worked had some form of "test" during every interview.

I can't explain the exact reason your HR has such a policy - for that you need to ask them. I'm sure they have a reason behind it, although it may not be a reason with which you agree.

If I had to guess, they are worried that your "testing" isn't applied equally to all candidates, and/or might be biased toward one group over another, increasing the risk of a discrimination lawsuit. This is something that is hard to realize when you are doing it. You might think your "tests" are objective, but HR might think that are not. HR might be trying to avoid a problem, and perhaps going overboard.

Your HR rep might advise you that asking for coding examples would be appropriate if and only if that coding is specifically the kind used in the job at hand. Or, HR might be just trying to avoid coding tests that aren't relevant to the job.

One of HR's roles is to avoid lawsuits resulting from interviews. If you are in the US, I'm sure during your training, you were told not to ask people if they were married, how old they are, or anything that might lead to a discrimination suit. That's HR's influence.

In our litigious society, it's difficult to interview and avoid "risky" questions, but it's important to try hard. The fact that you are actually being trained on how to conduct interviews is a factor that could be used in your defense of a lawsuit.

Try to see this from HR's point of view, and ask them about the thinking behind their suggestions.

| improve this answer | |

The following is admittedly speculative:

I have had a whole string of job interviews where people would ask me things like what is 'boxing/unboxing' or what is a singleton? I would routinely miss those questions, generally resulting in being viewed as unqualified. In short, people would grill me on arcana regarding some language feature I never used, therefore 'I must not be a programmer - all programmers that use this language know this stuff'.

Perhaps people are waking up to the fact that these technically specific lines of questioning result in a lot of qualified people being turned away. Fear of lawsuits doesn't seem to be an issue - I tried tracking this down and couldn't find any evidence of it. What is far more likely is that HR gets a few dozen resumes, finds out none of them are making through the interview filters, and at some point it occurs to someone that the interview emphasis is improperly focused. It's really hard to explain why out of 20 candidates that have 10+ experience in databases and web development, none qualify to work for you. This gets worse if the people that do make it through the filters aren't producing.

If one imagines a chocolate cake, the topmost layer should be focused on the large projects: if someone worked on a CRM system the questions should focus on the problems this person solved in the CRM development effort. Some of these are on the chunks of code the interviewee wrote, others are how the team divided the tasks, and how well that worked out.

The middle layer of the cake should be focused on unusual situations - my particular favorites are cases where I had to convert Pascal (6 byte) or MBF floating point to IEEE double precision using C or C#. These might be projects or simply 'fires' - someone pitched something in from left field - how did you deal with it?

The bottom layer has to do with 'when things went horribly wrong' - deadlines were missed, people quit in the middle, one was handed a can of worms and had to cope with it as best as possible. In short, what happens when the going gets tough?

Often questioning along these lines exposes categorical deficiencies, issues big enough to disqualify a candidate. Candidates that start talking about data services and configuration settings and manifests might not be experienced with stuff you use, but it shouldn't take long to piece together the big picture.

| improve this answer | |
  • 5
    I agree that the type of technical questions you mention are not ideal because they are purely knowledge based, and spot checking a few knowledge items doesn't correlate well with total knowledge. However, since the job is skill based (you have to read and write a specific programming language every day, as clearly indicated in the job description), having candidates read or write small code samples in that language is highly relevant, and every qualified candidate should be able to do this without trouble. – JMB Sep 11 '13 at 15:16
  • 1
    @JMB - I have no fear of coding tests, whether I fail them or not. Therefore I am in many respects sympathetic. However, practically every job I've had since 2009 (when I went independent) has been with people that could not evaluate my technical credentials. They simply took my word for it. Had I not been qualified they would have pulled the plug pretty quickly. The fact that I was kept around for a year or two suggests they had 'guessed right', based on gut feel or specific details that meshed with their judgment. – Meredith Poor Sep 12 '13 at 8:47
  • "Why would HR ban it?" is a bad question, it invites speculation and isn't too relevant. "Is it a good interview practice to ban it?" is the real question. Also, not enough information supplied: you say "the interview", but you don't say how many separate people will interview the candidate; are they peers or managers; how many will be behavioral interviews vs coding tests vs both. – smci Mar 5 '17 at 10:23
  • @MeredithPoor, thanks again! I always suspected that because I didn't know one or two answers. For example, one time I did not know what multi-tenancy was, I know was turned down as a result. – Daniel Nov 15 '17 at 12:33

Not the answer you're looking for? Browse other questions tagged .