I figured some of you guys would have conducted interviews for software developers. I'm on the other side of the desk now and have to interview a few .net developers. Any advice?

get a proper hr person?

Hire the one with the biggest boobs. (excluding fat nerdy males)

I generally base my decision on whether they've seen zoolander or anchorman.. etc

ask them to describe how they tackle a problem?
have them describe some projects they've worked on and their part in it?
consider giving them a test programming task (they could write .net or pseudocode)?

Imo with software developers you want to determine that they can:
a) actually write code
b) communicate with other people (ie. social reject types are such a hassle)

Another thing could be - do they actively go and teach themselves things (such as how to use a new API or language theyre interested in, not just if theyre made to use it). Initiative in learning i guess.

get some sodium pentothal.

http://images.projectstripe.com/jackchokesgraeme.jpg

TELL ME! HYPOTHETICALLY, WHERE ARE THE CANISTERS!

Scenarios and written questions let them prepare an answer in writing (say 15/20mins) and then present the solution ?

Come up with a list of scenario questions (ie: put them into a situation and ask how they deal with it), what have they done to improve business procedures, whats some examples of positive work, whats some examples of when they screwed up, etc.

Not sure about your style, but I always went in very casual and it worked out good. Tell them not to get too dressed up into suits/ties/etc, take them to a coffee shop, ask about their interests and so on.

man, job interviews are almost as unplesant for the interviewer, as for hte interviewee, imo

Get them to show you their work. Ask what they did on the project. Make them sell it to you.

Find out where they learn from - are they self learners? Are they still following the same conventions from years ago or do they move with the times?

Then call their previous employers (the ones with AND without references) and find out about their work ethic and time management skills. Sometimes people can be brilliant but have horrible self discipline.

Sometimes people can be brilliant but have horrible self discipline.

I'm living proof of this statement.

nF that was one of the most motherf***en harcore scenes ever on 24. Only Jack Bauer could kill his own brother. Awesome.

Not sure about your style, but I always went in very casual and it worked out good. Tell them not to get too dressed up into suits/ties/etc, take them to a coffee shop, ask about their interests and so on.

hehe, that would be quite funny if it was here

I like to make sure they know what they are talking about but wont be too worried if theyre the type of person that can learn. Its different for software engineering though, depends if you want to hire graduates or people wiht experience. If graduates then a test is a must do, otherwise can go back on their experience even though the places I've been at even seniors get tested.

People skills pretty important too as even though they might be good it can be hard to make it work if the team doesnt meld.

Oh, now this I can help with.

Things I would do when I was interviewing candidates:
0. Tell them about the company. First, or at the very least after they've introduced themselves, before you ask them anything technical.

1. Ask them an impossible question.
An impossible question is something like "How many street lamps are there in Melbourne?", "How many M&Ms have been manufactured?", "How many names are listed in the White Pages?", "How much fueld does a 747 use" etc.
A bad candidate will not even attempt it and just give an "I don't know" answer, only slightly up the scale but still a miserable failure is "I'd search Google", good candidates will go through their working and have some good rationale as to how they went about it.
It doesn't matter if the answer they give is wildly inaccurate, the important part is their procedure.

2. "I want you to design me a house". Give them a whiteboard marker, direct them to the whiteboard.
A bad candidate will start drawing straight away. This is where, when they've finished drawing their proposed house, that you get to point out this house is actually for a family of 17 giraffes.
A good candidate will go through tons of questions before they even show a prototype, and state assumptions.

3. Give them a peiece of obviously bad (but techically correct) code. Ask them to look at it, and ask them if there's anything wrong with it.
Include poorly named variables, little or no exception handling, hardcoded constants, incorrect or no comments (incorrect is better :)... all the kinds of things you would hate to see in "Hello, World!". You can easily do this with half a page/20 lines of code.

Here's a couple I used to use:

