Do Interviews Work?

  • Comments posted to this topic are about the item Do Interviews Work?

  • Great article Steve - as usual - and good timing too, as there is a fair amount of discussion taking place on different approaches currently, including a mixture of the two articles you posted....

    http://blogs.hbr.org/schrage/2012/05/projects-are-the-new-job-inter.html

    From my experience, starting someone as a freelance contractor makes far more sense to me.

    The number of times I have been hired on a short term contract (say 2 weeks) to do one thing, and then keep getting hired to do other things, is a far better corporate resourcing strategy - especially for fixed term project purposes - and taking into account Australian fulltime employment legislated requirements, checks & balances, etc.

    It's far more efficient to get someone in quickly, initially on a short term contract, then take the relationship from there - and if it doesn't work out, it's also far easier to let them go (since a contract has an end date already) and I'm sure this may be the case in other countries too.

    --Chris Hamam

    Life's a beach, then you DIE (Do It Eternally)

  • My preference is for a question and answer format coupled with a simple coding test in preference to a couple of hours spent solving coding tests

  • Steve, your article is well written and makes the important points. I haved hired a lot of peope during my career in IT, and have found a fairly basic and dependable process that rarely results in a bad hire. There are three legs on the "hiring stool", and without those three legs the candidate should not be brought on board.

    1, Avoid personality problems. Does the candidate have the personality to mesh with, and work well with, the current team members? Having the hiring manager and one or two team members participate in the interview should allow you to quickly determine this.

    2. Basic smarts. Does the candidate have the necessary brain power for the job? One tool is your own judgement during the interview, based on questions ranging from, when to ask for permission and direction and when to steam ahead on your own, to, how would you handle situation X? The second tool I have successfully used is a generic (not programming language specific) logic test. If they did well on that and the first set of questions they were asked, they have always met my needs in the brain power category.

    3. Knowledge. The last leg of the stool is based on your requirements for the job. Here you look at not how smart they are, but what knowlege and experience they have acquired. Do they have the basic knowledge needed? I use existing team members and/or other strong technical people to do a "tech" interview. Using a standard set of questions, which focus on the key areas of technical knowledge needed, you can get a very good read on a candidate's true level of technical knowledge. This portion of the interview can range from programming language skills to project management concepts, including soup to nuts project path steps, such as design methods, coding style, unit/system testing approach, and interaction with QA and end-users/business analysts.

    The above steps are used only for the small selection of candidates having made the initial cut based on reviews of resumes. There is one other item that can be a significant part of the decision making process. A recommendation from an existing experienced and trusted employee, based on their knowledge gleaned from having worked with the candidate in the past. This is invaluable because they can relate that knowledge of the candidate to the current team dynamics, the knowledge of the type of person the hiring manager prefers, and the requirements of the job opening.

  • Chris Hamam (5/17/2012)


    From my experience, starting someone as a freelance contractor makes far more sense to me.

    That's how I was hired most recently, only they called me a temp employee. I worked four months as a temp then they they hired me as a permanent employee.

    The only problem I had with the process was that I wasn't eligible for company insurance during that period.



    The opinions expressed herein are strictly personal and do not necessarily reflect the views or policies of my employer.

  • At my last job, I suggested that we try testing when we decided to hire a third programmer. We had gotten a lot of resumes and were having problems weeding them out--I suggested to do a programming test. It was really simple--my solution was 9 lines of code--basic Windows Form and inserting a record into an Access database. I gave the connection string, etc. as part of the test. I was appalled at how many people couldn't get it implemented. My boss asked if it was passable and I informed him that I cranked out my solution in less than 15 minutes. As a former computer science instructor, when writing tests, the guideline that my professors had given me as a TA was to write a test, take it and based on how long it took me to complete it, multiply that by 3 (maybe 4?) and that would be the time students would need so I thought that at most, people who said that they had skill set we were looking for should have been able to easily implement it within an hour (I also factor job interview nervousness:-)

    We had one programmer knock it out and she turned out to be a pretty decent programmer.

    Having said that, I really wish we would have done something similar at my current job when interviewing for the person who was to be my backup--in retrospect because after hiring a particular individual, it became obvious that he didn't have as much programmer experience as what he made his resume to look and the way he talked it up during his interview--he had spent like 6 years at his previous place doing networking and programming but it was a case of transferring into programming during the last 2 years of his time there. If I had given him a test, he wouldn't have been able to pass it but in an interview, he talked like he knew what he was doing.

    My lessons learned: for jobs like that (combined network and programming work), ask how many years were spent being a programmer. Also, referring to the "rebuttal" article--I need to pay more attention to the lessons learned stories that a true senior programmer will talk about. If there's none mentioned, that's going to be a huge red flag for me from here on out.

    Love these articles--they get people to thinking and talking:-)

  • "It depends on some good senior people in your own organization, and their willingness to assess the candidates without involving themselves in a competition of sorts with the interviewee"

    Never let them know you are better than them until after you get the job.

    Cheers

  • "Choose the best person for the job" is a mantra that so many people espouse, but we never have a repeatable, logical method for determining who the best person is, in any industry."

    It is not that black and white, excuse my pun. When your company comes under hiring quotas, then this becomes a little tougher to do. I have always tried to choose the best and most qualified person for the job in the past, but when we must have a certain amount of minorities and women represented in the department and that is being dictated by HR, then this becomes a lot more difficult to do. I am not saying that the most qualified or best person can't fit into that category, all I am saying is the primary emphasis for many companies is not always on the best qualified person. It is on other criteria for many other reasons that have nothing to do with that managers specific needs. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • jfogel (5/17/2012)


    "It depends on some good senior people in your own organization, and their willingness to assess the candidates without involving themselves in a competition of sorts with the interviewee"

    Never let them know you are better than them until after you get the job.

    Au contraire, if I interviewed someone better than me I would hire them on the spot.

    It's not about ego, we can *all* learn from someone else. Then again I am confident enough in my value to the organization and that they know my value to do so. I can totally see how some narrow minded people who care more about their own promotion potential than the success of their company would fear those who are better than themselves.

    --
    Anye Mercy
    "Service Unavailable is not an Error" -- John, ENOM support
    "You keep using that word. I do not think it means what you think it means." -- Inigo Montoya in "Princess Bride"
    "Civilization exists by geologic consent, subject to change without notice." -- Will Durant

  • jfogel (5/17/2012)


    "It depends on some good senior people in your own organization, and their willingness to assess the candidates without involving themselves in a competition of sorts with the interviewee"

    Never let them know you are better than them until after you get the job.

    What I think Steve was saying in that point you quoted above was as an interviewer our job is to accurately assess the persons ability to do the job, not "stump" the person with extremely difficult, ambiguous, and vague questions just to satisfy the interviewer's own egotistical need to display that they know more than the candidate does.The interview is NOT about the interviewer. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • I know that

    Cheers

  • TravisDBA (5/17/2012)


    jfogel (5/17/2012)


    "It depends on some good senior people in your own organization, and their willingness to assess the candidates without involving themselves in a competition of sorts with the interviewee"

    Never let them know you are better than them until after you get the job.

    What I think Steve was saying in that point you quoted above was as an interviewer our job is to accurately assess the persons ability to do the job, not "stump" the person with extremely difficult, ambiguous, and vague questions just to satisfy the interviewer's own egotistical need to display that they know more than the candidate does.The interview is NOT about the interviewer. 😀

    IMO it is a two-way street, and I have seen and done it from both sides. When I am interviewed, I am also assessing my prospective boss and co-workers and ask myself, do I want to work with them for the next year or possibly longer? And I am ready to say No.

  • Exactly, and I have turned down jobs and terminated the interview right there where my interviewer(s) revealed themselves (not literally) right in the interview. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • I think it is important to discover in the interview what kind of work the applicant enjoys doing. Especially if you are not in a position to supervise them closely. I learned the hard way that you can hire someone very strong technically and it turns out they have no interest in doing what they were hired to do. You end up spending too much of your own time just making sure they are doing their job. Distrust becomes an issue in the relationship and you both end up looking for ways to move on.

    I ask people to describe their favorite projects and what they liked about them while paying close attention to their body language to see what gets them excited and enthusiastic. I will take individuals with less experience but much enthusiasm over someone who can contribute from day one but prefers to spend their time finding things to do other than what is in their job description.

  • I ask people to describe their favorite projects and what they liked about them while paying close attention to their body language to see what gets them excited and enthusiastic. I will take individuals with less experience but much enthusiasm over someone who can contribute from day one but prefers to spend their time finding things to do other than what is in their job description.

    That is a "double-edged' sword IMHO. Less experienced people can get your production database(s) screwed up rather easily if they don't know what they are doing, irregardless of their magnetic personaility. On the other hand, more experienced people will take care of your business/databases quite well, but can be "personality pills' to deal with on a daily basis. Personally, if it came down to ensuring that my "multi-million" dollar databases are online and taken care of on a daily basis, I tend to come down on the side of experience every time. I don't need, or want "rookies and/or cowboys" experiementing with the "life blood" of my enterprise. Period. I can deal with the attitude that tends to come with an experienced DBA. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

Viewing 15 posts - 1 through 15 (of 29 total)

You must be logged in to reply to this topic. Login to reply