How to conduct an interview?
-
Bad experience at an interview yeah? Still, with your skills, I bet you never miscount them McNuggets!
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
Dalek Dave wrote:
Bad experience at an interview yeah?
Nah, that was his mother with his school report.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I work for a big software services company($6 billion enterprise). I have been asked to conduct interviews for developer and senior developer positions for .net I have some experience with selecting people for my own startup(earlier). I would like to know are there any guidelines which I need to follow to conduct this interview. please let me know about any of your personal techniques you follow to find the best person. Do share any pleasant :laugh: or not so pleasant:mad: experience you had while interviewing.
'Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.' Robert Heinlein (1907 - 1988)
I don't see much point in asking about obscure and little used language features unless your organization is at that level of sophistication. Giving a candiate some poorly written and uncommented piece of code and asking him what it does seems counterproductive to me. If you really have code like that, why would he want to join your company? Since the hiring process can be long and expensive you want to make sure that not only he is good for you, but you are good for him. The candidate needs to be able to do the work but also needs to be able to fit in well with the organization. Be honest about what you do, how you do it and what the job will entail. Then probe to make sure he is good with that. The brightest technical choice might not be the best overall choice.
-
T M Gray wrote:
If they tell you that they don't know but explain how they would find out, that is the best case scenario.
That's a little bit silly because how many times can an interviewee repeat "I'd google it"?
So you can follow up with "what would your search query be?" There is a big difference between searching for "ajax problem" and searching for "modalpopupextender duplicate IDs". Formulating good searches is an aspect of good critical and analytical thinking.
-
Maximilien wrote:
If it's someone that will be working _with_ you (in your team), then you should feel comfortable with that person, usually, it takes about 5 minutes to feel you don't like a person, if it's the case, just end the interview as fast as possible and as polite and professional as possible
I've got to say that I really don't like that advice. When interviewing, you're talking to people who may be nervous, hopeful, worried, the works; but even if they've had lots of practice at taking interviews, and can approach them calmly, they will still not be in their normal state. The kind of people who would get past you, if you used such a "technique", are the bullshitters and chancers, who can talk the talk but can't code the code. The kind of people you'll miss out on are the ones who are most affected by being in an interview situation, so can't relax and be themselves. I would hope that you don't give (or follow) that advice often.
I wanna be a eunuchs developer! Pass me a bread knife!
I agree with you partially. However, in some cases, you can really see how the person is. Someone you really realize you can't stand. That would be like bringing hell to your workplace. In most of cases though, you can't really know how the person will be on a daily basis. Most people won't reveal their personality until they get to know you. Also, in my opinion, I prefer the people who you have to extract information from them. In my experience, the most nervous and shy people are the best coders, who usually miss lots of opportunities because they can't sell themselves properly.
-
Interviewing can be useful to eliminate bad candidates, but to find good ones I think the only reliable way is to either find someone you already worked with, or get a recommendation from someone you trust. Anyway, when it comes to interviewing my list of advices would be: - Honestly explain them what their job is going to look like; if possible, show them the work area and maybe even a screenshot of your code base. If they are going to be dissapointed, it is much better for everybody for it to happen during the interview than after the person starts working. At a previous job, we hired a senior developer who assumed he would write new code, and then when we gave him bugs to fix he simply refused. - Let them ask questions and give as good answers as possible. Again, you don't want to lure them into something they will regret later. - Ask them a "controversial" question (placement of curly braces is one of my favorites) and see how they react, especially if you disagree with them. - Ask them about previous accomplishments, problems they solved and make sure you understand what was their role in the process. - Most of all: good luck! Both to you and your potental hires :)
Nemanja Trifunovic wrote:
Honestly explain them what their job is going to look like; if possible, show them the work area and maybe even a screenshot of your code base. If they are going to be dissapointed, it is much better for everybody for it to happen during the interview than after the person starts working. At a previous job, we hired a senior developer who assumed he would write new code, and then when we gave him bugs to fix he simply refused.
This happened to me once. When I had my first job not beeing a trainee, I thought I would code. The employer told me I was going to work with JAVA and ORACLE. I thought to myself: "Well, salary is not too good but at least I will learn something new, coming from .Net" When I started to work I found out I wouldn't code not even ONE line of JAVA (just look at it) and would pass most of my day doing SQL Queries to investigate issues and failures on the system. Bottom line, I was going to be tech support. Result: started looking for a new job 3 months later, left work before completing 6 months. So, its VERY important to make it really clear, what kind of role and taks the employee will be performing.
-
No, go right ahead. I was thinking of revising the first question with a jab from the cattle prod immediately following the question mark, not giving the candidate an opportunity to answer at all. You know, just to see how they deal with a sudden outside influence and the affects it has on their ability to form a coherent answer and participate in a group discussion.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...OMG freaking hilarious. I actually laughed out loud at that one.
Humble Programmer
-
I'm sure others will chime in with the standard interview techniques..so I will add a unique 2 cents... Ask them what their favorite publication is or online forums they like and why. (If they say codeproject.com, they get 1 point)
I was asked something similar to that at a recent interview and that was my answer. The actual question was what resources do you use when you don't know how to solve a problem. I said google.com and codeproject.com One of the programmers was in the interview and had never heard of it but thanked me in a follow up email... I got offered the same money to stay at my current job so I did not take the other.
Humble Programmer
-
I work for a big software services company($6 billion enterprise). I have been asked to conduct interviews for developer and senior developer positions for .net I have some experience with selecting people for my own startup(earlier). I would like to know are there any guidelines which I need to follow to conduct this interview. please let me know about any of your personal techniques you follow to find the best person. Do share any pleasant :laugh: or not so pleasant:mad: experience you had while interviewing.
'Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.' Robert Heinlein (1907 - 1988)
Having been on the other side of the table recently I'd say 1. Don't let whatever else has happened that day affect you. I had one interviewer had torn my CV into pieces and thrown it in the bin before I arrived due to an argument with the recruitment company. Safe to assume he wasn't in a positive mood. Laid the pieces out in a sort of rough jigsaw for the interview. 2. Know exactly what the person is actually going to be doing. I left one interview with absolutely no idea what the job involved. Might have involved a computer of some sort. Interviewer had no idea whatsoever what the IT dept did. 3. Don't assume the candidate has been given all the facts especially if there is something that might put someone off applying. "What do you mean the company supplies the bulletproof vest? Oh OK, it's just in case they get past the armed mercenaries guarding the convoy on the way to work. No the recruitment agent failed to mention that part"
-
T M Gray wrote:
If they tell you that they don't know but explain how they would find out, that is the best case scenario.
That's a little bit silly because how many times can an interviewee repeat "I'd google it"?
I have been asked questions that I did not know the answer to. I reply with, I don't know, can you explain it to me? This is particularly good if you understand the answer quickly and can ask intelligent questions about its' intricacies. It shows you are not afraid to ask questions.
-
T M Gray wrote:
If they tell you that they don't know but explain how they would find out, that is the best case scenario.
That's a little bit silly because how many times can an interviewee repeat "I'd google it"?
-
I work for a big software services company($6 billion enterprise). I have been asked to conduct interviews for developer and senior developer positions for .net I have some experience with selecting people for my own startup(earlier). I would like to know are there any guidelines which I need to follow to conduct this interview. please let me know about any of your personal techniques you follow to find the best person. Do share any pleasant :laugh: or not so pleasant:mad: experience you had while interviewing.
'Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.' Robert Heinlein (1907 - 1988)
One of the most important things in the interview will be what questions they ask. If you can ask questions that make them ask questions that's a good thing. In that you'll be able to tell if they are "just looking for a job" or if they want to further their career. They should be asking questions so that they can make a decision on whether he want's to work at your company or on your team. Interviews are really to get to know the person face to face. Skill wise their resume and references should qualify that. If they don't have enough references (ie: an entry level job) have them do a simple small coding test to see if they know the basics. I once hired a guy in an entry level position that came across as being a great guy and competent programmer. He was right out of school and had good marks. After a couple of months he was let go because he had problems with even the most basic fundamentals of programming (if, while statements, etc). Being patient we tried to teach him and give him books to read, but he never changed. That could have been avoided if he was tested before being hired.
-
T M Gray wrote:
If they tell you that they don't know but explain how they would find out, that is the best case scenario.
That's a little bit silly because how many times can an interviewee repeat "I'd google it"?
Ask to the oracle or Yoda
"Go for it!"