import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
public class ReaderTest
{
public static void main(String[] args) throws FileNotFoundException,
IOException
{
String o = "";
BufferedReader r = new BufferedReader(new FileReader(args[0]));
try
{
while (true)
{
o += r.readLine().toString() + "\n";
}
}
catch (Exception e)
{
}
System.out.println(o);
}
}

One for C devs:

/**
* - What would be the flow of this program?
* - Are there any potential bugs in this code?
*/
#include
int main()
{
int a=1;
switch(a)
{ int b=20;
case 1: printf("b is %d\n",b);
default:printf("b is %d\n",b);
break;
}
return 0;
}

For the above code, give the following printout of the output afterwards

[trowe@sahal.local] $ gcc printnum.c
(09:13:02) ~/qdc/codetests
[trowe@sahal.local] $ ./a.out
b is -1073743760
b is -1073743760

Spoiler:
Answer: Because b is inside the switch the value does not get assigned. Therefore you just get whatever random crap is in that memory address (or 10101010). Also, because of a missing break statement both the case 1 and the default case get executed, hence the duplicated output.


4. They absolutely must write code in their interview. Good examples are something like "reverse a string in place", "Swap two variables without using a third", or other simple algorithms - nothing that should take more than about 6 lines of code.

5. Ask them to criticize [methodology]. Agile ones are great for this.
5a. Later on, ask them what they like in project teams, what they avoid, etc. See if the two match or overlap.

6. For all programmers
· Explain polymorphism
· Explain any code example from http://www.gowrikumar.com/c/index.html
For Java programmers
· Explain how a semaphore works

7. Get them to briefly discuss a recent project they worked on and explain their role. Pick questions randomly from what they say. Press them on some things to make sure they're not talking crap or exaggerating.

8. Deliberately correct them (incorrectly) on something that's correct. See how they react (ie, whether they correct you, agree with you, get frustrated, provide proof... etc).

s***, i hope i never have to do a raven job interview!

Yeah, and that code looks fine to me.

As a guy who's interviewed many candidates in my time, I find the following to be effective:

Create a list of 20 to 30 questions that cover various aspects of .NET development (and SQL / Oracle / whatever tech is relevant). The questions should range from some simple, must-know things to really advanced (even obscure) subjects. The point should be to try to ensure that only really switched on guys could get all of them right.

Then anyone who gets 80% or higher is worth considering for a senior role. If you find someone who gets 100%, you've most likely stumbled across one of the true pros and should definitely make them an offer.

Don't tell them about the questions before hand. You want to know what they know all the time, not what they retain after preparing for a test. As for writing pseudo-code or code, I'm not a big fan of this. It takes up a lot of your time, and these days who writes all code purely from memory? A lot of coding these days (especially in the .NET world) is assisted with intellisense and other development aids. I'm more interested in good practice and design skills than if they can write perfect code. Compiler time to fix stupid syntax is cheap, redesigning flawed logic is expensive.

Oh, and go through the questions verbally. You learn a lot by how fast they answer, and how they get to the answer. Written answers don't give you that insight.

Raven's approach is damned good. My brother works as a lead software developer for a business intelligence company and the approach Raven laid out is fairly similar to what they do. Apparently, you should be prepared for s***loads of rejections and guys who THINK they're awesome, but can't code for s***.

I know I'm awesome >.> but I also know I can't code for s*** :D

Yeah, and that code looks fine to me.

If you're referring to the C code, it is _fine_ as far as the syntax goes, it will compile. But it's not "correct" logically because it causes runtime problem , obviously as Raven pointed out. (BTW I did spot the "flaw" before reading the spoiler heh).

Not really much of a java programmer but I'm guessing it'll get stuck in the infinite loop.

/back on topics.

I normally try to ask 1/3 close ended questions and 2/3 open ended questions. Closed ended questions are the ones that requires specific answers for - Raven codes for example. The answers are obvious, this designs to show their technical skills.

Open ended questions are questions such as:

- How would you deal with this situation if xxxx
- How do you think xyz could be done better

etc

