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.
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
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
- 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
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
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.
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.
You have no idea how stupid i feel having not been able to think of that on my own.
"Upon attaching the waterblock to my penis, I began to notice that I know nothing about computers." -- JRockway
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.
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.
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)'
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?
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
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!
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.
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.
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
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.
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.
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
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
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
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 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.
Bringing in code you've written for your present employer is unethical, because you have no permission to show it to anyone else.
:p
I showed them code I wrote in my spare time. They didn't request a full working program either - I can't remember if they even requested it or if I just offered, actually
Robots are everywhere, and they eat old people's medicine for fuel.
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
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
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
E.g. 1, 3, 7, 9, 8, 5, 4, 10, 6 becomes 137985410. The missing digit (in the range 0-9) is 6, therefore 6 is the missing no.
Still, it's not exactly efficient.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
- 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.
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.
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.
I agree with some of these points (particularly because I perform horribly in these "interview quizzes.") I've worked at a few places where candidates seemed to be shoo-ins based on the interviews, but couldn't handle the actual job of solving a problem and writing code (esp. modular code that was part of a large project). The other failing I've seen is the programmer who gave a great interview and wrote good code, but blew it on more basic employment skills, like showing up on time and being able to follow plans.
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"
ABSOLUTELY!!!!!
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.
If what you state is true, then I hate to say the following; if your résumé reads anything like this post, I can point out a good reason why you might have been passed up for employment. This is friendly advice: Try brushing up on your spelling and grammar before moving to New Zealand.
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.
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.
I agree. It definitely depends on what level of programmer you are looking to hire. I was assuming he was talking about a higher level developer, someone with some experience. A junior level person is just basically a code jockey and doesn't really need to worry about how something is designed, they just write code.
Personally, I believe that all good developers are designers by nature. They want to understand how things work together and how best to make things work together.
I think the whole dot bomb thing really killed the programmer profession. People who should never have been writting code were given titles like Programmer, Senior Programmer, Engineer, and Senior Engineer. Now these people are out there trying to get jobs as programmers and don't have a clue what they are doing, and it's making harder for the real programmers.
I would never hire a "compedent" programmer.
Perhaps I would hire a competent one, however.
[FromTheMorning]
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
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.
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!
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"
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 -
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.
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.
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
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
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.
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."
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.
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.
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.
BTW any Goto's... send 'em back to microsoft!
In general goto's are a bad thing.
BUT, there are situations where only a goto will work, without going through a lot of gyrations with loop constructs.
Mind you, in the past 10 years or so I have only had to use a goto twice...
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
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.
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
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.
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.
erm, 2 was your missing number not 6.
I'm a low level guy, so take each of the numbers take 1 and shift it up by the the value, OR it into your storage register, do the same for all numbers, invert the resulting register mask off unused bits, then shift back the number until it's equal to 1 incrementing another register each time, the result in that register is the missing number.
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.
... 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?
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.
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.
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!
2 . Scan through the list of numbers and stick them in their respective slot.
3 . Scan through the array and return the element index that is empty (or invalid value, as the case may be)
This is simple, straight-forward, easy to debug and only O(n). Why complicate things beyond necessity? With n unsorted elements, you are going to anyway arrive at an O(n) algorithm (atleast).
Programmers don't write code to fix problems frozen in time. The requirements keep changing and the code must be easily readable and maintainable! These are more desirable features in programmers.
In real life, in 3 months, the problem statement could be changed as - "atleast 2 elements may be missing and you have to return the highest, unless the lower missing number is 3, in which case you need to return 7".
Will the complex algorithms proposed handle this change gracefully?
All your favorite sites in one place!
It is a disturbing assumption, but all too honestly, a true one. I worked three computer jobs before quitting the business, and I remember _one_ woman programmer out of dozens, and no gay male programmers other than myself. _One_ of my computer science professors at San Diego State University was a woman. And according to a couple of articles I found after a quick search, the percentage of women earning baccalaureate degrees in computer science is _dropping_ (at least it was a couple of years ago.)
I wonder what the mean age of a software engineer is. For me, "software engineer" conjures up an image of a slovenly man in his twenties who hasn't lived in one place for more than a year at a stretch--but that's certainly not a true picture.
hyacinthus.
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).
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.
I always get those six mixed up! Er...wait.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
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.
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
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.
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?
Well.. considering I was doing about three or four other things and just trying to make a point and light-heartedly discuss, not pointedly focus my attention on the problem itself, no I did not check it. (I realize you were kidding, but a couple other posts were a little more offensive)
Jeremy
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.
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.
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
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 think the implicit assumption that the candidate would be a heterosexual male is even more disturbing. *)
It *never* stated the gender of the sample programmer. YOU assumed that and berated us because of YOUR assumption. Women may like other women and also football.
IOW, you look like a hypocrite.
Table-ized A.I.
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....
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."
Asking candidates to bring code they have writte for another employer is unethical, instead we ask them to bring code from a recent small project done outside of work. This is a great way of weeding out the ones who have not written any code except for work. These are generally the same who didn't write anything except that demanded by compulsory excercises as students.
Who would want to hire a mechanic who never fiddled with his own car? Or a carpenter who never used a hammer except at work?
"There is no substitute for thinking" - Bjarne Stroustrup
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.
There actually are different kinds of certifications than the Microsoft ones. Lotus, for example, certifies system admins and programmers differently, and you get either a CLP (Certified Lotus Professional) Developer, or a CLP Administrator certificate (or both). The exams to pass are completely different for each certification.
Donate free food to the hungry at The Hunger site.
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.
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.
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.
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
Depends on the application and size of n. If your n is very large, O(n) might not be good enough.
I guess I just like performance (and bit twiddling) and that is what I tried to acheive with my solution.
Also, adding comments in your code esp. about the limits of your function/algorithm helps with readablity problems. I would encourage applicants to add comments if they are being interviewed.
Steve
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
Your solution is more flexible, but your O(n) solution is killing O(n) memory at the same time.
Sorry, I'm bored. Can someone set my karma to bored?
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? :
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!
Don't feel bad. I've made a few "You're wrong...No wait!" posts myself. It just means you enjoy discussing algorithms. :-)
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.
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.
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
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.