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.
Some companies I sent resumes to for C# jobs called me up and 'put me on the spot' with programming questions that I had to answer before they would even consider an interview. Some of the questions I remember where things like: What is boxing/unboxing? What is a singleton? What are inner/outer joins? etc. I think the key was that they put me on the spot, and didn't arrange a future phone interview in which I could 'study' for. The questions did not get too advanced, they were just testing to see if the basic foundation knowledge was there. Only then would they set up an interview.
-
Personality is important, but my boss is very insistent that anyone we hire should be able to get up to speed almost immediately. I've interviewed plenty of nice people that I would enjoy working with, but unfortunately they were all fairly inexperienced and my boss wasn't willing to spend 6 months to train them.
I think you should disabuse your boss of that notion as soon as possible. I've been in the game for around 10 years now, and one thing I've noticed is regardless of complexity, background or skill level, it almost always takes 2 to 3 months before the new staff member is productive. It might be a function of the environment, or not. Before then, they will be producing work, but it will be at a very high opportunity cost. That is, for them to produce something it will require checking by you, which takes away time you'd otherwise be producing work as well. I'm not an expert, but that is what I've observed over the years, for what it's worth.
-
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.
Posting in a rush so don't know if anyones mentioned it: Book There's some great questions & advice in there
-
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.
-
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 think a short 7 to 10 question technical test would be highly appropriate. Don't make it too difficult.
-
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.
A short test might be in order to see if the candidate *understands* the code he writes on the target platform. Here are two suggestions, a subset of a C# quiz which has helped separate the men from the boys in the past. Even if C# is not your language, this might give you some ideas. 1) Show a short loop beginning: "foreach(CustomObject currentObject in objectList)..." Q: What interface must CustomObject implement for this code to work? A: IEnumerable. 2) Similarly: "using(ClientEntity client = new ClientEntity())..." Q:What interface must ClientEntity implement for this code to work? A: IDisposible. You'd be surprised how many candidates with impressive-looking resumes could not answer such questions.
-
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, 2001Think much of yourself, do you John? I do code in my spare time, but would never have any of my employers code on any of my computers. That would be a security violation.
-
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, 2001John Simmons / outlaw programmer wrote:
The guy asked a question, and I answered it according to my *own* experience.
No, John, you answered it with your own arogance.
-
I think you should disabuse your boss of that notion as soon as possible. I've been in the game for around 10 years now, and one thing I've noticed is regardless of complexity, background or skill level, it almost always takes 2 to 3 months before the new staff member is productive. It might be a function of the environment, or not. Before then, they will be producing work, but it will be at a very high opportunity cost. That is, for them to produce something it will require checking by you, which takes away time you'd otherwise be producing work as well. I'm not an expert, but that is what I've observed over the years, for what it's worth.
I'm in agreement on this, kind of. I know at my present position the first thing I was handed was a program that didn't work, no one knew how to work it, but yet it was very important that it work -- go figure? Anyway took me three months to get it up and running, however in that three months time, in addition to fixing the program, I also learned much about my company and internal IT structure, so I was more fully prepared to take on other challenges as they came up. You can't really expect someone (even with a high skill level) to immediately be able to grasp your business structure and logic without letting them look and learn. I have never had to provide code samples for an interview, but could at least tell someone about progjects I had worked on and the challenges I overcame in working on them. Perhaps just asking open-ended questions like What was the best project you have worked on? Why? What obstacles did you overcome? What made it such a successful project? etc. Even directly out of college I had several stories of programs and projects I had worked on in school on my own or with a team of students and what made them successful or not>
-
Marc Clifton wrote:
I would think a queue. Is that more-or-less correct?
Exactly, though shared-memory queue is more precise. If they say named pipes, they are summarily shot. We've actually interviewed people who fumbled around and finally said TCP! To which we answered "Yes, but what about using shared memory?" To which we've gotten the reply, "What's shared memory?" Needless to say, those people are shown the door immediately. We even had a guy suggest writing the file to disk and the other process would poll (yes, poll) that directory.
I'm working in some code that writes files to disk and polls for them all over the place. They even did that in the same process. This was supposed to be some magical fantastical best in the world project that we had to take over. I think of things that I should be putting in Coding Horrors daily.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
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.
In addition to the 'formal' interview where I try to get a grasp of the person and their capabilities, I alos offer a code test. Okay so does everybody - right? Here's how I do it: First, one of my favourite functions for the code test amounts to being atoh(), albeit specialized for the particualar application. 1) Part one consists of reviewing some code that was written inhouse which, in retrospect, could have been written better. I ask the person to take on the role of code reviewer. Their task, don't rewrite the code. REVIEW it. Add comments and ask about questionable constructs. 2) Part two is the fun part. And also the most revealing about the coding and thought patterns of the interviewee. In many cases this part is the deal breaker. I ask the candidate to write the inverse function to what they critiqued in part one. Essentially htoa(). In my specification for this 'inverse' function I practically tell them how they can achieve the results I want in about five-to-six lines of code. The catch? They get to take the assinment home! I tell them I want them to work on it in a stress free environment. No interview stress. No wacko "don't think outside the box, re-invent the box" questions. I want to see how they think and how they code. I ask for the results to be e-mailed to me with-in a day or two. The results I get are amazing. A solution can be written in about five lines of legible code. Over the years I have received solutions with more than 120 lines of spaghetti code that I have to read three or four times to see if the algorithm would even work. Convoluted, hard to read, difficult to understand, malfunctioning and in general random thought processes - OUT!
-
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.
I dont have free time code, and yet I am very serious about my coding skills ...
Edgar Prieto Software Engineer
-
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.
After all the suggestions you have been given, many of them excellent, once you have decided that technically the candidate is capable of contributing to the company, there is one other factor you should consider. Attitude. Given two people with reasonably similar abilities, the one that is excited to work on your project or work with you, or is at least interested in the work being done will be the better candidate. Someone that is so full of themself that he/she thinks others can't teach them will hurt your productivity. A person that comes in with the attitude that they can be useful, and wants to learn more about what you are doing, and maybe even enjoys design and coding can make all the difference in your work environment and the companies productivity.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
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, 2001You run an proper database server on your laptop, as well as the web server, Cold Fusion server, and so on? I'm impressed. All I've ever managed on mine is 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.
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