How to conduct an interview?
-
JazzJackRabbit wrote:
how many times can an interviewee repeat "I'd google it"?
Gosh, that would be an improvement. So many have "I'll post a question demanding code urgently from CodeProject" on speed dial.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Maybe someone should write an article describing how to make a web service for that. Maybe with a nice shiny WPF UI.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
aspdotnetdev wrote:
what is the purpose of that approach
Just to see if they are ready to give up old habbits to fit into a team :)
Resistance is futile. You will be assimilated. ;)
-
Create a comfortable, friendly atmosphere. An interview sucks enough already for both sides already. Ask HR Esp. with a company this size there are a lot of do's and don'ts. bets get a briefing from Human Resources. Let them write code. It is a controversial topic, but after having it doen in one round of interviews, I'd never again hire a developer without. You must must must prepar well, though. Set minimum standards. And never ever settle for less, no matter how badly you need help. Read Joels guide to interviewing. Jeff Atwood has some on writing code, too.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.peterchen wrote:
Let them write code
Whose code? What M$ invented today or what M$ deems outdated?
-
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)
It's worth chatting to HR for guidelines. Also whether you accept or reject a candidate make that decision for the right reason. I interviewed one guy who had spent his whole caareerr leturing then realised he needed to build up some kind of pension. He wouldn't have lasted a month in industry no matter how gentle you were with him and it was painful to reject him but it would have hurt him, me, my team and the company so I had no choice.
Join the cool kids - Come fold with us[^]
-
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)
The number one thing: Know WHY you are interviewing these people. Know EXACTLY what their first tasks will be and where you hope to fit them into your team. Illustration: Several years ago I had an interview where the headhunter thought and the hiring manager acted like I was being interviewed for a lead position for a product in the planning stage. Yet, the main developer was actually interviewing for a junior developer to help him polish up a product that was almost done with the core development. On the flip side, two years ago my lead and I interviewed several people that management sent us and not one was remotely qualified. Our team does hard core C++ development on embedded systems with some .NET. We were interviewing VB.NET and database programmers! Mostly nice people, but not what we wanted. One guy figured this out after about a minute and we ended up just having a nice chat about some very interesting things he'd recently done. (Two managers were there and had puzzled looks on their faces; we refrained from laughing.) During this process, we figured out a very small number of questions that told us immediately whether it was worth continuing the interview. They weren't trick questions (hate those), but questions about Win32 that only someone experienced in those areas would be able to talk about. These aren't nonsense areas, but things you do need to know about on our team (like multi-threading and synchronization.) Another, albeit risky, tactic is to argue with the candidate or cut them off; risky because I'm looking for them to argue back and force their point. How to act in those situations isn't always clear to the candidate. I don't like working for pansies and don't like pansies working for/with me. (When I do interviews, if you swear, you get bonus points. If you show up in casual dress, you also get bonus points. When I'm interviewing for a job, if you tell me beforehand that you can't find my articles on Code Project, I'll cancel the interview, and have; I hate working for dumb people.) Another interesting question is to ask something super obscure. When the candidate says they don't know, ask them how they would find out. Having said all this, it's still a judgment call. Years ago, we had a team interview. I thought we were interviewing the guy for one, fairly complex thing, everyone else thought they were interviewing him for something relatively simple. At the end, I said no since his responses seemed too academic (i.e. that he was simply repeating what he learned by lecture
-
peterchen wrote:
Let them write code
Whose code? What M$ invented today or what M$ deems outdated?
It's not about technologies, it's about how to approach a problem, how to diagnose potential problems, etc. The problems should be rather simple. Complexity of FizzBuzz[^] is usually good enough.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
It's not about technologies, it's about how to approach a problem, how to diagnose potential problems, etc. The problems should be rather simple. Complexity of FizzBuzz[^] is usually good enough.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.Agreed!
-
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)
Command him to sit down, walk around him once and sniffle once or twice, then slam a folder with his resume in it on the table and yell "WHATS YOUR DEAL!?
Watch the Fall of the Republic (High Quality 2:24:19)[^] Sons Of Liberty - Free Album[^] The True Soapbox is the Truthbox[^]
-
Command him to sit down, walk around him once and sniffle once or twice, then slam a folder with his resume in it on the table and yell "WHATS YOUR DEAL!?
Watch the Fall of the Republic (High Quality 2:24:19)[^] Sons Of Liberty - Free Album[^] The True Soapbox is the Truthbox[^]
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
-
It's not about technologies, it's about how to approach a problem, how to diagnose potential problems, etc. The problems should be rather simple. Complexity of FizzBuzz[^] is usually good enough.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.Jeff wrote:
Want to know something scary? The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.
That *is* scary! :eek: I thought of several solutions in under 30 secs...
-
At what stage of the process are you interviewing them ? Is this a technical interview ? A get-to-know kind of interview ? 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. If it's not someone you will be working with, have someone that will be with you in the interview, even if that person does not actively participate in the interview. For technical interviews, the manners in which the person answer the questions is more important (up to a point) than the actual answer. If you feel you want to "destroy" candidates by being overly clever or smart, DON'T. even if the candidate passes all the steps and you want him/her, probably the candidate will not want to work for/with you anyway. And remember you represent your company. M.
Watched code never compiles.
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 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)
The most important thing is to get them to relax. You'll know yourself that if you're tense, you'll **** up and say the wrong things, because you won't be able to think quickly or clearly enough, and there's no point in seeing how people **** up when they're tense in an interview with strangers; you need to see them as they normally operate. Things that help: 1. NEVER read questions from a piece of paper, unless you can make a joke of it ("the twats in HR always make me ask this"). 2. ALWAYS start with coffee/refreshments, away from the desk (i.e. don't get someone to bring the coffee; say "Let's go and grab a coffee first"). 3. NEVER try to talk about your own abilities/preferences/whatever; that can make the candidate feel that he has to say something about himself to compete with it. You don't want a competition; you want to see who the guy is. 4. NEVER interrupt when they're talking. It can be hard enough to get them talking openly, so don't do anything to make them clam up. If you've ever been interviewed by someone who keeps interrupting, you'll know it makes you feel like crap. 5. NEVER correct anything they say (until after the interview proper is over). Same reason as for 4. 6. ALWAYS remember your objective: you want to find the person who can do the job best, not a new best buddy -- and remember you're there for a reason, not to just chat about things that interest (the pair of) you. 7. HAVE FUN! It's a chore that you have to carry out, but it's one of those tasks that you'll do a hell of a lot better if you let yourself enjoy it. [Edited because I can't abide tpyos]
I wanna be a eunuchs developer! Pass me a bread knife!
-
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"