Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Do Interviews Work? Expand / Collapse
Author
Message
Posted Wednesday, May 16, 2012 9:46 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:57 PM
Points: 33,206, Visits: 15,361
Comments posted to this topic are about the item Do Interviews Work?






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1301470
Posted Thursday, May 17, 2012 1:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, April 23, 2013 3:29 PM
Points: 73, Visits: 520
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)
Post #1301527
Posted Thursday, May 17, 2012 2:50 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, June 22, 2012 1:41 AM
Points: 39, Visits: 50
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
Post #1301563
Posted Thursday, May 17, 2012 6:55 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, July 22, 2014 7:14 AM
Points: 95, Visits: 68
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.
Post #1301717
Posted Thursday, May 17, 2012 6:59 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, August 29, 2014 12:12 PM
Points: 760, Visits: 2,199
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.
Post #1301723
Posted Thursday, May 17, 2012 7:10 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, August 22, 2014 8:42 AM
Points: 9, Visits: 129
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
Post #1301735
Posted Thursday, May 17, 2012 7:33 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, August 28, 2014 9:47 AM
Points: 371, Visits: 964
"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
Post #1301752
Posted Thursday, May 17, 2012 7:54 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
"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. ..."
Post #1301778
Posted Thursday, May 17, 2012 8:11 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, December 19, 2013 7:41 AM
Points: 118, Visits: 381
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
Post #1301792
Posted Thursday, May 17, 2012 8:22 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
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. ..."
Post #1301802
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse