Discussion on:
View:
Show:
But, how do you handle reducing the stress specific to being interviewed? None of my development projects have had stress similar to that. It's good to see that you work with the candidates in such a situation to see if they can get past the stress.
Thanks for the compliment. I'm not sure I totally understand your question, but I'll give it a shot. I think you are referring to the fact that the mere act of interviewing is stressful. That's true, to some extent. But real life product development is probably more stressful, when the deadline is looming and everything isn't quite fully baked.
Part of being a good manager is making sure that your people succeed. It's similar for interviewing. The interviewer shouldn't "attack" or beharsh with the candidate -- the goal isn't reject everyone. Rather, it's to set up a situation where you can get a good sense of how someone works and how they will react when the technical pressure hits. Some folks do really well and some don't.I've worked at places where I interviewed using this technique and other development managers used the more classic approach. The most successful folks were the ones I hired -- the others tended to be more mediocre contributors.
Cheers -- jeffrey kay
Part of being a good manager is making sure that your people succeed. It's similar for interviewing. The interviewer shouldn't "attack" or beharsh with the candidate -- the goal isn't reject everyone. Rather, it's to set up a situation where you can get a good sense of how someone works and how they will react when the technical pressure hits. Some folks do really well and some don't.I've worked at places where I interviewed using this technique and other development managers used the more classic approach. The most successful folks were the ones I hired -- the others tended to be more mediocre contributors.
Cheers -- jeffrey kay
You got pretty close to understanding my question/point. People can perform quite well under some types of stress and not others. On a closer look at your article, I could see where you helped the interviewees past the "interview-type" of stress to see how they deal with "development preasure-type" of stress.
I personally think that although with normal interview methods you may end up with people who you really didn't want, with testing methods like the one talked about here you will also miss good people - perhaps VERY good people.
If you want someone who can throw together quick hacks to beat a deadline, by all means use this method. If you want someone who takes the time to think through a problem and come up with innovative ways to do things, you may be discarding them with this approach.
There are many brilliant people who can't come up with an answer to a problem in 2 seconds, but when they do come up with an answer it will be a very good and well thought out answer.
There is no perfect interview technique, and this one is no exception.
If you want someone who can throw together quick hacks to beat a deadline, by all means use this method. If you want someone who takes the time to think through a problem and come up with innovative ways to do things, you may be discarding them with this approach.
There are many brilliant people who can't come up with an answer to a problem in 2 seconds, but when they do come up with an answer it will be a very good and well thought out answer.
There is no perfect interview technique, and this one is no exception.
I would agree but disagree with AsSeenOnTV.
I understand the point about not being able to come up with a solution in 2 seconds - I prefer to cogitate myself - but I would like to see how someone asks questions. If they listen to you, go off for a month and come back with a grand answer, then it may be the right answer, but to a different question!
Even if they do not have answers, it is a good way to see what stock 'components' they have in their mental toolkit and how they go about deciding what to use, and willing, as the design evolves with new information, to discard components/constructs (some people try to bend the world around original assumptions instead of letting go)
Though your point is valid - a narrow minded interviewer who cannot see the skilled designer risks being left with slick and slippery on-the-fly hackers who will impliment their first idea to death.
I understand the point about not being able to come up with a solution in 2 seconds - I prefer to cogitate myself - but I would like to see how someone asks questions. If they listen to you, go off for a month and come back with a grand answer, then it may be the right answer, but to a different question!
Even if they do not have answers, it is a good way to see what stock 'components' they have in their mental toolkit and how they go about deciding what to use, and willing, as the design evolves with new information, to discard components/constructs (some people try to bend the world around original assumptions instead of letting go)
Though your point is valid - a narrow minded interviewer who cannot see the skilled designer risks being left with slick and slippery on-the-fly hackers who will impliment their first idea to death.
Maybe the article didn't state this clearly enough, but I believe the philosophy is exactly what Tim C. described -- you're not looking to see if the person necessarily gets the answer exactly right or complete, but rather the thought process they go through to solve the problem.
In my experience with this interviewing technique, you'll find that the people who are either completely unwilling to attempt to solve the problem (at which point the interview ends) will not be able to deal with ahigh-pressure work environment. People who at least make an attempt to solve the problem, using the right ideas but the wrong application of those ideas, have a chance of learning and surviving. It's not about what you know -- it's about your ability to learn. Also, people who are willing to work through the problem out loud in the interview might be the kind that will come to you with questions when they are unable to do their work; this is far better than the ones who will continue to beat their heads senselessly and won't ask for help.
As for the comment about hackers, those are easily identified in an interview like this. They're the ones who miss the boundary conditions, and continue to maintain that they're "done" with their solution even when you suggest that they're not.
In my experience with this interviewing technique, you'll find that the people who are either completely unwilling to attempt to solve the problem (at which point the interview ends) will not be able to deal with ahigh-pressure work environment. People who at least make an attempt to solve the problem, using the right ideas but the wrong application of those ideas, have a chance of learning and surviving. It's not about what you know -- it's about your ability to learn. Also, people who are willing to work through the problem out loud in the interview might be the kind that will come to you with questions when they are unable to do their work; this is far better than the ones who will continue to beat their heads senselessly and won't ask for help.
As for the comment about hackers, those are easily identified in an interview like this. They're the ones who miss the boundary conditions, and continue to maintain that they're "done" with their solution even when you suggest that they're not.
I believe that the hiring decision is very critical, so I tend to allocate a fair amount of time to it. The candidates that get hired are actually in the interview process for more than 3 hours -- usually four to six hours. I often set up the interview to start at 9 or 10, so that a candidate having success will get lunch for his or her troubles (which is also a 1 hour interview slot).
You could probably infer from this that I really don't like the situation where I have to relieve someone of their job because I made a bad hiring decision. Not every new hire is going to work out, but this gives me the best shot at finding the best people. If the person doesn't work out, at least I feel like I've done appropriate due diligence.
Cheers -- jeffrey kay
You could probably infer from this that I really don't like the situation where I have to relieve someone of their job because I made a bad hiring decision. Not every new hire is going to work out, but this gives me the best shot at finding the best people. If the person doesn't work out, at least I feel like I've done appropriate due diligence.
Cheers -- jeffrey kay
This approach is pretty much exactly the same as I have used, with the same results for years. The caveat I add is, that in the UK we use a higher % of contract staff, to whom I apply a very rigorous interview, primarily to establish a) they have the skills, b) they can take the pressure of the job ... with permanent staff one is looking also for longer term potential, particularly when dealing with junior staff, so one must often be prepared to take longer and be more patient under these circumtances.
I completely agree with the approach you describe. The one thing I would add is to use written interviews as part of the screening. I typically give a candidate 3 technical questions a day or two before their interview, and ask for written responses.
The questions, and length of expected answers vary. For a leadership role, I expect longer answers. For developer, one paragraph is usually about right.
The point is to discover: 1) whether the candidate can understand a written question,including discerning subleties and subtexts; 2) how good their written communications skills are; 3) whether or not they are serious enough about the job to put careful effort into their answers.
I've gotten everything from essay quality answers to unpunctuated crap, including a bit of rank plagiarism, in response.
The questions, and length of expected answers vary. For a leadership role, I expect longer answers. For developer, one paragraph is usually about right.
The point is to discover: 1) whether the candidate can understand a written question,including discerning subleties and subtexts; 2) how good their written communications skills are; 3) whether or not they are serious enough about the job to put careful effort into their answers.
I've gotten everything from essay quality answers to unpunctuated crap, including a bit of rank plagiarism, in response.
I have been thru numerous interviews and every once in a while I find some pompous a** who thinks they have "the" interview method. Usually it involves some "great" question and a whiteboard. I always play along, and answer the lame question (like Ineed a whiteboard and three hours to explain memory allocation or debug a swap macro).
I always end these interviews in one of two ways. One, I bring the interviewer to tears by asking questions about his upbringing. People who feel the need to conduct interviews in this manner usually have deep seeded mental problems and feelings of inferiority. Very easy to make this personality type cry. The second way I end these inteviews, usually when I am in a good mood, is to
go thru the process and get the job offer. Then tell the a** where to go. I would probably decide to make this guy ball like a baby.
Have a nice day genius.
I always end these interviews in one of two ways. One, I bring the interviewer to tears by asking questions about his upbringing. People who feel the need to conduct interviews in this manner usually have deep seeded mental problems and feelings of inferiority. Very easy to make this personality type cry. The second way I end these inteviews, usually when I am in a good mood, is to
go thru the process and get the job offer. Then tell the a** where to go. I would probably decide to make this guy ball like a baby.
Have a nice day genius.
I once worked with a very talented guy that claimed he walked out of any interview that 'quizzed' him on his skills in this manner. The company we were working at didn't have that sort of interview. I wonder if he realized that most of the people weworked with were idiots that fudged their resumes? Personally, I'd rather work with intellectual equals than people that are constantly asking me to double check their code or who are producing sub-par work.
You know, it's exactly this kind of ignorance and stupidity that makes me glad the market crashed for software engineers. People who think that they are somehow *entitled* to a job, rather than feeling that they must prove their worth and skills, really should find a job flipping burgers instead. There is absolutely nothing wrong with testing a candidate in an interview -- in fact, places that *don't* have a test make me nervous, because it could potentially indicate the quality of the employees who work there, and the level of difficulty of the work.
If you're going to be working in a high-stress, competitive, and challenging environment, the interview method suggested by Jeff Kay is exactly the kind of testing one should do to weed out the people who won't make it past the first month. If your job environment is less stressful, it's still important to test the candidate, but maybe with simpler tests. Tests that require recitation of function names or acronym definitions just don't work. Not testing at all is a recipe for disaster.
If you're going to be working in a high-stress, competitive, and challenging environment, the interview method suggested by Jeff Kay is exactly the kind of testing one should do to weed out the people who won't make it past the first month. If your job environment is less stressful, it's still important to test the candidate, but maybe with simpler tests. Tests that require recitation of function names or acronym definitions just don't work. Not testing at all is a recipe for disaster.
Did you get paid for this article? If so, did you keep the money? And if you did keep the money, how do you sleep at night? It isn't to late to return the money or at least donate it to charity or something. Think about it.
The whiteboard is an essential tool, IMHO, and agree with much that was said.
Some comments on stress: having snap discussions and rapid-fix/enhancement sessions, or the need to explain design to a senior Architect or Team Leader is very much like an interview - in fact it may be more stressful as the normal etiquette is dispensed with when butts are on the line!
There is also the need to cope with brainstorming sessions where there is public exposure to 'solution in progress' and thus egos have to be left at the door.
Even 'simple coding' questions should be pitched. Regrettably, most developers cease to learn new algorithms, refine those they have or, indeed, remember all those they were taught and HATE people seeing their often'vowel retentive' code (any link there, perhaps?). I am proud of all code I have written and will show it to all mad enough to ask.
You can read up and recite technology, but good design mentality, openness and ASKING QUESTIONS is the key. All myteam have been taught that the only bad question is one that was never asked.
Some comments on stress: having snap discussions and rapid-fix/enhancement sessions, or the need to explain design to a senior Architect or Team Leader is very much like an interview - in fact it may be more stressful as the normal etiquette is dispensed with when butts are on the line!
There is also the need to cope with brainstorming sessions where there is public exposure to 'solution in progress' and thus egos have to be left at the door.
Even 'simple coding' questions should be pitched. Regrettably, most developers cease to learn new algorithms, refine those they have or, indeed, remember all those they were taught and HATE people seeing their often'vowel retentive' code (any link there, perhaps?). I am proud of all code I have written and will show it to all mad enough to ask.
You can read up and recite technology, but good design mentality, openness and ASKING QUESTIONS is the key. All myteam have been taught that the only bad question is one that was never asked.
Onto the test, the stress test. An excellent idea. It should be apparent and obvious how competent we are, but how well do you fit into this mold is often the larger question. And there's always training, since everyone's everything is always different, so your total competency isn't always the most relevant.
Two questions we liked was asking about a system call that one should be familiar with (we were a VAX/VMS shop), with 12 parameters, which no one should remember. We'd ask them to list the 12 parameters. Again, how do they handle such an impossible question. Our favorite answer was one person who turned in his chair and pointed to the correct manual -- "I'd probably look there." He had won the interview at that point.
We also liked asking if beer should be in cans or bottles, and if bottles, brown or green glass. (clear is definitely a wrong answer).
Again, its reaction and humor that's being poked.
Doug Parsons
Two questions we liked was asking about a system call that one should be familiar with (we were a VAX/VMS shop), with 12 parameters, which no one should remember. We'd ask them to list the 12 parameters. Again, how do they handle such an impossible question. Our favorite answer was one person who turned in his chair and pointed to the correct manual -- "I'd probably look there." He had won the interview at that point.
We also liked asking if beer should be in cans or bottles, and if bottles, brown or green glass. (clear is definitely a wrong answer).
Again, its reaction and humor that's being poked.
Doug Parsons
My earlier post is missing.
I, long ago, read an article how we just hire professionals, without testing them, and it suggested testing was good. My dept. ran with the idea and over the next few days, developed a test. One member of our group thought this was insulting. We, prior to this, had considered his hiring (not by us) a mistake. When we were satisfied with the test, we went around I.T., asking people how they would react to taking such a test. All the people we thought were top shelf liked the idea and would have been glad to take the test. The people who were well-brand objected. And the more strenuously and loudly they objected, the more they confirmed our opinion of their programming prowess.
So, you might not even have to subject interviewees to a test -- just asking if they'd mind taking a test might tell you all you need to know !
Doug Parsons
I, long ago, read an article how we just hire professionals, without testing them, and it suggested testing was good. My dept. ran with the idea and over the next few days, developed a test. One member of our group thought this was insulting. We, prior to this, had considered his hiring (not by us) a mistake. When we were satisfied with the test, we went around I.T., asking people how they would react to taking such a test. All the people we thought were top shelf liked the idea and would have been glad to take the test. The people who were well-brand objected. And the more strenuously and loudly they objected, the more they confirmed our opinion of their programming prowess.
So, you might not even have to subject interviewees to a test -- just asking if they'd mind taking a test might tell you all you need to know !
Doug Parsons
I wholeheartedly concur with the majority of this article. Using a techincal test in the interview has helped me weed out several "less than qualified" candidates.
But, I can't imagine insisting on a FOUR TO SIX HOUR interview. This might work for unemployed candidates (with lots of time on their hands), but a candidate with a job can't be taking 6 hours off frequently. Back when I was looking for a job, I was interviewing several times a week. If someone would've asked me to block out 6 hours for the interview, I would've been forced to do it before work (starting the interview at ... 2am?) or after work (finishing the interview at ... midnight?).
But, I can't imagine insisting on a FOUR TO SIX HOUR interview. This might work for unemployed candidates (with lots of time on their hands), but a candidate with a job can't be taking 6 hours off frequently. Back when I was looking for a job, I was interviewing several times a week. If someone would've asked me to block out 6 hours for the interview, I would've been forced to do it before work (starting the interview at ... 2am?) or after work (finishing the interview at ... midnight?).
The company I currently work for uses a two-step interview process for both consultants and GIS/DBMS developers. First, the hiring supervisor will have a screening interview by phone or in person of app. 1 hour. This is to review the resume, get afeel for real relevance of experience to our work, and otherwise decide if this person is worth pursuing.
Success in this interview will lead to an invitation to an on-site series of interviews, which collectively will take 4 - 6 hours. Lunch is(of course) part of the interview process. Meetings are app. 1 hour each and will be with the supervisor, one or more project managers, and one or more technical staff (and possibly VP or above) -- tailored to individual skill set and anticipated duties.
We use more problem-solving and management oriented scenarios in lieu of the coding tests described. I like questions like the "beer container", which have no single correct answer but let the interviewee show how they work through a problem and how they present their answer.
The lengthy interview & mix of one-on-one and panel formats gives a good idea of how the person will work in front of clients. It also gives them a variety of opportunities to impress -- since some folk do better in one venue than another.
Success in this interview will lead to an invitation to an on-site series of interviews, which collectively will take 4 - 6 hours. Lunch is(of course) part of the interview process. Meetings are app. 1 hour each and will be with the supervisor, one or more project managers, and one or more technical staff (and possibly VP or above) -- tailored to individual skill set and anticipated duties.
We use more problem-solving and management oriented scenarios in lieu of the coding tests described. I like questions like the "beer container", which have no single correct answer but let the interviewee show how they work through a problem and how they present their answer.
The lengthy interview & mix of one-on-one and panel formats gives a good idea of how the person will work in front of clients. It also gives them a variety of opportunities to impress -- since some folk do better in one venue than another.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
