Interviewing / candidate qualifying tips
-
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.
I do not own a laptop because I just cannot work on such a crammed keyboard and monitor (No, not even for a short while. Thanks for asking. I've managed for so long without it). I think that it's a personal preference. There may also be those programmers who are serious, but don't have the money to buy a laptop. All those laptops that I've ever purchased and used were given to me by my employer. But I pester them continuously and give it back to them. Emails will be checked on the phone while on travel.
“Follow your bliss.” – Joseph Campbell
-
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.
Oi, my normalisation skills were learned from a book; the seminal "Information and Data Modelling", buy one of the relational gurus.
-
I agree with Rama. For me, it's more important that I discern how well the candidate will fit into the development framework rather than how well they answer abstract programming questions. Of course competency is important - but I don't want a programmer who is going to go "rouge" when given an assignment. Just my opinion.
Don Burton wrote:
Of course competency is important - but I don't want a programmer who is going to go "rouge" when given an assignment.
Better not hire me! ;) BTW, I totally agree with you. And actually, my standing policy at this point is that I don't do phone interviews. If that means I don't get the job, tough sh*t, they're the ones losing out, imHo. My articles and experience should speak for themselves, and as you said, what's important is how will we can all work together. Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
-
I have realized, all these questions are useless when it comes to hiring someone. I trained my 4 year daughter to answer some of these questions. My aim was to have her in a phone interview and pass it. But I never did it. :)
-
Why are datasets bad for numbers? BTW, EF seeks to what you say.
Anytime you change something on the customer you have the program use C# code to figure out which dataset needs to be told to change info, then it sends the info to an SQL server, which then changes the info using code in the dataset, which is then sent to the program, which then sends the changes to the actual data on the SQL server and that newly upsated dataset sends the info to the form to update what it says... We think retarded monkeys with typewriters could have done a better job.
-
I have won several permanent and freelance jobs without even a CV, never mind an interview, but ever once I have got through interview has been as much part of the recruiter as mine.
-
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.
Tip #1: Don't waste your money with worthless recruiting / head-hunter firms. Place an ad on Dice and you will get the exact same resume list head-hunters will give you. Tip #2: A code test is a good pre-screening tool. Best to require it use data you publish from a webservice you control. You would be surprised at how many ".NET Developers" cannot access a web service. Give a dead-line for submission. Tip #3: You get what you pay for. If you have a low budget hire college grad with no experience, professors letter of reference, a C or B average, and a degree in Computer Science and train him or her (who am I kidding, him). Don't get the A average people, some just work hard to pass but can't code and the rest will drop you like a bad habit when a good gig comes around. Tip #4: Low ball the candidate, price-wise, if they accept it they are desperate and you don't want them :p
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
Not al; recruiters are snakes. Just like people pay us to do our job, people pay then as well.
Brady Kelly wrote:
Not al; recruiters are snakes.
Not saying they are. It is just that it is very hard to judge someone's abilities unless you worked with them for a while, and recruiters can't help with that at all.
-
Don Burton wrote:
Of course competency is important - but I don't want a programmer who is going to go "rouge" when given an assignment.
Better not hire me! ;) BTW, I totally agree with you. And actually, my standing policy at this point is that I don't do phone interviews. If that means I don't get the job, tough sh*t, they're the ones losing out, imHo. My articles and experience should speak for themselves, and as you said, what's important is how will we can all work together. Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
Marc, your're the guy we google when we want the defintive answer on a technical question!
-
Tip #1: Don't waste your money with worthless recruiting / head-hunter firms. Place an ad on Dice and you will get the exact same resume list head-hunters will give you. Tip #2: A code test is a good pre-screening tool. Best to require it use data you publish from a webservice you control. You would be surprised at how many ".NET Developers" cannot access a web service. Give a dead-line for submission. Tip #3: You get what you pay for. If you have a low budget hire college grad with no experience, professors letter of reference, a C or B average, and a degree in Computer Science and train him or her (who am I kidding, him). Don't get the A average people, some just work hard to pass but can't code and the rest will drop you like a bad habit when a good gig comes around. Tip #4: Low ball the candidate, price-wise, if they accept it they are desperate and you don't want them :p
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
Ennis Ray Lynch, Jr. wrote:
Tip #1: Don't waste your money with worthless recruiting / head-hunter firms. Place an ad on Dice and you will get the exact same resume list head-hunters will give you.
Not my decision. As I mentioned in an earlier reply, this company provides various hiring services for us and my boss was adamant that we pass the buck onto them.
Ennis Ray Lynch, Jr. wrote:
Tip #2: A code test is a good pre-screening tool. Best to require it use data you publish from a webservice you control. You would be surprised at how many ".NET Developers" cannot access a web service. Give a dead-line for submission.
I like this idea a lot. I was balking at the idea of giving an extensive test during the interview itself, as I (nor the candidate I'm sure) don't want to sit around my office for however long it takes to complete a test-of-skills application. This would allow me to make them do it on their own time, and I could spend my time reviewing it with them rather than twiddling my thumbs waiting for them to complete it.
Ennis Ray Lynch, Jr. wrote:
Tip #3: You get what you pay for
Ultimately, this also is not up to me. I don't sign the checks. My boss' motto is simply "Get the #1 best person we can for the price we are paying". I interviewed a young, affable guy the other day who said he'd be happy with $30k. But he had no college degree and only about a year and half of actual experience. Contrast that with the international candidates who are asking for every penny we're willing to offer. To me, saving the money might make it worth considering the first candidate. To my boss, it's a waste because he won't be 100% ready to sit down and work on day one.
-
John Simmons / outlaw programmer wrote:
kryzchek wrote: They may not own a laptop They're not serious about being a programmer. Don't hire them.
Bullshit. Most of the better programmers I have known and worked with, have not started out with their own laptop. OK, in my country, laptops are damn expensive. My first, an Acer bought only this year, cost R15k, with my take-home after about six years as a senior programmer, being just over R25k, just before my R7k mortgage. As an 'overpriced' consultant, working a full 160hr a month, I can only get R48k. Most of my colleagues have actually taken their office desktops home every night. BTW, it's about 8-9 USD to one ZAR.
The OP is in the U.S. He is also looking for an experienced programmer. I don't personally know any programmers that don't own a laptop. I'm not concerned about the world economy or your own local monetary limitations. The guy asked a question, and I answered it according to my *own* experience.
.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 -
John 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
I own a laptop so I can code when not at home. The difference between me and about 99.9% of every other programmer is that I code at home almost as much as I do at work. I have about half a dozen things I'm working on that will eventually result in CP articles.
.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.
I spent some time reading through everyone's response and it's really discouraging to see the amount of people who say "If they don't know specific 'x', then they don't know what their doing. Don't hire them". Really? 'Cause I'd bet when you started your programming career you didn't know that, so by your definition you shouldn't have been hired. Specifics are a learned commodity. What I look for in hiring is someone who can solve a problem, not necessarily someone who already knows the answer. Usually those who want specifics are just looking for a clone of themselves. That doesn't make your application better. Sometimes you need someone to look at it differently. Now there are those positions that require a specific skill set and need it immediately. If that's the case then by all means ask the specific questions. More often, there are people who think they have one of those types of positions and they "need someone who can hit the ground running". Usually, they take longer finding that person than if they found a developer with good potential and let him do some on the job training. Another thing to consider is that "I don't know" is not an automatic fail. Anyone who claims to have the answer to everything are those who I am suspicious of. I've had people reply with "I can do anything you need." when I've asked them a question. It would have been better to explain how they would have done what I needed. We have several questions - both verbal and written we ask candidates, but only a few I pay the most attention to: 1) Can they verbally explain OOP concepts and give an example of how/why you would design this way. Nervous candidates may struggle with this, but that's why we follow up with the written problem: 2) Design and code an application to import a list of entries from a text file, sort them in alphabetical order, then display to the screen. Please implement the sort function, rather than utilizing a pre-defined sort call. (Any language) I just have them write this out by hand on a blank sheet of paper. This shows they don't need a wizard to design their skeleton app. Syntax is not incredibly important as the majority of developers today rely on the IDE to point out their mistakes. I really look for their use of classes and functions, do they add comments, and can they design a way to sort other than what's provided for them in a language. After this you can review their response and discuss why they picked one technique over another. If SQL is
-
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, 2001I considered getting a laptop. Then I decided to simply place my "top 100" best components on CodeProject, so I can access them wherever I am. :)
Best wishes, Hans
-
I own a laptop so I can code when not at home. The difference between me and about 99.9% of every other programmer is that I code at home almost as much as I do at work. I have about half a dozen things I'm working on that will eventually result in CP articles.
.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, 2001I code at home hopefully not as much as at work. Although I certainly have done this in the past I do not like pulling 80 hour weeks. My code however is on a cvs/svn server that is accessible from both locations. To make a long story short the cvs server is on my home machine since it would be too difficult to the network security guys to allow this to happen at work..
John
-
I spent some time reading through everyone's response and it's really discouraging to see the amount of people who say "If they don't know specific 'x', then they don't know what their doing. Don't hire them". Really? 'Cause I'd bet when you started your programming career you didn't know that, so by your definition you shouldn't have been hired. Specifics are a learned commodity. What I look for in hiring is someone who can solve a problem, not necessarily someone who already knows the answer. Usually those who want specifics are just looking for a clone of themselves. That doesn't make your application better. Sometimes you need someone to look at it differently. Now there are those positions that require a specific skill set and need it immediately. If that's the case then by all means ask the specific questions. More often, there are people who think they have one of those types of positions and they "need someone who can hit the ground running". Usually, they take longer finding that person than if they found a developer with good potential and let him do some on the job training. Another thing to consider is that "I don't know" is not an automatic fail. Anyone who claims to have the answer to everything are those who I am suspicious of. I've had people reply with "I can do anything you need." when I've asked them a question. It would have been better to explain how they would have done what I needed. We have several questions - both verbal and written we ask candidates, but only a few I pay the most attention to: 1) Can they verbally explain OOP concepts and give an example of how/why you would design this way. Nervous candidates may struggle with this, but that's why we follow up with the written problem: 2) Design and code an application to import a list of entries from a text file, sort them in alphabetical order, then display to the screen. Please implement the sort function, rather than utilizing a pre-defined sort call. (Any language) I just have them write this out by hand on a blank sheet of paper. This shows they don't need a wizard to design their skeleton app. Syntax is not incredibly important as the majority of developers today rely on the IDE to point out their mistakes. I really look for their use of classes and functions, do they add comments, and can they design a way to sort other than what's provided for them in a language. After this you can review their response and discuss why they picked one technique over another. If SQL is
I agree with you 100%. To me it's more important to see how someone approaches a problem rather than their command an particular language. I suppose this is the part of the interviewing process that I'm having difficulty with. I think I'll use your second test question as I think it gives some valuable insight as to how a candidate thinks. And for the record, I'd never be able to hire you simply because your prefix your SQL tables with "tbl", and that drives me nuts :-D Thanks again for the tips and help.
-
I code at home hopefully not as much as at work. Although I certainly have done this in the past I do not like pulling 80 hour weeks. My code however is on a cvs/svn server that is accessible from both locations. To make a long story short the cvs server is on my home machine since it would be too difficult to the network security guys to allow this to happen at work..
John
You'll need to cut John some slack. His new love for VB.NET has his nerves a little on edge. :)
-
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:
kryzchek wrote: They may not own a laptop They're not serious about being a programmer. Don't hire them.
Would you enter a pinto into the Daytona 500? And why would you have a pinto to begin with?
Todd Smith
-
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 personally believe that trying to glean something from a programming test at interview time is worthless. The length of time available limits the complexity and the situation will always be somewhat contrived. My method has always been to have a first interview during which I explain, in detail, what the role involves. I whose them the application(s) in action, I show them source code and database structures. I converse with them about these (few, if any , outright questions - a conversation is necessary - I need to work with these people and know I can do so at a technical level). If available I show them some crap code (maybe some prototype code, maybe something that's causing issues - but nothing too complex) and get them to understand the issues and help suggest improvements (e.g. in once case we had a 'fetchObjectFromDb' method that fetched a massive customer object by selecting from the customer table, then for each 'id' on that table, selecting from the child tables and building the child objects (Name, Address, and other business objects). I asked them to think of any issues (this object was used even if the app was displaying just the customer name in a list, and required up to about 200 calls to the DB to populate all of the objects). Discussion was my point - I didn't expect them to have an answer off the top of their head, I wanted them to think about, and discuss with me, the problem. At the end of the interview, after their opportunity to ask any questions about the requirements of the role) I would tell them that, if called for a 2nd interview they would meet the team (not applicable in your case, I guess!) to make sure they would get on with the members, and be able to ask them any questions - and the team could ask them questions too. And finally I would tell them that, if they were not 100% comfortable with their ability to perform the role I had discussed, that they should get back to me before any second interview to discuss the issues. I insisted (and meant it) that this would not preclude their selection, but that if hired they would be on probation, and I treat probation VERY seriously. If they were unable to perform according to my expectations (which I had carefully explained) using the code base and DB they had been shown, I would sack them during probation. No second chances. Of the 12 or so candidates I employed over 8 or 9 years, I sacked one. (I'm sill not sure if he had some mental illness, was on drugs or what, but the guy that turned up to work could have be