These questions would give you the indication of their problem solving skills and also gives you the insights in how they communicate the solutions to you.

Obviously depends on the role you're looking to fill, you may need to change the proportions of the close/open question i.e. for code monkeys more closed questions, for more senior levels, more open ended questions.

My $0.02

The impossible questions are so f***ing retarded that people should be shot for asking them. Instead of the impossible question why don't you just ask one thats relevant to the job and see how they go about working through the problem.

Instead of "HAY DESIGN ME A HOSE" why don't you ask "HAY DESIGN ME A PROGRAM!". You'll achieve the exact same thing except you wont come off like a f*****.

1. Ask them an impossible question.
An impossible question is something like "How many street lamps are there in Melbourne?", "How many M&Ms have been manufactured?", "How many names are listed in the White Pages?", "How much fueld does a 747 use" etc.
A bad candidate will not even attempt it and just give an "I don't know" answer, only slightly up the scale but still a miserable failure is "I'd search Google", good candidates will go through their working and have some good rationale as to how they went about it.
It doesn't matter if the answer they give is wildly inaccurate, the important part is their procedure.

See I'd answer that question, "thats a irrelevant question that no one could answer. Anyone that tries to answer it is a bulls*** artist. But if you have more parameters on the problem I am sure I could write you program that would guess it"

8. Deliberately correct them (incorrectly) on something that's correct. See how they react (ie, whether they correct you, agree with you, get frustrated, provide proof... etc).

At which point anyone of any quality is going to these guys have serious management issues... the managers are either incompitent or play games. And would say thanks not interested.

Lets assume its game playing (cos you have stated it is), its a trick question, some managers want to be told they are right and everything is wonderful, others want to be told the truth. In other words agree and be damned, disagree and be damned.

http://www.funpicsfree.com/photogallery/funny_pic_050908/quick-job-interview.gif

Yeah, alot of ravens questions don't sort out good candidates, they sort out good interviewee's, 2 very different things.

Quite frankly i'd much rather hire someone who when given an obviously impossible task didn't waste a week or working time reading forums/ mucking about, then come back and say "after research, this is impossible". They should just say, that's impossible, next.

Actually alot of fortune 500 companies used to subscribe to that sort of theory (obscure and cryptic interview questions), and now don't, because they found it helped naught in finding better suited staff. It also put alot of good candidates, off. You know, the ones who aren't interested in a company that goes out of its way to confuse people with questions like that, for no good reason.

At which point anyone of any quality is going to these guys have serious management issues... the managers are either incompitent or play games. And would say thanks not interested.

I agree. Don't forget that while you're interviewing the candidate, your candidate is interviewing you. And that applies more to the good candidates that you want to employ. If you contradict something incorrectly, you come across as confused or ignorant or someone who doesn't check facts. At that point I'd start wondering about the quality of requirements that I'll be asked to develop software for. There's nothing more annoying than dodgy requirements provided by people who only really start thinking about what they want once the software's about to go live.

If I was in an interview and the interviewer corrected me (and was incorrect) I wouldn't make a fuss of it and would probably just put it down to stupidity. Unless I was pressed on the issue I wouldn't even bring it up that they got it wrong.

Asking someone to actually code during an interview is interesting, but does not really show you how good someone is at a programming job. A lot of the work you do as a programmer is in a totally different environment, over a totally different time frame, and under totally different pressure. I have been for a number of interviews and have never been asked to actually sit down and code.

I couldn't tell you off the top of my head how to do a lot of very specific tasks (like write an algorithm to do x), but I know where to quickly find answers (not just google). And how do you test the much larger picture of someone's programming skill in a single interview? Such as their usage of patterns or just general design skills.

I guess the roles I have gone for and the ones we look for at my current job involve a lot more than just programming. We don't hire code monkeys, we look for people with better than average analyst skills and communication skills.

Yeah personally I never could understand the logic behind getting someone to cut the code during the interview. For me that would simply stretched the interview out for too long and would take your time to prepare (unless you kept using the pre-canned ones and rotate them).

