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.
One trick I've had thrown at me in an interview was to be handed a very large chunk of the prospective employer's own code, and asked to explain what it did, and how to improve it. If you wanted to be totally fair, you could even give them access to all the facilities they'd usually have while working (like a syntax reference, and Internet access).
-
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.
1 - If the interview is in house, you can develop a partially working application and ask the candidate to finish implementing the application. This helps to see if he has layering notions, Database skills and coding experience. 2 - You can leave some bugs in the application so the candidate can debug and fix. 3 - Asks what he has already developed, how he did it, using which technologies... In the mean time, ask the problems encountered, pitfalls and the lessons learned. Regards, Fábio
-
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.
kryzchek wrote:
I've also considered giving a small test, but I'm not too sure how long or difficult I should make it. .. 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 been on both sides of that one. Use quiz questions to gauge depth of knowledge in specific areas that are used a lot in your code and to weed out posers. For example, if you use a lot of templates in your code, have them do something with them on a whiteboard: write somethihng from scratch, spot the flaw, or just explain what a piece of code is going to do. Expect to have to prompt some candidates until they figure out what you're after. Assess not only how well they do with the code, but how well they deal with the stress of performing on the spot like that, and how they go about getting an understanding of what you're asking for, etc. You're going to be giving them direction. Will they take a guess and charge off in the wrong direction? Do they need to be spoon fed every last detail before they can even think of getting started? Or will they ask some questions, get into the problem, then come back and ask more questions to refine what you want once they understand more?
kryzchek wrote:
I've asked for code samples
I've been asked for code samples in interviews before, but never asked a candidate for one. I'd have to study their code for too many hours to grasp what its doing, and how well its written. It would be a good way to gauge their style of coding and OO design, but I find quizzes like the above to be a better gauge given the time constraints of an interview.
patbob
-
I like that Joel article, but I also like this rebuttal about finding those who "get things smart."
-
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 once interviewed at (and was accepted) a place with an interesting technique. The development manager there felt that the usual technical tests really only measured if you’d read the manual recently. He felt that that was unimportant because when you were working you’d have access to the manual (and Google, etc). What he really wanted to know was how you think. So he posed a simple programming problem ... He started with a 30 second overview of prime numbers (in case you’d forgotten them from high school) and then, on a white board, asked you to write a function that, given ‘n’, would return the first n prime numbers. (Hard coding an array of prime numbers inside the function was not acceptable.) He explained that it didn’t matter if you didn’t get the syntax exactly right, just the overall logic. And he wanted you to explain your thinking as you worked. I watched him run this test on a number of other candidates since and it was surprising how many ‘gurus’ (who know the IDE inside out, know every control and their properties) are unable to complete this simple task! He had a similar task for testing database design skills (requiring designing a few tables). So in your position I would you could try this technique. And back it up with a few technical discussion points too ... I’d like to ask what the candidate understands of the Dispose method. Have they ever implemented IDisposable on one of their classes? And an important trick question: Do you ever need to call the Dispose method of a form? If so when and why, if not why not? (Get that wrong and their code will memory leak.) Too bad you are in the US (according to your profile), I’m a C# winform developer looking for work right now but in Canada. :sigh:
-
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'd suggest you think of terms of stages : the goal being to spend the minimum of your time and money at each stage of qualification. 0. identify absolute minimum set of core competencies you believe they'll need for getting productive in two months time. 1. evaluation (without face to face or phone contact) : the resume. No experience with any one of the absolute core competencies ? : next. 2. phone contact : ask probling questions related to core competencies, if they get vague : pin them down. Points for honesty if they say things like "I went to this level with SQL Server; I'm not familiar with the whatever you are describing to me now, but see no difficulty in learning the things you are describing to me." 3a. face-to-face : you and them : guts, instinct, vibes : is this person going to "fit" in this environment. note when I say "fit" that doesn't mean "get along like happy hobbits" : the best thing for a bunch of up-tight anal compulsive nit-picking slow-going coder types who are more interested in unit-testing than coding might be an off-the-wall visionary. your company might well benefit from the personality of someone who was very different than the rest of the people who work there ... or not. 4. put to the test. put the person in a nice room with Visual Studio fired up with some kind of program loaded that uses the core competencies you are looking for, and give the person one or two specific tasks, and just leave them alone for an hour, and then ask them to come in (with the entire programming team present) and describe what they've done and why. Did they change the UI ? Why ? Did they not change the UI ? Why ? Did they add a class, or an interface, or change some basic inheritance pattern : Why ? Watch how they react to questions from people they haven't met : you might get some clues as to how they will respond in "peer code review" sessions. 5. Assuming you've got a viable candidate : now's the time to send them round to meet each team member one-on-one. Then have a meeting : listen to the other employee's perceptions and analysis. 6. All of this followed by ... assuming you've got a viable candidate ... due diligence on your part to weed out psychopaths and liars, to confirm the resume and claimed experience : contact at least one reference ? best, Bill p.s. above all I hope you'll avoid the moronic questions HR types and recruiters are always trained to ask like "tell us about a time when you made a mistake in judgement" :)
"Many : not conversant
-
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 had to do this a few years ago at a previous job. I used a written test that covered various aspects of the technology we were supporting. We were also looking for someone with a lot of experience so the test was 2-3 pages. the test started off with some basic language commands (including a term that did not exist) Followed by some schema design (yes we did it all) and SQL. Then finally some short coding exercises. The language commands questions can be a good phone interview material to weed out potential face-to-face candidates. In may last three job interviews I was asked to solve some kind of logic problem: Parse roman numerals into an integer, reverse a string without using any high level commands, etc. This type of problem could replace code samples. Also, for may last job interview (where I am currently working) I brought a small sample of some code I wrote to extend the gridview control to drill down into nested properties of a class to display columns. It was short, one-page and highlighted some deeper technical skills. You might ask for something like this rather than a full body of work or application. The important thing is that you definitly need to do something because some recruiters will present anyone that they think will get them a commission.
-
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, 2001What I notice is that you have actually made two assumptions: 1) If one doesn't own a laptop they are not serious programmers. 2) That if they don't have a development environment on their laptop they are not serious programmers. I think both of the assumptions are fallacies. For one thing, I know at least one serious developer who always uses desktop computers. Also, while I currently have a laptop, I don't have it setup for development. I simply use my employer supplied laptop for that. (Even for my personal projects which are not numerous.) Actually, if I were asked to bring my laptop it would send up some major red flags (or perhaps flares). In fact, before showing up you would need to provide information on what equipment you intend to provide me to work on. Or alternatively what kind of compensation you provide for me to get my own. A better idea in my view would be to have a setup to allow for a coding challenge (on your equipment).
-
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.
So being able to enjoy a beer (or socialize after work) with a co-worker takes precedence over how they perform on the job? That seems like a strange metric on which to base a hiring decision. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
In all honesty yes. I didn't say I'd employ someone I could have a beer with, but was awful at his or her job, I just said I didn't want to work with someone who I couldn't have a beer with. It's a differentiator; the being good at your job is a given.
-
Oi, my normalisation skills were learned from a book; the seminal "Information and Data Modelling", buy one of the relational gurus.
Sure - I was being a bit rash. However, if you start bumbling on about normalisation and talking about the 4th normal form, I'm going to start to wonder why, and if it was book learnt, and not based on any experience. In all reality the 4th normal form is quite impractical from a business perspective (OK, not always), and if I'm hiring someone who's being that pure about their database design, they're probably not going to be able to balance the need to be technically accurate with the need to design things that can be built quickly, and do the job with the minimum amount of effort. BTW - like your idea about mixing the database and chess stuff up for senior DBAs.
-
Tell them to bring a laptop containing their development environment and a running application that they developed (including the source code), and tell them to be ready to explain the program's functionality, problems they encountered, and how they resolved any issues.
.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, 2001Not everyone owns a laptop with a developement environment on it. That should not disquaify them.