How Should You Interview a Programmer? 1136
phamlen asks: "Having hired several programmers who haven't worked out, I'm wondering if other people have better success with interviewing techniques. Usually we have a two 'technical interviews' and a final interview. The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility. Unfortunately, we've been burned a couple of times by people whose performance didn't measure up to what we expected from the interviews. So I'm wondering if other people wanted to share their interviewing tricks - how do you find out if someone is a good programmer?" Surprisingly enough, we've done a series of these, so if you are interested in similar questions for sysadmins,
network engineers, or the one who will follow in your footsteps, then we've got it covered. We've also covered core IT questions as well. What special ways do you have of evaluating potential coders? How well have they worked out?
Good question (Score:4, Insightful)
Re:Good question (Score:5, Funny)
Re:Good question (Score:5, Funny)
What I do (Score:5, Funny)
Re:Good question (Score:5, Insightful)
These are the biggies, IMHO. This is what being a good programmer is all about.
And poetry.
-oakbox
Re:Good question (Score:4, Insightful)
Re:Good question (Score:3, Interesting)
> (this may take a few tries). If they try to feed
> you some BS they're probably not a good candidate.
> Its always good to know you've got people willing
> to give the honest answer, "I don't know".
Heh. I went to an interview once for an administrative/support position. From the questions the interviewer asked, I got the opinion that he had an overestimation of his own abilities.
Anyway, he asked me a question but first gave some background. He said that he had a SCSI problem with a server that had taken himself and 5 other engineers over 6 hours to diagnose. He then asked me the question. I asked him a question about the system and instantly knew I was on the right track by his reaction. He said to me that it was ok if I didn't answer it correctly in the the next few minutes. I then asked him the second question about the system (zeroing in on the solution) whereupon he began looking uncomfortable. I asked the third question and hit the nail on the head. He said he'd get back to me and that I had figured it out.
I never heard from him again. To this day, I guess I intimidated him or he thought I was a smart@ss.
I'm not trying to brag or anything... it's just that I like to know my stuff. I like solving problems and fixing things.
I guess the moral to this story is that sometimes you have to feign stupidity? Don't look better than the boss... I dunno. I just get the feeling that they are looking for YES men who make them look good rather than people who know what the fsck they are doing. Heh whatever.
Re:What to look for (Score:5, Insightful)
also, 90% of work is on the job training... do you expect people to be a perfect match walking in the door? wouldn't you rather have someone intelligent, adaptable and dependable, than someone who really really knows css and frontpage?
Re:What to look for (Score:3, Insightful)
Re:What to look for (Score:3, Insightful)
The important thing to test in an interview is *method*. Not whether the answer was right, but whether they went through the right steps to get there. If they got the right answer by some random guess, that tells you nothing, but if they went through the right steps and made a mistake, in the real world they can back-track and find the mistake.
Grab.
just out of curiosity (Score:4, Insightful)
wouldn't you rather have someone that can think on their feet rather than those that heard from a friend what your interview was like and studied to do well for that interview?
Re:just out of curiosity (Score:5, Insightful)
How about someone who answers a technical question, "I don't know off the top of my head, but that's what man pages are for."
I'd tend to hire someone who's willing to say "I don't know" over someone who tries to BS an answer.
Re:just out of curiosity (Score:4, Insightful)
* Past behavior is the best indicator of future behavior
* Most people can not lie well (and won't anyhow) when being questioned directly to arbitrary levels of detail
* Technical ability is best determined by specific and relevant tests
* "IQ testing" can be fun and enhance the interview experience, but it's not of primary importance.
But let's take a step back. To get ideas for questions, I start by making two lists: "hard" skills, like particular technologies and experience levels, and "soft" skills, like ethics, interpersonal skills, and general fit with company culture.
From the "hard" skills list, I try to think of a few technical questions that I can ask informally, like academic questions about programming languages, or other specific knowledge. If possible, I'll also use a short programming problem that can be completed in 30-60 minutes. The rapid-dev code sample is always informative! If this isn't an option, asking them to send in their answer later still tells a lot, but less about how well they code under pressure.
Then comes the fun part. From both "hard" AND "soft" skills, I think of behaviors or circumstances that come up where they would need to be exercised. Then I ask the person questions like "Think of the last time you [were asked to complete a project without enough time] or [had a dispute with a coworker] or [had to design a schema]. What did you do?"
Sometimes, the person will answer saying "Well, I always.." or something like this. If that happens, I tell the candidate that I would really like them to think about a specific single occurance, so we can talk about it.
When they tell about what was going on, and what they did about it, you can learn a lot about their personality, real-life communication skills, self-image and more. But don't stop there! Ask for more detail. Ask about the algorithms, or the outcome of a dispute, or what they learned from it.
It's important also to manage your own perceptions throughout the interview. If you start to get the idea that this candidate is *really good* or *really bad* in a particular area, you should challenge that thought right away in the interview, by asking a question that gives them a chance to talk about their strengths (if you think they are weak) or how they have been challenged (if you think they are strong) in that particular area.
Through this kind of questioning, you get to know the interview candidate a lot better. A textbook response or whatever their friend told them to say just won't be helpful here. A lie will get complex very quickly when you tack on follow up questions. And you let them choose the best ways to explain themselves, while learning what you need to know about their behavior.
Re:just out of curiosity (Score:5, Insightful)
People who have the certification and went to school plus have work experience (usually during school), reseach experience, personal projects, and possibly a track record of past successes can usually think well on their feet.
Personally, the ones that can't think on their feet are usually the ones that can't remember how to fix a customer's tech support problem even though they've been told how to fix it at least 3-10 times already. These are usually the ones that piss the customer's off the most and end up getting me involved in a pointless conference call with the customer due to some perceived "catastrophic bug."
The ones that think on their feet are the ones that use their own credit card to renew their company's $70 domain reg before millions of users of their free web-email service get locked out due to no resolvable DNS record. The same ones are those that pull a screw driver and make a tweak to your broadcast equipment 10 seconds after your first color TV broadcast goes live and everyone realizes all the color TVs everyone bought have a problem receiving 30 frames per second. (Now US TV gets 29.997 frames per second due to this same technical person.) Too bad there aren't more of these types of people out there.
Re:just out of curiosity (Score:5, Insightful)
Being a contractor for the past 7 years I have been to 100's of interviews and to be honest there comes a point when you realize that its normally the person doing the hiring that is kind of nervous or off thier game (they don't do interviews everyday normally).
I also don't tend to think about wheather im going to get the job or not, instead I think of them as a paying client already and I try to get them into discussions about thier current enviornment, issues, future plans etc. Then I provide advice and suggestions on these things. sometime if I steer it right I can go through the interview without ever having a formal tech-out or question anwser session becasue you show your skills right away.
Re:Well.. (Score:3, Insightful)
Education does not make you a professional.. it lays groundwork.
Most important thing I ever learned - is how to learn.
Riddles... (Score:2, Insightful)
the ones discussed here [slashdot.org]
Re:Riddles... (Score:3, Insightful)
Algorythms come and go, looking for a programmer based on what algorythms they know is stupid and useless--all it proves is ythe person has book learning and nothing more.
What's missing from the applicants skills can always be trained. Phamlen seems to be doing what most companies have been doning they look for book learning type skills. They want someone whose skills exactly match what they are looking for in a programmer, and that WON'T always work.
One simple little function... (Score:3, Interesting)
And understanding pointers (even if you use non-pointer languages) seems to be a common trait of most "Good Programmers".
Re:One simple little function... (Score:3, Interesting)
My simple question is this: You have two tables, one called "orders" that has "customer_id", "item_id", "quantity" as fields, the other called "items" with "item_id" and "price" as fields. The second table is foreign keyed by "item_id" in the first". Write a select statement for the total amount in dollars that customer 5 has ordered.
About 1 in 10 candidates get the join part. 1 in 15 get it all right. Simple questions really are important in an interview to weed people out. They don't tell you how productive they are, though.
Re:One simple little function... (Score:3, Insightful)
I did not know SQL. Never did. Did not put it on my resume.
Had a project requiring implementing DB access. I got a book. By the end of the day had it working just fine.. with all fluff and what not.
Our DB guru was reviewing it a bit later and said it was one of the cleanest made solutions he have seen. Note: it was reviewed.
My point being: yeah, when you need an exact narrow skill, or just to weed out liars - sure, that approach works fine.
You will not find people who can learn new stuff, and apply it sucessfully, that way. You will be stuck with jacks of one trade.
On my book - #1 skill is the ability to learn.
Well (Score:4, Insightful)
Seems far too many people think it's about hotshot know-everything-instantly type of work, where you work when inspired or work when you are 'in the mood'.
What about those who can methodically and cleanly produce code day after day?
Re:One simple little function... (Score:3, Insightful)
Make them sweat (Score:2, Funny)
Q: Which is better vi or emacs?
My experiences (Score:4, Interesting)
It was really freaky how accurately it described me... the main point was to evaluate me with reference to the type of person that excels at my job (Programmer/Analyst with some support duties)
They also asked for source code I had written and numerous references.
THe problem with an interview is it's too easy to bullshit. You need to go beyond the interview, as my current employers did.
Clearly this is what Certifications are For (Score:4, Funny)
It is obvious that anyone with hiring expertise, such as human resource specialists, can most effectively hire potential candidates by insuring that they have MCSE (Microsoft) or Red Hat (Linux) certifications.
This removes the requirement for the interviewer to ask intelligent questions, and for the interviewee to provide intelligent answers, streamlining the entire interview process completely.
After all, how else is an interviewer going to be able to BS a potential candidate into believing they know what they are asking about, and how else is a potential candidate going to BS an interviewer that they know what they are talking about?
As Microsoft and Apple have been pushing for on the desktop for years now, it is time we removed the expertise and knowledge from the entire process altogether, thereby "enabling" and "facilitating" the hiring process.
[/humor]
Not freaky, it's called the Horoscope Study (Score:4, Informative)
I don't know what survey your employer used, but you spent some effort to complete the survey, expecting that a well-designed system would evaluate some qualitative aspects of you. When presented with results, you subconciously hoped to be:
- described accurately
- described favorably
This subconcious desire on your part made you willing to forgive minor points that didn't fit your desired outcome, and willing to magnify points which did fit the desired outcome.Again, I don't know what survey you used, and there certainly are valid personality tests out there, but don't get too freaked out when one seems to describe you to a T.
Re:My experiences (Score:3, Informative)
Here is the order:
1) Introductory interview - they turn on their BS detectors, ask a few standard questions and then call me back later.
2) I show up again, they give me some written tests to take home and some verbal tests on the spot. I bring sample code.
3) They call me back one last time, give me the profile (they hire an outside company to do the tests, btw, they don't perform them). They ask some more questions - more in depth with specific technical questions.
4) They call me and give me the job.
The fact is, they wanted to hire somebody smart. I did not have all of the qualifications (i'm originally a hardware programmer - now I do business apps) but since I was honest and showed my potential, I received the job.
ask them to pick a number (Score:4, Funny)
Hire only people you know (Score:2, Insightful)
The ultimate way. (Score:2, Insightful)
Re:The ultimate way. (Score:3, Funny)
I'm a frikin' genius!!
Re:The ultimate way. (Score:3, Funny)
Tech: We found him digging around in the trashcans out back, sir.
Manager: He any good?
Tech: His revision of the notepad program became self-aware about 45 minutes ago.
My Mommy? (Score:4, Funny)
Re:My Mommy? (Score:4, Funny)
Re:My Mommy? (Score:3, Funny)
You could always respond that you liked his better...
Re:My Mommy? (Score:3, Funny)
I was interviewed at Adobe Systems a long time ago, and one of the people asked me if I liked my mother.
Did it go like this?
Hire the programmer on a temporary basis (Score:3, Interesting)
Odd questions (Score:2)
performance not measuring up? (Score:3, Funny)
/me closes the browser window
Re:performance not measuring up? (Score:2)
By 'performance not measuring up,' do you mean that they simply did not know how to build what you wanted to build? Were they not fast enough? Did they not build stuff according to your specifications?
Please explain how you determined that they were not 'measuring up to standards' !
Show me the money.... (Score:5, Insightful)
Ask them if they write code as a hobby
What Open Source projects have they contributed to?
Ask them to bring some samples of source code they've written, and then do a walk-through
Ask them to solve a simple exercise with pseudo-code, then explain which language they would choose to implement it and why
Get them to find a known bug in some code that matches your "house style" (describe the unintended behavior)
Talk to their previous associates and boss....
YMMV....
Re:Show me the money.... (Score:5, Insightful)
Bad. Leading question.
It is likely that a coder who contributes to Open Source projects will have a true passion for coding, and probably producers better code for it, but it's possible to be an excellent coder and not participate in OSS projects.
In fact, it's possible to be an excellent coder while being morally opposed to the entire concept of Open Source...
Re:Show me the money.... (Score:3, Insightful)
Re:Show me the money.... (Score:3, Informative)
Fact is, while certain factors (such as marital status, religion, age, etc.) cannot by law be considered as factors in hiring, employers in all fields *do* ask about professional association memberships, related volunteer work or internships, and so on. In some fields, if you haven't done any work for free, there's no way in hell you're going to get paid for work (see: Entertainment Industry for further information). The fact that someone has not contributed to any Open Source projects does not mean they are a bad programmer, but those that have probably will be more enthusiastic about their work, and have more easily verifiable skills.
Re:Show me the money.... (Score:3, Insightful)
Of course, there are also lots of folks who do contribute to OSS and aren't quite godlike in their skills (yours truly among that group).
I'm not going to not hire someone because they haven't contributed to OSS on their own time -- but it's still a reasonable question to ask, as long as it's only one indicator within a larger evaluation process.
Finally, let me mention that most of the open source work I've done has been while employed. Indeed, I'd estimate that over half of my contributions to open source have been done within the context of my job (my present employer is in the embedded Linux business). Most of the major contributors to Linux/MIPS, Linux/PPC and gdb (and probably many other projects) also do so professionally, not on their spare time and certainly not on account of being unemployed.
Re:Show me the money.... (Score:3, Insightful)
Haha, like anyone with a brain would want to work for a company with that attitude? Especially since you'd have no money to pay them since everyone knows you can't make money by giving away free software!
Re:Show me the money.... (Score:5, Insightful)
Coding as a hobby definitely demonstrates a personal interest in programming, and a willingness to spend the time (my own time, no less) to learn whatever it is I'd need for that hobby (and, hopefully, the ability to use what you learn).
Samples of source code are sort of good, but the applicant might only be able to bring "hobby code" from home (because the 'good stuff' belongs to his current company), and that probably won't be as well refined as the stuff you do professionally. Though it also might be more cool, elegant, or just innovative, depending on what work's like (you're leaving, remember?)
Actually going to a whiteboard to solve a problem seems about the best way to gauge an applicant, in my not-so-complete-interviewing-experience. You're getting the most real-world example of the applicant, with peers, discussing and analyzing a problem, then sketching an outline for how to solve it. The details (which language, what modules, should you use pointers here, etc.) seem (to me) to be irrelevant. You're hiring someone to solve problems -- so, solve a problem, with the team, just like you would on a normal work day.
However, a couple of other suggestions seem like they wouldn't work. Asking about open source involvement just measures someone's interest in the open source community. Plenty of people (including myself) do a lot of programming at home, for fun, on projects that are primarily of interest to no-one but the applicant.
Finding a bug in sample code might work, if it's a small enough sample (like a simple routine), but there you're treading too close to testing for book knowledge ("Ah! You forget that the squiggle goes on the LEFT of the arrow!"), and book knowledge generally flees an interviewee at warp speed as soon as they set foot in your building. (Plus, that's why we *have* books, and man pages, and CPAN, and....)
Finally, talking to associates and bosses is tough, especially in a tight job market where someone might be afraid to even *suggest* that they're unhappy, for fear of being laid off and replaced with someone desparate for work off the street.
I don't know. I hate interviewing people. I hate *being* interviewed even more. I'm just not sure there is a good way.
Re:Show me the money.... (Score:3, Interesting)
I've been in this biz only a little longer than you have and agree with your approach.
A couple things I've noticed about the better programmers I've worked with/hired are:
Most play a musical instrument of some kind.
Most enjoy and are good at strategy type games such as chess and go.
Left handedness seems to be higher than in the general population.
They do crossword puzzles.
John
Re:Show me the money.... (Score:5, Funny)
With a pen, not a pencil.
Re:Show me the money.... (Score:5, Insightful)
Building on your ideas, I think it's important to avoid asking a question while simultaneously giving away the answer. Some interviewers might ask "Do you code as a hobby?" but I would rather say "Tell me about your hobbies", at which point I am listening for things related to coding. If I hear something interesting, then I ask a follow-up question, where I attempt to find out of the candidate has what I want. Along the same line... "Tell me about: "
- your past/current job
- projects you worked on
- your role in those projects
- a project that failed -- what went wrong? -- what did you learn?
The whole process needs to be more of a conversation, not a TV game show. The facts are to be extracted from what the candidate says. The most valuble information is what you get by reading between the lines.Asking for a code sample is a good idea, as is the debugging exercise. The pseudo-code exercise has merit, but it has to be simple enough to stay within time limits. None of these things will identify the best candidates, but it will surely identify the worst.
I am always amazed to see hiring managers that are over-relying on credentials and memorization-style questions. Some of the most talented IT people I ever met are those who came from non-traditional educational backgrounds -- essentially people who fought an uphill battle to get into the IT dept. and an even more uphill battle to get promoted.
Somewhere along the way, hiring managers forget that a good programmer is not the person who can memorize the syntax of a language, it's the person who can learn something new by spending 5 minutes with a manual and crafting a crude-but-workable piece of code that can be later refined and used in a project.
The programmer can be compared to a composer. Essentially, we want a person who can write a song, and play it for us on a piano. We want a good song; the ability to play piano is secondary. The hiring process tends to produce highly qualified piano players who have degrees in music and have memorized hundreds of other peoples' songs. It sounds great when they play, but they can't write a damn thing for themselves.
Re:Show me the money.... (Score:3, Insightful)
If you are keeping your eyes open, then either your desire is just money, or something else it wrong. My guess is the former.
I'm astounded by this attitude. Are you seriously suggesting that there is something wrong if your employees keep their eyes open? Are you seriously suggesting that if an employee is happy working for you, then there is no possibility of a better job coming along that might be more in line with what they ultimately want to do?
Personally, I don't feel this need to hold employees in bondage and take it as some personal insult if they happen to find another job that is better for them. I don't know; maybe I'm just weird but I'm happy for people personally when they are able to find something better. Sure, it's a pain in the ass to replace people and often I wish they would stay, but I just don't feel this greedy need to hold onto every employee at all costs, and think "that ungrateful, disloyal bastard!" if they happen to find something better.
To be honest, it sounds like you (whether you think you do or not) look at employees as chattel who shouldn't dare to think their might be something better than what you offer. Maybe you should expand your outlook a bit and think that maybe employees are human beings with their own disires and ambition, and your job offering may not match what they ultimately want.
Re:Show me the money.... (Score:3, Insightful)
Wouldn't it be more effective to identify the superset, thus ensuring that you don't overlook good programmers who don't meet your more restrictive criteria?
Identifying the subset exposes you to the following risks:
Your subset includes only the least qualified of the applicants
Your subset doesn't identify any candidates at all
You're mighty quick to attack other people's logic skills, there, partner.
Re:Show me the money.... (Score:3, Insightful)
Not usually.
Logic is all well and good, but for those who haven't noticed, it tends to break down a bit where human beings are concerned. When we are in a position of evaluating other people, we necessarily rely on certain prejudices based on our prior experiences or information gained from other people. In some cases, the prejudices are unjustified (eg: I don't like people with beards because I was mugged by a guy with a beard once) and sometimes, they are justified (eg: among the people I've worked with over the years, the ones who are willing to correct me tend to be more intelligent and resourceful). Regardless of the genesis of the prejudice, however, you will *always* eliminate some people who otherwise fit your criteria.
The reason we do it this way is simple: because we just can't cope with too much information. The nature of our brains is such that we *have* to simplify input in order to analyze it. We seek patterns (that sometimes aren't there), we prejudge based on past experiences (that sometimes aren't valid), and so on. This is a *human* thing, not a logic thing.
Ideally, I suppose, we should sit down with a committee, come up with all the possible criteria, weight them for a particular position, give the prospective applicants a detailed questionnaire based on the list, enter it all into a database, and have a computer sift through it all to find out who is the BEST applicant for the position. Unfortunately, we're likely to forget something... and that approach doesn't leave room for the applicant to add some surprising detail that puts them over the top.
So until our brains are significantly augmented, we're going to continue using "illogical" methods to cut down the amount of information we use in making decisions. Address complaints to the psychology department of your local research hospital.
Get them to code... (Score:2, Interesting)
Re:Get them to code... (Score:5, Interesting)
I hate, hate, hate, hate, *HATE* programming questions during interviews.
I'm nervous enough as it is without having to spew code on demand. If all you want is a mindless spewer, buy a coding-tool. They're cheaper and don't require benefits.
Personally, I'd rather be involved with design and architecture.
At one interview someone asked me about how I'd do something with a linked list or somesuch, and I asked him why was he using a linked list for something that'd be better off in an array?
That stopped him cold for a second... He asked why I'd use an array instead of a linked list and upon hearing my answer he put his list of prepared questions and put them aside. "Finally!" he exclaimed, "Someone who's *thinking*!"
Unfortunatly I didn't get the job...the company laid off 20% of its employees the next day.
In another interview, I was asked another coding question. My solution worked, but didn't match what the interviewer was looking for. In fact, I poked a few holes in their "correct" answer. Didn't get that job either. Rule 1: Don't piss off your interviewer...
Anyways, this is why I don't like having people write code for an interview. It doesn't tell you a lot, and usually just unnerves them even more.
What is a "good programmer"? (Score:5, Insightful)
There are, of course, a whole range of programmers from the code pounder to the system architect. Are you looking for someone who will produce tight code from a very well defined set of specifications? Are you looking for someone who can take a general "we'd kinda like this" and create code?
How were you "burned" the previous times? Did the interviewee misrepresent themself or did the project turn out to be different then what you were trying to fit the person into?
Another thing to remember when interviewing potential candidates is to look at your current staff and see if you can promote one from inside. That way you can interview for a more entry-level/well-defined position and increase morale by advancing your current employees.
The real answer (Score:4, Insightful)
The *only*, absolutely, unquestionably the *ONLY* way to evaluate a programmer is based on direct past experience with them. There is NO OTHER WAY!!! Everybody is completely fooling themselves with all the dumb little tests and riddles and IQ tests and evaluations. It is absurd. Hire programmers, evaluate them for a couple of months, and if they do not work out LET THEM GO. During this recession there are many more deserving programmers that need jobs. During an expansion is also a good time to let unproductive programmers go, since they can find a more appropriate position easily.
There are a few magical people who actually can evalute programmers based on an interview. These people do not use any tricks -- no tests or riddles or exams or anything. They just talk to the person for awhile, and they seem to always make the right decision. This is not a skill that can be taught or explained -- some people have it, the rest of us never will. If you can find a good manager like this, hire them, and your company will have guaranteed success. (There is a little recursion going on here, granted, but in the long run things either work out or they don't.)
All of these "interviewing methods (TM)" are arbitrated by people stoking and strutting their egos. Why can't you just admit that you don't know the answer sometimes?
What do you want to hear? (Score:3, Interesting)
My personal opinion of interviews is that you should be interested in 2 things:
1) do they know what you want them to? and
2) are they good workers.
The problem is that people try to add any of these criteria:
3) do you LIKE them?
4) Are they professional enough?
5) do they fit into the corporate image?
6) will they stick around?
None of which are useful for hiring employees. Sure you may not want to invite them to the company picnic, but man can they crank out the work.
I would also like to point out that "productivity" is overrated, unless you are ranking on a scale normalized for "quality" of program (quick scale = lines of code/errors found later)
just my rant for the day.
easy (Score:5, Funny)
Programmer:
Interviewer: What do you do for fun outside of work?
Programmer:
Interviewer: Hmm. What do you look for in a woman?
Programmer:
Interviewer: Great then, one last thing we need to check...
Programmer:
Interviewer: Ok then, see you Monday.
The "Dave" theory of gender distribution. (Score:3, Funny)
The number of women present is less than or equal to the number of men named David.
Balanced binary trees... (Score:2)
Interviewing Programmers 101 (Score:5, Interesting)
The key to interviewing is to scope out the person's general work ethic, overall personality, and how well the person can do the job they have applied for. That's it!
In previous Slashdot threads we have learned that it's not wise to sit programmers down with a pen and paper and get them to write C code on the fly! Yet... the interview techniques you are mentioning are a lot like that.
Getting people to 'think on their feet' is good, if you're just talking concepts and ideas, but don't expect people to get things 100% right sitting at an interview table. These guys are programmers, not TV evangelists with all of the answers at the tip of a hat.
From the sound of your post it seems like you have interviewed people, found them to be great at algorithms and answering your questions, but then have found their work ethic stinks or that they're not as ingenious as you thought they were. That's because you assume that someone who can answer questions quickly and proficiently is a good programmer. Wrong!
Instead, look out for programmers who list extra-cirrucular projects on their resume. Look for programmers who have worked on their own projects, and can demonstrate them for you. Would you rather employ someone who coded a great deal of Gecko, or some gimp who can answer your algorithm questions?
Look for people who don't need incentives to work, but those who will program whether they get paid or not! Those are the people who will stick with you, and aren't just learning new languages to make a quick buck.
New Slashdot Section? (Score:5, Insightful)
It seems that we have a collection of these articles and comments in our little community. CmdrTaco, why not put together a new section with a theme of Technical Recruitment.
Perhaps this new section could include these helpful questions and resources following the current re-education and recruitment techniques of the industry.
Any thoughts?
You shouldn't. (Score:5, Funny)
-JDF
Re:You shouldn't. (Score:5, Funny)
Manager: Where do you see yourself in 10 years?
Programmer: On the other side of this desk, Bob.
Re:You shouldn't. (Score:4, Funny)
So you only want managers who can't code?
<sarcasm>Heaven forbid you hire a programmer with managerial aspirations. If you did that you might end up technically competent managers, and we all know programmers don't want those.
</sarcasm>Joel's got help (Score:2, Informative)
Technical questions are irrelevant (Score:5, Funny)
And to be honest, most projects don't require skills nearly that nebulous. How many projects today are: get the data off the screen, validate it, then create the invoice.
The bigger question is whether they'll actually work hard on their jobs, or just play on SlashDot all day. And I don't know how to interview for that (and obviously neither do my employers).
.
Our interview process (Score:4, Interesting)
However, the one thing that is difficult to test but really seems to be the deciding factor of a new hire "working out" or not, is whether or not they have the "passion". One way we try to determine their take on programming (just a job vs. a fun hobby) is to ask them to describe one software project that they have developed on their own time (not on the job or necessarily part of schoolwork). It's amazing how few actually code for fun or just to continue the learning process.
We then ask them what their favorite joke is just to jolt them a bit and see if they have a sense of humor. Most people fail this question, unfortunately
Re:Our interview process (Score:5, Insightful)
Re:Our interview process (Score:5, Insightful)
Check their grasp of reality. (Score:5, Funny)
Some example questions would be.
Which compiler do you prefer?
Complete the sequence. 2, 4, 8, 16, 32, 64
Are the voices in your head loud enough to disturb your coworkers?
Story about a guy at work (Score:5, Funny)
Well, 10 minutes later, the president came back in the room, and there was a web browser displaying his creation -- a single sentence, "Hi Tim, I wrote a web page" in bold and italics. Up on the screen were other web browsers containing internet searches about basic HTML, as well as the output of "view source" from one of our web pages.
Three years later, this guy is still with us, by far the best customer service manager we've ever had.
I guess the point is, give the person a puzzle that you know that they have no idea how to solve, and give them the resources to figure out how to solve it, and see what they do.
Re:Story about a guy at work (Score:5, Funny)
"Here's my computer. I'll be back in 10 minutes. I want my box rooted 10 ways from Sunday. Make me your bitch."
Otherwise, it's was pretty clever. I guess your boss was a bit shocked...
Re:Story about a guy at work (Score:5, Funny)
Does he get oral sex in the meantime?
Re:Story about a guy at work (Score:3, Funny)
simple (Score:3, Insightful)
Ask questions of humility. That should be a good indication. Honest people will have no trouble telling you of their past mistakes and faults as well as their strengths and abilities.
If someone only tells you all the good they've done [e.g. positive outcomes] then they are either a miracle or holding things back.
Tom
Don't Focus on Quiz Questions (Score:5, Insightful)
I've been on both sides of the interview table, and from what I can tell, most interviewers fall into the same trap: focusing too much on detailed technical questions. In reality, your programmers are going to be involved in much more than writing eloquent solutions to programming problems. Your programmers will most likely be involved in project management, project design, project implementation, project testing, and project deployment. Be sure not to get wrapped up in asking too many questions like "how many bytes in a java int?" Instead, look for good all around problem solvers. Ask about their design experience and what tools or resources they have used in designing previous projects. Ask how they would handle testing when a project has been under-quoted. These are questions that good problem solvers will be able to answer quickly, and those who "studied" for an interview will not. It will give you a much better idea of how your potential employee would work out in your business. Be sure that your interviewee will not only be a good programmer now, but also in the future when your development tools change.
Another useful tool for an employee interview is to have a break for lunch with a group of your staff. This will give you and your staff a chance to meet the interviewee in a less structured environment. Many times, an interviewee will relax a bit during your lunch, and you get a much better idea of the person's attitude. Someone who answers technical questions very well may turn out to be a social dunce. Or you may find that the person doesn't share the goals of your company. It will also give your staff a chance to find out if they fit in with the group.
If you don't feel satisfied without asking some technical questions, be sure to ask questions which apply to your framework, and not necessarily the programming language you use to implement that framework. For instance, if you design using Object Oriented principles, ask about "has a" and "is a" relationships. The idea is to ask questions that are still relevant if you change languages from C++ to Java or to some other language.
Using some of these ideas, my company has been able to easily pick the good candidates from the poor ones. YMMV: good luck!
And the almost always overlooked flip question. . (Score:5, Insightful)
I'll bet the answer is well over 'one.'
You're looking for a magic bullet. A simple mechanical reduction of human issues. It doesn't exist.
The only sure fire way I've ever found of evaluating an employee is to give them something to do and see how it works out, bearing in mind that often times a person with mediocre skills turns out to be a very valuable employee and those with great 'creds' often turns out to be nearly worthless. That's why God invented the probationary period.
To get a better look at what I'm driving at here take a look at another flip side. *You* are asking this question because you are performing less than 'perfectly' at evaluating prospective employees. Why? Because you're humans. You yourself are too complex to easily reduce your performance to a repeatable, mechanical formula.
It is always, ultimately, no matter what interview and evaluation process you impliment, going to come down to what it has always going to come down to, an educated guess and a gut 'feel.'
And you'll make mistakes, you'll hire people you shouldn't have, and *you'll let go people you should have kept.*
Thus it has always been, thus it will always be, as long as it's people we're dealing with.
KFG
The problem appears to be... (Score:5, Insightful)
I worked for a startup company back when it was the cool thing to do. The nerds with titles were debating how to interview for a new position, and the battle came down to this essential problem - which is the best question:
1. What is java.lang.Thread.join()?
or
2. Tell me about how you start and stop different execution paths in a multithreaded application.
If you ask (1), you get a code monkey. He or she will write good code when given proper instruction because he or she has a minimum set of skills. Code monkeys can handle hammers and screwdrivers because they've used them before. Ask them to use, say, a quarter sheet finishing sander and they will be confused.
Ask (2), and you get an engineer or a scientist. Knowing that you can wait for the termination of a thread in java with join() is nice, but understanding the implications and uses of join() is ten thousand times more important. Understanding the concept is more important than perfect syntax.
My suggestions for questions are these two, because I think you are less likely to pick a code monkey and more likely to pick an engineer:
1. Tell me about a project you are particularly proud of, and explain some of the technical issues you faced in finishing it. (This is a good question for several reasons. First, you get a good sense of interpersonal skills, because they have to tell a story. You also can gadge a candidate's general interests in the larger field of computer engineering/science, and a feel for their particular strengths. Lastly, you get to see whether this candidate is a finisher or a ship-it-when-it-compiles person because you asked about finishing a project, which is never the most glamorous, but frequently the most important part of being a software engineer.)
2. Tell me about a project you worked on with a team. What kinds of challenges did you face and how did you solve them? (Again, story telling, this time with a definite bend towards interpersonal skills. You also get to assess team work skills, etc., in a technical environment. When I was asked about this question I talked about how my junior design project team needed to be more organized to meet our project schedule, so we got stricter about version control, documentation, etc. If the candidate tells you story about this irritating person or that jerk, you should consider whether or not you're going to be the jerk he talks about in his next interview.)
My top ten questions... (Score:5, Insightful)
2] How did it work?
3] What did you do on it?
4] At our company, we have this general problem X. What are your first thoughts on how to solve it?
5] How would you rate yourself in (language)?
6] A language specific question. For instance in C, what does "volatile" mean? For C++, write code whose meaning would change if you used the keyword "virtual" in front of a base class. (Note: passing the test is nowhere near as important as that it generally matches with the answer under #5).
7] (Note: several questions may be done in this area - again, it is more important that skills are accurate on the resume than everything is done exactly right.)
8] Say you have a technical disagreement with a fellow programmer, and you really think you're right. What are the steps you'd take to resolve it?
9] What sort of software tools are you familiar with? How to you coordinate development with other engineers?
10] What are the things you expect from the company for us to make you happy?
I have noticed in interviewing that engineers can easily spot other good engineers. If you can't, it's because you can't program yourself. So go get someone with the skills to do your interviewing for you.
DO's and DON'T's (Score:5, Insightful)
DO NOT make them solve brain-teasers on the spot, regardless of what joelonsoftware.com might say. I love brain teasers personally, but trying to get all the members of U2 across a bridge two at a time doesn't exactly translate. Reread number 1, and if they gave you their stuff, you're safe.
DO ask them to review code from your shop and tell you what they'd do differently. Whitespace, comments, logic that should be pulled into functions or other objects -- these are the kinds of things a good programmer will notice. A good potential team member will even point them out, point blank.
DO NOT discriminate because they haven't programmed in your particular programming language, unless the work is very short term. They're all dialects of the same language. Good code is good code, even VB! (Note that I didn't say "working code" -- I *mean* good, commented, well laid out, non-repetitive code) The only exceptions are pointers and object oriented code. Some people just can't get it. Test them [by showing them code to review] if you use either.
DO look for someone who gets passionate about a topic during your interview.
DO NOT for one second think that someone who claims they have 10 years experience in C, VB, Java, and FORTRAN means it. Ask what they've done which each language. If they can't tell you in enough detail that you can envision it, that's a "no hire".
DO, for heaven's sake, call their references.
And most importantly (and this is something olde Joel gets right), "Maybe" means "Don't hire". If you can't strongly recommend the candidate after the interview, don't hire him/her. Mistakes at hiring time will cost you for months and maybe years. It's worth spending the extra month or two to find someone worth their salt. Oh, man, it's worth it.
The 'Toilet Tank Test' (Score:4, Insightful)
The 'TTT' is designed to find out if the person thinks about programming off the job, if programming excites them and just doing it is enough to motivate them all by itself. It works like this:
(After technical, logic puzzle and attitude questions are dealt with)
-- First Interview --
INTERVIEWER "OK, so let's suppose I walk into your house and go into your bathroom right now. What magazines would I find on your toilet tank, or wherever else you keep magazines you read often?"
INTERVIEWEE 1 "Uh... Golf Digest, Sports Illustrated, People I guess." (Doesn't mention Penthouse.)
INTERVIEWER "Thank you for your time. Don't call us, we'll call you."
-- Second Interview --
INTERVIEWER (asks 'TTT' question)
INTERVIEWEE 2 "Uh... Linux Journal, Dr. Dobbs, Game Developer I guess." (Doesn't mention Penthouse.)
INTERVIEWER "When can you start?"
Jack William Bell
Don't Ask "What", ask "How" (Score:5, Insightful)
The old adage about "if all you have is a hammer, everything looks like a nail" is what I'm going on about here.
If your candadate only knows one thing ( Java or Delphi, or C++) be wary.
If the candidate knows something useful about a wide variety of things (Java, Delphi, C, C++, shell scripting, XML, XSL, HTML, CSS, Perl, Python, Ruby, batch files, SQL, XQL, servlets, JSP, ASP, PHP
Before anyone chimes in with the old myth "you can only know one thing well" - I agree completely, you can only be an expert in one or two areas. But you CAN know a dozen (or two) things well enough to know which to use - one of the brightest developers I've ever met was a guy smart enought to say "I shouldn't do this - it needs X and I don't know it well enough. Give this to person A and I'll pick up what they are currently doing." This same guy scored 100% on the Java certification exam - he's that good.
Ask your candidate what tools they know - from what vendors. Don't settle for one or two - keep pushing for as many as they mention. Ask them to explain how they would choose between tools - if needed, give them a scenario or three.
One of the things you're trying to find with this approach is how well they might understand the principals that underly the languages - just as you wouldn't ask a fish about water, you can't ask someone who knows only one tool to critique that tool.
Another idea is to get your candidate to give a five minute off-the-cuff presentation on something interesting. Limit it to stuff relevant to the position you're interviewing for, but otherwise leave it open for the person to choose for themselves. They'll choose something they know well - look for how they speak, how well they explain, how well they teach. Also shows how they work under pressure.
pairing (Score:4, Insightful)
Then ask yourself (remembering that this is your first pairing with this person)..
Did I like this person?
Did he try to work with me or against me?
Was he technically capable?
Was his technique compatable with yours?
Could he adapt to your style?
Could I corroborate daily with this person?
Does he smell ok?
Did he offer to buy you lunch?
Was he enthusiastic?
If the answers were yes or mostly yes, then you've got a winner.
Knee-jerk responses... (Score:4, Funny)
1.
2. For myself, having hired several
bodybuilders who haven't programmed...
Beware of complex answers... (Score:4, Interesting)
People who have "training" but lack skill or experience are desperate to show you what they know. You can ask a very simple question, and they'll throw out names of tools they think might be relevant, and buzz words they've heard. They're unlikely to give you the simplest answer.
I once was asked in an interview for a DSL installation tech job, "if you installed a memory upgrade into a laptop, and upon boot up the new memory wasn't recognized, what would you do next?"
I felt kind of foolish saying "Well, I'd open up the laptop, reseat the memory, and try again." But the interviewer nearly wept... he'd been interviewing people with all kinds of "qualifications" all day, and I was the first person who had given this answer. He told me how everyone else had said "Well, I'd start up Tech Tool..." or "I'd get out a memory tester and..." without even checking that the installation had been done right in the first place.
That, of course, is not a comprehensive method for finding a good person for a job, but it might make your technical questions a little more effective.
ask them if they read this article on Slashdot (Score:3, Funny)
Forget diplomas, hire smart people (Score:3, Interesting)
If you care how I can tell the good ones from the bad ones, read on.
It all boils down to someone being proactive in learning things, entusiastic about the field he/she is going in, being able to communicate effectively, and basically have the capability to look at things in more than one way.
In my experience the best thing during interviews is to let them talk as much as they want, you will be surprised how much you can learn from them in just a few minutes. Encourage more conversation by asking short questions along the form of "can you explain that part a little bit more for me?".
Also, to avoid the "bullshit talker", once in a while interrupt them and ask them to described how exactly (in pseudo-code) they solved a specific problem.
It's also a great idea to ask them to draw visual diagrams that explains how things work. This tells you a lot about the way they solve problems.
If you have the time, place them in front of a computer and hand then a piece of pen and paper and tell them to write a made-up documentation for a fictitious project. This will tell you how well they communicate and how well they express their ideas.
During all this, it is up to you to figure out what makes this person special from the others. Is he great at explaining things? is she great at understanding what you mean and putting it down into a design on a piece of paper? Does he come up with novel ideas to solve problems?
That's basically it. I usually refrain (unless it is a basic requirement) from asking language-specific questions (C, Java, VB, etc), since usually a smart programmer can pick just about any other language in a few weeks, and besides, usually newcomers don't start from scrach programming, there's usually an installed based of development tools and written code which can bring him/her up to speed.
Those are my 2cents of wisdom.
The question is stupid (Score:3, Interesting)
It hardly ever happens this way in real life. Many interviewers have no clue what they are looking for. Most questions are egoistic - just to prove that they know something that the candidate doesn't. Last year, a business software company asked me questions about Turing machines and the Halting problem. I answered him and further added that I had never thought about those since school and did not expect to use them at his company. So why did he ask me that? He said he just wanted to test me!
An interview is not a quiz. If you are looking for a software developer to write Servlets, don't ask him higher math and complex algorithmic questions. Try to find out his views on software engineering itself (good practices that we all know about) and technologies related to his job (HTTP protocol, for example).
Also, don't ask a programmer about any specific api or libraries (unless knowing that is specifically his job!).
Don't ask him about tools ("how comfortable are you with Visual Cafe?" is a stupid question").
And so on. Bottomline: Know what you need from him and see if he has that!
The Guerrilla Guide to Interviewing (Score:3, Interesting)
More horseshit (Score:4, Insightful)
If you have to include a "technical interview", not to mention 2 of those, then your company is shit. If your hiring manager can't get by with interviewing the guy/gal with some of his/her folks doing an informal interview (that do have some probing tech questions), then your entire structure is fucked.
A bit ago I went through a tough time at my company, so I started out interviewing. I got 3 tech interviews that asked me questions like "what is the command to increase the frame relay delay timing", "what is the public number for public MIBs", and what are the arguments to display only workstations in a Tivoli system?"
Give me 2 minutes with my books, I would have no problem. Expecting me to memorize all this random shit is just beyond stupid. Go find a 5th grader who memorized the nation and state capitals on the 1st try if this is what you want. If you want someone who actually solve a problem, maybe you want to hire someone who can research the problem and come up with a better solution.
I'm still with my first company out of college. The hiring manager didn't even ask about my skills- he wanted to know if I wanted to learn, if I wanted to gain new skills, and if I was willing to put in the time to learn new stuff. Of course, I'm a DoD system and network consultant, so I need to learn and master new stuff all the time. The couple of corporate projects I've been on have so focused on one single aspect that they get a llama that can program in Java, and they still hire the llama. (Yes, that was mostly facitous).
So go interview the guy/gal about who they are, what they want to do in life and in thier job, how they like to do their work. Don't worry about what languages they can program in (unless thi is what you are looking for), any literate computer person can learn a new language in a few days.
In summary, look at the person, not thier certificatons and answers to crazy technical questions.
Re:Check there referances (Score:3, Interesting)
Re:Check there referances (Score:3, Funny)
Re:well (Score:5, Funny)
I don't have anything against vegeterians either </in our "How to cover up a typo" series> ;))
Re:It's not all about ability (Score:4, Funny)
You MONSTER! Do you know how much it costs to care for and feed a puppy? And you'd inflict this financial burden on poor orphans?
You're sick SICK SICK!!!
Re:It's not all about ability (Score:5, Funny)
Didn't get the job, though.
Re:Hiring a programmer (Score:3, Insightful)
Can't tell you the number of times I've been asked to scribble down some code only to have the interviewer say things like "you missed a semicolon here" or "you got the arguments backwards."
At one point I told him that's what the compiler is for, but he didn't appreciate that... Seemed to think that syntax == algorithm, therefore bad syntax == bad algorithm == bad programmer.
Re:Find missing number 1-10 (Score:3, Interesting)
2 . Scan through the list of numbers and stick them in their respective slot.
3 . Scan through the array and return the element index that is empty (or invalid value, as the case may be)
This is simple, straight-forward, easy to debug and only O(n). Why complicate things beyond necessity? With n unsorted elements, you are going to anyway arrive at an O(n) algorithm (atleast).
Programmers don't write code to fix problems frozen in time. The requirements keep changing and the code must be easily readable and maintainable! These are more desirable features in programmers.
In real life, in 3 months, the problem statement could be changed as - "atleast 2 elements may be missing and you have to return the highest, unless the lower missing number is 3, in which case you need to return 7".
Will the complex algorithms proposed handle this change gracefully?