Nor the puzzles in the interview... I don't get what it supposed to tell you. Some people are better at solving puzzles than other people but you're not looking for a puzzle solving champ, you're looking for staff who:

1) Can perform technical tasks
2) Can communicate their solutions and reasoning
3) Will be a good fit for your organisation culture.
4) Can work independently but at the same time will take instructions from other team members.

As far as I can see the puzzle types and coding during interview only answers the first questions. But the open ended type questions will give you a better insights (sure may not be accurate due to this being an artificial circumstances) on how they think and their personality.

I guess different people have different styles.

As a guy who's interviewed many candidates in my time, I find the following to be effective: Create a list of 20 to 30 questions that cover various aspects of .NET development (and SQL / Oracle / whatever tech is relevant). The questions should range from some simple, must-know things to really advanced (even obscure) subjects. The point should be to try to ensure that only really switched on guys could get all of them right. Then anyone who gets 80% or higher is worth considering for a senior role. If you find someone who gets 100%, you've most likely stumbled across one of the true pros and should definitely make them an offer. Don't tell them about the questions before hand. You want to know what they know all the time, not what they retain after preparing for a test. As for writing pseudo-code or code, I'm not a big fan of this. It takes up a lot of your time, and these days who writes all code purely from memory? A lot of coding these days (especially in the .NET world) is assisted with intellisense and other development aids. I'm more interested in good practice and design skills than if they can write perfect code. Compiler time to fix stupid syntax is cheap, redesigning flawed logic is expensive. Oh, and go through the questions verbally. You learn a lot by how fast they answer, and how they get to the answer. Written answers don't give you that insight.

Is the world only 5000 years old?

Is the world only 5000 years old?

No don't be stupid it's a lot older than that, but I'm sure it's flat though.

I'm now going around the office to all the software engineers and asking them the swap two variables question. Pretty hilarious.

I'm also interested to learn how to swap the 2 variables without the third one. Do you use a pointer or something?

I cheated and google but most of the solutions assumed they're numerical types.

Oh wait or is it one of those trick question where you can use a function to swap because it's not a third variable but you're using a function call instead? Because it's a "function" it's not a variable so you can use that to answer?

f*** I hate puzzle.

just use dodgy php

$x = array('X' => $x, 'Y' => $y); $y = $x['X']; $x = $x['Y'];

I think that works for php, but it's so dodgy I feel dirty for having written it.

last edited by Furgle at 16:02:55 22/Oct/08

Just do the interview naked.

See what happens.

1. Ask them an impossible question.
An impossible question is something like "How many street lamps are there in Melbourne?", "How many M&Ms have been manufactured?", "How many names are listed in the White Pages?", "How much fueld does a 747 use" etc.
A bad candidate will not even attempt it and just give an "I don't know" answer, only slightly up the scale but still a miserable failure is "I'd search Google", good candidates will go through their working and have some good rationale as to how they went about it.
It doesn't matter if the answer they give is wildly inaccurate, the important part is their procedure.

So you want employees who lie about what they know?

I think that is the biggest problem in IT - people who give you an answer without actually knowing the answer.

1. Ask them an impossible question.
An impossible question is something like "How many street lamps are there in Melbourne?", "How many M&Ms have been manufactured?", "How many names are listed in the White Pages?", "How much fueld does a 747 use" etc.
A bad candidate will not even attempt it and just give an "I don't know" answer, only slightly up the scale but still a miserable failure is "I'd search Google", good candidates will go through their working and have some good rationale as to how they went about it.
It doesn't matter if the answer they give is wildly inaccurate, the important part is their procedure.

my missus has been working in HR for like 9 odd years and she's pretty good at what she does, fairly certain she would think that is retarded

ask em if they play wow

lead em into it by saying the workplace has a guild and they raid alot..

if they say cool i'll transfer over with my tier 56 lock... next

if they got time for wow they aint got time for you

ask em if they play wow

