Interviewing / candidate qualifying tips
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
I was in the same boat you are, a year ago. What I found as reasonable is to walk them through a problem, not a hard one, but an unusual one, and watch how they look at it. I generally look at: -- the quality of the questions they ask how quick they catch on to new ideas I feed them how well they generalize from answers I give them -- But figure out a couple of questions before hand, and be prepared to spend time with it, I have not had an interview with a reasonable candidate in the last year that lasted less than 75-90 minutes. The problem I present (which was used on me) is this: You are given a 2.4 GHz machine with 32 bit XP, 2 GB ram and roughly 400GB free disk space. The US phone system generates more than 2^30 calls a day, so you have a stream of call records coming at you, roughly 10-20k records / second. The records have the 10 digit phone numbers for the source and the sink of the call, as well as start time and duration. You are a carrier, you have a list of subscribers, and you want to go build a list of 'friends and family' of the people on your list. How would you solve it? -------- Some times people will just say 'put the number of interest in a hashtable and for each record, check to see if it contains the from and to numbers' This is a good way from a maintenance standpoint, assuming the string hash is fast enough. But this does you no good since you can't watch them solve it. The point is not that they have to know all this stuff, but to see if they are capable of learning, and if they care to. The less they know about this, the more info the questions can give you. -------- Hints/things to look at -- Is 2 GB ram enough to build an in memory array of bit bools for each possible phone number? DB queries probably won't be fast enough, but how would you check? Can you use the structure of the phone number to help you? Array[1000] of bools indexed by area code, would it help? Do they think they can get away with a single prefix array? Do they think they have to have 1000 prefix arrays? How will they get from the area code array to prefix array? Maybe area code array is not bool after all? Would array of objects/null work instead? If they see how to do that, can they generalize it to prefix to suffix? Than walk them through to the hashtable solution. Are they having 'AHA!' moments, or couldn't they care less about solving the problem and learning? A priori knowledge is good, but not what I try to look for, capabily to handle novel problems is.
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
Do you really have to go through the recruiters? I bet you could ask around and find someone who is looking for job *and* is recommended by someone you trust.
-
The other suggestions are good... You do want to see a sample of their code, if possible... But that only tests how well they can program in THAT LANGUAGE, not how well they program in general... I'm no expert in this (And I'm dreading the day when I'll be put in your shoes), but I'd care less about their actual code and more about their general knowledge... I like the old "What's the difference" questions, like: - What's the difference between a quick sort and a bubble sort? - Between a class and a structure? - Between passing parameters by reference or by value? - Between an array and a list? - Between an interface and an abstract class? I think anyone who can answer those, and sound like they actually understand the subject matter (As opposed to just quoting books), would probably be at least somewhat competent. One I've always wanted to throw in... "What runs faster? C# or VB.NET, and why?"
Proud to have finally moved to the A-Ark. Which one are you in? Author of Guardians of Xen (Sci-Fi/Fantasy novel)
Ian Shlasko wrote:
at least somewhat competent
Even students can answer those questions, but I haven't met one of them who knew what
x&(x-1)is useful for - in fact most of them didn't even know what "that funny &" does. They can't actually program, they just write code. (but there are exceptions to that rule, as always) -
That may or may not be feasible simply because: 1. They may not own a laptop 2. Their development work may belong to their previous employer, so it's proprietary, private or not even in their personal possession (say that 3 times, fast). Although that does bring up a good point: I've asked ones who couldn't provide me with a code sample due to either #1 or #2 above to give me a sample of a personal project they worked on in their free time. To me, when they still *can't* provide a code sample--because they don't do any development in their free time--it tells me that they're not too serious about developing their skills. I may have 75,000 un-finished projects that I've started in my spare time, but at least there's something to be said for taking it upon myself to learn some new things and get some practice.
kryzchek wrote:
They may not own a laptop
They're not serious about being a programmer. Don't hire them.
kryzchek wrote:
Their development work may belong to their previous employer, so it's proprietary, private or not even in their personal possession (say that 3 times, fast).
Not a valid assumption. I have a laptop, and I have a development environment on it that includes all of my tools and whatever source code *of mine* I might be working on. That's what I meant by "development environment". Providing a code sample without being able to show that it actually works and that I know what it does is a waste of everyone's time. I took my laptop to every job interview with several of my codeproject articles ready to demonstrate, as well as some of the web sites I've built. Nobody wanted to see them, but I was ready if they did.
.45 ACP - because shooting twice is just silly
-----
"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." - J. Jystad, 2001 -
Do you really have to go through the recruiters? I bet you could ask around and find someone who is looking for job *and* is recommended by someone you trust.
We tried last year to find and hire a person on our own, with no success. We already have this recruiter on retainer for some other head-hunting, so my boss is adamant that we use him to find the developer as well. In my area there is a surprising lack of developers based on the current demand.
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
I am also conduction a bunch of interviews in January. I am setting up a development environment at my work with the code, the source control and internet access. The candidate will be invited for 4 hours of interview and will get a office (like the rest of the employees). He will be free to go to the refrigerator and get drinks or go to the coffee machine and have coffee. This will also give me an idea of how well he meets and greets existing employees. I will give him 3 problems and about 3 hours to work on them. 1. Coding to spec. A spec will be handed to him and the candidate has to develop an application per the given spec. 2. Fixing an issue in existing code base. I will give the candidate an issue and he has the resolve it. This will give me an idea of his problem solving skills. 3. Coding in ambiguity. A simple problem statement will be given to him and the candidate will have to implement in the technology of his choice. The problem statement will be generic and the candidate will be free to ask questions (via IM, emails, Phone). This is where I have found most programmers to fail. His level of skills can be ascertained by the way he solves/approaches the 3 problems. A junior level programmer can do task 1 without any problems but will have problems with 2 and 3. A mid-level programmer will have problems with 3 but will be able to do 1 and 2. A senior programmer should be able to do 1, 2 and 3. Of course, in the entire process the candidate will have to interact with me. Also, both I and the candidate will be able to ascertain how well he can fit in the company. He will see the actual codebase and work with real people.
-
If they don't have a laptop a CD/USB drive can serve as a code transport device.
3x12=36 2x12=24 1x12=12 0x12=18
-
kryzchek wrote:
They may not own a laptop
They're not serious about being a programmer. Don't hire them.
kryzchek wrote:
Their development work may belong to their previous employer, so it's proprietary, private or not even in their personal possession (say that 3 times, fast).
Not a valid assumption. I have a laptop, and I have a development environment on it that includes all of my tools and whatever source code *of mine* I might be working on. That's what I meant by "development environment". Providing a code sample without being able to show that it actually works and that I know what it does is a waste of everyone's time. I took my laptop to every job interview with several of my codeproject articles ready to demonstrate, as well as some of the web sites I've built. Nobody wanted to see them, but I was ready if they did.
.45 ACP - because shooting twice is just silly
-----
"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." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
They're not serious about being a programmer. Don't hire them.
It's unlikely that I would have a laptop if I did not get the company to pay for it for remote debugging purposes. And I would definitly call my self a serious programmer. I have churned out somewhere between 500K to 750K new C++ (mostly MFC but now Qt) lines in the past 12.5 years..
John
-
kryzchek wrote:
They may not own a laptop
They're not serious about being a programmer. Don't hire them.
kryzchek wrote:
Their development work may belong to their previous employer, so it's proprietary, private or not even in their personal possession (say that 3 times, fast).
Not a valid assumption. I have a laptop, and I have a development environment on it that includes all of my tools and whatever source code *of mine* I might be working on. That's what I meant by "development environment". Providing a code sample without being able to show that it actually works and that I know what it does is a waste of everyone's time. I took my laptop to every job interview with several of my codeproject articles ready to demonstrate, as well as some of the web sites I've built. Nobody wanted to see them, but I was ready if they did.
.45 ACP - because shooting twice is just silly
-----
"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." - J. Jystad, 2001 -
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
All the head hunters who've contacted me have passed along a link to an online skills assessment that the employer has requested. They're awful, but fairly painless. You should probably do that.
-
We tried last year to find and hire a person on our own, with no success. We already have this recruiter on retainer for some other head-hunting, so my boss is adamant that we use him to find the developer as well. In my area there is a surprising lack of developers based on the current demand.
kryzchek wrote:
In my area there is a surprising lack of developers based on the current demand.
Interesting. Anyway, this is unfortunate. The only certain way to hire a good employee is to find a former co-worker that you know is good and is looking for job. Finding a good developer by interviewing random people is pretty much a matter of luck: all you can do is filter candidates based on their technical skills.
-
My company has decided that after 4 years of me doing 100% of the IT work, we need another developer. This person will work directly under my supervision and be tasked with maintaining a C# distributed WinForms app as well as some ASP.NET work. We've hired a headhunter to pre-qualify candidates and set up phone & in-person interviews. And this is the point where my inexperience with hiring really comes to light. I'm getting a little better at the face-to-face and phone interviews, but I'm still not sure how to qualify a person skill-wise. It seems like right now all I'm doing is saying things like "Do you know C#? Have you use SQL Server?" And naturally the candidate tells me that yes, they have. Can anyone give me some tips on how to gauge just HOW experienced or skilled someone might be in the areas that I require? I've asked for code samples, but some candidates can't provide that as it is most likely property of their previous employer. And I'm not sure that 1 class file will really give me a good reference point as to their skill level when taken out of the context of a project as a whole. I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. Suggestions or comments from those that have experience with hiring and interviewing would be most appreciated at this point.
We tend to start off with a logic test (it's a programming test, but it's not specific to a language). We then move on to ask some fairly specific OO, .NET and SQL questions, to which there generally is a specific answer. We then move onto some questions asking them to talk through solving a problem. We use designing a chess game from an OO point of view, and designing a database schema for a car rental company, and simply keep asking more probing questions about their answer until we feel we've guided them to a good solution. If they don't seem to get it, drop it. You'll know if they seem to know what they're talking about. For instance people who can design database will get what you want from them straight away. People who are book-learnt will waffle about normalisation, but never really get there. We decided we'd rather hire someone who's very logical than someone who can quote MSDN. For us, there's been a direct correlation between book learners and poor scores on logic tests. The last guy we hired simply admitted he didn't know the answers to a few of the more tricky questions, rocked the logic test, and within 2 months was writing some fantastic code; he made a real contribution. He also had a social life outside work that wasn't programming. The others who could quote MSDN just wanted to program when they got home. I don't want to work with people who don't have other things to talk about when you're having a beer after work.
-
We tend to start off with a logic test (it's a programming test, but it's not specific to a language). We then move on to ask some fairly specific OO, .NET and SQL questions, to which there generally is a specific answer. We then move onto some questions asking them to talk through solving a problem. We use designing a chess game from an OO point of view, and designing a database schema for a car rental company, and simply keep asking more probing questions about their answer until we feel we've guided them to a good solution. If they don't seem to get it, drop it. You'll know if they seem to know what they're talking about. For instance people who can design database will get what you want from them straight away. People who are book-learnt will waffle about normalisation, but never really get there. We decided we'd rather hire someone who's very logical than someone who can quote MSDN. For us, there's been a direct correlation between book learners and poor scores on logic tests. The last guy we hired simply admitted he didn't know the answers to a few of the more tricky questions, rocked the logic test, and within 2 months was writing some fantastic code; he made a real contribution. He also had a social life outside work that wasn't programming. The others who could quote MSDN just wanted to program when they got home. I don't want to work with people who don't have other things to talk about when you're having a beer after work.
mincefish wrote:
I don't want to work with people who don't have other things to talk about when you're having a beer after work.
I would love to hire those people in a startup company. Those are the people who are passionate about programming and can lead a startup companies to big success. However, if you have a lifetstyle company these people will not fit well.
-
Ian Shlasko wrote:
at least somewhat competent
Even students can answer those questions, but I haven't met one of them who knew what
x&(x-1)is useful for - in fact most of them didn't even know what "that funny &" does. They can't actually program, they just write code. (but there are exceptions to that rule, as always)You know, I consider myself a pretty decent programmer, and I'd never heard of that trick until now. That's why I judge people on ideas instead of specifics... Someone who knows the concepts may not know that particular trick, but would pretty quickly be able to figure out that it could be used to test for powers of two (Unless there's another use I didn't notice). Nice trick, by the way... Limited usefulness for what I generally write, but still nice.
Proud to have finally moved to the A-Ark. Which one are you in? Author of Guardians of Xen (Sci-Fi/Fantasy novel)
-
Pair programming is a good way to identify the capabilities. Give him a problem and ask him to code it in a specified time. Sit with him and work with him by discussing various methods to solve the problem. Allow him to come up with alternative solutions. This will help you to identify 1 - Ability to code in a reasonable time and ability to follow good coding standards. 2 - How he is coming up with solutions and how good are they. 3 - How good is he in taking suggestions and implementing it. 4 - Communication
Best wishes, Navaneeth
N a v a n e e t h wrote:
Pair programming is a good way to identify the capabilities.
Yes, Now that you have qualified a Thoughtworks interview you will say that. If you did not make it, I wonder you will have the same opinion. But I think I agree with you.
-
-
djj55 wrote:
we hired a guy who talked a good talk but did not program well. (He also missed the first day of work).
If I was in charge he would have missed the second, third etc. Not coming in on a first day is a sure way to get fired!
------------------------------------ No Good Deed Goes Unpunished Clare Boothe Luce
They let him slide but by the end of his first 90 days they fired him.
-
Ian Shlasko wrote:
at least somewhat competent
Even students can answer those questions, but I haven't met one of them who knew what
x&(x-1)is useful for - in fact most of them didn't even know what "that funny &" does. They can't actually program, they just write code. (but there are exceptions to that rule, as always) -
I am also conduction a bunch of interviews in January. I am setting up a development environment at my work with the code, the source control and internet access. The candidate will be invited for 4 hours of interview and will get a office (like the rest of the employees). He will be free to go to the refrigerator and get drinks or go to the coffee machine and have coffee. This will also give me an idea of how well he meets and greets existing employees. I will give him 3 problems and about 3 hours to work on them. 1. Coding to spec. A spec will be handed to him and the candidate has to develop an application per the given spec. 2. Fixing an issue in existing code base. I will give the candidate an issue and he has the resolve it. This will give me an idea of his problem solving skills. 3. Coding in ambiguity. A simple problem statement will be given to him and the candidate will have to implement in the technology of his choice. The problem statement will be generic and the candidate will be free to ask questions (via IM, emails, Phone). This is where I have found most programmers to fail. His level of skills can be ascertained by the way he solves/approaches the 3 problems. A junior level programmer can do task 1 without any problems but will have problems with 2 and 3. A mid-level programmer will have problems with 3 but will be able to do 1 and 2. A senior programmer should be able to do 1, 2 and 3. Of course, in the entire process the candidate will have to interact with me. Also, both I and the candidate will be able to ascertain how well he can fit in the company. He will see the actual codebase and work with real people.
Rama Krishna Vavilala wrote:
A junior level programmer can do task 1 without any problems but will have problems with 2 and 3.
In some ways a 'better' junior programmer who was always able to write his assignments perfectly the first time would have more trouble with 2 than someone who had more difficulty and spent a lot of his student time digging through stuff with the debugger to figure out what his stupid mistakes were. I blew through what was supposed to've been a 2 month pile of bug fix/enhancements in only one on my first job because I was intimately aware of how to use a visual studio debugger to poke around in the guts of stuff.
3x12=36 2x12=24 1x12=12 0x12=18
-
Rama Krishna Vavilala wrote:
A junior level programmer can do task 1 without any problems but will have problems with 2 and 3.
In some ways a 'better' junior programmer who was always able to write his assignments perfectly the first time would have more trouble with 2 than someone who had more difficulty and spent a lot of his student time digging through stuff with the debugger to figure out what his stupid mistakes were. I blew through what was supposed to've been a 2 month pile of bug fix/enhancements in only one on my first job because I was intimately aware of how to use a visual studio debugger to poke around in the guts of stuff.
3x12=36 2x12=24 1x12=12 0x12=18
I agree. But I am talking about more real life bugs or issues for which some experience in working in live environments will be required: code which will work fine on development environment but breaks in test environments. The candidate may have to use Google search combined with ability to navigate through huge code base to solve those issues.