Slashdot Mirror
How Should You Interview a Programmer?
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?
Unfortunately, I don't have the answer... I tend to look for someone with general problem solving skills, intelligence, and a genuine passion for that they do.
Ask them what they consider a productive day.
if you are asking them actual questions that have definite single answers - what is to stop them from studying for it?
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?
There are some odd things afoot now, in the Villa Straylight.
Ask them a few riddles. For example,
the ones discussed here
My other first post is car post.
... the swap function. It may be simple and about three lines long, but you'd be surprised how many people it weeds out who simply don't understand pointers.
And understanding pointers (even if you use non-pointer languages) seems to be a common trait of most "Good Programmers".
When I applied for my current programming job, they gave me a barrage of tests and compiled an aptitude and personality profile of me.
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.
Robots are everywhere, and they eat old people's medicine for fuel.
...if they answer "42", then hire them.
You cannot go wrong, when you either only hire people you know or hire people, that are recommended by someone you know to be a worthy developer. If you don't get enough people this way, you can always ask the candidate if there is someone who can recommend them.
Have you contributed to any open-source projects?
If yes, then take a look at there work.
thank God the internet isn't a human right.
Add the numbers an -55. Tada!
Remember, the worse he looks, the smarter he is.
Finally, math books without any of that base 6 crap in them.
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
/me closes the browser window
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....
Paul Gillingwater
MBA, CISSP, CISM
Interviewer: Who won the superbowl last year?
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.
Casca
Referrals from your best developers.
"'Given the numbers from 1-10 missing one number, how do you find the missing number?'"
lets examine this question here. If I give you the number's 1-10, minus a SINGLE number, then how difficult is it to FIND THE MISSING NUMBER? maybe thats why you get burned, you're asking silly questions.
Go Figure
This is my sig. Its pathetic.
Ask them when they would implement a balanced binary tree as part of a solution to a problem. The correct answer is "never". You would never want to implement one, since it is so much of a pain in the ass and is so prone to error. In the real world, when you want a balanced binary tree you use someone else's implementation (e.g., STL). Any programmer who would implement one himself is likely to waste too much of your time and money.
My other first post is car post.
The original posters questions and theories are a little weak. Testing a programmer's skills in constructing algorithms for random scenarios is a great idea.. if they need to use lots of algorithms.
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.
mogorific carpentry experiments
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?
If you're interviewing the programmer, you somehow got pushed up to management and are screwed already. :)
-JDF
You'll find out sooner or later anyway, and many techies are best defined by what they simply can't put up with. Might as well prepare for it.
This question tests the candidate's basic ability to discern solid objects in space, as well as their ability to follow directions. To correctly solve the problem, the candidate must be able to use their built-in senses of vision (or touch) to ascertain what parts of your hand can be defined as finger-like appendages, and then to count (starting at 1) the total number of "fingers" you have extended from your otherwise-closed fist. Off-by-one errors are unacceptable.
Laugh all you want, but it really works!
http://www.kylefreeman.com
Joel (of Joel on Software fame) has an interesting article about interviewing, entitled The Guerrilla Guide to Interviewing. The name is self-explanatory, I guess.
"Here's a piece of paper. Write me a program that does ."
I actually had a guy do this to me. I'm a very good programmer, but I don't keep syntax of every language I've ever used in my head, that's what REFERENCE BOOKS are for.
Find someone who understands logic, flow, analysis, etc. and is also good with people and you will have found yourself an excellent programmer. Getting hung up on syntax memorization is retarded.
"I'm just here to regulate funkiness."
Solution is easy! Hire me! C/C++/Java
d ex_files/re sume.pdf
Resume:
http://danwoods.linkedresources.com/in
char *mySig;
Until recently, I would ask for their slasdot ID and then check their karma. I always assumed ability was inversely proportional to slashdot karma.
Ask them if they are a virgin and then convince them that they are.
ender-iii
You start off with "Can I get you a soda or something with caffeine?"
..for the most part. Most programmers with some sort of qualification can get your jobs done, unless your jobs require some amazing degree of skill. I probably couldn't write you out a bug free Quicksort first try, but I could certainly implement it in a real project.
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).
.
Let's not stir that bag of worms...
I would have them come in and instead of doing a technical interview, have a small project that they should be able to complete in a few hours.
Then sit them in a room with just an internet connection and a linux box. See if they can install their compiler of choice, get everything working, and begin coding. Best man wins.
Moon Macrosystems. Sun's biggest competitor.
Our 18-member team likes to have birthday parties every month, and we've got every month covered except September, so we've asked management to make sure our next hire has a September birthday.
At my company, since we're small, we need to know that new developers will click quickly. We do a technical paper exam (one hour) with some standard programming/algorithm questions. We then do a few riddles and logic puzzles. These are the best way to test raw intelligence, IMHO, since you have to think abstractly and quickly. We then do a few more design questions at a white board to test their skills at high-level design and diagrams.
;-).
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
--- witty signature
Ask for a sample of their source, say 300-1000 lines min. and a few example apps of what they've written in the past.
Your own 'good' programmer should be able to tell you how compedent he/she is.
BTW any Goto's... send 'em back to microsoft!
- Simple HR-like questions (i.e. how do you handle deadlines, etc).
- Simple-to-moderate technical questions (i.e. why is it important to use parens in a #define)
- Brainteasers
It's the brainteasers that's where the 'okay' and the 'excellent' really differentiate themselves. The questions I ask have solutions... they take the typical person several days to work out. But I'm not interested in the answers, I just want to see how they think and attack the problem -- can they see the blind alleys? can they recognize when they don't have enough information? what sort of questions do they ask?Occasionally, I throw a curveball. "I see you have experience with the PPC architecture. What's your favorite PPC instruction?" You'd be suprised how many people answer that with "eieio, because it sounds funny". Which isn't a bad answer -- I wanted to see how they reacted to an unexpected question. Another candidate told me once that (for the ARM platform) the bit-invert function was good for writing highly-optimized bit-manipulation functions for banging away at hardware registers.
Through all of this, tho, you need to keep in mind their personality. Will they play well with the rest of the team? That's a difficult factor to judge, and I'm likely to cut a candidate some slack on this.
Ask questions about problems you've run into while working with the lang but not nessecarily related related to the syntax or structure of the lang (ie classpath problems with Java or connection errors with databases)
Most of these are pretty easy to setup a test for on your computer which you should have them use to trouble shoot during the interview.
The other thing you should do is check with their past managers. Make sure that they've actually worked where they said they did and they did what they've said they've done.
And finally look for their name on google!
By the sound of the questions you ask, alot of good coders would probably screw them up in the heat.
I know I could probably screw them up quite easily.
why? Because with those questions your testing invterview skills, not programing skills. I'm a shy and nervice guy, as such in an interview I'd likely get paranoid and worried and just blunder everywhere (and probably try to answer too quickly). Even though I know the answer.
Someone who is good at being interviewed would take it calmly and answer calmly, correctly.
And as you probably know, most good programing geeks arn't exactly totally out there and self confident.
What you want to do is two things:
a) Look at their previous work. What projects have they worked on, what have they done personally in there own time. Ask them to submit any work they can do.
b) Make them feel comfortable and then ask them technical questions, but in a chatty way so they don't feel pressured, it shouldn't be a Q&A type session.
Disclamer: I've never interviewed people or been interviewed. But I am a programer, and have had two jobs as one (one I'm in now).
Cheers
David.
stuff
One of the reasons I contribute to open source projects is to learn something new that will perhaps be needed for a future job. In the interview for that job, I would think that being able to point to source code that is in production, so to speak, would be a tremendous advantage. Has this been the case for anyone? Has anyone gotten a job primarily due to related open source contributions?
...casually ask them where they post. Then ask them what their User Name is. Then go read what they have written.
Not only will a handle like LuvWarez or MyBossSux tell you a lot, but I suspect that over time a person's SlashDot messages (for example) are a good indicator of their real personality and attitudes. And intelligence. And sense of humor.
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?
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
give them a piece of paper with the word "Slashdot" on it. If they pull out a pen and scribble "first post" at the bottom of the page, don't hire them.
Ask him/her to do something repatly, if he organizes a way to do it faster, or to do it easier then just repeating each time a different way, the he/she is a good programmer. ;o)
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
I think this is a good question:
How do *YOU* make sure the code you write is of good quality.
The answer must involve a discussion on what characterizes good code, *AND* how this particular person gets his/her code to that goal.
It should reveal if the person doesn't understand what quality is, and/or if they have no idea how quality code gets written. A good programmer needs to know both these things.
It is a really hard question, and I think it would be pretty obvious if you try to bullshit yourself around it.
Mats
Ask them about their for-fun projects. This will break the ice, and give you an idea for their level of geeky enthusiasm for programming. It will also give you a look at how they approach problems, and will give you a good buzzword-free handle on the sort of thing they are good at.
If you task a programmer with things similar in nature and challege level as the stuff they are doing for fun on their own time, you'll have a better fit to their skills. A programmer knows what they can do, and they will use everything they've got on their own projects. A programmer with no projects of their own probably lacks design skills and is more of a coder than a programmer.
It may help to point out that you're not asking this so as to steal away the projects, but rather to gain a better/wider picture of one's experience.
(I work as a programmer for perspective information).
---
Play Six Pack Man. I
I recently started work for a small comany that has a pretty solid core staff of people that have an average tenure of about 5 years. As part of my interviewing process, I was introduced to a standardized test that one of the executives had recently learned about, taken, and felt was an excellent measure of an individual's professional and personal fit in the organization.
While I don't tend to put much stock in most standardlized testing, I am currently sitting at my desk at said employer and must, therefore, acknowledge that the process played some part in my receiving an offer.
The push now is to apply the test to everyone in the organization, to pick out common themes of people who've been part of this company for some time.
While I'm not sure this would have any bearing on assessing someone's performance in a technical role (there are some reasoning aspects to the test) it will help to ensure that there is a sanity check as to who is a good fit moving forward.
Perhaps this is one way to address the issue, as someone who gets along with peers and can relate to them, is more likely and willing to mold into the culture of the organization.
"I'm disrespectful to dirt! Can you see I am serious?"
One of the best phone-interview questions I was ever asked was "what mailing lists are you on?"
Ask them how much they've done in the past 3 months to improve their skills. If they say nothing, show them the door. A good programmer is always looking to expand their skillset in some way.
The Blaster Master Fighting for Truth, Justice, and Evil Pie since 1979
Much to a lot of interviewee chagrin, I advocate the employment of logical puzzles as part of the interviewing process. By throwing the 'technically-inclined' candidate a logical problem, and asking for thoughts aloud, the interviewer can test the applicant's ability to formulate correct assumptions, heuristically test solutions, and explain their reasoning/rationale.
.. and if those aren't valid points, every interviewer should have some lithe trick up their sleeve to make the interviewee squirm. =)
/.'d, there exists an expansive collection of riddles/logic puzzles/etc. at http://www.ocf.berkeley.edu/~wwu/riddles/intro.sht ml
For those who may have missed it the first time it was
Pick the one with the highest percentage At home.
This is such a tough thing to do. I understand why there are the strange creative-thinking or logic problems offered-up to applicants (How many bricks would you guess there are in this building? How many gas stations are there in Florida? Using a 5 gallon bucket and a 3 gallon bucket, give me four gallons of water -- not sure the wording on this one). I have never been very good at logic problems like Brad has on a green shirt and is sitting next to a woman; Mindy is wearing a blue shirt and is sitting beside someone wearing a purple shirt; what color shirt is Tracy wearing? I would have never made it on the LSAT test for law school. Of course, I have never claimed to be a great programmer or anyone dedicated to reading enough to be an attorney.
Good luck in your hirings! At least it sounds like you can get rid of staff if they don't work out. I have seen terrible people get to sit on the job endlessly because the company fears firing anyone from the liabilities. I have worked with a CNE (Novell Netware certification) that had never built a Netware server, didn't know how to create/manage print queues, and could not figure out Groupwise or Netware Connect. I have worked with some "Linux experts" that didn't know what an inittab was for, could not install Linux, and were totally clueless when it came to installing software. I have also worked with programmers that used all global variables, did not put things into separate, clear functions (500+ lines of c in main() ), and couldn't figure out how to do anything from scratch. They all got to sit around while someone else (me usually) covered for them!
Click here or here.
One the best techniques I've used (or had used upon me) is to pose a general problem, maybe even one you've encountered before on this project, and see how the candidate addresses it.
The trick I've found with these sorts of questions is to pose it very broadly at first ("This piece of the application goes slow. What do you do to make it go faster?") Then see what kind of questions they ask you. ("How is this piece configured? Have timing measurements been taken?") What they ask you can reveal much more about their thinking processes than any puzzle-type questions you ask them.
Beyond that, identify the three or four key skills that will be needed for the position, then come up with two sets of questions for each: a normal set and a mean set. The normal set should contain questions that any programmer with a reasonable amount of experience should be able to answer. (For example, a Java question might be "Why would I decide to use an inner class?") Then you can ask mean questions to see how far their depth goes ("You can't use the keyword synchronized on a static method. Why?")
Always always always get them to talk about a past project. Drill into their knowledge and find out exactly what they did.
-- What is this Earth thing you call "slow"?
For programming questions I tend to ask high stress problem. Such a problem has a simple solution, but it is non-obvious, and puts people in a time crunch. One such problem I would use is find a regular expression that you can put into the search box of your text editor to find the first c-style comment (no "\/\*[^]*\*\/", and "\/\*.*\*\/" don't work, although they are the most common first answers). Things that I've run across that were harder than I thought they would be or have elegant solutions that I didn't think of right away. I have several from my college classes where the professor presented something and the whole class gasped, and said, "Why didn't I think of that?".
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.
- In Capitalist America, law violates YOU!
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.
"Is friendship inherited?" is just a bad interview question. Are you looking for specific programming languge knowledge, or the knowledge to search for answers? "How would you find out?" indicates the latter. Phrase the question accordingly: "If you wanted to brush up on friend classes, where would you turn?"
Depending upon the skill set you're seeking, algorthimic questions should be of an appropriate level of difficulty. "Given 1-10, with one missing..." is a question my mother could answer without any knowledge of computer science. If you want to check for algorithmic understanding, pose a graph problem. They're easy to visualize and easy to describe. You should get some stock answers like Dijkstra's or BFS or Kruskal's... Then ask for the person's own algorithm to see how he reasons through the problem and modifies his approach. This helps test for intelligence and flexibility in thinking.
As for testing team skills, pose both hypothetical questions and real-life questions. "What would you do if a person in your team was not pulling his weight in a project?" "Describe a time in your life when teamwork was essential. What were some problems you encountered?"
In general, the best thing you can do is force the person to talk. Not just simple, short technical answers, but stories and long "essay" answers. You shouldn't ask specific details about C++ ("In a switch() statement, how you specify the default case?") but general questions ("When would you use a switch() statement?"). Of course, you would want to ask harder questions, but you get the idea.
The best interview I had was with the CIA (Central Intelligence Agency). Did they care about my technical skills? No. They had my resume and my transcript. Every question got me talking about myself. "Tell me about a time you failed" separates the men from the boys. And you get a good sense of who this person is... which is the goal you're really seeking.
If he comes back to you with a kick-ass Linux box, hire him. If he comes back with a Windows box, tell him you'll let him know. Then hand the box to the next candidate and say:
"Given this computer, a T1 line and 5 hours, build the best server you can."
Repeat.
This may sound trite, but I've seen it happen successfully over and over in the past three years the tech world has been languishing: Hire people you've known professionally. There are a lot of folks that got tech jobs due to the dotcom expansion who would have otherwise not had that exposure. The VC money was just phosphorus for the tech algae bloom, though. Now the colony if is dying off, and the strongest ones survive. Trouble is, some of the weaker ones can fool you into think that they are really strong ones. The only good way past this is first- (or even second-) hand knowledge about the person you're hiring.
It's common knowledge that the the job boards (Monster, Dice, et al.) are completely useless and that the only way to get a tech job is to get a referral/offer from someone you already know. So it stands to reason that the people who are looking for work either don't know anyone else professionally (not a good sign) or they know people professionally, but those people either can't or won't hire them. You can't tell the difference between them all from one interview/phone screen.
Interviews are like references: they can be as useful as the interviewee is honest. But the best way to hire good people is to hire people whom you know are good. Failing that, hire someone as a temp, on spec, for a probationary period, etc. If they work out, then hire them full time. There are a lot of very talented people out of work, and it's something of a buyer's market. If you have a decent position open, then many people will put up with being a temp in order to secure the permanent job.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Traditionally, interviewers would ask clever questions requiring the candidate to think on their feet. Of course, if the candidate has heard that question before, they will slam-dunk the answer regardless of their intelligence/ability. From earlier stories, lots of
The other approach is to ask the candidate what they've done and how they did it.
- Describe the design patterns you used on your last project
- Describe a difficult algorithm you had to write recently and how you wrote it.
- Describe a problem you had on your last project and how you solved it.
- Describe your role on your project team.
- etc...
Then, take their answer and drill into more details on it. Try to understand their process of working and solving problems on a real project.I think this approach works well.
At one job interview, I was asked "What would you do if you found $2500 on the street?"
I said, with a shit-eating grin on my face, "I'd buy puppies for orphans", and was hired on the spot.
In any case, I think a good sense of humor is essential, if I was in a position to hire someone, I'd ask them to tell me a joke during the interview. You can learn a lot about someone by what they think is funny. An employee's technical ability can be improved as needed, but their personality is what it is.
-72
-Those who dance are considered insane by those who can't hear the music.
Ask them about their programming "style". I know I've worked with other programmers who are on the same skill level as myself, but have fundamentally different approaches that just did not work well with mine.
Even though a wide array of viewpoints can be important, similar mindsets can go a long way to a team working well together and opposing styles can kill productivity.
Dark Nexus
"Sanity is calming, but madness is more interesting."
I start out with a 15 question test from BrainBench on the subject matter. When I tell candidates that they will be taking a test, about 25% weed themselves out (ie I never here from them again). I only continue inteviewing those that didn't flunk the test. I am not a good test taker, but I think I am a fine programmer. So, I don't want to miss a good programmer just becuase they don't test well. However, If someone flunks the test, that means (to me) that they don't no sh!t. Next, I have a real-world programming problem I faced a while back that I offer to the candidate. During the interview, we walk through how to solve the problem. This gives me a good window into their analytical abilities, programming skills, and general organizational and thought processes. The problem is solved with psuedo-code, but I make sure to ask some questions relating directly to "mechanical" issues of programming (memory amangement, data connection, remote data, Big O, etc). The third ingredient for me is gut feeling. I have a pretty decent knack for spotting BS.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
seek honesty not perfection.
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
Someday, I'll have a real sig.
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!
fill in the blank questions...
1. All your base are belong to ___ ?
This is left as an exercise for the reader.
...don't work. Measure what a person can do based on what they have accomplished. Cute questions, so typical of programmer interviews, only show a specific example under the heat of an interview. A different question and likely a different result.
In the real world, reflection is more valuable than a quick answer. Don't attempt to make a hiring decision based on one set of interviews. For final candidates, stretch the preocess and talk to the person several times over a period of days/weeks. Glean keywords. Get to know the person. How they will work together is very important.
ofcourse it depends of the type of work and team he/she is going to do and join. I don't think there's any magic in it. Once, for example, I talked with our new foreign employee and my present friend only via Irc, for maybe 6 months. That time was long enough to cover all kinds of things, and to solve some real problems along the way - do some teamwork.
That might not have worked in most of cases. Anyway, I think it's generally good that the whole team meats and possibly even "works" with the new possible team members, and make the decision together. That way, everyone has the chance to say "u suck", in time.
So, maybe I think there should be some kind of traditional formal interview part but I think that atleast as important is - especially if you have never met the person before - to do something together.
Sk1llz are not all that matters, I think that the co-operating skills are maybe even more important than being a guru in anything or even everything.
I don't do recruiting for my work, but this is the feeling I have got.
IMO: If you're working on something that isn't terriby secret around the time of the interview ask the interviewee for his/her opinions about the solution to the problem. This gets you a little free (although dubious) advice and lets the interviewee know the sorts of challenges that they will face in the job.
lol I cannot spell omg i think i'll post on slashdot DROOL....
When I applied for my current programming job, they gave me a barrage of tests and compiled an aptitude and personality profile of me.
It was really freaky how accurately it described me...
Not really. The big fault in all these tests are that they are essentially asking you what you think about yourself,
and then spitting it out in different words.
Here's another simple test:
10 PRINT "How would you rate your programming skills?"
20 INPUT ANSWER$
30 PRINT "This is our evaluation of your programming skills: ";ANSWER$
So you shouldn't be surprized at the result matching your view of yourself;
The question is if the test result matches your co-workers descriptions of you.
I am terrible at reciting text book algo's and other terms a CS major would know. I learned to code on my own and take a deconstructionist perspective on coding and architecture. I've always been able to catch on quickly and get the job done, but I don't have the academic background other have. But for me that is a strength, because I learned critical thinking in college. The techniques apply to every engineering challenge I've come across and helps me identify non-engineering problems blocking the solution. I'm no guru or anything, but from my personal experience, the drive to excel is your best bet.
Don't confuse greed and expectations of wealth with a person's desire to improve themselves and reach their full potential. I usually with my gut and think, would I want to spend 7 hours working with this person. If the answer is no, then the chances of that person fitting in the team is pretty unlikely.
Mix that with good behavioral interviewing techniques (ask your HR people for help, in other words) and you should do ok.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
A quite simple test. We give them a compiler, and editor, and a bunch of problems to solve (obviously with the editor already configured for Fn=compile+link). These range from anything as simple as "Make a loop to print ten consecutive number starting with n" to more complex algorithms, over to huffman coding (where they are already give the huffman table) to basic graphics manipulation, a simple sound low-pass filter over a given sound input file (file by name, where the correct output file is present for them to compare) and such.
:-)
This will display a number of skills: Do they know how to even make a loop and print output. Do they know some basic computer algorithms. Do they know file in/output...
It might sound silly, but I don't think you'd be surprised how many of our applicants fail. Hell, it seems half of them don't even know there is something called CRC, much less can they explain what it is, does or is used for in an abstract way (without requiring them to even explain the polynomials or the inherent complexity - which is well beyond even my comprehension). Many seems to have fiddled with VB for a week and two and then come to the conclusion (probably due to M$ hype): "Hey, I'm a programmer!".
What I'm trying to say is probably that you have to put a considerable amount of effort into _your_ selection process to see what applicants are candidates for the job you seek for. _You_ have to create the tests. Create them in a hierarchical manner so you can reuse the most basic e.g. C++ tests for a C++ position and so on, but don't EVER ask why manholes are round!
I usually ask if they contribute to open source. Then, if they answer affirmatively, I tell them they can telecommute, give them a design spec document, and give myself a bonus for saving 100 percent on salary!
XOR all the numbers together.
XOR the result with 11.
The number you end up with is the missing number.
a ^= b is the fastest operation a cpu can perform. I think this is the fastest possible way to do it.
Can I have a job?
Check the questions asked here, you may want to include this as a side test: Personality Disorder Test
Do you own your own computer? If so, what exactly is in it and what OS is it running. Please justify each answer.
Basically, if person doesn't own a computer or only owns a Dell that they just bought use to surf the web, then they aren't really "into" computers. To be a good programmer it has to be a hobby too.
The way the programmer thinks is also a value-added skill-set to today's rapid-prototyping startup company.
Such an example would be to ask the Programmer what steps he/she would take to write the code for "Fermat's Algorithm."
Then listen carefully as to how the problem is solved (preferably step-by-step). If the candidate says "google it," firstly, its a pretty good start.
Second would be how the algorithm is ported to C (or C++).
Thirdly would be how the code is organized.
Fourthly, how it would be tested.
and if you're extremely lucky, he'll start writing the algorithm in C on the whiteboard.
Really... the person may not have a clue what Fermat's algorithm is, but the strong-willed, articulated and attention-to-detail programmer will show how to accomplish the problem.
Self-starter... are management's best asset.
Do you realize you're an at-will employee and can be fired at any moment if we don't like you?
I've been through many interviews in my search to find a job, as well as put groups together for specific functions. IMHO, the best interview is NOT a technical interview. I believe any interview should have "technical" components, but barrage someone with syntax questions is no way to find out if they are a good programmer. Broad conceptual questions like : "How would you build a house for a giant?" seem much more useful in finding out how someone thinks. People who memorize syntax and only grasp the concept definitions do not make good programmers. Additionally, do not hire someone who does not seem genuinely interested the work you are doing.
Sigpilot : I'm in the pipe, 5 by 5.
maybe the people you are hiring have psychological problems after a few weeks of working for you. i usually employ a psychoanalytical style of interivewing to check for the likelihood of this.
[humor]
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]
The Future of Human Evolution: Autonomy
I tend to agree with Joel on Software in the Guerilla Guide to Interviewing. The whole goal of your interview process is to determine if the candidate is (1) smart and (2) gets things done. There are a lot of other good tips on that site in various articles. The bottom line is to have them design something so you can see how they think. You're trying to decide if they're smart and get things done. You also want to see if they would fit in with your team (personality). At the end of the interview, if you're not 100% confident it's a HIRE then it's NO HIRE.
Having been on both sides of too many interviews, the best process I have seen is Art & Logics. They require applicants to write a short program using a class they provide. The first "test" of the interview is to see the applicant's response to the class not compiling. If the person write HR asking for a working version, the process is terminated. Besides getting a feel for the applicant's nature, the fix requires a knowledge of the c++ preprocessor. After getting past that hurdle, the applicant is free to design/code the program as they see fit. (They are required to follow certain coding standards). Once submitted, it is reviewed by senior programmers. Those that have done a nice job are then provided an in person interview. By this time, the employer already knows quite a bit about the applicant. As one who hates technical interviews (ie: Microsoft's), I actually enjoyed Art & Logic's. It provided a non-threatening environment that allowed for creativity while being able to learn about my technical abilities. See: www.artlogic.com
Ask questions that allow you to ask "why".
For example: 'Given the following scenario blah, blah, blah, what type of data structure/class would you use?"
When they answer with Tree/Hash etc. Ask them why they picked that answer. Ask for the logic behind the decision. Most people in the field have either read enough/heard enough in school to scam their way through multiple guess, yes/no type questions. But its hard to fake your way through good thought processes. For every "reason" they give, you also have another option to say "why" or "what about an alternative"...In general the "whys" are more important than the "hows".
Ask what the person does with their home computer.
If they don't use a home computer for anything useful (i.e. more then email/games) its much less likely that they enjoy their work than one who uses their computer for other things. Do they write code of ANY kind at home? Do they tinker with the hardware. Do they run *Nix or something else other than Windows?
Ask what they do for fun. Someone with no social life may be productive but will probably cause you other problems because they wont play well with others. They'll be an outcast (i.e. no communication) or they'll just creep people out so that no one wants to deal with them.
I am in the same position at a small company and we've had our share of hiring bombs (excluding me :) ). Here, I think, are some core issues to consider:
1) Decide what you want. Uber genius or uber implementer. Everyone falls in between but I beware of people who claim themselves to be "really into design" when we really need implementers.
2) Don't ask the same old questions. I think most everyone is aware that a book of interview questions can be found online. Sometimes learning the answers to these is as easy as memorization.
3) Find out what the interviewee knows and doesn't know, never just one. One beef I always have is that when I'm being interviewed the interviewer would assume I know some very specific about a certain technology I worked with. Why would I know the specific way threading works on web servers when I've done web applications?
4) Technology and experience must go hand in hand. I think every programmer knows that technology can sometimes be seen in terms of an API. While experience is useful, so is design experience (and vice-versa). One doesn't necessarily make up for the other.
5) Ask relevant stuff. While intelligent people may correlate to good programmers, intelligence alone might not make up for lack of experience and/or the ability to learn new technologies quickly. I've had my fair share of algorithms and trick questions asked to me at jobs where I never implemented any sorting/searching algorithm nor did a project on how to measure time by burning candles. One thing I would look for is initiative to learn new technologies. Did they learn how to design and implement a web application on a short 6 month project? Or did they just manually fix html bugs for 1 year?
Lastly, if you're unsure to hire than pick the hotter chick (or the only chick).
"Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr.
The first reason is that the programmer's employer is (almost always) the copyright holder of the code. A lot of companies consider their programs to be both property and a protected secret -- asking the candidate to bring in code is like asking them to steal. To put things another way... how would you feel if one of your employees was taking your company's programs to other employers (and potential competitors)?
You could require that the candidate to have done something for the Open Source or shareware communities... but then you're really limiting your choices.
The second reason not to ask for code is because you have no reference for it. You don't know how well it works, how well it integrates into the system... you don't even know if the person you're interviewing wrote it! I have known a couple of programmers who have submitted "brilliant" code samples to the PHB, but couldn't function in a working environment.
On a related note, would you penalize the programmer for adhering to his/her company's standards for formatting code, because they don't conform to yours? I've had interviewers say they didn't like the way I formatted my code, despite the fact that it was required for the job I was currently doing.
My suggestion: set up a computer off the network. Allow the candidate access to manuals, and give them a small programming task (and about 30-45 minutes) to complete, and let them work.
- Why do you want this job?
- What single accomplishment of yours are you most proud of?
I would also have a creative problem-solving question. Ex: How would you walk on water, or, Design me a mailbox. Inspired by Joel's Guerrila Guide to Interviewing, we were content to look for someone who was (a) smart; and (b) got things done. Best way to judge (a) is to have them solve a problem they haven't thought of before (no algorithms! no riddles!). Best way to judge (b) is with the questions above.-Renard
Many moons ago I used to ask questions like "What is your favorite movie?" to try and loosen candidates up. I then got the smackdown from our corporate HR, which informed me that the question could be viewed as discriminatory. Same thing for any questions about "for fun projects" or anything of a personal nature. It's a thin line to walk.
So a whole herd of us manager types got shuffled off to Behavioral Interviewing training. The basic premise is that you construct questions to gather information on specific work related issues they have experienced in the past. Assuming past performance is indiciative of future value in this case, you can get a good feel for how a candidate will perform in a given situation. As for faking the answers, that can be tough to do with some of the questions unless you are dealing with a very gifted improv performer.
Behavioral Interviewing is the norm at several Fortune 500 companies I have worked with. Take a peek at it, and definitely run any ideas you read here past your HR folks. All it takes is one lawsuit and you will find yourself on the other side of the interviewing table.
I also like the interviewee to go through an example of a project that they have worked on, and show me the architecture. I then ask questions about their design and it lets me know how good of a communicator they are. Somebody may be a good coder, but they also have to be able to communicate their design in an efficient manner.
If somebody doesn't understand low level computer basics such as interrupts, semaphores, synchronization, etc. they don't make the grade for me!
Try to get to know them better, and see if they _fit_ in your company. Introduce them to some of the future colleagues.
It's pointless to hire some top notch coder if your company sucks and the guy leaves in a month.
But a not-so-good one might actually feel at home, and turn out much more productive.
If they do, make sure it is open source, their own project, or have authorization to do so.
Then you have to question them on it to make sure it is really their code, not something they ripped from someone else.
Fight Spammers!
It's pretty easy to find out if they've actually done work with that technology or if they're just filling their resume with buzzwords.
I also like to hear the applicant extend his answers. For example :
Me: Have you ever used a Model-View-Controller pattern?
applicant : "Yes"
That was the wrong answer. I want him to say "Yes, when I was building such and such a project we created Java beans to hold the data, Java servlets to be the controller, and Java server pages to control the viewing of the data." That shows me that he's A: not lieing to me, and B: that he really has used it or at least understands the technology.
Riddles, trick questions, it's all crap. You can't determine if applicant A is better than applicant B based on whether or not he knows why manhole covers are round.
One guy here likes to ask the applicant "I want you to build me a calculator program. How would you go about it?" Think about all the logic behind a simple calculator program. It has parsers, language definitions, a GUI and so on. Does the applicant say anything about searching for existing applications and reusing code? Or does he want to figure out a recursive decent parser on his own? Does he even recognize what the task entails? If he's being interviewed for a C++ position does he recognize that in Bjarne Stroustrup's book "The C++ Programming Language" he uses a calculator program as an example of the C++ language. The applicant should have at least read the book enough to know that an example of how to do that program already exist.
Always ask if the applicant has any questions for you. If he doesn't then that's a sign that he's either in "deer in the headlights" mode, or he just doesn't understand you just talked about.
But these are just a few exmples. If you're already doing 2 technical interviews and an HR interview and you're still getting duds then you need to look at the guys in your company who are doing the technical interviews. The problem may be with your interviewers, not the applicants.
I used to review peoples CV (not a job that requires me to spell!)
The most amusing was a CV from a guy who claimed to be a proof reader for 4 years, he also claimed that he wasnt an idol worker.
If i want for a job where the interview/company was lame enough to worry about my spelling then I wouldn't want to work for that company anyhows.
thank God the internet isn't a human right.
One thing that seems to be skipped is a clear description of what you WANT in a programmer.
Most jobs I've had I've had great evaluations due to my attention to detail and care given to corner cases. I pay a lot of attention to the design phases and ask a lot of questions. I communicate about deadlines and the occasional slippage. Project managers tend to love me.
One job let me go after my 90-day eval because they said that I didn't take enough on, didn't invest myself fully, wasn't enough of a self-starter.
From their viewpoint I had a great interview and didn't live up to it. From mine I was left ticked off that they didn't communicate they wanted a shoot-first-ask-questions-later guy. Or a throw-myself-to-the-wolves guy. I'm neither.
Since then I've switched to freelancing and I love it. My clients love me and call me back for their next projects.
Other point - occasionally, I think too much emphasis is placed on the brainteaser questions. Assuming someone's resume doesn't lie, a failure is more likely going to be about work style and personality flaws than someone's brain being too slow. I've had five salaried positions since college. Four asked me technical questions relevant to my experience and a bunch of other questions about what kind of guy I was, and they went well. It was the other one that focused on brainteaser questions like dumping cubes in paint. There needs to be room left for gut feelings in those kinds of decisions.
We've had this problem where I work, and have been fooled by people (well, one person in particular) who had an impressive resume and could talk the talk. He turned out to be someone who couldn't code his way out of a wet paper bag.
Our solution, which has worked very well for the last four years or so of hiring, is to sit the person down in front of a laptop connected to a small and portable flatpanel. I sit on one side of the table, watching the flat panel, and the candidate sits on the other side, working on the laptop.
The entire interview consists of trying to fix all the bugs (and there are many, some obvious and some subtle) in a small command-line tool. During the interview, the candidate is requested to think out loud as much as possible, so that I get a feel for how they're thinking about the particular problems they've been presented with.
Fixing every bug is not necessary or expected -- tackling the problems and presenting good solutions to those problems is crucial. It really gives you a taste for how the person goes about problem solving and how they code, especially under pressure.
Several people have commented that this seems like a severe way to interview, but most of the candidates I've interviewed have demonstrated a fairly good ability to work under these kinds of conditions, and it has improved the quality of our department staff considerably.
Joel Spolsky seems to have a bit to say about this. Try his Guerilla Guide to Interviewing. Of course, not everyone agrees with everything he says, but, in my opinion, he has quite a few insightful points.
You can go here to find all the articles related to growing a software team.
Hope that helps.
The trick isn't to find someone who knows it all, but someone who is aware of what they don't know yet, and is curious enough about it to stay up all night with a puzzle if needed.
"with their freedom lost all virtue lose" - Milton
The standard interview format doesn't work for programmers. The best interview I've been given was from Art & Logic, which is a coding test. It weeded out the weak pretty well, as well as the non-self motivated types (I made the cut, worked with them for a while, then got an offer I couldn't refuse elsewhere - but they're a great team of solid coders).
My only complaint with them is that I didn't get a peer code-review afterwards - I would have liked to have had more feedback on the code, even though they apparently liked it enough to hire me.
A lot of game companies do this as well - I know Acclaim's subsidiary Iguana software used to ask for you to write a Defender knockoff, and I've heard of others.
I write code.
Here's a tech question you could add, and it's fun to show your friends that don't already know it:
Write a swap function that doesn't require a temp variable.
If no one gets it i'll post an answer.
What we often do is hire peopel we like part time to see try them out for 6 months or so and, this is where my boss comes in, we give 'em the axe if we've totally failed or hire them full-time if they are as awesome as we thought.
"Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr.
I first learned C++ in 1991, from Ira Pohl, no less. In 1995 I took a graduate seminar in object-oriented programming, again by Dr. Pohl, while getting my MSCS. I have had a job programming in C++ since 1998. And I would have no idea how to answer that question other than "look it up in my copy of Stroustrup". Class friendship is something that I've needed so rarely in my work that I don't know how it works off the top of my head.
If one of your main criteria for what makes a good programmer is "knows every obscure detail of C++ by heart", then I'm not surprised your hires are not working out.
Know your subject and know what you want done in the project.
And half not a joke. Prepare yourself, don't take this presonally, your mileage may vary, one man's experience, etc, etc, etc...
Programming skill is often proportional to beard length.
Value of code is often inversely proportional to beard length.
What I mean by "value of code" is maintainability, documentation, cleanliness, and all the other measurements besides "cleverness". The worst programmers I've ever had work under me had huge beards and antisocial personalities (of which beard length is often a symptom). These people gave ZERO thought to the programmers who would come after them, and only worshipped at the altar of "cleverness". Their primary objective was "how do I entertain myself today" rather than "what is the best solution for this problem taking into account the business case for the solution".
Once again, I'm half kidding about the "beard test". Mostly I'm issuing a warning against finding people who are TOO into programming for programming's sake, rather than "software engineers" who really like the "right" solution rather than the "clever" solution.
Sometimes it's best to just let stupid people be stupid.
Why is there a "television" icon for "How sould you interview a programmer?" subject?
:)
Someone needs to put the bong down.
Ask them to give you the five most recent articles on slashdot... if they know the answer, then don't hire them -- since they'll just spend all of their time goofing off and reading slashdot :)
How many people have you rejected that would have turned out to be the best people in your company?
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
I've seen an ex-drug dealer turned so-so tech leapfrog over everyone else because of the ruthless bullshit tactics he used. In the meantime, I was stupidly working on technical stuff and got axed.
The slippery anus gets the dick!
If you give them a logic puzzle, make goddamn sure you tell it right.
I was asked a nearly impossible question yet I knew the answer immediately. One guy thought I had talked to the other cantidate before but I didn't. (I was interviewed by a group of people sitting at a table) Anyway, turned out I was perfect for the job. I didn't know everything they needed but I knew how to solve complex problems and that was more important to them than to have it all stored in my head. Later on, they were hiring another person there. He had his MCSE and on his resume it said "I know everything about computers." He had 2 strikes already. 1. MCSE and 2. "I know it all" So the interviewer asked him the pinout of an ATX power supply. He had a blank stare for a few moments and then stood up and said "I don't think that this position is for me." And left.
Nowadays there's so much of an emphasis on code reuse that a person might not know what classes/libraries you use and therefore will have a hard time popping out specific code snippets.
On the other hand, you should ask questions and allow psudocode. This way, you can evaluate their thinking process. It's a little bit tricky, but you can also see their talent level in the specificity of their pseudo code. If they don't say very specific things and have some structure, even though it is pseudocode, you can tell they are bullshitting you.
~ now you know
As for my question I would ask: 'What Simpsons character are you most like?'. If he says anyone other than Comic Store Guy, he doesnt get the job.
What I've found helpful is to realize that in order to find out how they'll perform in the future, it's a good idea to look how they've performed in the past. Towards that, here are some pointers:
Use experience-based questions: don't just ask them how they would solve a tough problem, ask them what they did in the past when presented with a similar problem. This means, don't tell me how you would do something, tell me how you did do something. The proof is in the pudding.
Three words: references, references, and references. If they sound like a good canidate, make sure to check their references. It's impossible to get a very good feeling about a person after speaking with them for an hour. Find out what people who have been working with them for a long time say.
helped out our PM with interviews...
.dlls. I explained the project and asked if they would have any concerns. The ones who talked about being concerned with memory useage/leaks got my attention. Then I asked how they would solve it. I liked one guy who rattled off four or five good tips (maybe split up the program into multiple versions for the different user types... switch from MDI to SDI.. make sure to clean up references to .dlls by expliciting clearing references -- VB is supposed to do this for you, but is notoriously sloppy for doing so).
I like to determine if they geniunely LIKE computers and using them. Some people don't -- they just got inthis for the money. I ask about there computer at home. I don't care if it's old or not, they ought to tell me SOMETHING about it, preferably something like a harry IRQ conflict they had to solve or something.
I want to ask them something about solving a particular problem (in general terms).. in one case we're hiring a VB programmer to take over an existing program. This program is pretty large LOTS of forms and
That's a good example of an answer. Bad example: One guy's response was: Well, the install probably wouldn't fit on a floppy, and you'd probably have to use a CD-ROM... I dunno when this guy last used VB because freakin' hello world ain't fitting on a floppy in VB by the time the installer packs all the GD runtime dlls on it, but even so: Who cares? CDr's cost essentially nothing. That's not the issue. Anybody who knows anything about the industry knows that distribution is essentially free. You're obviously clueless. next.
DO NOT DISTURB THE SE
that you're interviewing programmers, aka code monkeys. They might dance, but they will never perform. You'd probably like an engineer or a scientist. How you interview for them is totally different.
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.)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
Your approach strikes me as combative, ill-defined, and uninformed.
Combative and ill-defined because you're setting the interviewee up with your cagey use of the phrase "when they would implement...". I believe most people would answer the question by describing when it makes sense to use this structure. If you expect a certain answer then you need to ask the question very carefully, unless you're just trying to trip them up.
Uninformed because there certainly are times when one may need to implement such a structure, rare though they may be. You're exhibiting your own ignorance here.
If I were presented with this in an interview I'd likely remove this company from my consideration. I have no desire to work with, or for, people who take this approach.
Remember, they're interviewing you at the same time. Tricks like this will lose you good candidates.
As a professional developer, I might be offended by specific technical questions that I can find the answer to in 30 seconds or less, but don't know off the top of my head.
Three interviews is a large time investment: I suspect that that time would be better spent researching an applicant's past performance through his references.
Geez, how hard is this? You make sure their references are valid and you call them. A given programmer may be able to answer a bunch of math trivia but it doesn't mean he can code or act responsibly in public. Make sure he/she is not a loudmouth or a jerk or a do-nothing. Offer them a project leader job for the same amount and see if they spring back with "Oh yes, I'm really not very technical". BUSTED.
I have been involved in one probation firing and in that case, we didn't call his references. Ya gotta do dat.
If you aren't part of the solution, there is good money to be made prolonging the problem
People who focus on trying to test algorithms and ask a lot of technical questions are either (a) insecure about their own ability (b) Have no ability to tell a good technical match from conversation about approaches rather than detail.
1] Describe the technical accomplishment you're most proud of.
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.
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.
Programmer: Firing you.
pooptruck
NEVER hire anyone for a computer related job that does not have a computer at home. If they have been doing networking for a long time, they should also have a home network. This is a MUST, because it reveals the personality of the person you are hiring; if they dont have a computer or a network, they dont personally see any value in it.
Manipulate the moderator system! Mod someone as "overrated" today.
Maybe its not them, but your development environment. Are they familiar with all the tools they're going to use? What about peculiar aspects of the OS? Can they create a make file?
Its easy to find people with knowledge of C/C++, but knowledge of the use of your development tools and system is almost as important as knowledge of the language you're using. Programmers can get frustrated at the prospect of having to learn about all the little quirks of a particular system and this can make them much less productive.
IMHO, the "proper" answers below given to the missing number question wouldn't be the one I'd give (or want to hear).
My answer:
"I'd do it the simplest, quickest way to code that achieved the desired result. Offhand, I'd just write a damn loop from 1 to 10, compare and see if the current index is in the list, and if not, I'd have my answer. If at some point in the future, the application had speed problems and a code analysis showed this loop near the top of time wasters, then and only then would I think about ways to improve my code. Too many programmers get stuck on doing things perfectly and fritter away countless hours on 'great' designs so their code will be 'maintainable and scalable' only to find that their code is long retired before it gets too slow or the business rules have changed SO drastically it is worthless."
DO NOT DISTURB THE SE
DO ask for demos of working apps from previous jobs/schools. If they don't have anything working to show, they can't take a project, even a simple one, cradle to grave. You want self-starters who don't need constant supervision.
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.
It's all 0s and 1s. Or it's not.
By now I have interviewed several hundred programmers; some of them worked out, others didn't. I've found the following to be the most successful interview technique.
First, do not ask a standard set of questions. Standard CS questions are known by almost everybody, even wrotten programmers. "How do you implement a linked list" will not assure you a good programmer. Pick an area in which the applicant claims to have significant expertise and understanding. Then, ask increasingly difficult questions about _that topic_ until they can't answer all your questions any more. This gives a good indication of the level of technological sophistication.
Furthermore, ask WHY. "What is the purpose of third normal form?" is a _vastly_ better question than just asking what is third normal form. Everyone knows what third normal form is. Asking why allows the programmer to demonstrate genuine understanding. Not so many people understand the rationale behind the trivial facts they've memorized. Anyone can memorize facts; fewer people can understand.
Also, look for a background of challenging projects. People who have had significant roles in successful, challenging projects are generally good programmers.
Finally, don't ask questions that are only relevant to yourself!! Several commentators here have said you should ask "Which open-source projects have you contributed to," and judge based on that. Because you are an OSS advocate does not mean that OSS people are the best programmers (they often aren't). Some people here have said you should ask "Explain (blank) algorithm in detail..." when that algorithm relates to speech processing or compression etc. That's YOUR area of expertise. Ask them about THEIR area of expertise.
I found that asking impossible questions or riddles works best. And not for the reasons you expect. I don't want them to answer... I want to see how they deal with pressure and problem solving.
You might try standard stuff... OO concepts, SE questions or some of those interesting riddles (like the one with the three lights and the three switches in the different rooms).
Now if they can easily answer the questions, fine, find ones they can't (at least not right away).
See how they go about it... how they attack the problems, what questions they ask you, how frustrated they get, how well they take being stumped, if they are willing to ask questions or be defeated.
The best ones are those who come up with interesting ways of attacking the problem... and who can appreciate a novel solution.
Trust me, it really reflects on how it is to work with them and how willing they are to learn. It is easy to teach a good worker a new skill, it is more difficult to work with a prick who just happens to know everything.
What is music when you despise all sound?
If I was asked the 1-10 which is missing I would walk out the door.... I bet you have a bunch of smart asses that like to try and out do each other.
I have done a ton of interviews... I've been told that I am very good at them. One thing I stay away from are those kind of retard brain teasers. What you get is someone who is good at retard brain teasers.
I'm not even going to help with any suggestions. It's is plain to me that you or your company has a problem with programmer centric ego's.
by the way... add them up and subtract from 55.
Last one in jail is a fascist.
You post was a little vague on how you were burned by these programmers. Did you hire them in management positions and they did not manage the project? Did you hire them as pure coders? Were they given proper direction and help to fit into the team and become productive? Having worked as a contractor for several years and working in many different work environments, it takes about 6 months for any new member of a team to be considered a true member of the team. Adding a single new member to a team will cause the whole team to fall apart for about that length of time before everyone starts working as a unit and can be considered a true team again.
If you found that these people could not program that is one problem and you did not interview adequately. If it is productivity, take a look at your team leaders and project managers and determine why they could not get the best out of these individuals. If you truly found someone who was liked by the other team members you should have spend time and energy improving their time management skills. Just because someone is a good programmer and an intelligent person does not make them good at allocating time to tasks. Sometimes it just takes a good mentor to straighten them out.
Productivity is something that comes from a good working environment with defined goals, policies, and expectations.
Oooops, that's enough here, my productivity is dropping....
There seem to be lots of good responses here, many of which I have used myself in the past. But no-one has mentioned my favorite; the 'Toilet Tank Test'.
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
- -
Are you an SF Fan? Are you a Tru-Fan?
1) Define the person you need
A job description is often deemed as overrated, but it's helps to insure that the person is going to be happy doing the job. Even if the job is a jack-of-all-trades, there are going to be dominant tasks, and the person has to be able to do those well, and enjoy doing them.
2) What is the importance of current and future knowledge
In my experience tests can be very effective to judge current knowledge. What tests are less good at is to determine how quickly the person can gain new knowledge and how quickly the person is going to be able to apply that knowledge to the job. Even a good college GPA is only so useful.
3) Can the person write code
A simple coding test can validate the knowledge of standard idioms and basic language constructs. What is often harder to test is whether the programmer can write code that is useful. That is, is the code written to minimize bugs? Is it modular enough to facilitate debugging? Are the interfaces clean and clear? I have had only one interview process in which these skills were sufficiently tested. Some might say that looking at past code is good, but who wrote the code? In one job, half of the people who were hired with me were let go because they could not write code, even though they had the technical skills.
4) Can the person work in the environment
My experience is that professional can work in a wide variety of environments.. They question is does the person want to work under the conditions, and will the current staff accept that person. That is why I believe in face to face interviews with co-workers much more than personality tests. Unless the test is screening for certain philosophical beliefs, such tests are a waste of time
I find interviews like these to be the most. Interviews that do not follow these guidelines tend to be a waste of time, at least for me.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
...but not the one you think.
Bringing in code you've written for your present employer is unethical, because you have no permission to show it to anyone else.
Therefore, if you refuse on ethical grounds, you pass.
Those questions are worse than useless. I don't have any particular suggestion for what to use instead, but I know what doesn't work.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
In a corporate development environment, you don't want someone who can only write code based on what they already know. You want someone who can accept a task requiring skills they don't already have - yet deliver quality anyway.
...) then you have a candidate that has a variety of tools in their skills toolbox.
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.
It depends on where your hires are falling short and what you expect of them. If your looking for an old fashioned "closet programmer" who knows the entire C syntax by heart but has the communication skills of a rock. Then simply give them a programming test during the interview. If your looking for a developer who will be working alot with customers don't worry so much about there deep technical skills. Make sure they understand concepts well, are good at listening to other's ideads, have good communication skills, and are problem solvers. Learning a new syntax can get better with time. You really need to classify your programmer based on what job he will be doing and not lump him into a generic group like a programmer. There are Design/Analyst, Data Analyst, Project Managers, and Coders. Also look more on how your bringing them in most development jobs I've had I felt out of place at for the first few months. Usually I get very poor training, a lot of companies have a tendancy to put thier best developer in charge of the other programmers this is often not the best idea since a lot of great programmers don't have great communication skills.
If your not cheating your not trying. If your not trying your not winning and if your not winning why play?
Also, What is your favorite data structure.
I have always done best when I can work torward
my next career goal, and can do things I'm
genuinely interested in.
Also, try to find out how people work best; I
believe that many people work best in small
groups, and some work best alone. Personally,
I prefer working closely with someone on a
project around half the time.
My $.02!
Testing a programmer's skills in constructing algorithms for random scenarios is a great idea.. if they need to use lots of algorithms.
Good point. These days you don't need to write any algorithms at all. You just use the standard template classes. Any programmers who write their own algorithms are jst reinventing the wheel and wasting your company's time.
I don't know the particulars of the situation, but it sounds like your organization (like most others) focuses on people and not on process. Basically, you assume that when something fails or someone doesn't "work out", it's the fault of the person ("Stupid Peasants") and not the processes, policies, and management ("Flawed Government") that dictate much of their everyday routine.
I've seen many companies like yours where you focus on insanse quizzes (which are most likely illegal in some states of the U.S.) and questionaires to hire people. Then, when the person gets the job, they are forced to wander around the building begging people to help them get started. There is no documentation on your processes. You have no way of initiating new developers. There is no software quality assurance group responsible for the quality of the process and the code. Projects only succeede if the grandmaster coder or super project manager are on the team. And, you insist that all developers perform as well as your current "uber-geek-god-coder" rather than accepting that people work at different levels. Worst of all, you have no way of empirically measuring what the uber-geek does different, let alone what "perform as well" even means.
What you need to do is move away from your people focus, and start adopting a process focus. This way of running things assumes that people are intelligent, and that if they don't perform well, then there's something wrong with the processes and policies. In other words, rather than firing people, find a way to improve things for them. If you do this, then you can spend less effort trying to find uber-geeks as regular folks should be able to work efficiently.
The best thing I've seen for this (and what I currently follow) is the Capability Maturity Models at CMU's SEI. It is a very good process which focuses on measurement and doesn't require any particular development method. We use a mix of XP and other stuff for our processes. The primary thing CMU tries to emphasize is that you should always try to improve your process (something the manufacturing industry has known for about 20 years). This continuous improvement is what is needed to stay ahead of the competition, and has worked well for many other industries. The trick is improving process without stifling creativity (although, most coding I do isn't that creative).
The downside to CMM is that people assume it will cause all their projects to instantly succeed. This would be a matter for another discussion, but let's just say that I can't think of any other industry that tries so hard to make so much crap "succeed". CMM will only help you produce the best crap you can, it doesn't turn crap into gold.
Finally, it seems that your managers tend to blame the workers when things go wrong, even though managers setup nearly everything in the environment. This way of running things will probably need to be the first to go since CMM (and any process improvement) forces management to admit that they are responsible for failure since they are in control. Once that psychological hump is rolled over, things get easier.
Enjoy! And I hope you start looking at your management practices, not your hiring practices.
Well, there are many technical questions one can ask to get a handle on a programmer's skill level, but I've always felt that that's only part of the issue. I once worked in a place where, after an interview, each interviewer would answer three questions.
1) Can the person do the job?
- This would be the technical part of the interview. Does the person have the appropriate technical skills to get the job done? Do they have a good, problem-solving mind?
2) Will the person do the job?
- This is as important as number one. You want to get someone motivated to work. Also, if you're hiring someone to do program maintainance, for example, you don't want someone who looks at the job as a three month stepping stone. They need to be excited and ready for the specific task at hand.
3) Am I willing to work with this person while they do the job?
- We all like to think that we can be rational, detached creatures at work, but its important to be able to get along with workmates. It makes work more enjoyable, and workers more productive.
The best hires I've seen, are the ones who receive strong passes on all three questions.
How do I get a job that they pretend to pay me and I pretend to work? Fake it 'til you make it, it really works. Give it the old american, half-assed try and it'll all work out. Because, in the end, you're dead and all is forgotten!;-)
Selah,
~chess
"I'm a dirty white tomcat, enter my world..."
The iron maiden and/or rack should tell the tale.
than just know a programming language. Most script kiddies can tell you about pointers and write a simple swap function.
Ask them about systems they have written in the past. Have them discribe, draw, diagram these systems and explain how the different parts work together.
Ask about problems they ran into designing and writting these systems and the solutions they came up with, and why they choose those solutions.
Give them an example of a problem or system you might be trying to implement and ask them if they have any ideas on design and implementation.
Yes, it is important for a programmer to know a given language. But most good programmers are problem solvers. They can look a system or problem and design and write a solution regardless of the given programming language.
We never hire "unproven" staff and put all perspective or potential employees on a 30 - 90 day contract. This allows us to determine if (1) are they competent, and (2) can they interact with the other team members. If things don't work out, it's very easy to get rid of the contactor, much more difficult with perm. employees.
... surf the net and make sure you don't have a Bernard Shifman walking in for the job...
-- I'd say your post was about 3 monkeys, 18 minutes.
First you have to have trust in the people which will recommend you the candidat. Willt ehre be nepotism ? Further, the system advanatge people with "link", "insider". meaning if you are a God in programming, but you don't know anybody, well abd luck. Somebody mediocre but friend with somebody will get the job.
Referal System is IMO one systemw hich call for more abuse than pure random system 8as it is mroe or elss know with programmer hiring in some firm : "did he/she had good cloth ? What is her/his astrologycal sign ?").
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
"Do you read Slashdot?"
At a "yes" dismiss him/her; slashdotters aren't productive.
Many moons ago I worked for a large multi-billion dollar company. They had a simple rule about interviews. No one interviews until taking a class in how to interview. At the time I thought it was kind'a silly. But after going into contracting it simply ammazed me how few hiring managers actually know what the hell they are doing. Technical people are even worse. You can divide the questions into several categories of stupidity:
1) Have you ever/Do you know?
It's the start of a good line of questioning. However, rarely does the interviewer ever follow up. For instance, Do you know Perl? Yes. I've used Perl in a variety of projects from X to Y.
It's a start, but you want to ask something again to double check. What version of Perl did you use? DId you use CPAN modules with it? When should you "use strict" in a perl script? etc. etc.
2) Riddles.
It could show someone is really good with logic, or, it could show that they just have heard the riddle before. You'd be better off giving the person a problem based on something they might see in the position they are going for. You could ask a web application developer what is the likely cause when a program seems to run fine, but the web server says "Premature end of headers". The real world problem not only looks at logic, but experience.
3) Programming questions that have little to do with the job.
Why ask a VB programmer an XOR question. There are all sorts of questions that seem great for figuring out how well someone can think on their feet. But they may or maynot actually get the person you want. Just like riddles you could have someone who had a prof in college who liked these logic problems. Maybe the person understands whats going on with the problem, but the person could just as easily be doing it from memory. Again, real world problems, and keep digging for supporting facts that the person knows what you want.
If you are having a problem getting the right canidate you need to bite the bullet and reconize that it's YOUR FAULT you end up with crappy employees. Take a class on how to interview. Learn how to ask the right questions, and how to follow up with addition questions to find out what the canidate really knows.
I am a senior software specialist for a large data center and I frequently interview programmers for open positions. The MOST effective question we have found (weighted 50% of the interview) is to give them a coding problem. For intermediate programmers we ask them to parse a word out of a string (that we give them) in any language they know. They are asked to write their CODE on the white board. Actually, we give them the question prior to the interview and give them 30 minutes to think about it.
"When is the last time you spent your own money on a technical book for your own education?"
"Did you read it cover to cover?"
----- Lotus Super 7 - A real car.
so let's focus on jobs that require skills other than being able to type into a keyboard fragments of caffeine-induced hype fallout, i.e., jobs that require some amount of analogy mapping aptitude (AMA for short). an analogy is the layman's term for "model" which is what needs to be clear in the Programmer's head at some point in the process, preferably early on.
mapping is the translation of this model into some design and eventually code. the mapping needs to be flexible because not all parts of the model are architecture (fundamental to that class of models); some parts are implementation (likely to change at the whim of your customer). a good mapping produces two deliverables: the design and the cleavage points (if you will) where a small tap can separate the architecture from the implementation (to facilitate maintenance, don't forget about that :-).
lastly, aptitude is what you think it is: tractable ability honed from either intuition or experience, preferably the latter. here, tractable is the meta-ability to call forth the ability at will and also includes the social skills of working with other people. the latter is (un)fortunately outside the scope of this post, however.
so now that we've defined these terms, how to go about assessing the candidate Programmer AMA?
here's a concrete suggestion: pick a process (say the hiring process or the process of recycling glass bottles or the process of programming itself (if you think the candidate is sufficently meta)). ask the candidate to model it. check to see if the description includes all inputs/outputs (interfaces). ask the candidate to redesign that process to optimize it somehow (say, for less paperwork --- always a relatable goal!). check to see if the interface breaks in the new design. if the interface breaks, your candidate does not have Hacker nature, but may still be competent in other ways. obviously if the candidate cannot do this redesign, or if the new design doesn't work at all (after some encouraging re-iteration --- no need to be hard-ass), your candidate may not be a worthy Programmer.
keep in mind, too, that sometimes people have ability to change themselves in which case their (un)worthiness as a Programmer may improve. but that's another post for another time...
...the best systems engineers, application architects, programmers, methodology gurus, information architects, UI designers, usability experts...you name it, I've hired them and been successful. My secret is...
A HAHAHAH!
RIIIIGHT!!!
Like I'm going to tell you! I'm going to keep all the wheat for myself, and leave the rest of you to make do with the chaff! Once my company full of Big Brains (TM) has achieved global domination over you Teen Brained (TM) competitors, you will all bow down to ME!
BUWAHAHAHAHAHAH!
BUWAHAHAHAHAHAHAH!
BUWAHAHAH
No, Minnie Steve! NO! We do NOT eat our kitties!
B. Gates.
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
What the hell. Not everything is 1+1. just because someone is great with coding for Gimp/Gecko/what-have-you doesn't mean that the programmers is going to work out for YOU. I have conducted the 'tech' part of the interview. I've been burned a few times. But on an average, I've done well with the people I've recommended.
I do make sure that the person is up to the (algoirthmic) challange. I mean if the person doesn't have any brains, a thousand monkeys could eventually come up with the code... Then it's your gut feeling. (we do do the psyc test too.) Just talk to the guy. Get a feel for the person. Then go with whatever your gut says. You just can't judge a person by adding numbers -- be that the algo-tests, psyc test ...
There's one easy question that will immediately weed out 99% of all applicants:
Have you ever done anything....high tech?
You can start with having sex with your dad's second wife.
Every really good programmer I know (including myself :-) has a resume stuffed with tasks, responsibilities and roles. Good programmers get known for solving problems and they get the big ones assigned to them.
Look for somebody that keeps getting the work piled on them at every job they go to -- they were the big fish at their last job and they will be at yours.
In particular look for programmers that describe their previous job with something like:
The problem with appitude style tests is that they select for smart not for productive. You want both.
I keep seeing replies of "ask them logic problems" or "ask them to come up with an algorithm to do this or that". Sure, these questions could be important for a particular job, but that has nothing to do with how well a person can program.
Questions I'd ask? This of course depends heavily on the language in question, but I'll assume C++:
1) What progamming books do you own? - This would tell me if this person truley LOVES to program and tries to learn as much as possible on his/her own, or whether it's just a job for him/her. I'd also look for well known and respected books such as Code Complete, Design Patterns, Effective C++, Modern C++ Design, Exceptional C++, etc.
2) Name some design patterns and their uses. - This would tell me not whether they know syntax (who doesn't), but whether they know how to properly architect and design large complex applications using reusable and maintainable code.
3) Ask them to explain what use STL, functors, policies, typelists, smart pointers, etc, are. - This would give me an idea on how well they know/use generic programming and code reuse.
4) Ask to see any source code he/she owns. - This has already been mentioned numerous times, but it would allow me to see whether this person can write readable code, whether they comment their code, whether they've implemented any of the items mentioned above.
5) Talk to them on a personal level. Joke around, BS. - This would allow me to actually see their personality, how well they communicate, sense of humor, whether they are easy going, etc. All important aspects for programmers and team players.
I've yet to see a company ask even two of those five questions, but I think an employer could betetr judge programmer using these than asking them "how would you reverse a linked list" or other such questions.
- Houdini
Here is what I do with programmers.
I give a small code sample. I ask the person to describe what the sample does. I tell them that this code worked fine in development, but when it was put into production there was a serious performance problem and this code is the cause, why? Ask them how one could solve the problem.
Throughout I stand ready to explain any language construct that they find troublesome.
The code sample I usually use is a double-loop to find the intersection of two arrays, and happens to be written in Perl. I have had Perl programmers stare at me blankly, and people who have never before seen Perl find the whole exercise trivial. (It should be trivial, and this is not the kind of thing I want you solving by rote.)
A followup is to take something that the other person claims to know (eg what an "object" is) and tell them, Pretend that I don't know anything about this. Explain it to me. I then ask questions wherever I think a bright non-programmer would be lost. Plenty of native English speakers completely flub this since all that they understand are the buzzwords (and presumably program by cargo-culting off of examples). Plenty of people who speak English as a second language do fine.
Getting through those two does not guarantee that you are worthwhile. But flubbing either indicates that you probably are not going to be a competent programmer.
Another fun question (but one which is harder to compare between people) is this, Describe a recent difficulty you had, and how you solved it.
Other areas (eg sysadmins) would get different specific questions, but it still is easier than you might think to come up with good questions.
Coming from other areas in a software company (QA, and
network admin,etc.), the best programmers were the ones that
understood how to deal with the people from other teams.
If QA finds a problem, just admit it, fix it, and move on.
Throwing the problem report back at QA 20 times will
alienate the whole QA team.
I realize that the whole 'in the flow' issue is very
REAL, so attempt to work out a system whereby QA can
swing by to discuss problems with the code or how the
product is supposed to work.
Working with a programmer you can talk to is a godsend.
Working with a prima donna is a one way ticket to the 4th
circle of hell. So lighten up.
Follow the specs and make sure everyone knows what you
consider to be a bug.
My company is kind of small, and being that I am the technical catch-all, I never really sit down and interview anybody in the traditional sense... however nearly every person we've hired has been run through the "geek gauntlet" with me during their interview.
With the programmers, I usually ask them about what kind of stuff they hack together on their own time. I'll ask what games they love to play, what their hobbies are... what I am really looking for is to ilicit some kind of really passionate reaction - I want to see their eyes light up as they delve into a description of whatever it is that they love to do. No passion, no thumbs-up from me. People who are dead inside don't make good co-workers and they sure don't hack code until 4am.
Then I always finish with "Coke or Pepsi?" I don't actually change my opinion of them based on this answer, but I get to give 'em a hard time if they say "Pepsi"
*grin*
The Digital Sorceress
It doesn't really matter what you ask or how long you Interview. It's ALL a crap shoot just like Vegas!!! You've got people who are test takers or have a photographic memory but couldn't write a program to count from 1 to 10. And they might even have a Master's or PHD too!! Not that any of the above is bad other than the fact that they can't program. I want somebody that I can get along with and who's willing to learn ANYTHING. I can't tell you the number of people I've worked with over my 22 years who don't want to EVER learn anything new. After all change is bad right? My .02 cents...
We needed C programmers. What we did:
.c and .h files that #included (directly or indirectly) a particular .h file.
;-)
pick the 5 most promising candidates. Give them a programming problem that is pretty hard to solve in a day for a mediocre programmer, and give them a day.
Our problem was: write a utility that scans our source tree, printing out all
See how the resulting code output varies wildly, even though people have comparable CVs.
It worked like a charm, and it was fun. The winner was very good indeed. Later he appeared to be working at home on his own unix kernel, running on an Atari Falcon (it was '90, '91 or so). Linus wasn't the only one, albeit the most successfull
Certifications are only good for sysadmins not programmers. What does the MCSE have to do with my c++ skills? Nothing. What we need is a accreditation system for programmers. Engineers need to take tests to become engineers, so do brokers and accountants. Why not programmers? Something alon the lines of the MCSE but for coders not sysadmins.
There are some really good suggestion here and some really stupid ones. (some funny ones too)
People who ask little riddles or spot quiz questions are simply not the people I want to work for or want working for me. While these are ok if they are part of a larger picture of quality, they usually are poor indicators of real talent.
Remember;
Never memorize what you can look up!
I am more interested in hiring someone who has a reasonable match to the skill set the position calls for but more importantly a person WHO CAN THHINK, not rattle off answers to a quiz.
No programmer has ALL the programming answers at the tip of his/her tounge. But, how would they go about researching the answer is more important.
I've actually worked with some people in the past that could whip together code-snipets in a flash but wrote unmaintainable, undocumented code. If not full of bugs, full of severe limitations, that the end user was not interested in using.
What are the goals here?
- Incompetent or minimally experienced coder
- unmotivated
Are you interviewing for technical skills beyond your own? You're going to need some help if that's the case. Don't try to assume that because you're good at what you do, you'll be able to spot someone who is good at what they do, because that obviously isn't working out.If you're hiring people who just don't do a very good job, you're not weeding that out in the interview process (sorry, obvious). Source samples brought in can be immeasurably tainted. Don't try to learn much from them. A person may be able to recite their samples and explain the whys and hows of every line, but that can come from simply studying someone else's code. If they're incompetent, you need to schedule more time for, and be tougher in the interview. If they have to write code on a whiteboard for 3 hours, that's easily worth the investment. I've known people hired by Microsoft who would write code on a whiteboard for 8 hours to answer a single question. Don't finish their sentences. I see people doing that a lot, and then not really counting it against the interviewee in the evaluation meeting.
This is the person who has the requisit number of years experience in their field, but doesn't do any of it at home. Or maybe they bring their home projects into work when there's work to be done. Maybe they read TOO MUCH Slashdot (Me). Maybe this person worked in a team, and can easily mask their level of involvement. Find a way to weed these people out in the interview. They may seem less than excited after spending an hour writing code on the board. Ask them about projects where they felt like they carried the brunt of the load.
But of course, without knowing what kinds of problems you've had with the people you've tried, it's hard to say where you're going wrong. There's so much talent out there and out of work, that it's almost safe to say you should be looking only for people who've lead teams and done the majority of the work before. That can be a good indication of talent as well as motivation that you won't always have the luxury of filtering for.
I always thought a "programmer" was a lackey that wrote Excel Macros or built spreadsheet formulas or made Access applications.
Maybe you want to hire a professional "Software Developer", somebody who knows not only what an algorithm is, but also how to select the appropriate ones and implement them.
I'm a 2000 man.
You can write a double-linked list using only one pointer per element for navigation.
How? And if you do this, how can you recognize the end nodes?
Sure, it may sound like they're just going in circles to piss you off or avoid the question, but..
:)
In my experience, lots of programmers (myself included) like to bring ideas full circle several times, sometimes out loud while discussing the problem, this is to make sure that the entire problem is understood and a solution that is generated is applied that fits the entire problem and not just the noticible part.
I can plan an entire client/server enviroment verbally in discussion, know exactally how to do it, then spend a few weeks documenting it afterwards, find 2-3 problems with it, fix them, go back over everything, etc, it can take 6-8 weeks (depending on the size of the project, mind you) of planning on the part of the lead programmer to come up with a solid concept before code actually gets written.
Asking people to produce code to do X Y or Z during an interview is just wrong, because if they have time to research doing X Y or Z they may discover a way to do it no one else has thought of before. I've walked out of interviews that asked me to write code during the interview, because it's not worthwhile, they could have asked me for refrence code prior, and chances are these people only care about bang for buck anyway.
I was actually asked to write a simple client/server hello world once, the interviewer had the nerve to insult me further by saying I couldn't do it to aggrivate me, so I did write it in about 15 minutes without any of my normal refrence, had one compile time error that took 10 seconds to fix, and even used a message sending protocol instead of a normal socket reading and dumping method, then proceeded to inform the entire room of people I did not wish to hear from them and was no longer interested in a job where HR insulted its employees. A friend of mine that worked there told me the HR guy doing the interview got fired for that one.
Is from upwind.
don't judge people based on thier college credits, judge them on work they can present to you that they can prove they made. Personally i am about to move to NZ because thats how they do it there. i know 13 languages(and another 20-30 that i can read, because when i say know i meen i can code perfectly or near perfectly in them), 8 of the top graphics design programs, and can work on Mac, Linux, and Windows. I am about to drop out of high school because formal schooling hasn't taught me anything new since the 5'th grade(When i got my first net connection), i now know and can interperet theories on Cosmology, Nuclear Physics(so easy..)Particle Physics, Thermo-Dynamics, and Quantum Mechanics; as well as being well versed in art, music, phylosophy, etc.. I couldn't get a job after 2 months of trying(not even an interview without at least a college degree, let alone a high school one). i have a friend who dropped out of school in 7'th grade living in nz, almost the same coding skills, he went out and after a week he found a job and got it that pays 1,200/week, the reason you can't find any good coders is because you havevery bad standards, i have done code on places like rentacoder.com for college student's finals that they aced, because i needed cash.. make sure anyone who you hire can prove it rather than presenting a silly high school or college diploma.
Interviewer: Can you explain in English John Carmack's recent comments about how the Doom 3 engine renders? YOU GOT THE JOB DUDE!
About a year ago, for reasons I don't need to go through, I was getting ready to switch jobs. So I started taking interviews on companies I felt like working for. Since I was the one "picking" and I was not really under pressure to get a job (I had one already), I could afford to chose carefully.
Well, turned out that after a couple of interviews I started to be the one making most of the questions. I wanted to know about the methodologies in place, work environment and so many other things that I ended-up discarding quite a few companies based on their responses or their attitude. I got offers, but I turned down many based on what I gathered from these experiences.
On the other hand, I have come across more bags of crap that have 'systems engineer' or 'chief architect' or such that it makes me sick... mainly because it spoils the real idea of what these jobs entail and turn people off of them. Then there are good managers (of course I have not worked for them yet) that have the identifier of '[chief] systems architect/engineer' to which it is simply just the incorrect title, and not that they are puss covered bags of puke like so many other managers are in large companies and government. (Hey! I know buzz words... watch me dazzle everyone and NOT DO MY F%^&*#& job)
I agree in full that there is more to programming than just the language... for developers and above. For a simple programmer, that is all they really need to know. Ideally you want your programmers to be developers, meaning that they can offer good suggestions, understand the big picture, the requirements (if your shithole management bothers to gather, organize and disseminate them) and interaction/integration methods and goals... then you will have that much better of a implementer. I always believe that more knowledge brings forth more skill and overcomes low morale (which includes apathy) and is good for you in the end.
After a point, I think that the ability to do anything moves away from technical skills/learning into personality and socialization. Bright people who don't talk to others without any drive don't get a lot done.
I would look for people with STRONG work skills who get things done, and if their not the best of the best in techie skills ignore that. People who sit down and do the work are who you want, even better is finding people who will ASK for help or look something up when they get stuck. It isn't how smart you are it is how smart you work
Interviewer: So... Given the integers from 1 to 10, inclusive, how would you find the missing number from a list of 9?
/\/\3 teh j0b 0r 1 w1ll h4x0r jO0!!11!!!11!
JeffK: ?!?!!1!111??? 5ub7r4c7 73h 5uM fr0/\/\ 55, |\|umb|\|u75. Novv g1v3
What kind of interview question is that? FRIENDSHIP BREAKS ENCAPSULATION, A TENET OF OO DESIGN! Obviously, if your candidate speaks volumes on friendship, than he is a hack who will run rampant through your code and leave spaghetti in his wake.
Seriously, a better question would be, "How would you approach writing a program that does X"
The same things for finding good programmers holds true for any good selection interview.
Most interviewers do a horrible job, because they never stop to think about what traits are required for their ideal candidate. Most go so far as to focus on what knowledge the candidate has instead of the more important question of what traits. 'Programming' is an art and science that involves many traits we can readily define (such as problem solving), but the organization that is hiring should have a much more detailed idea of what they need. If you're using a buddy system and frequent code reviews somebody who works well in solitude isn't as important as someone who communicates well and is into the 'team concept'.
Once you have the list of traits and skills you want, you should be able to prioritize them. From there you can write a list of questions designed to help you identify the traits desired. Just remember the real answers you need are to whether or not the candidate has the traits/skills you are looking for. If their answers are not satisfactory you must continue to probe until your real question is answered.
It's also important to help the interviewee in whatever way is possible. Most people are understandably nervous in a room of strangers answering questions. If performing under stressful situations isn't part of your needed traits, you should do things to help settle them down. For instance one form of interview is the funnel interview. You begin with simple closed questions that should be home runs (e.g. What was you GPA? How long have you been programming?). It's not until later in the interview you hit them with the open ended questions or the ones that really stretch them.
A more generic one would "find the missing number 1 .. n. Add all the numbers and
subtract the result from (((n+1)*n)/2),
this is your missing number.
Now, can anybody tell me what use that is? How can you tell that somebody is going to be doing there work on schedule with high quality from that?
If you where to roll out the useless questions tests on me, I'd probably terminate the interview right there and then, "thank you, but if this is how you select my work mates, no thank you.".
It seem apperent that you're method is not hiring the people you need, because you need people to solve really world problems not problem to pass the time on a bus journey.
Why don't you ask questions like: "When you write code, how long do you expect the code to be in use?" "What do you do to ensure your code meets it's predicted life expectancy?"
(By the way, will you post you company's name so I can make sure it's crossed off my interview list in advance.)
Btw, I'm really good a sovling really world problems, I'm really bad solving problem that start with and number of villages, or you have three canibals and boat. But I'm really good getting working code that wouldn't have to be rewritten next year and give deadlines and time estimates that are accurate.
Find the hardest non-NDA bug or problem that you or find a work mate who has been working on a tricky problem for while and let the interviewee chew on it for a while. Sometime I'd take somebody out of an interview and hand them over to a colleague for ten minutes to see if he can help them with a problem.
This will give you several benifits. One: you have some insight into how they will act when they turn up to work and have to solve real problems. Two: you will beable to get an idea if other team members can work with the interviewee. Three: hell, they may even solve a useful problem for your team, for free, whether you hire them or not.
I can't spell for shit, but nobody has ever hired me spell.
M0571y H@rml355.
I also like to ask problem solving questions, which can be design questions, find the bug in the code questions, describe a problem and ask you they would debug questions, etc.
It's not likely that I'll get one, because the company is really not that big (12 employees thus far), and I'm the only developer/programmer, but I would REALLY like a co-worker. I wouldn't settle for a simple "answer this questionaire" type interview though, if I had to hire some one.
...
In my job, 85% of the time is spent inventing new stuff, so just because you can fix bugs in 200 OSS projects, doesn't mean you can fill this position.
I want some one who can listen to an idea and have his brain run amok in synaptic explosions, because even though 99% of those explosions are going to be misfires, some of them are going to pay off.
I want someone who handles a new idea like Microsoft and embraces it (but not quelch it), and not reject it like a foreign object in the bloodstream.
I want someone who's creative; who'll look at an idea and throw it around, complement it and give it a fair chance, instead of thinking "well, we can just patch this and this in yonder program", because sometimes you have to throw out what you have and just use your experiences from earlier.
I'm tempted to pimp an idea of mine (not work related), to give you an idea of what I mean by "creative" and "inventive", but this is not the forum
Anyway, not all companies wants someone who can code the pants of anyone - sometimes they want one who's creative and open minded. I know that's what my current employer told me (and still tells me) was the reason they hired me.
We do not live in the 21st century. We live in the 20 second century.
The person will interview with a bunch of different people, all who have a different focus: Mike grills them on their academic history. Ruth grills them on their technical skills. Bill chats with the candidate, and gets a feel for the person.
All three are really good at their particular interview tactic, and the people who've gotten thumbs up from all three have turned out to be great.
The last time I remember that we hired someone without buy-in from all of them, Bill said that the guy just didn't feel right. About a month later, he wound up getting sacked because he really didn't do much of anything.
So my advice is figure out what each person on your team is really good at evaluating, and make them focus on that.
obviously. Experience outweighs education.
Education does not make you an expert, it gives you enough to START doing what it is you want to do.
Education does not make you a professional.. it lays groundwork.
[how to intreview someone]
On one hand Mr. Anderson you have a very impressive resume. You worked at a highly profitable software company, re-wrote an SDK by yourself and you help your manager log into his workstation when the caps lock key is on....
On the other hand Mr. Anderson, it seems you lead a double life. At night, you go by the name "Bob", have a girlfreind that you take shopping and spend 12% of your free time with. You like to take her to dinner at a Tai place down the street from your apartment.
One of these lives has a furture Mr. Anderson.
Have them show samples of code they've written and see if they can explain it to you, preferably not stuff they did in school but on the job.
"You'll get nothing, and you'll like it!"
A lot of posts suggest asking about off-the-clock projects. The implication seems to be if you're not doing extra programming on your own time, on top of what you do at work, you don't have the passion to be a good programmer.
What about the rest of us who go home and play music, or go hiking, or weave baskets? Those who think life is too short and too big to spend all your time doing just one type of thing? Does that mean we will never be considered good programmers, even though during the day we enjoy churning out good, fast code, just like the geeks?
To answer one of your questions... In c++ at least "friendship isn't inherited, transitive, or reciprocal"... NO need for the job really..
The other thing is I was browsing el Reg this evening, as you do, and noticed this story:
Man's right.
Real geeks don't send CVs in Microsoft Word format - at least not to people they respect. If the CV is in TeX, or postscript, or plain text, or XML, or even, at a pinch, PDF, that's a good clue that the person who sent it is a geek. Likewise if it's in any proprietary format, even if it's the cool Linux Wordprocessor du jour, there's a good probability that the person who sent it is a luser.
I'm old enough to remember when discussions on Slashdot were well informed.
I've done a fair amount of interviews over the last five years, both as interviewee and dozens as the hiring manager for programmers, QA people, and other managers. One of the most important things that you can learn about hiring: you get what you ask for (this is true of many things, actually). You have to understand what you need. And I don't just mean job descriptions (though I'd bet that those are a little weak, too). You need to think about the person's role on the team and what kind of personality will excel at that.
:), that's a very different personality. Next, you have to keep in mind the team dynamic--you can't just load up on one type or you'll miss a lot of angles. A room full of heads down coders will happily deliver the shittiest program you've ever seen, 'cause that's what you asked for. However, there is some inherent conflict between some personality types you have to watch for--that's (partly) why the manager has a job, though :)
b ook
For example, if you need a coder that keeps his head down and does what you tell him, that's a fairly specific personality type. If you're counting on the coder to tell you you're wrong (when you are
Anyway, we found it very useful to lable the position with a short but colorful personality description. This personality will determine how important the technical details are. For example, if you're hiring a blackbox tester, niggly details about platform differences are important (how do you examine cookies in IExx on Mac?), whereas you expect an architect to have very broad knowledge and the ability to get and understand details when needed. Here are some examples of how we might characterize the needs of our positions:
Yesman
Bullshit-o-meter
Swingman
Schedule Monkey
Mad Scientist
Maud'Dib
Professor
Mechanic
By-the-
Can-smell-trouble (ie bugs)
Programming Seal (ala Navy Seal)
a Machine
These types of characterizations are useful because your non-technical interviewer can understand the gist and help look for them. Also, you can find professionaly prepared interview questions along with guidelines for how to interpret the responses for these types of things.
Once you've got this figured out, you can decide whether or not you should ask syntax minutiae, give logic riddles or textbooky exercises, ask them to explain concepts, or ask them to tell a joke they like. All in all, if you know what you need, it's much easier to spot.
Why not take your top three candidates and pair with each of them for an hour or two? Pick a task with little domain knowledge needed. Let them drive or do the majority of leading and see what happens...
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.
managers...why god invented purgatory
Unfortunately many programmers/developers also don't realize the difference and think they are both. In truth you can't be one without some of the other, but after a few years you will realize which camp you really excel in. I once worked with a large team of only (good) programmers and it was a nightmarish experience because they didn't appreciate the "development" side of the work, leading to a steaming pile of logistical problems and a missed deadline. Conversely, a team of only developers will likely turn out code with great intentions and design but a weaker implementation.
Its not a matter of being better or smarter or more personable or working better in teams because those skills are valuable to both trades. It really boils down to
To answer the question at the top, I think the first thing you need to do is find out what you have on your staff already, and then establish what you need and interview with that in mind. Looking for the person who does everything and does it well is likely going to lead to dissapointment.
This is not the greatest sig in the world, this is just a tribute.
So what if I'm the kind of programmer who would have to whip out a book to do this? Does that make me a bad programmer? What if my methods and code are far cleaner and efficient than most, and I always produce what I say I'm going to produce on time.. are you going to discount my work as a programmer because I had to look something up? Because I didn't know it on the spot?
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?
Rule - hire programmers you know. Period. I'm the world's worst interview, and a really good programmer. Beats the hell out of me how you find that out until I work for you. Too much resentment bubbles up when some goofball asks me a shmucko question about programming. I am really easy to work with, not at all nasty on the job--but syntax interviews, or even reasoning interviews, just piss me off. But anyone who doesn't hire me on that basis is missing a sure thing, and talent ain't that common. I liked the vi question (it's :q, by the way). Even simpler - what's the UNIX equivalent of dir? That kind of simple question is actually the best.
To the other ones, like "whether friendship is inherited," I'd say "sheeeit, I don't know. Why don't you tell me?"
Good programmer characteristic number one: he finds someone who already knows AND ASKS. Every other talent is totally secondary.
To ask them questions about working with a team of other developers. I dont care if you can program the best code in your basement what can you do as part of a team.
You'll want to look for answers like the applicant getting his previous employer setup on a cvs or other version control software.
Setting up instant messaging systems (which are surprisingly not used by a lot of business) and just a general idea that the candiate has worked as part of a team before.
Things that will not tell you a good programmer from the bad are technical questions, tests or multiple interviews.. You're just wasting peoples time.
If you know what a good programmer looks like you'll probably know it from his cv.
MCSE+BSci == crappy programmer.
why because he got into it to make money.
highschool dropout with oss contributions and his own dotcom will be a much better worker for you.
The reason is simply because in the programming world you dont need (or at least i dont) a bunch of jump-through-the-hoops lackies.
I want a developer to challenge the way i do things if he can provide a better way. I am not so egotistical like a lot of management i've seen to get upset when someone wont do it my way.
These confrontational non-nonsense programmers are not going to waste your time or theirs. IF theres a job to be done they'll get it done faster.
I hired my share of bsci's even a few masters before I caught on.
the formula i use is.
(time spent on degree) * 0.25 = relevant experience.
so when you hire your next developer look to someone with 5 years real-world experience and not someone with 5 years education. Because really they wont learn crap all that YOU can use until they're out in the real world for at least 5 years.
Another good question for your prospective employee is if he would be willing to take less salary and join in a profit sharing program.
If the canditate believes in your business he or she will take your offer. If not they'll stick to their guns.
I'd hire the former.
This may be obvious, but it's important that the candidate has experience with at least some of the technologies you will be using. As a Windows coder (it pays the bills, folks), I constantly deal with folks who have decent pure programming skills, but do not understand enough about the platform we're dealing with.
.Net Framework, etc. We've all seen folks reinventing the wheel when the widget they needed was available to them already.
For example, if your candidate has years of experience working with Oracle and your app is being built with MySQL, you need to be aware of the risks. It is entirely possible that the employee might design in features that are missing or difficult to build using MySQL but were simple in Oracle. By the same token, they may not understand the performance characteristics of the available ODBC drivers, or whatever.
This is particularly important when using large libraries like GTK,
Of course, this is only one concern among many. In certain situations, where something really new is being developed, cross-pollinating different types of developers can be helpful. However, for most of the corporate apps being built today (content management, ERP, etc.), risk management is likely to be one of your highest priorities.
BRENT ROCKWOOD, EST'd 1975
1. What is the best Star Trek Movie? Answer: #2
That's all folks. I've met precious few programmers who didn't like Trek and I'm willing to treat them like experimental error.
Period. Look at their code. Find out how long it took them to make it. Would you hire a glass blower without seeing his work?
69: If they choose this number, only hire them if you are running a pornography business.
666: If they choose this number, immediately hire them, and send them to your legal department. Many companies are already following this same practice.
(As a side note, you may also want to send some of these people to your accounting department, as in the case of WorldCom and Enron)
Any number greater than the salary you are planning on offering them: Laugh, and then tell them that only the people in management get those kind of salaries, not the programmers!
I'm one of those who solve problems with some kind of backgroud mental process so I am usually asleep with I come up with a solution. Unfortunately, it's considered bad form to fall asleep during the interview.
I typically put the applicant in a lone chair in a large room with a lamp hanging directly overhead. As it sits blindfolded, I play strange sounds like rat-feet scurrying, Pink Floyd, or the Windows Boot Up wave file. Then silence. I remove the blindfold, but remain outside the light. I make visible a loaded 9mm glock with glow in the dark sites I bought from ebay for 59 bucks and no questions asked.
:)
"I only have one question...." I say as I deftly chamber a round and put the working end of the gun to it's head. "What are you thinking right now."
Some answers which have ended the interview badly:
* My dog/cat/pet won't get fed.
* I didn't get to tell my friends/family/s.o. that I loved him/her/it.
* I'm too young to die.
* crying
Some winning answers:
* My cron job will fail if I'm not there.
* Can we do this tommorrow I'm on call tonight.
* I forgot to cut some space on the xp512 for >.
* My quake clan is going pissed about this.
* Damn, I'm gonna miss Enterprise/Buffy/Farscape tonight.
* Go ahead you ain't got the cajones.
"This isn't a study in computer science, its a study in human behavior"
Precisely. And xfig even makes it easy! (Hint, use 'update' on a compound object.)
Or, if you're boring and code-inclined:
curr = head;
while (curr)
{
-
next = curr->next;
}curr->next = prev;
prev = curr;
curr = next;
head = prev;
Does that look right?
--JoeProgram Intellivision!
After the standard questions to determine that the person has indeed attended college I usually ask them to solve something I'm working on. You often have to take some of the details out of the problem so they can understand. At the very least you'll get another opinion on how to solve the problem you've currently got.
how about you ask them "if you had to interview a programmer, what would you ask them?"...
hopefully they'd raise a lot of points in this thread during the discussion of what they'd do.
I would likely look at a number of practical skills tests focussed on key skills. For example, I might have a simple 5 to 10 page brochure website in straight html on a floppy. I might ask him to maintain the look, but convert to style sheets. Have them sit down at a PC without a net connection.
Or find out and fix something that is broken on a page or in a piece of sample code.
In other words, have tests for key tasks, nothing huge. You could even make it a timed test. Create a benchmark by having all current personnel also take the test, so you know what the bell curve is. The current crew could even help design it, supplying questions that people should be able to figure out in order to work there.
"It is a greater offense to steal men's labor, than their clothes"
How can someone who does not have as much experience in specific areas prove themselves if they are given things that: 1) no one else can do 2) not given info, tools, training on that new system 3) observes that training, orientation and assistance are given to those that where described as being self sufficient and solution providers? That is a never ending spiral downwards and a saavy businessman would understand that it is in their best interest to provide their staff with the best means possible to grow and flourish. An analogy would be with gardening: what if you bought two types of tomatoe plants? One was a normal breed, but the second was some uber-mater that was light years ahead of the other. It needed vastly less amounts of water, but yet would not suffer from over watering. Could grow perfectly in the shade, yet suffered no ill effects of day long full sun. Produced massive disease resistent tomatoes that ripened quickly and were as sweet (or tangy if you prefer) as can be yet could survive a 10 foot drop without a bruise. Grows great in nutrient poor soil, in basic or acidic soil as well as in sandy, clayish, or silt like soil. It matures amazingly fast, does not crawl all over the place or get leggy, and produces tomatoes 10 months in most North American regions. All this and of course you must pay about 5 times as much.
Now with this in mind, wouldn't it be silly to starve the 'normal' tomato plants of water, sun, nutrients and basic care yet give all that and more to the uber-maters? Isn't that rather inefficient? If you give those nutrients to the normal plants you can have in essence double what you get without. This is a basic economic principle... that of making the most of limited resources. Children often make the mistake of getting enamoured by sparkles and shine and devoting all their 'resources' to what does not need them. The result is that one thing only being decent, while everything else is crap. I fail to understand how it is that this basic understanding of business (or common sense practice) sense methods are overlooked when people promote and hire management. A manager, like with an athletic team, definitely does not need to do every task of every player, much less do it the best or even as well. However, they must understand 'why' and 'how' those skills/positions and the interaction between them are so important. They are not the boss just to be the boss. (RHIR should ALWAYS be higher in priority to RHIP) They are not just coordinators of tasks, but the motivator, the liason and the visionary. Instead, what I have found entirely too many times are managers in name only (I suppose that includes pay, rank, etc also but that is not the point of this) As position increases, so does the impact of decisions. So, it is silly and backwards to hold a higher standard to people on the lower end than the higher. To do so, is to declare you do not care about good results from your organization. (besides it pisses people off and bad morale has a horrible effect on productivity... just ask Sun Tzu, well you know what I mean)
Back to programmers (sorry for the rant), but I think that there should be differing types and levels of entry instead of the perfect person. Ideally, find someone who is enthusiastic about that type of work (the one that pesters and bugs you to do that work), put them with experienced people, provide adequate resources (hw, sw, training, leadership, etc) give them direction, give them REQUIREMENTS, and for God's sake please organize your methods and processes so as to make sense to the unnitiated... create some CONTINUITY. Provide mentorship through the work and you will be amazed at the loyalty and hard work that will give you great results. Those results will be direct and indirect (more skill, more motivation to learn more, more ideas, etc) so as to help your organization get the best of both worlds. Or, you could just stagnate and spin your wheels and then yell 'Quality' once in a while.
Don't get me wrong, skills are very important, but you do not, under any circumstances want to forgo skills for personality.
To be a good programmer you need to be:
1) easy to work with.
2) No Prima Donna attitudes.
3) passion
4) smart
There are some people that I have worked with that were really good at bug fixing. One co-worker would spends hours and days until she found really really tough bugs so she was really useful. Because she was good at fixing bugs, she thought she was a great programmer. WRONG! Fixing bugs is easy, it's generating your own code from scratch that is hard. This bitch thought she was too good for code reviews so she never did it, and changed code whenever she wanted and wreaked havoc on our products. Whenever you even mentioned some of her code she would get defensive and on a couple of occassions started crying because she thought we were attacking her. No dumbass, we're just trying to fix a bug in the program. Anyway, believe me, you do NOT want to hire people like that.
Brain teasers are the stupidest things to ask during an interview. Figuring out problems is only half the solution when it comes to programming.... you also have to worry about maintainability and coding style because in the long run, this is what matters most.
When I start conducting interviews again, I will
1) ask some technical questions to see if they can talk the talk
2) go for lunch with them and just shoot the shit to see what their personality is like
3) give them an overnight somewhat challenging coding project and have them e-mail me their code the next day. This lets them code in their most comfortable location, gives them all the reference materials they need (who they hell knows all the syntaxes off the top of their head) and I can take a look at their coding style.
The other thing I have learned for myself is that the next job I take, I'm going to require them to show me a sample of their code for their products. I will not take a job where the previous coders left a piling of steaming shit and then I have to come in and either clean up their mess, or code through hoops because everyone is too afraid to touch it because it might break everything.
I'm afraid that demos of working apps from previous jobs or schools are often simply not going to be available, no matter how good a programmer is.
My job at school had me writing embedded systems software. I'm sorry, but I can't haul a 50 foot neutral buoyancy tank into your office for a demonstration. Or how about my telco billing system? Nope. Can't demo that. Secret defense systems? No way! Nitty gritty systems programming projects for an ISP that has gone through two acquisitions since then? Nope. Proprietary intranet for an up-and-coming services company? Not a chance, babe.
Between clearances, non-disclosures, and the impracticality of emulating some operating environments in your office, I think that's it's more than a little unreasonable to expect demonstrations of working projects.
Moreover, if someone does manage to show you a demonstration of previous work, there's no way of knowing how much the person sitting in front of you actually contributed to the application in question. It's possible that all of his code was ripped out and refactored, and that his ineptitude pushed the project three months past its deadline.
Most programmers that are really enthousisastic about programming have some protfolio they can show. In the game (entertainment) industry it's quite common you bring along your portfolio and show some demos of the things you've already accomplished.
I think a lot of 'good programmers' do progam for fun in their free time. So I think, most of them should be able to show a portfolio.
- For every winner, there are dozens of losers. Odds are you're one of them -
#1 If the programmer has any of the following, they are automatically out no matter how he describes himself: a mullet, a visible tattoo, a pony tail, facial piercings, gauged ears, or if his breath smells like he just ate a pile of rhino shit. All of these things are signs of a complete asshole.
#2 If the person calls you "sir" (or ma'am if you're a fem-geek. In which case I say "such my dog's dick".
#3 If the person smokes crackrocks, they are dope fiends and shouldn't be trusted.
#4 If the person gives a shout-out to a rock band during his phone interview say "fuck off" to them.
#5 If the person reaks of shit, pick that mother fucker up by the throat and threaten to arrest him for being a loser.
#6 If the person programs in Delphi or Perl tell that mofo to get a job elsewhere. As a cock-sucker.
#8 If person is a nigger, say "good day, sir" when they leave. Tell them that you're an equal-opportunity employer and talk with them for many hours before the "good day, sir". Make them your best friend and invite them to a barbecue with your family. Then take them to a dinner at a classy restaurant and drink expensive champagne with them.
#9 Examine their source code.
If you stick to that, you'll weed out good canidates from the bad.
I'll typically look for interesting things on their resume and ask things like:
The point is that I would rather have a moderately experienced coder who knows how to think than some prima dona, Java Certified, programmer who cranks out crappy code and doesn't get along with other team members.
Thus sprach higg.
... you are not measuring anything meaningful. I can memorize answers to many things that you can ask me (see the slashdot sites for specific examples). It is only when you get me in front of the stuff can I perform, and either sink or swim.
There is no question you can ask me that is truly indicative of my knowledge level/ability. OTOH there is simply no way to fake actually doing the work.
On a very much related note, some of the worst people I have hired have been straight A students from top universities. Some the best people have been B and C students. Seems counter-intuitive, but many of the B and C folks really are quite smart, but are bored with the classes. It is hard to find these nuggets, but when you do, single people of this ilk are worth 10 of the best folks from MIT.
Find out what gets their juices flowing. If it is nothing, well, you have a dud. See who has gone far afield to learn how to do something. See who has taken the road less traveled. It is more often than not, the people whom you least expect.
In various fields of study at universities, you often have many foreign (for the US) students with straight 4.0 averages. Seemingly wonderful students. Get them into a lab, give them a measuring device, and tell them to "do". Most of the time they cannot. has to do with the fact that memorization is not learning (internalizing and understanding). Many straight A types are memorizers. These are the ones who do really well on the questions you ask.
Give them a 60 day window if they pass the rest of the muster. If at the end of the trial period, they have not measured up, out they go. Wheat will be in one pile, chaff in another.
Amen to this, I think far too many "managers" out there are the cause of employee failure, not the employees themselves.
/. how to solve your management problems is like asking random guy on the street, we don't understand your situation nor do you have confidence in our ability to address your concerns. Now back to our regularly scheduled advert^H^H^H^H^Hnews articles.
Given the areas that phamlen is asking the candidates, they have some skills...But perhaps the questions don't match the needs of the workplace or (I'd guess being just as likely) the workplace is not conducive to productivity and the managers are expecting far more than is humanly possible. Then again, anyone dumb enough to work for such a shop (and not quit) are fools as much as incompetent.
(Phamlen, had many people quit the project?)
Unluckily, asking
Having hired several programmers who haven't worked out...
... or showered, or shaved...
1.
2. For myself, having hired several
bodybuilders who haven't programmed...
Considered harmful.
Not just a programmer, anyone technicial!
All the interviewers I've had the misfortune to interview with these last five months have had one thing in common, they are very uncomfortable interviewing older workers, they seem to want animated snappy youthful answers to their question, I even went to a workshop on inview tecniques, I thought the video examples they showed us were just plain stupid, the actors in the little vignettetts heads were bobbing around like some crack addicted bird, I was told by the instructor that I "had no body language" and that I should "project enthusiasm", what a bunch of BS!. It would seem that answering tecnicial questions correctly isn't enough, you have to look like you are a member of the interviewer's peer group, you know someone to have as a playmate, I didn't get a job as sysadmin at WalMart.com because the head System Administrator (a twenty year old kid) didn't like the fact that I prefer RedHat over Debian, your should have seen the look on his face when he saw me! even his Micky Mouse T-shirt got mad.
I killed da wabbit -Elmer Fudd
My boss is pointy-haired in that he has no idea about what I, or the computers I control do. Fortunately, he understands his pointy-hairedness and put me (the only programmer at the time) in control of hiring my assistant. Hmm. I'm gonna have to work with this guy every day. He's sharing my freaking office, for crying out loud! I'm gonna find me the best partner I can get.
So... I looked through the resumes, put the straight-edgers (class presidents, etc.), PhDs, (we're making webpages, not rockets... we can't pay for that) into the "I'm keeping this because I'll get sued if I don't" pile, and called in some of the younger guys (my age) for interview.
When they came in for interview, I took them into my office with my music blaring, and shut the door. I seated them in an almost ridiculously small folding chair, contrasted by my boss's plush leather armchair that I was sitting in. There was a normal chair turned to face the wall, which only one applicant took (he was the only one that passed that test). I started out with a few questions, but other than a few skill-related questions, it was mostly personal. The less I liked them, the less personal it was.
Then I got down to business. I showed them my company's website, a little bit about how it works, and told them about a feature that we were adding. Told them a bit about how it was supposed to work, and showed them my prototype. It took me about 30 minutes to do, and I told them I expected the same of them. I sat them down, and watched them code. After about 20 minutes or so, I'd ask the applicant if they were uncomfortable from my presence. If they denied it, I stayed there. If they didn't, I got my homework out and worked alongside them. I got a very good picture of how they worked under pressure, and how they coded. I denied more than one fully-qualified applicant on the grounds that I knew I wouldn't get along with them. I'm still confident that I hired the best man for the job, 4 months later.
.sigless since 2003
#1 sign of a good programmer: self-starter who reads documentation and uses example code to write in any language. Face it, no programmer you hire knows the apis and features of the language you select and the architecture you construct 100%. A good programmer learns quickly, adapts programming examples (with code conservation). Stupidest questions ever in interviews: Can you tell me how works? I.E. is Friendship inherited? Please. A good programmer RTFM when he needs to determine if friendship is needed and if its inherited.
Hey, I'm just your average shit and piss factory.
Of the dozens of people I've done technical interviews of, the clear factor distinguishing the hires who worked out from those who didn't was their ability to go in-depth on a topic. It annoys the heck out of me to have someone listing an MS degree (or with a decade of "experience") who can't expound on a subject without prompting.
Heck, I recently revisited my resume, and realized that I could still go deep on projects I've not been working on for 5 years or more.
Well, technically, two:
1) "Are you Das Megabyte?"
and
2) "How much do you want?"
Hey freaks: now you're ju
I find that criminal background checks are useful.
Give serendipity a chance.
I recommend you read _Ask the Headhunter: Reinventing the Interview to Win the Job_ by Nick Corcodilos. Nick is a silicon valley head hunter and also writes a column for the EETimes (http://www.theworkcircuit.com/headhunters, also good reading). Although intended for job hunters, I think much of his advice makes sense for employers looking for new people. To summarize, he says the best interview is one where you actually do the job, thereby showing your ability to do the job. The reason you were disappointed with the people you hired? You asked them one set of questions and checked for one set of skills, and then when you hired them, you expected them to have another set of skills.
Sit them down and show them the work you want them to do. In particular, show them a problem you currently have open and ask how they would approach it... Get them doing the job in the interview.
It doesn't matter if they can answer riddles.
It doesn't matter if they have a shiny resume
It doesn't matter if they know exactly how language X's pre-parser works.
It doesn't even matter if they are a genius prodigy programmer. (seriously)
What matters is that they can (help) solve the kinds of problems your group faces regularly (or expect to face soon).
So try to get them doing that during your interview. If they can, they you have a potential winner and can start thinking about how they would integrate into your group's personality.
Then you have them casually meet their potential co-workers and you can get those people's impression of the candidate.
One website I really love is: AskTheHeadhunter
Particularly these articles:
asktheheadhunter.com/harespecting.htm
asktheheadhunter.com/hatenmistakes1.htm
asktheheadhunter.com/hahireright.htm
Come play free flash games on Kongregate!
have your interviewee sit down at a machine with a random file of code open in some development ide.
then time how long it takes before IE is fired up to slashdot.
(withdrawal symptoms such as sweating and mouse-finger-twitching often appear first, so these are sometimes good indicators as well)
So before you attack Gimp, I suggest you consider what you are saying.
Did you realize that a troll actually has to have some sort of truth or some sort of humor in it? You have missed on both marks. I didn't even mention 'Gimp', you gimp!
mogorific carpentry experiments
I wrote my resume in PDF (Specifically LaTeX) and it looks rather good.
NOBODY FRIGGIN' CARES. They want MS Word.
I often send my resume in BOTH formats. One woman (recruiter) was completely lost as to "what the 'other' file was".
PDF gets you nowhere with HR or recruiters.
And the funny thing is that the majority of jobs that I am applying to are Linux / Unix jobs.
You won't be considered unless you submit in MS Word.
Period.
Were I to have the permission/wherewithal/time, I would try to get three other people and play either a game of Hearts or a game of Spades with the candidate as my partner. What might also work would be to get some poker chips and play a few rounds of No Limit or Pot Limit Texas Hold-em, just to see how they react.
Or maybe I'm just a sadist.
"My God...It's full of ads!" -Fry, about the Internet, Futurama
whatever you're thinking of doing, guarenteed it won't work.
I worked at a large pharmacuetical company in the support center. One day I and a collegue were given a call to a user who had recently installed a scanner, and now thier SCSI card wasn't working. I think it was on a Sun Ultra machine.
On arriving at the users desktop my collegue starts fucking about with a windows CD ROM, which for obvious reasons wouldn't install (presumably he hadn't even realised it wasn't windows). After 5 minutes he proclaims that the SCSI card is dead because "the balloon didn't go up".
On questioning him on what the hell this balloon stuff was all about, it turns out his only experience with PCs had been working in a PC World, installing components - as all of the components were identical, and the procedure always the same he had assumed that ALL computers and components were the same. The balloon in question was some kind of SCSI checking program that came with the cards he was used to.
Anyway, after that it took me ~20 seconds to discover a SCSI ID conflict. switch flicked, job done.
1) There is no such rule in English, and
2) In this instance, "to" is a verb fragment, not a preposition.
It doesn't mean much now, it's built for the future.
I've had two interviews recently and they were both superficial. They wanted me to think creatively on my feet on an optimization problem, debug a simple string class, and quote verbatim from windows.h. None of their questions accurately assessed my programming skills. Creative thinking is hard to do in a group interview situation, fixing a string class is a fair enough test but I should be left alone to do it, and who cares if I know the exact syntax of every function? My interviewers tested my charm and memorization skills, and lost the opportunity to hire a great programmer.
On a similar note, don't look for a grocery list of skills, look for concepts. For example, a company I worked for hired two Java contractors with lots of Java and Oracle experience. Their skills were a perfect fit, but they both left a showstopping bug in the main servlet because neither one of them had a clear understanding of how client-server applications work. There is a difference between years of experience with specific applications and quality. Quality usually comes with a passion for the work, which is why so many of these posts have emphasized personal projects and open-source contributions.
You test, test, test....
We have been looking for a Java Programmer for some time, and to alleviate the riff raff we typically give them a Java Test, and SQL Test. The SQL Test is more knowledge base with very little thinking and the Java test is mostly developing algorithms. The sad thing is a lot of the people come in asking for a starting salary twice as high as mine, and can't even pass my fscking test. Sad thing is no one has passed the test yet, so we haven't hired anyone...
I would say this test is on par with a 2nd semester programming class midterm.
"It takes many nails to build a crib, but one screw to fill it."
Answer: It's not difficult at all.
... missing number = 55 - (sum of the 9 given #s). Easy!
If the interviewer gets stumped by this answer they are not smart enough.
(Remember an interviewee should also try to find an employer who is a good match. A dumb interviewer asking apparently smart questions is a bad sign).
Interviewer: care to elaborate?
Answer: "Assuming that the question meant you're given 9 #s between 1-10"
state your assumptions when given such poorly worded questions. Good scientists, Engineers and even Techs (e.g testers or tech support trouble shooters) never blindly assume anything. State your assumptions & keep them in mind all the time. Ask for clarification when forming the assumptions. If the assumption is wrong you'll likely get a wrong answer. On the other hand if you correctly answer the wrong question the interviewer will think you're crazy.
Is it difficult to find the missing # that would make a total sum of 55?
No b'se
Give them a programming assignment besides the general interview. Even if it's way over their heads (or may take too long to do in the time given), pay attention to how they go about solving the problem.
Tell them, "Try to do this and return anything of value that will help you or others achieve the goal."
So we asked some basic Unix questions and a bunch of general CS questions.
Certainly as a manager you need to know what skills your guy is really going to need, and whether this guy has these skills (or is going to be able to pick them up in a reasonable time). I'm only suggesting this:
For a lot of programming positions, many applicants will be overqualified technically - or at least able to get the job done in a reasonable way. In these cases, your best bet as a manager might not be to say "Which of these guys has the most technical knowledgge?" but instead "Which one of these guys is going to work hard, be willing to learn, be good to work with, etc..."
For lots of jobs this won't be the case. You'll need to verify specific technical skills.
Let's not stir that bag of worms...
I'm glad someone mentioned this. Being a good programmer is not the same thing as being a good teammate.
If your project is a team project and I assume it is then you need to hire good teammates. That means someone that can do the work *and* someone who fits into the team culture. That doesn't mean they have to be carbon copy personalities, but it does mean that they need to get along with the people they work with.
I once made a horrible mistake in this regard. We interviewed this guy and he was technically smart, but his personality seemed oddly stoic. I thought he was just nervous because of the interview. Turns out he was just weird and not in a good way. He was a loner and lacking many common sense social skills. He just did not fit in, and try as I might I could figure no way to connect with this guy. Our boss had to micromanage him to get him to do anything. Needless to say, it was not a good situation. He was not a good teammate, and although very smart, he did not contribute to the team effort to the degree which was required.
My requirements for a new hire are that 1) They are smart enough to be trained to do their job in a reasonable amount of time and 2) They are someone I can relate to on a personal level. If I can't have a casual conversation with this person then I know that working together will necessarily be less efficient.
The most productive teams I've worked on are the ones where my teammates also became my friends. These groups are spontaneously organizing. We had informal offsite get togethers often, and no one person was the central organizer of this effort. Things just happened, and work was the same way, things just got done without the need for much management. We just worked together well, because we got along with each other well.
I would also advise against hiring someone just because they would make a good friend. They have to be able to do the work too.
My last piece of advice is, if you do find yourself in the situation where the group is high functioning and high performing, don't let upper management fsck it up. Unfortuantely one of my greatest success stories also became one of my greatest tragedies, because management couldn't let well enough alone. They destroyed the team and nearly destroyed the project. It is still limping along now, but it may not survive.
The key is to hear somebody say "I don't know but so what?" People without fear are the best programmers/sysadmins, it's impossible to know everything so the key is to be brave enough to find out and solve a new problem by themselves.
....(Can't remember but they are fired at the end)
Fear leads to anger, anger leads to
My thinking on this is that you can throw as many technical questions at a person that you want, but what you might find is someone who may be a good programmer, but not a good employee. I would qualify a good employee as someone who has a good aptitude to learn, communicates well with others, and is going to add personality to the work environment.
Being on both sides of the interview process, what I find works best is to have a conversation, not an interview. Ask questions about their non-computer related interests, get a conversation going from that, and once your into a conversation, continue to have a conversation about the more technical and business aspects of their experience. What you do is make the person more comfortable and gets them out of their pre-rehearsed "interview" shell. If you can't find experiences in common to talk about, or they have no interests aside from computers, that probably was not a good candidate to work in your team. You still will want to get a sense of their technical acuity by asking them technical questions, but not until you have had a chance to assess their personality.
Incidentally, in one interview I was asked "Do you consider yourself a programmer?". My response was that I consider programming to be one of numerous tools that I use, but I had no interest in doing nothing but programming. The interviewer's reply was "Good, we don't hire those people." I got the job, and am still working at it three years later.
Well,
In 50% of the interviews I was evaluated it was obvious that the interviewer had far less clue than I.
That might be a typical problem as "staffing" often seems to be done by guys from the staffing department.
So, two things bother me:
as potential employee I do not know how to answer a question where I see the asker does not understand the question himself but is looking in a list of possible answers wehter I answer correct.
Further: as an interviewer I meet regulary people who just learned one thing: how to pass a test, how to be brilliant in an interview, how to socialize to look "intelligent" / "nice" / "competent".
With interviewers not mature in the topics important for IT/developers/architects/programmers you never find the right guy for a job.
With questions who only imply "Oh, my god, what does the interviewer like to hear?" reactions, you get no good answers form a good guy either.
Does friendship get inherited, is a absolutely dumb question.
Its a typical question which tries to trick even the expert.
And the question does absolutely not matter.
Better questions would be:
Suppose you have a bug to fix. The bug involves a wrong value in a private field of a certain class.
Wich options do you have to modify the code to solve the bug and to access the private field to store the correct value?
Why would you prefer one option over the other?
And yes, using a friend could be one of about 10 possible solutions.
And each one has their own advantages and drawbacks. And certainly the discussion is far bejond a simple job interview and the fnnal descission can not be made without looking deep into the problem environment.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If you are hiring a java developer the worst thing that you can do is ask questions about java. Real programmers will not remember all the niggly little details because they can look them up when they need to. By definition, anybody who knows a huge amount about 1 language and is applying for a job doing relatively menial work in that language does not know how to program. The algorithmics interview is good and the nontechnical interview is essential, but then it becomes a question of what you ask. If you want somebody to write good code for you they have to love writing code; so find out when they started programming: was it when they were 10 and got onto the commodore 64 or was it when they entered first year in some kind of college? Ask them about the recreational code that they have written on their spare time. I've yet to meet a competent programmer who doesn't write their own stuff.
I spent a year writing java for a dotcom and it was all good code, but for the life of me I couldn't tell you whether friendship is inherrited right now. But give me the code you've got and a week and I can outclass (bad pun) anybody who "wins" in your java interview.
Another really important thing is to make sure that people have a handle on assembler, digital design, and structured programming. Nomatter how object oriented your codebase is, if they think structured programming means putting in gotos when they don't know what to do, then they are not worth their salt. Likewise, if you are going to get decent code out of a developer, they've got to understand what it will look like when a compiler is through with it...even if it is being compiled into a java class, that is no excuse for not understanding how it would translate to assembler commands.
And with the digital design type stuff, it may seem irrelevant, but I once had a long argument with a coworker (with a degree from Sadam Hussein University - I kid you not) who really beleived that a variable in java could be written to atomically; she was a human dictionary of java definitions, but she spent two weeks writing a procedure to put commas and a period in dollar values for large sums of money...and it didn't work when she was done. Looking at the code, there was crap I had never seen being written; I couldn't make heads or tails of it. Someone who can't do this in about 20 lines of code should be vaccuuming the carpets at night, not writing code. The scary part is that she was the one interviewing the new developers at the time by seeing if they knew the java buzzword definitions etc, and ALL of those hires were heinous.
To sum up, you're much better off looking for a good programmer with a degree from a good school (read: Waterloo, MIT, CalTech, Carnagie Mellon, IIT, etc) who has never seen java than somebody who read the book, How To Pretend to Know What You Are Talking About: Java Edition.
You might want to take a look at MicroSoft's methods of hiring...despite everything about the company, they are good at hiring. I once had an interview with Cognos that was really superb too. The technical portion included questions like, "Here is some code; will it compile? will it run? if not then correct it." The last question was, "Estimate the number of cars in Canada [because that is where we were]. That question was judged on time, explanation, and result. Not only that, but it confused the bejesus out of me to be asked that immediately following, "at what point in time will this variable actually be initialized"
There are three crucial things you need to find out:
CompuServe used to administer a test for anyone applying for a programming position. It was called the CompuServe Programmers Aptitude Battery and you had to get at least 80% to be hired for most programming positions. The test was similar to an ACT and covered logic, math, etc.
It actually worked pretty well, though of course it didn't handle personality issues. That's what the actual interviews should be for.
* As is generally the case, my opinions do not reflect those of my employer.
The unit I work for has a policy of hiring new tech staff via a temp agency first, so if they don't work out they're easy to get rid of... I don't think it's the best way to do things, but depending on your situation it just might work.
Take him to a bar and see how well he can hold his liquor. If he holds it well, higher him. If he also buys, make him the CEO.
1.) WHAT is your name?
2.) WHAT is your quest?
3.) WHAT is the capitol of Assyria?
Riddles are a useful but dangerous interviewing tool. You need to steer clear of "gotcha" riddles. Those are the kind that either you get or you don't, and no amount of sitting in silence is going to help. They have some sort of 'trick' and basically a one word or one sentence correct response. Which direction is the bus going (hand-drawn picture of a bus)? Left, because you didn't draw the door. Terrible interview question.
Riddles that require the interviewee to ask a lot of questions and talk things out are very good for gaining insight into their thought process.
"Faith strikes me as intellectual laziness." -Robert A. Heinlen
I was interviewed at Adobe Systems a long time ago, and one of the people asked me if I liked my mother.
Leon: My mother?
Holden: Yeah.
Leon: Let me tell you about my mother...BLAM!
As a person who has been programming professionally since graduation 1988 (and a lot longer before that), I'm not a fan of worrying about certifications. I've programmed in i386 assembler, C, C++, Java, Prolog, VB, Windows, Unix (multiple flavors), and if I didn't feel like programming any more I have full LAN admin experience in both Windows and Unix. I've spent my free time building Linux From Scratch (www.linuxfromscratch.org). I programmed in C++ in the days of cfront and have taught it in classrooms both at work and at a local community college. Then fairly recently my employer decided it likes to see certifications and wanted people to get them. I was actually working as a LAN admin at the time, was my department seriously going to pay/let me waste time getting my C++ certification? I think not. Was I really going to get my MCSE, Java, Unix, C++, and LAN security certifications? When would I have time for work?
Also, I'd much rather ask someone if they program for fun. While I like open source and use it all the time, the programs I spend my own time writing have so far been VERY specific to my home setup and wouldn't be useful enough on a wider scale to distribute - I've also been more in "what is possible (and educational)?" mode rather than what
would be practical for others to deal with.
The problems with technical questions is that technology changes quickly and people who tend to memorized "syntax" are great programmers in that one area. They also tend to be less flexible about what they can and cannot do - and they tend to stick with the areas that they are the experts. Then when they new technology hits - they are the ones trying to play catch up.
I tend to seak out people who =
a) Understand the software concepts (OOD - or just design tradeoffs - for example) and can explain them to a ten year old. This shows that they can break down a problem to it's simplest form.
b) Do not have all the answers, but knows where to find them (the answers). This shows me that they can teach themselves - this is a biggy...
c) Finally - that they have completed projects. This is the hardest to find in a programmer. The closer we (as in programmers in general) get to finishing a project - the more we look to the next project. Finishing is must in order to be successful....
Jesus H. Crist
Quit being such a bitch and write the code your goddanm self. You fucking pussy.
Then at least you'll know it is right
I interviewed with Microsoft for a software developer position. For one of the on campus interviews I had a programming test. I was shown a sheet with C source that had Open Soure info in the comments. I was instructed to copy it to Microsoft compatible libraries.
Another task was to write a few text manipulation functions in C that are part of Microsoft's implementation of C. I had to repeat the same thing for each language I told them I was interested in.
Soon after the interview Microsoft flew me out to their campus to meet some of their people. Their people are very unorganized and it is suprising they actualy produce a products.
contract to hire.
The Kruger Dunning explains most post on
People usually hire others that they feel are similar to themselves. If you have had a bad run in hiring good programmers, perhaps you shouldn't be interviewing them (seriously, this isn't meant as an insult).
It could also be that your organization isn't attracting the top talent. Most places think that they are the end-all, be-all of great places to work, but most of them are not. Good luck telling them that, though.
ESB
Cliff,
Although the majority of my friends and coworkers would argue with me, I am a moderate programmer at best. I also have a small social science background and therefore have my share of interviewing experience.
I see a few issues with your interviewing process. First, asking relatively simple algorithmic questions does not accomplish anything. If your interviewee is a poor interviewer and happens to be nervous then they may make mistakes that the normally wouldn't make. If the person codes the algorithm effortlessly you still haven't learned anything about them. They could still be a terrible programmer! Unfortunately it is not practical to ask a difficult algorithmic question in an interview because of time constraints among other reasons. Second, your theoretical questions seem quite limited. Questions like, 'Is friendship inherited? How would you find out?' let you know how well your interviewee knows a language and its basics. Again, you don't seem to learn much from this. Your interviewee could be an amazing programmer in a non-OO language.
I am a firm believer that everyone is capable of answering the questions you ask at interviews. It all comes down to if they have had exposure to the languages you develop in and if they are nervous interviewees. Both of these things should be completely irrelevant to the interviewing process. In general, employers want someone who can excel not over the first few weeks on the job, but someone who will excel over their entire career. To uncover if an interviewee is capable of doing this it is important to learn two things: how well does this programmer grasp big picture concepts and what type of projects has the interviewee been involved in (and what was their involvement)?
If the interviewee has a good understanding of the concepts behind your project you know that they will be able to add to the project team. If they don't, it is a good idea to ask the interviewee big picture design questions that pertain to other areas of programming (Systems, Data warehousing, Networking, Graphics, etc). This way you can figure out if the interviewee is capable of understanding the entire project you are working on.
If the interviewee has worked on some large-scale projects and is able to explain a good overview and a specific piece in detail (preferably something they coded) then it is safe to assume that this person can program effectively. This eliminates the need for algorithmic on the spot coding questions. If you are worried that the interviewee is not proficient in the languages used for your project then it may be necessary to ask some of your language specific questions (memory management, pointers, OO questions, etc). Just remember, the longer you plan on having this employee work for you, the less important it is that they know every in and out of a language (languages are just a tool to convey the design/theory behind your project).
Interview Outline
1. Ask questions about hobbies, sports, extra curricular things
This accomplishes a few things: First, it gives you a grasp on the interviewee's personality. Second, it gives the interviewee a few minutes to loosen up.
2. Ask about previous projects they have worked on
Generally people are fairly comfortable discussing past work experience. They are transformed from an interviewee to an expert on their pervious projects.
3. Go in for the kill and ask the questions that pertain to your project.
a. Overall design/theory question
b. Possibly some extremely important language concepts
If they are in a slightly different role, e.g. sysadmin, see the sites they run. Ask them about uptimes, downtimes, reasons for these, possible improvements. What would they change? What do they like?
These questions are all easy - if they actually work on the articles in question, they should have no problems. Their answers might surprise or impress you (or not). If you like their work, and you appreciate how they achieved it, then hire them. My website (down at present and I don't want it slashdotted anyhoo) is based on remarkably (less than one week's) little coding experience - but it runs MySQL/PHP/Apache and I like to think it looks pretty. Could it get me a job? No - I don't know enough. But I could talk about it enthusiastically, to anyone who would be interested, and I could explain exactly how I achieved what I did, and how (IRC, those web monkeys built my damn site, I admit it!) I would change things a second time. Getting the job done is far more important than than how (unless you are Sigma designs...) and what better to talk about than your own work? After all, you know more about it than anyone else.
This idea was invented by Shampoo.
This is a common fallacy. Crackers are basically QA testers: looking for flaws in a system. While this is a useful thing that the security guy needs to be do, the security guy has a bigger problem: design a system without flaws. Actually, the problem is worse: design a system as "flawless" as possible while still meeting the needs.
They both need to aware of the things that go wrong, but designing requires much more global thinking, while hacking (and QA testing) requires much more patience and persistence.
The skills to be an editor are different than the skills to write a good article. Managing programmers requires a different skill set than programming. Cracking is different from securing.
We started our company as a partnership. Two programmers and a guy with lots of charisma and sales ability. When the time came to expand and hire another programmer our sales guy handled it.
After a hundred or so resumes and about 20 interviews he found the perfect fit for our company. The prospect was into snowboarding, rollerblading, ultimate frisbee, and had cool taste in music. However after I asked a few (barely) technical questions it became clear that he couldn't code himself out of a wet paper bag.
My one piece of advice is to be aware of the people whose only experience is a 6 month course. Good programmers whether self taught, or formally trained have honed their skills over time and all good programmers have some sort of portfolio of code they have written. Even if it is a school project.
it works in the other direction though; A good security guy *SHOULD* be a good cracker... or at least familiar with the methods. I would think that most are... I know how to secure systems (except my current one... since you can't layer security over windows^H^H^H^H^H^H^Hinsecurity) but it's much more fun to break systems ;)
Oh god, that woman is John Romero!
My favorite question to ask when interviewing a potential co-worker is "what question should I have asked you?". A good candidate will think up a question that you never would have, and a good answer for it. Someone who thinks at least a bit differently than you can be a great asset, as they are likely to be able to offer alternate approaches to solving problems. I always save that question for last as it gives the interviewee the chance to get in any information that they wanted to convey, but didn't fit into any of my previous questions.
A question I usually ask near the beginning of the interview is "reading what book has most improved your programming". A great answer is something like "the pragmatic programmer", "code complete", a book about development methodologies, or a general computer science book. An acceptable answer is any decent in-depth book focused on a specific technology. If they answer foo in 24 hours or bar for dummies, or can't come up with anything, the interview ends quickly.
Aside from that, a programmer needs several things to work well, but three utmost are:
- Basic skill set, knowledge of tools used in particular tasks in your company - you don't want to hire a programmer who knows little java for an all java job unless the other qualities are far and above others you interview who do know java
- Problem solving skills, an interest in the solutions of unique problems, etc. This is your programmer's greatest asset. Their ability to find out information about something they do not know about is just as important as leaning back and considering a problem. Finding an elegant solution is nice, but finding a solution that is workable and maintainable is paramount.
- Lastly, and perhaps most important, is the ability to cummunicate. 90% of your problems are problems of communication (and 72% of statistics are made up on the spot). Teamwork is important for companies where programmers work together, but more important where they work alone or are one of the few technical people in their department/company.
-AdamYeah, it's exactly like Daiktanka's engine ... only a little better.
(I didn't bother to check the spelling of Daiktanka because I don't really care)
The first foo is a pointer to void. The second foo is a pointer to a function which takes no arguments and has no return value.
...so I guess that tells us that you don't check your work ;)
... to simple questions.
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.
Don't you wish your girlfriend was a geek like me?
She's dead you insensitive creep!
You're set from there out.
Just becuase you memorize definitions (ie: what is friendship? what is polymorphism? what is inheritance?)... doesn't mean you know what they are, how to use them, and WHEN to use them.
I would definetly hire someone who is capable of learning, interested in what you're doing, and a hard worker. All of the "programmers" at my company fit this description. Then again, none of them are CS majors. All of them are Electrical Engineers... Which is probably where their problem solving background was forged.
Apparently it needed to be pointed out -- nobody else has.
Given that this comment was made in the context of hiring, I think the implicit assumption that the candidate would be a heterosexual male is even more disturbing.
Come on people! Don't let this kind of crap go unchallenged!
and don't hire them, because not only do they read every single Slashdot article instead of working. But now they also know all the same tricks you picked up here.
You can't handle the truth.
What would you do if you ran out of things to do?
http://pcblues.com - Digits and Wood
You have worked at all these programming jobs and don't have anything written outside them? I think anyone worth their salt has written programs outside of work or school. If they haven't then they probably don't enjoy programming enough to be very good at it anyway.
This Wiki Feeds You TV and Anime - vidwiki.org
In one of my previous companies we actually tracked engineer recomendations for new hires (i.e.: how well did a person you recommend to work at the company is actually doing after a period of time X), and after about 18 months I came up on top of the list after 98% of the people I recommended ended up being described as "outstanding".
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.
So the guy that has thought about the problem wisks off an answer in 30 seconds and appears a wizard. The guy who has not encountered that specific problem really searches the depths of his experiences and doesn't flash an answer until he is pretty sure it is the "best" answer - and after 15 minutes of very careful design places his answer on the board - and in comparison appears very slow.
Now what does that tell you about the performance of both applicants for a problem they haven't seen before?
So hire the female that looks good in a short skirt. If she is not the best programmer, so what, educate her.
I am only half joking. Women on average tend to be better at listening, empathic to the needs of others, less likely to hide behind jargon, willing to admit to not having all the answers and ask questions, and will work very hard to prove that they deserve their job and are not just a pretty face.
So you'll be getting someone who is willing to work with the team, can listen, less likely to be a smelly offensive troll to non-technical colleagues, and you'll be helping to combat the inbalance of the sexes in computing.
Oh, and hire someone happy to work for your company. Most of my employment partings involve not being able to stomach my employer or the (mind numbing) work I did for them any longer.
The ability and willingness to learn.
The interveiwer for a professional position must examine candidates in terms of has done, can do, and will do.
Has done is what you see in the 'employment history' or 'career background' sections of a resume. It should be evaluated for scale, ie: how many millions of dollars was in your budget? Mostly, however, it is used as proof of can do.
Can do is what the interviewee can do for your company right now, with no training or preparation. While this is important, it is nothing compared to
Will do, the potential benefits your candidate would provide with training and advancement. An assessment of loyalty is made here, as well. No need to train someone to get a better job with a competitor.
Ever gone into an interview as the most experienced candidate within a 300 mile radius, only to find the (bastards) hired some entry-level hack? Well, sorry to tell you, but you were almost certainly lacking in will do.
Technical questions are good for can do, but so what? What do you do when the limit of can do is reached? Your boy may be able to recite the entire Win32 API by heart (which would be damned impressive), but what happens when your company makes the move to *NIX? He better have a hell of a lot of will do...
Oh, and a tape recorder to take notes.
I like to ask them what they don't like about their favorite programming language. This will either reveal their strengths or weaknesses very quickly since it exposes the boundary of their knowledge and experience. It's also useful to ask the same question about tools, OS's, methodologies, etc.
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!
All your favorite sites in one place!
You need to concentrate on someone who is able and willing to adapt. Be they fresh out of college or 50 years old if they're only ready to do one thing they will be useless in a changing industry. Experience with the technology you're focusing on in the short term is crucial but general computing knowlege (as seen the the Knuth books) and decent finite math skills are a much better measure of long term worth.
You want someone who will go learn Java, C++, Perl, PHP, ASP, VB, or C# at the drop of a hat if that's what is required. Find someone who understands theory and has working in several different languages if possible because they make the best programmers over the long haul.
Once you find this person treat them well and try to keep them around and happy and if they don't work out don't be afraid to fire them. The mistake that most companies make is they don't fire the incompetents who drag them down (especially in small companies where dead weight is a death sentence). Unemployment may suck but crappy code and having a salaried slot filled by a useless mound of meat is worse.
Ask him or her to count to 10 if they start at 0
Hire them!
dude, we like you, you seem to be good. now there's just one thing.
would you prefer bangalore, bucharest or sydney..umm?
Your post raises a lot of questions in your interview techniques themselves. First, as another poster has mentioned, "Is friendship inherited?" and "...how do you find the missing number?" are not particularly useful indicators in language and algorithmic knowledge.
The second question raised is that you have two technical interviews and a final interview covering, I assume, more HR-styled and team-based questions. At most, you are probably talking about 3 hours (assuming each interview is 1 hr rather than 30 or 45 minutes), and that in practice is often not enough time to tell if a person interviewing well is going to work out. Sure, you can spot an obvious dud in 15 minutes or less but identifying a false positive takes the better part of an afternoon. For example, at Microsoft, a programmer typically has an HR interview followed by 4 1-hour technical/team interview, one as-appropriate, and one more return trip to HR. That's the entire day when lunch is tacked in. (Although, not everyone in the MS interview loop is as skilled as others
First, sort out the garbage candidate by doing 30 to 45 minute phone interview. Spend 5 minutes going over their overall background (right off their resume). Many people OUTRIGHT LIE on their resumes and this is much more true of students than long time professionals. Young graduate students who are about to leave with a masters degree and who have never had real job experience are famous for padding their resumes with crap. If someone says on their resume that they know Java, ask them how long they have programmed in it and what they have used it for. Don't forget to turn on your bullsh*t detector before they start speaking. After the background stuff, ask a couple of "simple" technical questions regarding data structures and algorithms. Remember, this is over the phone so you can't get too hairy where you will need a shared work surface (blackboard, whiteboard, piece of paper). Just make sure that they can verbally describe how to traverse a binary tree in order (or pre-order, or post-order) or something to that effect. If the person breezes through this in one minute, ask one question that is relevant to THE AREA OF EXPERTISE REQUIRED BY THE JOB: (multithreading and deadlock; rule-based logic programming, etc...). If the person resume need not be garbaged collected at this point, spend the final 15 minutes on the phone talking to them about your company and the job that they are applying for. Ask them if they have any questions about the job although keep things brief. Invite the 5 (give or take) most promising and inquisitive candidates to interview and assume that you will push one person through per day -- this will take an entire week.
On site interview: bring in the candidate for the better part of the day. Think 10am through 4pm. Schedule lunch with one or two team members included. You can learn a lot about someone over lunch regarding how they will fit in. Not including lunch, schedule 30 minutes to 1 hour of HR-styled interview, 2 to 3 hours of technical interview, and 1 to 2 hours of "here's how we operate" interview (which can be schedule as appropriate based on how well they have done so far).
Technical interview: DON'T waste your time with puzzles or brain teasers. DON'T waste time on programming language trivia. Instead, do the following three things: give them one _warm_up_ algorithms/data structures questions based on something that you or your team really had to implement. If someone really needed to implement a linked list and then perform some search, sort, delete, or insert and this really exists in your code base, ask them to pseudocode on the whiteboard some functions that maintain a linked list. Note, I didn't say what kind of linked list or what it will be used for. LET THEM ASK YOU for the specifications. There should be conversation about what is needed while the pseudo code is being composed on the white board. A good candidate will get through this in 15 minutes or less.
That leaves the 45 minutes left in the first of two technical interviews to ask real questions regarding the kind of code your team is implementing. I can't tell you want to ask here -- you need to figure this out yourself but, does your programmer need to do a lot of design work or will s/he being implementing from godly detailed specs handed over by someone else (who really has the time to dot the i's and cross the t's -- heck, you may be in aerospace!
The second technical interview, done by someone else, can go more or less the same way. The idea is to have two different people assess the candidate's technical abilities. If you require that a person can hit the ground running in a specific language, the second technical interview can focus more on programming language skills. Ask a few straight forward questions about proper use of the language (Java: what is the difference between an abstract class and an interface? When do you use one over the other?) and pose then some straight forward design questions that can be solved with 15 minutes of code writing. Again, pick something relevant to your business. Assuming that there is time left over, pose a coding problem that you (the interviewer) recently got stuck on and just talk it out to see what they would do with it.
Third technical interview: ask the person about a recent project that they contributed to. Have them explain to you what the problem was, what the requirements were, how the solved the problem, how the solution was implemented and (if relevant) how the team worked together and how the code was maintained. Listen, ask questions. And ask yourself -- can this person explain things such that I (and others) can understand what the heck they are talking about? This trips up a lot of techical wizzes. Sure, they can code but they can't communicate. Can you afford to hire someone who can't explain things to other team members?
Heres-how-we-operate interview: Explain the job. Explain what the team does. Explain how the team operates. Explain what this person will be expected to do. Do they have questions? Are they excited about what you are telling them? Are they picking up on the subtle difficulties inherent in the position? (spent 20 to 40 minutes on this)
NEXT, tell them what their first assignment would be (or make up a real-world first assignment that is similar in nature to their actual first assignment). Ask them how they would go about attacking the problem. Schedule 20 to 45+ minutes to talk about this. Make sure that there is a conversation going on rather than them just scribbling on paper or looking off into space. You want to know HOW they think and how they plan to contribute. Talk through with them as they formulate a plan of attack.
Good luck!!
I spent all of those years as Anonymous Coward and all I got was this lousy number (204976).
I am seeing the job of "lackey" in your future.
I think the 55 - sum() method is the fastest way of solving this problem, unless you had an infinite amount of cache memory and could concatenate the 10 values together and just do a table look-up (assuming that the table was defined already).
the 55-sum() method is faster than the worst case binary search, and a much smaller algorithm:
li $1,55
lb $2,0(input)
lb $3,1(input)
sub $1,$1,$2
sub $1,$1,$2
lb $2,2(input)
lb $3,3(input)
sub $1,$1,$2
sub $1,$1,$3
lb $2,4(input)
lb $3,5(input)
sub $1,$1,$2
sub $1,$1,$3
lb $2,6(input)
lb $3,7(input)
sub $1,$1,$2
lb $2,8(input)
sub $1,$1,$3
sub $1,$1,$2
answer is in $1, in 19 cycles with no stalls. That would be 19 nanoseconds on a 1GHz machine.
With a binary search, you are going to have to worry about filling branch delay slots and things like that.
You could speed things up slightly if you loaded words (4 bytes), whose sums were precalculated in a 64K table. Then you could do
li $1,55
lw $2,0(input)
lw $4,4(input)
add $3,$2,lut
add $5,$4,lut
lb $3,0(lut)
lb $5,0(lut)
sub $1,$1,$3
sub $1,$1,$5
lb $2,8(input)
sub $1,$1,$2
that is 11 cycles, but uses an enormous amount of cache (which would of course take a lot of time to precalculate!)
Obviously, "what you interview for" is going to depend on the position you're trying to fulfill. A systems programmer needs a different skill set then a web "programmer".
This may sound like a radical idea, but the interview isn't for you, it's for the people the new employee is going to work with. So, try this:
Take potential employee.
Give them access bade for area they would work in.
Take them down "to show them around".
Manage to "lose them" for an hour or two.
Come back, thank them, etc.
Interview everybody else.
Karma: Food Fight (Mostly affected by Date Plate).
The best programmers can produce results in environments where there is both complexity (in the scope of work to be done and in the business case for the projects); and ambiguity (a lack of direction and not readily apparent resources).
This means you're looking for exceptionally bright, resourceful and highly internally motivated invididuals.
What questions do I use to identify them?
1. What's the hairiest most difficult development effort you've worked on, and why was it so?
2. Give me some examples of times you've had to make your own way through development and how did you go about it?
3. What's the most complex piece of software you've written and what made it complex in your assessment?
4. How do you produce results in an environment where your only resource is you - and how do you feel about having to deliver in that kind of environment.
www.hiredinsight.com
Something important to consider; if you are hiring programmers and have several that don't work out there is a good chance that there is nothing wrong with your technical interviewing. There may be real problems in the management.
A lot of frontline managers of programmers are exdevelopers promoted into leadership roles with little to no training.
Here are a few points to think about...
1) For the most part this isn't rocket science (NASA types please substitute something else like maybe auto mechanics)
What I mean by this is that in general most of us DON'T work on difficult research and development problems. The average programmer in your group is NOT going to create a new data structure or intriguing new algorithm or solve the halting problem. In general she will apply known good techniques to fairly simple problems for instance writing a device driver or web service.
Almost any technical interview will reveal if a candidate has the basic skills to do this.
2) Different people work differently.
Not everyone responds to the same managerial strategies. In fact the essence of management is in figuring out how individuals are motivated and figuring out how to meet that within the constraints of your corporate and managerial culture.
In general people like to work and like to succeed but are often unaware of what motivates them to excel. There are a few people who need little to no outside encouragement or affirmation to succeed. The fact that your group produces does not indicate perfect management.
How about asking hem their nick or email address they usually used and use google to search for the names. If you found them posting comp.lang.c or others technical discussions ( open source or non open source ), it can used as an indicator for how passionate the person is in that field. More posting - better . More posting with sample source code even better.
Use what you have available,
_asm xchg eax, ebx
Voila!
(cheers from the adoring crowd)
No you can't have the job, your answer does not work. Suppose the missing number is 4. Your solution will never catch it (unless the number is 15).
However, here are some ideas that might actually work.
I work for a major manufacturing company... I can't say who we are, but if you watch Formula 1 racing at all, you see some of our products....
And if you don't like Free Software and the GPL, we won't hire you. Go elsewhere.
If you're selling software as a business, then you're selling buggy whips in a world that has just met the Model T. Sorry guys, but the majority of programmers work as service providers to companies that make products or sell services themselves. Selling software when there are better Free Software alternatives is a poor business case, don't you agree?
If not, you won't be working for us.
Well, at my company several engineers interview each candidate and everyone has there own interview style.
:)
For myself, I like to pick a DSP subject on their resume that I only have a passing familiarity with and teach me as much as possible about the subject during our hour or so together. Filter design is my favorite, as I do very little of it myself, but I know enough to be able to pick out bullshit. Generally, I look for how much I learn and how enthusiastically its presented - enthusiastic, competent people that can explain complex subjects to others, well those people rock
But, in the end, you're right. I may have gotten bad vibe off of some competent people because they weren't as hyper as I am about the subject. On the otherhand, I don't know if I want to work with people who don't totally dig their work...
Tim
I don't think I've ever been broad-sided by a bad hiring decision. When I've made mistakes, it has always been because I was in a hurry to find staff. My strategy is to try to put the interviewee at ease and then find out what they like about being a developer. Then I listen. If the hour goes by quickly and I feel the candidate is enthusiastic about writing code, and critical about the work they have done previously, I put in a recommendation to hire. If I have any doubts, if the interview was just OK, I pass. If you feel you have to resort to gimmicks, you probably haven't found the right candidate yet.
Lookie here, and repeat after me:
"All the world is *not* a PC. All programs are *not* applications. Some programemrs have *zero interest* in writing code that isn't assembly language for small systems, to them C code and operating systems just get in the way"
I happen to be one of these people. Applications hold very little interest for me. I like programming hyper-optimized aeembly for DSPs, data framers, network aggregators, embedded control systems, etc. To me, if I'm not programming to the bare-metal, its an uncomfortable experience.
Needless to say, there isn't a whole lot of hobbiest stuff to do in these areas within the means of anybody who doesn't have a trust-fund and tons of spare time. Just to do my job effectively at work, I have over $300K of scopes and analyzers of various sorts at my bench - needless to say, open source is not gonna happen.
Tim
I like his take on all things software.
I guess that you have never seen people flail with closures, templates, or advanced macro techniques then?
Details of syntax are not a problem. Entire programming techniques and philosophies can be. Understand what your shop uses that others might not, and think carefully about whether that is likely to be a problem.
I think the key to your technical interviews is to have someone technical do them. Don't give some recruiter who doesn't know a three button mouse from a gerbil up his ass to read trick questions that you've typed the answer to for him.
Am I seeing this right? No-one seems to be saying "look at past work they've done". Look at their source code too, if at all possible, and find out how long past projects took, how many people worked on them, what they did to contribute, how they made technology and implementation choices, how they prioritized design ideals with reality, what major unforeseen problems they ran into and how they solved them, and so forth.
Asking pointed questions about past projects makes it pretty clear whether they have design experience and understand design tradeoffs, whether they can really handle writing a substantial sub-system, and whether they know how to write robust and maintainable code.
Quizzing people and cute interview tactics don't do any of that.
Another thing to consider when hiring doesn't work out: Are your own expectations realistic, or are they failing to work out in an impossible management environment? These are way too common, in my experience, to ignore this side of the hiring coin.
How they feel about there home computer and how
they connect (broadband) is intresting.
Put them in from of a keyboard. Many good programmers are good keyboarders (but not all)
Listen to them explain about a previous project. Think about if they were explaining a future problem to you.
Get a look at previous code they generated.
is the proverbial heroic figure who finds him/herself single-handedly saving the asses of the incompetent. I see. You must be a higher-up where you work, because this is every bosses wet dream. Come on...overlooking your domain reg deadline? That sounds like "oh, I thought it was his job" crap. There's a difference between what you want and resourcefulness. Too bad there aren't more of the people who know how to prevent that kind of crap from happening.
They interview you! at least the really good ones do...
Trust me, if the programmer is begging for a job then he is not worth his salt. If the programmer is making all sorts of demands then the one asking for the the most outgragous remuneration package gets the job!
but hey, even if the guy can't program worth beans, at least you can say one thing about them, they've got hutzpah! and they will go far in the company...
From excellent karma to terible karma with a single +5 funny post...
I am amazed at how many people seem to like riddles, quizzes, and tests. Maybe it's just me, but I have to think about something for a while, and if I am at an interview I am just not ready for such things. Or you run the risk of the person giving you a better answer than the one you know, and you may not even realize it! Example: An interviewer asked me "What happens if you decrease the sample rate on a digital control system?" I replied, "The poles and zeroes rotate around the unit circle toward pi." "No," he replied, "it causes the phase margin to decrease." What was I supposed to do then, teach the guy a semester-long class on the z-plane versus the s-plane?
What I do is I talk to the people about their past work, what sort of problems they hit, what they did about them. You can usually tell if they are bright just by the sorts of things they talk about. See what they think of process. See what kind of things they know about. See if they know anything about stuff that is not in their courses and/or work experience. Not with quizzes, but with conversation.
I've hired a couple of losers, but I've hired a lot more competent people, and some who were just plain awesome (at least from my view).
-- Pete Buechler
I found this a worthy enough read to bookmark it. The author has some good ideas about preparing for an interview and formulating a meaningful evaluation of that individual's skills beyond the basic text-book Q/A dialogue. http://www.joelonsoftware.com/articles/fog00000000 73.html
Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. ~A. Perlis
Having sat on both sides of the table (being at the moment on the interviewee side as I'm looking for a job) here's my two cents worth (and worth every bit of sense you can get out of it too).
I don't trust exam type things - especially with pen and paper and looking at specific skills. Indeed, I personally don't tend to care much about specific skills - the organization may need those today, but what about next year? Things change.
The "here's a puzzle, stand at the board and talk about it" is always a good way to find out what how the person works - but don't just go for the right answer - go for the method and how the person reacts to getting stuck and to hints.
(On one such exam (PHD qualifiers actually) I got stuck completely and spent an uncomfortable amount of time trying to unstick myself - but when the examiner said "how about this" - I saw the answer immediately and said "Ah..." It was the "Ah" that the examiner had been seeking. )
I do always ask about a previous project that they enjoyed, and about one they hated (these can be school type projects). For each I try to find out what was the best part, the hardest problem, the worst part... And I'll usually encourage them to talk about team problems as well.
Finally, in the case that the interviewee is undergoing a number of interviews with people in the organization) I encourage interviewees to just relax and take the time with me to decompress (to the extent that they can) and try to just chat about whatever. This gives me a chance to find out if they can talk and know something besides geekdom - which I think is a nice plus.
But you might want to do just the opposite of my ideas - I've managed to make some quite wonderful mistakes. One of my favorites was very talented, but very inexperienced - he had the bright notion that it would be a good thing to send a 2000+ line program to the compiler writers and insist there was a bug in the compiler because it didn't work.
Hmm, come to think of it, that would be a good question : "Have you ever found a bug in a compiler? - How do you know?"
2. Pick a problem you're currently facing. Ask him about it. Does he sound like he can come up with a solution that will work for you? Does his approach mesh with your group's current style?
I'll probably get crucified for this....
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.
Vote monkeys into Congress. They are cheaper and more trustworthy.
There's nothing like real code to see style, error- and unanticipated-situation-handling, algorithm design, use of object-oriented concepts, design ability.
At my company an engineer comes in for an interview and we do the standard things. We then assign a programming task. If the candidate's interested they won't mind the 4- to 8-hour job.
A typical programming assignment:You'll get a handle on the engineer's intellect. You'll also see how well the engineer will fit in a team. To hire an engineer without asking them to write code is a bad idea.
Do you know who Donald Knuth is?
I want to buy a car. So I start looking at various models and rate them on only two things: speed and acceleration.
And so I spend a lot of money on a car that can accelerate from 0-60 in 3 seconds with a top speed of 225mph.
Did I buy the right car? Will I ever have to drive at 225mph?
We rate programmers solely on intelligence and problem solving skills, and we invariably end up with assholes with big egos and poor work ethics. Give me a less talented, reasonable developer who is willing to stay the long haul any day.
I always give this multiple choice test:
...
...
...
...
1. A good programmer always shows up for work
A. At 8 oclock sharp.
B. 10 minutes befor the boss.
C. In time for lunch.
2. UNIX is
A. A religious cult.
B. An operating system.
C. A virus.
3. A UNIX programming Guru is
A. A leader of the UNIX cult.
B. Someone who can write programs that work with the next rev of the OS.
C. Someone who can write programs so obscure that they don't work with the next rev of the OS.
4. The best text editor is
A. VI.
B. EMACS.
C. cat.
I seem to recall a diddy in my General Psychology class about something like the Fundamental Overattribution error or the like, which states that people (in our case interviewers) are more likely to attribute a quality to the person (the interviewee) than the situation (what the behavioral interview is looking at).
On a personal note, you're right many fortune 500 companies do use the Behavioral approach, as their hiring managers are usually grunts who worked their way up the line from cashier to head cashier to store manager, etc. I remember a really perculiar interview for a local Hastings (which has since closed down). They start things off with a nice SAT style test to gauge your overall intelligence and give you perhaps 10 minutes. I believe this is to keep people from maxxing out the test as there is something like 60 questions on the test. The other thing that stood out was "Tell me about a time you exhibited leadership." At the time I was just out of my freshman year in college and looking for a summer job.
My only previous job was a dead end stint as a movie theater grunt. All forms of independent action are strictly discouraged there. That is to say, they run 30 screens at that place and don't have time for concession grunts to waste on pleasing someone whose credit card isn't working. So any "situation" is dealt with by a manager or supervisor. Instead, leadership there was more of a trend. In odd cases where no supervisor was assigned there was a sort of politics over who wielded the radio, the communication device that whoever in charge would use to request assistance and answer to higher ups from afar. Is grabbing the radio really a situation? Not really. Is habitually grabbing the radio a trend of leadership? Probably. Hell, I would show up early just so nobody questioned my authority or made a power grab before me on the shift change. And for the most part, nobody questioned it. After a while I made the mistake of not playing the management's mind game of asking for a promotion rather than being bestowed one or solicited for it. They started expecting me to carry the torch without the benefits of recognized authority or pay, both of which would have improved my output as an employee. Anyways, back to the other crap job story.
So after considering the previous paragraph (in a much shorter time frame in which much of it was internalized) I concluded that I had not exhibited leadership in a specific situation, and moved on. Did it hurt my chances? Nope. I got the job alongside four other less savory candidates for register jockey, in which I learned the place sucked hardcore. Hastings presumes everyone is a theif. They reward you 10 percent of the loot if you turn in an employee shoplifter (I'd wager you can cut a better deal with the shoplifter himself at 50/50). They also have what I like to call "use prevention" devices on their DVDs. They put them in these cases that require a special piece of plastic to pierce the lock on. Only the damn things are impossible to open when they're not broken, which is easily done. Additionally, their inventory system is outdated and really wierd. Rather than correlate a scan code with a given price, they generate a bunch of price stickers, stick them on the book and have you punch in that number. Which makes it really easy to misprice a book or used cd for 1.99 instead of 19.99. So how do they deal with this? They keep records of all your transactions and run it against a national database of costs. If you sell too many "red line actions" a flag pops up. I'm guessing red line means below cost. So if you get the register right next to the clearance bin...
Well the other question is, did it work for them? I'm guessing no, but maybe the manager who had to pull together a new schedule when I quit after a week of "Training" (another joke) has a different opinion. Maybe she thinks that I was a bad employee because I only balanced my register to a penny. Or that I quit having been offered a job paying more using tools that work.
I Browse at +4 Flamebait
Open Source Sysadmin
Ok. Do you know the latest Java/C/C++ patterns? Yes? Great. Do you know what to do with XYZ algorithms? Fine. I gotta lay down the truth here. I don't give a damn what you know or don't know. I want someone that can make my job easier....i.e. either save my company/client money, or make money for my client/company money with me having to do as little oversight as possible (assuming I'm your manager). Do you take on new tech challenges and responsibilities with enthusiasm? Have you ever worked a menial job and found yourself working towards making things better, bigger, faster with no prodding? Do you count matchsticks which fall on the floor? You are a gear-head, but can you talk to pointy-headed-bosses? Great, you have growth potential, OR no, you can still be a valuable gearhead to me. DO YOU DO YOUR FRIGGIN JOB? Do you go home at 5 even though deadlines have not been met? Do you have a dream, and does it involve perfection of your code? Are you flexible, can you take on new technologies? Are you resilient, can you work on the same old shit for years on end? Do you understand the software development lifecycle and your role in it? Yes? Good, explain it to me. Do you know what testing is? Do you know what version control is? Do you know what UNIX is? No? Well, your're just like the rest of them, can I see your standardized test results? No. I don't care about your certifications.
You sub-contract them.
duh.
I'm partner in a consulting firm and we staff VB/ASP UI and C++ backend programmers. I can reconfirm from my experience that being good at programming trivia and being a good progammer are two very different things.
The only way I've seen to get an accurate feel for a programmer is to give them a chance to write a small program on their own. There are a million toy problems that are perfect for this.
Here are a few:
http://acm.uva.es/problemset/
Give them a choice at least 2 problems and plenty of time to do one. Leave them alone while they work and go get some work done yourself. You know you have plenty to do. If they finish the problem(s) as well as you'd hoped, great. Talk through their solution with them to see if they know what they are talking about and get a feel for how easy they are to work with when it comes to *their* code.
We discovered that if a programmer can get the job done and get along with other people while doing it we want to work with her. We have had good success finding those programmers hiring this way.
I totally agree... After you've been, uh, synergizing all morning, nothing hits the spot like interviewing with some HR clod who doesn't know dick about IT or technology, but thinks they do because THEY'VE HEARD OF APPLESCRIPT.
No. Seriously. Here's funny but true story #1: At one big software company I worked that had a very entrenched corporate culture (no, not Microsoft!), one day my manager introduced me to our new hire. Lets call him 'Paul'. Paul was a programmer doing an MBA at a two-bit suburban university. Paul seemed to think he'd soon be running this company. (Let me tell you now this'd *never* happen) The first thing he did was arrange a departmental meeting every Monday morning; "I'll bring the doughnuts" he said. Everyone was oooh so impressed with the prospect of yet another meeting. He seemed clueless and/or lazy and kept asking questions in the manual. RTFM! we told him. Then Paul actually refused to do programming tasks. After watching one of his lame-o jobs fail for a week (customers were waiting for it), I told him he'd have to come in that evening and make sure it ran. He Told us (including his supervisor) we could do it. Sheeeshhh! We got sick of him by this stage. So Paul called a meeting, didn't show up, and left. I expected he thought this would teach us a lesson, but we just thought this made him even more pathetic. So how did this loser get hired? He was interviewed by two women managers. He was tall and had a loud voice. That was all he needed. But the crowd always figures you out in the end...
Funny story number #2. Lame-o programmer, lets's call him Maurice couldn't code, so he "borrowed" one of my programs and tried to modify it to get it to do what he wanted, but he had no clue of what 98% of the code did. I didn't know about this, until we were at his walkthough with my supervisor and a few others. Imagine my surprise when I recognised the code. My supervisor ripped though the code, asking him why he did this? What did that do? Actually I thought my code was a class act, but my supervisor thought otherwise. Ripped it to shreds. He couldn't answer any questions and I sat there trying really hard not to laugh. He looked like the fool he was. Despite his incompetance, we covered for him. But we later found out he bitched to the managers we weren't supporting him (we wish now we hadn't), and he capped his off by stealing Timothy's Mars Bars. Maurice is still with that company. People don't always get their just desserts. This sap even had the hide to eat someone elses.
I heard this a while back and it's been true in the majority of the technical situations I've been in:
The number of women present is less than or equal to the number of men named David.
- AlanH
I think the key to your question is not XOR, but the loopholes involved in "doesn't require a temp variable". I/O to a file or pipe comes to mind. So does the question, "What is a variable?", which suggests arbitrary memory locations, registers, etc. And also "What is a temp variable?", as opposed to non-temp variables. Even more interesting would be Rube-Goldberg-esque custom hardware involving either explosives or DNA.
It's like the old Bananna Nuclear Reactor solution.
A question to answer a question. What do employers look for? I'm currently going to school now for computer software and applications. I'm half way through school and i was wondering what they look for? I have NO programming experiance other than school, and i have no idea what is expected of a no experiance newbie on the job.. know what i'm sayin? I love programming but i know it takes more than passion to get a job.
I used to try to think of good and interesting questions, but now I just hope they know the basics.
I recently interviewed someone who had 2 Masters in CS and Math, and over 15 years of experience in object oriented programming on their resume, and they had no clue what are inheritance, abstract classes, the "this" pointer/reference(depending on the language), exception handling, static member variables and methods, etc...
The person litterally said "I don't know".
And you will be surprised how many people with supposed experience can't answer basic questions like that.
I have trouble finding people who even have a clue what a linked list is or how to do simple bitwise operations.
This is all very depressing... I don't even know why I even bother even trying to interview people.
Suffice to say, I was offered the job the next day, which I respectfully declined - stupid motherfuckers.
For a typical programmer: 1) its all about computer science basics so ask those type of questions A) programming language concepts - ex. generally how does function calls effect the stack and heap B) basic algorithm and data structure concepts - ex. bubble sort vs quick sort - try and stick to algorithms that are highly common and ask what would be the best kind of data structure to use C) database concepts - ex. Define normalizing D) optionally you could ask about OS concepts - like file discriptors, threading, memory management etc If they ace these type of questions then they can pretty much handle anything that you give them. This basic knowledge is what all programming is based on no matter what language, platform or software you are dealing with. Now usually you want to find someone that is more than just a programmer. someone that can think on their own and be creative. Here you can pretty much ask anything...like do you think Apple should offer Mac OS X on x86? why? Does it make business sense? Would it be politically acceptable with the existing Mac community? or with the Unix community? why? How do you think Microsoft would react? why? Monitor the answers and be objective...its not about the topic but about the creative answers/thinking. Also it doesn't hurt to ask a few business minded questions (ex. We need a basic database to use inside one of our applications and we need to do it cheaply..what's your recommendation?) Personally I'd look to the open src community ;)
And the most important Management 101...never every compare the person to any other person especially you. I don't know how many times I've heard from managers that just hired someone make a comment like she worked at so and so just like me or they have demostrated the same working habits as i do etc...big mistake. the person is not you so don't treat them like they are.
I am an IT mgr at a televison station, and have worked in damn near every dept. there over the last 20 years, including production and engineering. Most folks here really do shoot from the hip in a hairy situation very well, bit there are still few who do simply cannot pull their own weight, but never get released.
We have one (not in my dept.) that helps out a bit in IT when things get hairy, and even though I have showed her how to set up a windoze pc into our domain numerous times, she still has to ask for all the ip address (ip, gateway, wins, etc) and domains, and she has worked there five years now.
Show me something once, and I will remember it forever. Some people just learn how to manipulate the system and do so their whole miserable lives.
Live televison is a perfect example of this. If you can function well in a live tv enviroment when things go to hell, you can pretty much do anything (I would imagine air traffic control would be similier).
Go to college with the guy you are about to interview for four years, and during the interview, you can just bullshit and talk about how that one instructor was a bastard and gave impossible to finish tests, then turn to the other interviewer (typically someone from HR) and say "I know he can do the job. I've seen him work - under pressure and all - and I know he has the skills to do what we need done."
That's what my last interviewer did. Now, if he'd just get the paperwork filed and light a fire under his boss' ass....
*hahahah* - Sorry Mike....
Sorry, we know you answered our questions wonderfully. But Joe Boxer here will work for almost free to feed his family. Later ~
Just curious, what is the correct answer for #20 in this thread here?
"I say we take off, nuke the site from orbit. It's the only way to be sure."
Ask them what they, as programmer, would do to reduce the support costs of
1. deploying some application to a specific user set
2. maintaining and deploying updated versions of said application
If they can come up with thoughtful answers to those questions that consider the "real world situation" ("all clients will need new computers and broadband connections" doesn't really work) then they just might have something.
That's what *really* counts in my experience. You've go to have end user focus, any moron can be taught to cut code.
Also, genuine sympathy for the poor shlubs on the support desk is desirable.
It's simple realy: ask them four questions:
1)Why(Ie Why would you want to treat your.Java files as objects)
2)what(What's their prefered programing language for fun if the answer is C++ don't hire if its ObjC ANSI C Logo or Java 2 do so)
3)How(How do you solve your limitations ie: Do you ask for a another pair of ies do you use logic do you think like an enginere?)
4)Last but not least: how man math,fantasy, and theology books do you read, what do you do for fun what's your favourite game, and have you experienced?
you might also ask them to visualy graph a program if it's not clean simple and elogant then it's a no go.
This is the wrong answer to the question, even though it gives the right answer. Why? Well for one thing, it is "clever", which as any real programmer knows is the sign of something bad. What about 1..11 with one number missing? Oh no, it's broken! Actually, then you just subtract from 66 (for those of you who didn't get inflicted with series in math enough to just recognise this, 55 = 1 + 2 + ... + 9 + 10, and 66 = 55+11 ), but if you have two numbers missing it actually is broken. A general solution is almost always a better solution. If I were asked this during an interview, my response would be "I'm not sure, but I most definitely would not just subtract the sum from 55," knowing that is probably the answer they are looking for, and then explain why. Then I would state that I don't believe that trivial little mathematical puzzles are a very good way to try to select a computer scientist, or even a mathematician for that matter.
Best Slashdot comment ever
But first tell them there'll be only one of them still working after three weeks.
If the Questions in you're example are real (i can hardly believe that), you should stop asking them. I'd never want to work for somebody, who thinks they'll find goog programmers by asking stupid questions. And yes, i am a good programmer.
The problem with hiring a good programmer is you don't know how good they are until they've been working for you for around six months. Then the real problems come in when they act like they're working but don't put anything out. No amount of interviewing is going to help you there - you should contract these people for one month at a time with the understanding that you will renew the contract if they perform well. If their performance starts to really slack off after a few months, then you know they're burnouts. You'll also know if you want them around after any other problems. Motivation is the key factor in development. I can name off many many programmers who know a lot but don't like to work. Looking for a college degree doesn't help either. If someone can program insanely well without anyone showing them how, would you think they were better or worse programmers than someone who had college professors show them how to do everything? Hiring only college grads will give you a lot of programmers who can't think and learn on their own, and are not willing to try new things. And think for a while about the technical questions you are going to ask. I have heard some VERY stupid questions lately in interviews, and those programmers will resent your stupidity the entire time they work at your company.
Who moved my sig?
Programming involves a lot of things, but ultimately it requires writing. If the programmer can't write well in a language they've used all their life, what does that say? Do they ignore punctuation, grammar, and spelling? What does it mean if they can't be bothered with details?
Even better would be to have them write a poem in iambic pentameter, explaining to them what that is if necessary. Languages already impose a certain discipline, but how does the programmer react to extra disciplines? Does she only want to write in free verse? Ever tried to read an undisciplined programmer's spaghetti code?
To be fair, this works against those whose native language isn't English, but that's the language I communicate in. For such people, a similar test might be to give them a syntax diagram of a computer language they don't know and ask them to write something in it.
These days, dragging a control onto a form and hooking up the events is considered programming. Re-usable objects are Good Things, but it feels more and more like connect-the-dots rather than programming. I'm more interested in the person who wrote the control than in the person who can drag it around.
The other test I give programmers is to have them copy a sheet of paper with sixteen rows of random sixteen-bit binary numbers. At least you find out the ones who pay attention to detail and check their work, both of which are important for programmers.
Which is more important? -- that is the question.
Look. Your list of questions can be a mile long, if you don't know how to ask them, you loose. Too many interviewers in my experience have their own baggage or are prima-donnas who want clones or just plain d-o-n-t l-i-s-t-e-n. If the candidate is a close fit, expect to do some training - remember training, it used to be really popular. If the candidate is covering up weaknesses wilfully and they have the knack of evading and/or sounding plausible then again, no amount of questioning is going to help. Set them a test, either on paper or writing live code (using the target environment), ideally in a closed room. Give everyone the same amount of time, always add five minutes and sit behind em to add a bit of pressure, have a standard markings scheme and use it. When they are alone in the test keep an eye out, if they reach for the mobile throw them straight out the door and call in the person they called for interview instead. In short, forget about standard questions.
First Post
I've found the best way to interview people is to actually get them in and work on a problem amongs their potential co-workers. I personally don't interview very well when it comes to answer questions; don't get me wrong, I know my stuff, it's just I have a tendancy to work myself into a stew (just like I did before I took any exams). I was really surprised when I went for an interview at a company when they turned round and asked me to come back and spend a day with their development team, working on a problem that was related to their product. It gave me the chance to actually sit at a machine, code, talk to the team, and generally show what I could really do.
If you want to know if someone will fit into a team then the only real way is to put them in the team for a while. It worked so well for me that I took it to the next company I worked for.
Obviously you still have to have that first interview where you do ask some technical questions, but make the questions those that will identify someone that knows nothing about something they've put on their CV so you can cut the dead wood quickly.
Have you published any open / free software and if so what's the URL?
If he answers yes you can go and look exactly what this guy knows and does he plays well with other.
Gilad.
First, the riddle we ask the guy is based on something implemented in our product, true, but it is a design question. The system is something standard, with a twist that allows better optimization.
I'm looking for whether the guy can give the basic answer off the top of his head, and how he is handling the twist. An important factor is whether they will accept help. If the guy will make 95% of the way on his own in ten seconds, but then half and hout later still won't let me hint him the remaining 5%, that's a problem.
We're also picking a random project the person participated in, and pick that project apart. Ask about the most intimate details in the project. At that stage you are looking for whether the guy knew what he was doing, or whether he was just tagging along. If the guy was a crucial part of the project, he will have answers for you.
quicker than sum subtract and works with big numbers. Up to around 4 billion on 32 bit machine instead of around 32k with the sum solution.
// magic 1-10 starting value.
:)
uint findmissing(uint *numbers)
{
uint answer = 11
for i=0 to 8
answer ^= numbers[i]
return(answer)
}
okay mark this as redundant or the other. Didn't know which thread was better
Background - I needed to hire 10 solid capable C++ developers for a new product development. I'm gaves candidates a (C++) language test, but not a "sit in a room and do it" test, but a "we'll work thru this together and see where it takes us". I want to cover some solid items, but I'm mostly looking for the ability to empathise, and for a way to provoke conversation about what they've done.
So my test is more along the lines of a few simple items like "Read this real production code and tell me what it's doing. Do you spot any errors in it?" Then I use these questions to seed the conversation: "How would you write this code differently? Do you understand the problem this is addressing? Does the code fix the problem or not?" I also get an idea of how they read code (hint: given a strange function the good ones ask for scrap paper and walk through the operations by hand almost immediately).
I really dislike the "put these 4 operators in order of precedence" tests--in fact I want people that say "It's a bad thing to memorise these details, because the person reading the code may not know them, so I always use explicit braces anyway." - but then, that's how I answer the question in an interview....
I also throw a few syntax errors, style errors, off-by-one errors, resource leak errors, etc. into the code to see how much eye they have for detail, allowing of course for the pressure of an interview. Some things should be in-grained in C/C++ developers, even in an interview. If they mention the typo in the comments...well, it's more about HOW they comment: is it patronising, informative, a throw-away line ("I'll gloss over the typo here.")? If they don't mention it they may be just polite, but by the time you have a dozen of these openings in 10 lines of code it gives at least one chance for a conversation to start, and it gives me an idea of how they operate....
Similarly for testing Awareness I give them a list of names of people and technologies and ask them what these mean to them. We can then use that to chat further: "So, you've read Mythical Man-Month, tell me what you think of it?", "How much of slashdot do you read then?", "If I was new to OO, how would you describe polymorphism to me in a single sentence?", "What kind of books DO you read then ?".
None of these are "trick questions", and I tell them that it's not a "you scored 7 / 10" test (I also tell them that I know all the answers because I wrote the test, not because I'm smarter than them), but I find this method useful for helping me be consistent between interviews, for giving a clear plan and structure (and control) of an interview to both sides, and for seeing HOW they address the question even if the ANSWER eludes them, and that's what I REALLY want to know: "How do you react when you don't know the answer (yet)....?"
It ends with discussuion items including "This interview process sucks/works/is-skewed" where we chat for 5 minutes about how they interview, what the problems of hiring people/accepting a job are etc.
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
Seriously, a BSOD generally does mean something just in the same way as a Kernel panic and a console dump from VMS. It can sometimes point to a particular component that is having problems. I have done a bit of systems programming in my life time so I have triggered more than my fair share of these things!!!!!!
It was on a computer, and it asked multiple-choice questions, with a score assigned to each answer, so stupid mistakes lost a lot of points, and different "correct" answers were worth different points. If you do well in a category, it starts asking more difficult questions, so the test is always challenging no matter how good you are. I scored very highly, so I consider it an accurate measure ;-)
While I agree entirely with the above, I think factual questions do have genuine merit as well. If someone is an experienced user of Tool X, they will know the basics of Tool X off the top of their head. The more familiar they are with it, the more depth of knowledge they'll have available immediately. Whether or not they're a natural "memoriser", this will be true to a significant degree for everyone.
You can gauge a lot about a person's experience from that depth of knowledge. If they have to look up some obscure CSS property to get the effect they're looking for, sure, go find a good book or your favourite web site. OTOH, if they don't know the nesting of <HTML>, <HEAD> and <BODY> tags but they're claiming to be a web design expert, they've probably used too much Frontpage without ever learning what it does. That may or may not be a problem depending on why you're hiring them, of course, but it's certainly a legitimate thing to want to know.
And of course, at the end of the day, if someone can show you a deep knowledge of their subject in interview, you know they know their stuff. If they appear to know where to look and they are efficient at finding what they need, that's great, but it could be hiding a lack of understanding that you won't find out until it's too late. You could take a competent programmer and give him a new language to program in, and after a few weeks, maybe he'll be up to speed because he's good at doing his homework. OTOH, if you hired a guy who already knew the language inside out, he'd be more productive from day one.
For these reasons, my suggestion (not that anyone ever lets me interview these days...) would be to sit the candidate down in front of a PC, with all the facilities they'd have available doing the job (help, web sites, books, whatever), give them a reasonable task to do, and ask them to talk you through what they're doing and what they're thinking about. That will make clear what their depth of knowledge is, at least in this particular area, and it will also find out if they know when they don't know enough, and they know where to look to fix that.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It makes you a slow programmer who doesn't know his subject, and who will have to spend 95% of his time reading books rather than coding.
I don't have a problem with needing to look up details when it's appropriate, but it's a matter of scale. A professional programmer who can't write a swap function is a contradiction in terms.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Do you play Counter Strike? :
Just like PGP (or should I say GPG?).
Hire people on recommendation. Trust only the recommendations of people you've worked with before and whose judgement you trust.
Oh. And if you hire someone who turns out to be a dud....eject them.
Is he like that because he got promoted to management, or did he get promoted because he is like that?
Live today. Tomorrow will cost a lot more!
Undoubtedly, this will be lost in the noise, but I'll feel better if I say it.
Actually read the prospect's resume. If your selection is based on running it through a buzz-word filter, all you'll get is someone who knows how to get through a buzz-word filter (I dunno, maybe that's what you want....).
I also started by thinking about an array or tree based approach, but there's a much simpler algorithm: add all the numbers and subtract from 55. 55 is the sum of the numbers from 1 to 10, so the difference will give you the missing one. This also easily scales to larger ranges, though of course it doesn't scale as well to more than one missing number.
-Playing JS Bach "The well tempered klavier". All the Preludes and fuges. Both volumes. In a real piano. OK.
-Local chess genius. OK.
-Crosswords. reluctantly OK.
-Left handed. NooooooooooooooooooooooooOO!!!!!!
I have missed the 3ll33t test to detect good programmers.
IANAL but write like a drunk one.
So you appreciate loosers that after coding all day go home and continue coding.
Charming.
IANAL but write like a drunk one.
I agree completely.
I haven't had a true tech job yet, and was kicked out of college so I don't have a degree. What do I have? I do have a cert, but I don't think it was hard to get. I learned SQL within a couple of weeks, visual basic in a day, and I already had the design skills, so a MCSD was pretty easy to accomplish. If I had a degree I'd probably have a job doing development, instead of looking at going back to a factory job or something similar while I work on getting up enough money to go to school again.
"Tax preparation software eliminates errors your[SIC] may make...." From IRS home page.
---> First, if the original question came from an employer, perhaps consider whether you are a decent place to work.
* Some places are already decent places to work and being able to see whether a programmer has the flexibility to fit into this framework would be the main thing. The clever questions are baloney, as mentioned by the zillion previous posters.
* Some places might be decent places to work if they could drop the seeing the trees for the forrest routine.
* Some place will always be loosey. And if you're just as bad as your interviewing questions, then you deserve all the misery and the pain of getting the employees you deserve, getting the bad designs, the irrationality, the panic and the constant you deserve.
Actually, he's a SHE.
And she's worked for the NSA and is a PhD doing research. Don't talk to her about production environments...
But yes, I do understand your comment on clear code and concise comments! And I quite agree. Which is usually why I like having someone who doesn't know my programming language very well at my design inspection. If they can't "get it" from my comments, then my comments SUCK.
In the future, I would want to not be isolated from my friends in the Space Station.
"He" is the neuter in English.
Good comments are a poor substitute for clear code.
-Peter
I got so tired of interiewing people I finally decided to cut to the chase - in each interview I started asking what their favorite Miles Davis album was. I didn't hold it against them if they couldn't name one, but ff they could name one, they improved their chances. No one ever said "In a Silent Way", but if they had, they would have been hired on the spot.
When you're interviewing kids out of school, there's not much to go on besides their project work. Grades are misleading, sample code has often been reviewed by others. They have all the raw materials they need from school, but school can't provide them with the knack for figuring out how to structure thier logic, which is essential for programming. Here's a little game I've found that really brings out the winners. If they solve it in an hour, good. 40 minutes, great, 20 minutes, wow!, anything less, they've seen it already. I've had several candidates not be able to solve it, but I was already suspicious of them. Give them paper, and examine how they went about solving the problem.
Here are the rules:
There are 5 different houses in 5 different colors.
Each house is owned by a different person with a different nationality.
Each person drinks a certain beverage, smokes a certain cigarette, and
keeps
a certain pet.
No owners have the same pet, same cigarette, or same beverage.
The question you are trying to answer is:
Who owns the fish?
Here are the hints. You need these to answer the question:
1. The Brit lives in a red house.
2. The Swede keeps a dog.
3. The Dane drinks tea.
4. The green house is on the left of the white house.
5. The green house's owner drinks coffee.
6. The person who smokes Pall Mall rears birds.
7. The owner of the yellow house smokes Dunhill.
8. The person living in the center house drinks milk.
9. The Norwegian lives in the first house.
10. The person who smokes Blends lives next to the person who keeps cats.
11. The person who keeps horses lives next to the person who smokes
Dunhill.
12. The person who smokes Blue Master drinks beer.
13. The German smokes Prince.
14. The Norwegian lives next to the blue house.
15. The person who smokes Blends has a neighbor who drinks water.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Or they actually respect the trade secrets of their past employers. If someone turns up for an interview with a copy of his past project's source code, he's probably ignoring part of his old contract for personal benefit, and that says far more about him than anything in the code will.
There are many more exceptions than that. OO and procedural are hardly the only two programming paradigms around, for a start; there are plenty of other, radically different approaches. Someone who's got experience of similar tools and techniques to the ones they'll be using is certainly a potential candidate, but someone who's never done anything at all similar is a different matter. Then again, someone who's picked up three or four different paradigms already will probably pick up a whole new paradigm pretty quickly, too. It's all down to the level of generality they operate and think at.
References are an interesting issue. While they can confirm job history -- probably a good plan -- they are of questionable value beyond that. I volunteered to provide references to my current employer when I was interviewed a few months back, and they said "thanks, but no thanks". They explained that they could gauge someone reasonably well in an interview, they'd soon find out if someone grossly misrepresented themselves on their CV (which would be grounds for immediate dismissal) and you're bound to get a good reference whether you're the best programmer ever or whether the old lot can't wait to get rid of you, so basically it doesn't tell them anything useful. You can see their point...
I do agree with the rest of your comments, though, particularly getting them to review something in your own style and comment, and looking to see whether they get passionate about their work.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
An interview for a programmer should be a programming assignment... Short but sweet. Give them at least an hour and see what they come up with. Otherwise, you're looking for a good computer science student, NOT someone who(m)? can get the job done.
This is a good question for the current job market:
Are you willing to take less pay than the other 250 candidates we have for this job?
The flaw: your argument is a sweeping generalization. Utilizing the CLASSIC technique of coming up with an exception I have debunked your statement.
That is you lesson for today. Good day, young grasshopper. Come back when you've shaved, son.
In the future, I would want to not be isolated from my friends in the Space Station.
You haven't dubunked anything. You illustrated that in a sufficiently contrived circumstance unreadable code may be a necessary evil. I don't deny this.
.
The flaw: you set up a false dichotomy. It can be both a poor substitute and a necessary evil. I certainly never said anything negative about good comments . .
As far as the age thing goes, I'm 27, and wore a full beard until about five months ago. I've been around the block once or twice, and you haven't shown me shit.
You're a professional student, I take it?
-Peter
The most amazing interview I had was given a task to do... This is an example of the kind of project we work on you have an account and 3 hours to code a solution to this, you can work with your potential collegues and have full access to the online help, manuals etc..
Talk crap to your collegues and relax, pretent it is a normal day at work...
But seriously, I've been at this since 1988 and I can't wait to get out of this industry! It blows.
I think it can only be both in cases where there is an alternative (the all possible worlds case). However given performance criteria, schedules, and the need to build to spec there frequently is no alternative. And a functional yet difficult to understand segment of code is the only option (necessary evil) and there is no substitute. As such, your only hope for future maintainance is commentary. Or a miracle. whichever comes first.
So maybe we are just arguing symantics (wouldn't be the first time!) but I think that "necessary evil" and "poor substitute" are mutually exclusive .
re: shaving- what a great guess! I had assumed you had/have some facial hair. Glad to hear you've shaved! (just a personal thing. I find beards difficult to care for and after I shave them off I am amazed how much better I look without one).
re: ageist: I think I'm 6 months your junior.
re: professional student: Nah, I'm getting a drive through masters while I work on communication networks for air traffic management.
Work pays for it, so hey, free sheep skin!
So when you fly in US or UK air space, think of me.
In the future, I would want to not be isolated from my friends in the Space Station.
I counted 4 different kinds of associations. The construction seems to be: Subdivide the Houses into enough same house pairings so that no two houses can be isometric. Then introduce enough singletons and oriented adjacent house pairings to force the houses to line up in a row. Finally, include all but one of the remaining attributes in non-oriented adjacent house pairings. The resulting description will uniquely define your attributes in houses that sit in an oriented row, and you can ask for the location of the single remaining attribute [in this case, "fish"].
Once you figure out the algorithm, the idea of being asked a question like this by some Human-Resources dweeb is really infuriating.