haha, last time i hired for the positions i was trying to fill, i was extremely tempted to ask if they played wow, so as to not hire them

I know of someone who responded 'have you read my f***ing resume?', when asked a .NET question and his resume clearly showed no .NET experience.

He got the job :)

Same guy actually walked out of the interview when the interviewer turned out to be a dick head. Apparently the interviewer didn't take it so well either.

You should have a fair bit of advice by now, but if not feel free to contact me on PM. I work in an internal recruitment role, spending the bulk of my days interviewing people for roles in sales, HR, IT, finance, marketing, admin, etc, for 8 offices globally. May/may not be able to help.

man, job interviews are almost as unplesant for the interviewer, as for hte interviewee, imo

Yeah tell me about it. I used to be so s*** scared of job interviews but ever since I've been working I.T. for a recruitment company and seeing the other side of the fence its really opened my eyes to "hey they're just ppl too!"

One thing my work had me do in the second interview (after the initial meet/greet) was they created a test environment of their in house software and broke a few components and set me down to fix them.

I think this works on a few levels - it give them an idea on how good my problem solving/reasoning is and also gave me an idea on the sort of codebase i'd be working on.

I also had a small take home project to do that didn't take more than a few hours.

I should also mention all the recruiter mags atm are calling it a "candidate short market" meaning candidates have pick and choose so as others have said its no longer "I R interviewer impress me" You've got to convince the candidate that they want to work for you and annoying bulls*** questions that waste their time isn't achieving that goal.


last edited by Fizzer at 21:12:17 22/Oct/08

cool! thanks for the tips guys.

might not do the crazy questions/test type things. not enough time for me to prepare a decent test...

hope we don't end up with a dud.

how did the interview go?

Ask them if they actually like programming in .net to see who the liers are.

- Former .net applications developer.

I've interviewed a lot of people for .NET positions over the last 2 years - maybe 50? - and tried a variety of different things.

Raven's suggestions sound good in theory (and maybe make sense for junior positions), but I 100% agree with eu4ia - questions about API's, design techniques, and so on that can be answered within 30 seconds have provided excellent results.

Some people will argue against this - who memorises APIs, you should test problem solving etc. In my experience though, there's a very high correlation between people who do well on these technical "knowledge" tests and overall ability. I think the reality is that its too much stuff to memorize to try and get through an interview, but the better people just "know" it because they utilise that knowledge every day at work.

I ask various questions about previous employment too, but these are really just to try and evaluate the person's personality. Knowledge tests also have the advantage that its easy to objectively compare candidates.

Why don't you just ask them for code examples?

Interview performance is very rarely correlated with job performance. Often, people think they can pick good employees by talking to them and asking them different questions, but when you do the stats, it's all bulls***. The best indicator of future performance is past performance.

it is the best indicator, but past performance isn't usually available in the form required for subsequent employers. and I disagree totally with the former part of your post

Well you know what they say about research - it's all made up anyway, right?

Well you know what they say about research - it's all made up anyway, right?

I thought they said it's how you interpret it :p

That said, I agree with the original sentiment that interview performance rarely indicates what job performance will be - kinda makes the process slightly depressing and frustrating.

That may be true in the general sense - particularly for manager roles, creative roles, etc - but something like IT or engineering I think you can get a pretty high correlation.

I certainly do (or I'm just lucky)

I think 'write code' tests take a comparatively long time, and have a relatively narrow scope. They're perhaps useful for figuring out if someone can code at all, but not so useful for trying to distinguish between average, good, and great.

get two of the same boxes of lego. Give them one pack and tell them to make anything other than what's on the instructions and you'll call them in 10 mins on the phone to see if they're done.

call them in 10 minutes from your office with the other box of lego and tell them to instruct you how to make the same thing they've made.

Is an excellent test of them being able to patiently explain unfamiliar concepts.

That or it might just be an excuse to buy lego on the company credit card

That interview situation sounds too weird.

My future boss...
Wants to play lego with me...
Hmm.