Interview tips
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
I disagree. Having them write code before your eyes gives you a sense of how they think as they work through the problem. What has to be tempered is your expectation of the code they produce. You have to bear in mind that they are under a nervous pressure which means you won't see the best they can do, but you can get a good idea. I interviewed for a large corp that had me write code under a NetMeeting session. I was nervous as hell, but it was a good experience. You just do what you can, and talk it out, think aloud, and let them take part in that process. Its kinda like Pair Programming at this point. And if you can't handle anyone watching you code, then you might have other issues. But keep the problems within reason. One was: "Describe a design for a logging system, and define the initial interfaces. Not the implementation, just the interface." Another one was: "Write a program which calculates the angle between the hour and minute hand." I got the offer but had to decline do to my wife entering surgery, but the experience in itself was worthy. This was also for C++ which my skills had gotten rusty from all the C#. So it was an eye opener too. Let me know where I was at. I also agree with the comments regarding understanding verses knowledge. I don't care if you've memorized any api, but if you're not too proud to tell me you'd use MSDN or Google, or just F1 in response to a question, then you've earned a couple of points. I think the ability to research has to be accounted for as well.
This statement was never false.
-
That's the only thing where they can't BS you, and I've seen it show huge differences between candidates that are resume-wise hard to tell apart. You need a few problems ready that you deeply understand and can be solved in 10..20 lines (he might race through a problem he already knows by heart, so you need at least a second one to throw at him). Does he: Make a plan? Rely on unconfirmed assumtions? communicate with you? Write solid code? Check for errors? Encourage him to talk about his thoughts, help him when he's stumped or makes a stupid mistake, be relaxed about abbreviations, typos and general "looks", but be tough about things that matter. Play devils advocate: think of all things that can go wrong (overflows, strange inputs, ...) and question/nudge him to see how many he finds. What would he do if he can't use CString class? The second most important thing is: set a minimum standard. Don't hire the best you can get just because you need one desparately. For a 1h interview, I'd say roughly 20 minutes warm up, asking the usual resume questions, poking for passion, discussing previous projects (can he explain the task of the software in terms you understand?), getting over the initial nervousness. 20 minutes "write code & discuss", and 20 minutes about the project he is to work on: what you require, what he expects, where are his deficiencies and how to catch up. If you have more time (I found that short of 90 minutes feels necessary), expand the first and the last part.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistWhen we were interviewing C++ candidates, I'd use this function below and just ask them to explain it to me. Amazing the range of responses.
void foo(char *p, char *q)
{
while(*p++ = *q++);
}This statement was never false.
-
Nishant Sivakumar wrote:
It might sound unethical, but it's part of corporate IT hiring
Nothing unethical about as long as you aren't stealing "secrets". Free markets aren't just for goods, labor should move freely as well.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
Exactly. And too bad that's often the only way to get a raise. Lateral movement. It seems that companies have a hard time rewarding existing employees, but no problem paying more for a new person, even though they have to train them etc. Oh well, such is life.
This statement was never false.
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
Paul Brower wrote:
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.
Give them a laptop with your IDE loaded, am sure most good programmers would not struggle with that.
- sajith m
-
pgorbas wrote:
The output would be something like this - there would be 100 results: 1, 2, 3, Y, 5, 6, 7, 8, 9, X,
Gee. I thought 8 was divisible by 4. :-D;);P
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
This thread is interesting, but this quote had me laughing out loud!
Tom Delany wrote:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
agi20dla
I wish I could take credit for that, but actually, my 16 year-old son came up with that from somewhere, and I thought it was funny.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
Ask them to bring a project/program/util that they have written and ask them to wlak you through parts of the source code, from that you'll know if they can cut code or not.
.net is a box of never ending treasures, every day I get find another gem.
norm .net wrote:
Ask them to bring a project/program/util that they have written and ask them to wlak you through parts of the source code, from that you'll know if they can cut code or not.
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented. In the US actual employees will not have that right to company materials unless it is specifically given by the employer. And many contractors will not have that right either.
-
norm .net wrote:
Ask them to bring a project/program/util that they have written and ask them to wlak you through parts of the source code, from that you'll know if they can cut code or not.
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented. In the US actual employees will not have that right to company materials unless it is specifically given by the employer. And many contractors will not have that right either.
jschell wrote:
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented.
You said employers, I've written a networking desktop application that is and looks professional enough to be sold by Microsoft. This has been written in my own time and not connection with my current employers. And anyway you are showing code not giving it away.
.net is a box of never ending treasures, every day I get find another gem.
-
jschell wrote:
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented.
You said employers, I've written a networking desktop application that is and looks professional enough to be sold by Microsoft. This has been written in my own time and not connection with my current employers. And anyway you are showing code not giving it away.
.net is a box of never ending treasures, every day I get find another gem.
norm .net wrote:
You said employers, I've written a networking desktop application that is and looks professional enough to be sold by Microsoft. This has been written in my own time and not connection with my current employers.
If it is your own code, you have no limiting contractual agreements with your employer (some employers require such contracts), and it does not reflect what your employer does then you can show it. Contractual agreements might include any of the following or more - Rights to anything you produce, regardless of industry - Rights of first refusal on anything you produce - Rights of no-compete within the same industry If you signed something then it is your responsibility to know what you signed.
norm .net wrote:
And anyway you are showing code not giving it away.
Wrong. It is intellectual property. You have absolutely no rights to it. Including just "showing" it.
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
I think you should find one or two guru/consultants to sit in on the application process with you. They can help you weed out the wannabees. Just make sure they aren't looking themselves, or they will pull the best applicant away from you. Another thing you can do is employ a company like brainbench to have a small test prepared for applicants to take, they can provide you with a report of the skill level of your applicants. I've had to do this a few times for some jobs I've taken. Good Luck!
-
Ask them to bring a project/program/util that they have written and ask them to wlak you through parts of the source code, from that you'll know if they can cut code or not.
.net is a box of never ending treasures, every day I get find another gem.
Personally, I've never worked in an environment where any code has been allowed to leave the premisis, but on another note,check out these tips from Joel Spolsky: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html[^] NB: See those in Edinburgh at the Radisson for a pint or two tonight.:-D
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
Get through it without using the word "challenge", in any of its forms. It turns me off no end when people describe a job I'm offering as "challenging" -- if I need someone who can't do a perfectly do-able job without struggling, I'll scout universities, not advertise in the pro press.