Interview tips
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
Wjousts wrote:
They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking.
First and foremost you have a management problem. :suss:
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
Paul Brower wrote:
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.
That's right. And a surprising number of interviews ask you to write code at the interview.:(
Kevin
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
Wjousts wrote:
They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking.
It sounds like you haven't done a lot of interviewing yet. :sigh: If my experience is anywhere close to typical after the first 20 or so phone screens you'll probably want the original guy back. I've had people tell me things like they stopped writing code since the wizards in visual interdev were so good. Just asking basic questions about jobs on their resume has been the best indicator for me on that part of the interview. Asking things like what aspects of their contribution to the project where they the most proud of. What were some of the difficult issues they had to overcome etc. The ones that you bring in. I'd definitely have them write some pseudocode on a whiteboard. Nothing too complicated, the most important thing is to get them to show you their thought process when they write code. Are they thinking about error conditions. Why they choose one approach over another. Ask them to re-write it with a different approach. That's worked best for me.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
I must not be good, but I get leery of interviewers that don't have me write code. The jobs that I've taken where they didn't have me put some pseudocode up on a whiteboard have turned out to be some bad places to work.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
Ask them to bring a project/program/util that they have written and ask them to wlak you through parts of the source code, from that you'll know if they can cut code or not.
.net is a box of never ending treasures, every day I get find another gem.
That's a pretty good idea... I have been struggling too about estimating a programmer's level. We've noticed a resume does tell you very very very little!
Wout
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
That's the only thing where they can't BS you, and I've seen it show huge differences between candidates that are resume-wise hard to tell apart. You need a few problems ready that you deeply understand and can be solved in 10..20 lines (he might race through a problem he already knows by heart, so you need at least a second one to throw at him). Does he: Make a plan? Rely on unconfirmed assumtions? communicate with you? Write solid code? Check for errors? Encourage him to talk about his thoughts, help him when he's stumped or makes a stupid mistake, be relaxed about abbreviations, typos and general "looks", but be tough about things that matter. Play devils advocate: think of all things that can go wrong (overflows, strange inputs, ...) and question/nudge him to see how many he finds. What would he do if he can't use CString class? The second most important thing is: set a minimum standard. Don't hire the best you can get just because you need one desparately. For a 1h interview, I'd say roughly 20 minutes warm up, asking the usual resume questions, poking for passion, discussing previous projects (can he explain the task of the software in terms you understand?), getting over the initial nervousness. 20 minutes "write code & discuss", and 20 minutes about the project he is to work on: what you require, what he expects, where are his deficiencies and how to catch up. If you have more time (I found that short of 90 minutes feels necessary), expand the first and the last part.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
One sneaky practice that's getting popular in India is to steal employees from other companies in the region. Usually this is done by offering a huge joining bonus and a substantial increase in salary. Of course you still need to validate that the candidate is the right one - but you have a higher chance of getting quality candidates when your pool is already filtered (the other company would have done all the interviewing and choosing for you, or if they themselves have stolen the candidate, then the original company would have). It might sound unethical, but it's part of corporate IT hiring :-)
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link -
That's the only thing where they can't BS you, and I've seen it show huge differences between candidates that are resume-wise hard to tell apart. You need a few problems ready that you deeply understand and can be solved in 10..20 lines (he might race through a problem he already knows by heart, so you need at least a second one to throw at him). Does he: Make a plan? Rely on unconfirmed assumtions? communicate with you? Write solid code? Check for errors? Encourage him to talk about his thoughts, help him when he's stumped or makes a stupid mistake, be relaxed about abbreviations, typos and general "looks", but be tough about things that matter. Play devils advocate: think of all things that can go wrong (overflows, strange inputs, ...) and question/nudge him to see how many he finds. What would he do if he can't use CString class? The second most important thing is: set a minimum standard. Don't hire the best you can get just because you need one desparately. For a 1h interview, I'd say roughly 20 minutes warm up, asking the usual resume questions, poking for passion, discussing previous projects (can he explain the task of the software in terms you understand?), getting over the initial nervousness. 20 minutes "write code & discuss", and 20 minutes about the project he is to work on: what you require, what he expects, where are his deficiencies and how to catch up. If you have more time (I found that short of 90 minutes feels necessary), expand the first and the last part.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistpeterchen wrote:
The second most important thing is: set a minimum standard. Don't hire the best you can get just because you need one desparately.
That's a really good point. So many questionable hires have been made just because of that.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
One sneaky practice that's getting popular in India is to steal employees from other companies in the region. Usually this is done by offering a huge joining bonus and a substantial increase in salary. Of course you still need to validate that the candidate is the right one - but you have a higher chance of getting quality candidates when your pool is already filtered (the other company would have done all the interviewing and choosing for you, or if they themselves have stolen the candidate, then the original company would have). It might sound unethical, but it's part of corporate IT hiring :-)
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkNow I just need to find one of those companies to steal me away with a huge signing bonus. Maybe I should move to India? Dustin
-
Now I just need to find one of those companies to steal me away with a huge signing bonus. Maybe I should move to India? Dustin
Dustin Henry wrote:
Now I just need to find one of those companies to steal me away with a huge signing bonus. Maybe I should move to India?
:-) Since you live in the US, that won't work, since the highest Indian salaries are still less than an entry-level US salary for the same job/position/experience-level. Maybe in 10 years though, the gap between Indian and US salaries will get small enough that people in the US could get decent jobs in India ( and in the bigger cities where they'd get a close-to-western environment to live in). [btw I know you were joking, my reply was hypothetical]
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link -
Dustin Henry wrote:
Now I just need to find one of those companies to steal me away with a huge signing bonus. Maybe I should move to India?
:-) Since you live in the US, that won't work, since the highest Indian salaries are still less than an entry-level US salary for the same job/position/experience-level. Maybe in 10 years though, the gap between Indian and US salaries will get small enough that people in the US could get decent jobs in India ( and in the bigger cities where they'd get a close-to-western environment to live in). [btw I know you were joking, my reply was hypothetical]
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkNishant Sivakumar wrote:
the highest Indian salaries are still less than an entry-level US salary
Maybe then I could just convince my employer to pay me an entry-level salary, or remove the shackles, either would be nice.:)
-
Wjousts wrote:
Anybody got any?
If the interviewer has a spectacularly large and grotesque growth on his face, try not to focus on it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001What about the chest? If they have spectacular growths on their chest, is there a polite way to gaze, without getting called out?
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
Wjousts wrote:
They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking.
First and foremost you have a management problem. :suss:
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
Paul Brower wrote:
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.
Today's WTF article is about absurd interview questions. http://worsethanfailure.com/Articles/Riddle-Me-An-Interview.aspx[^]
Farhan Noor Qureshi
-
Wjousts wrote:
They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking.
It sounds like you haven't done a lot of interviewing yet. :sigh: If my experience is anywhere close to typical after the first 20 or so phone screens you'll probably want the original guy back. I've had people tell me things like they stopped writing code since the wizards in visual interdev were so good. Just asking basic questions about jobs on their resume has been the best indicator for me on that part of the interview. Asking things like what aspects of their contribution to the project where they the most proud of. What were some of the difficult issues they had to overcome etc. The ones that you bring in. I'd definitely have them write some pseudocode on a whiteboard. Nothing too complicated, the most important thing is to get them to show you their thought process when they write code. Are they thinking about error conditions. Why they choose one approach over another. Ask them to re-write it with a different approach. That's worked best for me.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
Paul Brower wrote:
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.
Today's WTF article is about absurd interview questions. http://worsethanfailure.com/Articles/Riddle-Me-An-Interview.aspx[^]
Farhan Noor Qureshi
-
Wjousts wrote:
one interviewing a candidate
Here is a section for the employers might be of some help[^] Best
Omit Needless Words - Strunk, William, Jr.
Vista? Cryptography Next Generation (CNG) here