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.
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.
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
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
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."
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
I have to agree whole heartedly. One of the nice things about programmers is that you don't have to guess whether they are good or not. You can look at their code or ask them to interpret some that your team has already created and critic it to see if they code in similar ways etc. Since it sounds like you are employeeing multiple programmers. Have one of them sit in with the guy and talk shop, work on functions, etc. If your guys are good programmers, they should have a pretty good BS detector. Artists have portfolios, why shouldn't programmers (PDA's aside).
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?"
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.
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.
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.
seek honesty not perfection.
Ask questions of humility. That should be a good indication. Honest people will have no trouble telling you of their past mistakes and faults as well as their strengths and abilities.
If someone only tells you all the good they've done [e.g. positive outcomes] then they are either a miracle or holding things back.
Tom
Someday, I'll have a real sig.
I've been on both sides of the interview table, and from what I can tell, most interviewers fall into the same trap: focusing too much on detailed technical questions. In reality, your programmers are going to be involved in much more than writing eloquent solutions to programming problems. Your programmers will most likely be involved in project management, project design, project implementation, project testing, and project deployment. Be sure not to get wrapped up in asking too many questions like "how many bytes in a java int?" Instead, look for good all around problem solvers. Ask about their design experience and what tools or resources they have used in designing previous projects. Ask how they would handle testing when a project has been under-quoted. These are questions that good problem solvers will be able to answer quickly, and those who "studied" for an interview will not. It will give you a much better idea of how your potential employee would work out in your business. Be sure that your interviewee will not only be a good programmer now, but also in the future when your development tools change.
Another useful tool for an employee interview is to have a break for lunch with a group of your staff. This will give you and your staff a chance to meet the interviewee in a less structured environment. Many times, an interviewee will relax a bit during your lunch, and you get a much better idea of the person's attitude. Someone who answers technical questions very well may turn out to be a social dunce. Or you may find that the person doesn't share the goals of your company. It will also give your staff a chance to find out if they fit in with the group.
If you don't feel satisfied without asking some technical questions, be sure to ask questions which apply to your framework, and not necessarily the programming language you use to implement that framework. For instance, if you design using Object Oriented principles, ask about "has a" and "is a" relationships. The idea is to ask questions that are still relevant if you change languages from C++ to Java or to some other language.
Using some of these ideas, my company has been able to easily pick the good candidates from the poor ones. YMMV: good luck!
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.
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!
Do you realize you're an at-will employee and can be fired at any moment if we don't like you?
[humor]
It is obvious that anyone with hiring expertise, such as human resource specialists, can most effectively hire potential candidates by insuring that they have MCSE (Microsoft) or Red Hat (Linux) certifications.
This removes the requirement for the interviewer to ask intelligent questions, and for the interviewee to provide intelligent answers, streamlining the entire interview process completely.
After all, how else is an interviewer going to be able to BS a potential candidate into believing they know what they are asking about, and how else is a potential candidate going to BS an interviewer that they know what they are talking about?
As Microsoft and Apple have been pushing for on the desktop for years now, it is time we removed the expertise and knowledge from the entire process altogether, thereby "enabling" and "facilitating" the hiring process.
[/humor]
The Future of Human Evolution: Autonomy
I 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.
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!
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.
It isn't hard to do. The question just is meant to see what kind of thought process one would go through.
ie. "Well, you could sort the list, then scan it with a simple loop... But that may not be the fastest executing method (although it is straightforward, and may be the fastest to implement if you already have a sort). Perhaps you could use bins to keep track, and a couple loops. It's O(N), but may require writing more code. Still, it is a straightforward problem; what if you had a larger list with many missing numbers? Solving the sparse problem could be quite different from solving the dense problem..."
Something like that. You just want to hear how they think and reason (or weed out the chaff).
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
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
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
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.
No, it is not silly. It is a simple question where there are multiple solutions, some of which are more elegant than others. The ability of a person to find the elegant solution for an easy problem speaks volumes about how their brain works.
My first response to this question would be a process of elimination where you use some sort of binary decision tree (or a case statement in java) to eliminate the other possibilities. This is non-elegant and downright ugly. Too many ASM instructions. Hard to implement on embedded systems.
Now a few minutes later I believe I have found a more elegant solution:
Missing number = 55 - sumof(9 numbers)
Assuming the 9 numbers are in an array or linked list, a simple loop or recursive function traverses it, adds the numbers, and then one lines subtracts the sum from 55 to get the answer. I think that that is more elegant.
Can any *real* programmers come up with a better (more elegant, faster) answer?
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.
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.
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.
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?
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.
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.
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.
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 ...
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.
We just turned down an applicant, partly due to poor spelling on her resume. This was a scientific position which requires careful attention to detail. If she couldn't be bothered to run a spellcheck on her resume, why should we assume that she wouldn't take the same attitude to her work with us?
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".
I hate brainteaser questions during an interview.
Wanting to know what my thoought processes are is one thing, but more often than not you're going to expect an answer - and if the candidate takes too long or doesn't get it, what then? Reject them?
One of the worst interviews I had was at Microsoft. 8 straight hours of nothing but linked-list code fragments and MENSA questions.
At the end of the day, I still had no idea what position(s) I had interviewed for, and couldn't tell what any of the folks I talked to actually did. Sort of makes answering "So, would you like to work here?" sort of tough, unless all you want to do is solve brainteasers while your peers look on and say "Come on, you're going too slow."
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.
6) How do you debug a program and come up with a solution that will work? It may seem easy at first, oh I use a debugger or I use print statements. That is all fine in a situation where you can use a debugger or print, but what about black box debugging? What about gl accounting bugs? Or bugs that are formula driven, where you know the formula is correct but one of the inputs is getting messed up.
additionally you couls ask
7) Can they 'read' code?
Anyone can learn syntax, and style and how to read a book, but not everyone knows how to debug "other peoples" code. Also not everyone has worked on a large application where what may seem like a small change may actually have major reprecussions.
Only 'flamers' flame!
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"
a few minutes though - since no one else has done it - gives
S = N/2 * (2a + D*(N-1))
where a is the first term, b is the last term, D is the difference, and N is given by
(b-a)/D + 1
I also like to ask problem solving questions, which can be design questions, find the bug in the code questions, describe a problem and ask you they would debug questions, etc.
It's not likely that I'll get one, because the company is really not that big (12 employees thus far), and I'm the only developer/programmer, but I would REALLY like a co-worker. I wouldn't settle for a simple "answer this questionaire" type interview though, if I had to hire some one.
...
In my job, 85% of the time is spent inventing new stuff, so just because you can fix bugs in 200 OSS projects, doesn't mean you can fill this position.
I want some one who can listen to an idea and have his brain run amok in synaptic explosions, because even though 99% of those explosions are going to be misfires, some of them are going to pay off.
I want someone who handles a new idea like Microsoft and embraces it (but not quelch it), and not reject it like a foreign object in the bloodstream.
I want someone who's creative; who'll look at an idea and throw it around, complement it and give it a fair chance, instead of thinking "well, we can just patch this and this in yonder program", because sometimes you have to throw out what you have and just use your experiences from earlier.
I'm tempted to pimp an idea of mine (not work related), to give you an idea of what I mean by "creative" and "inventive", but this is not the forum
Anyway, not all companies wants someone who can code the pants of anyone - sometimes they want one who's creative and open minded. I know that's what my current employer told me (and still tells me) was the reason they hired me.
We do not live in the 21st century. We live in the 20 second century.
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.
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?")
The problem with questions like that is that you come across looking stupid to someone who does know their stuff. (You can use the keyword synchronized on a static method.) You might lose your best candidates right there -- not because they can't answer the question, but because they won't want to work for a bozo.
I had a co-worker who liked to ask a really obscure technical question (typically something about determining the convex hull bounding a set of points in 3-space), not to see if they knew the answer, but to see how they reacted to the question. If you tried to bullshit your way through it, you were out. An honest "I don't have any idea, but here's how I'd research it" type answer was about as good as actually knowing what he was talking about (the question had nothing to do with the kind of work) and giving a technically correct answer.
-- Alastair
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.
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?
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
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.
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.
Well, technically, two:
1) "Are you Das Megabyte?"
and
2) "How much do you want?"
Hey freaks: now you're ju
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)
Erm, what does a "Gaussian summation formula" really have to do with anything? Given a known set of distinct numbers, determining which one was missing would *always* be a simple case of subtracting the sum of the provided numbers from the sum of the full set.
Unless both I and the grandparent to this post are really missing something obvious, this is a real non-question, and I can only be surprised by the poster who suggested that this was some kind of difficult mathematic solution...
Depending on the environment, though, it *might* prove more efficient to actually loop through the entire set, checking whether the number actually existed in the subset..
you would expect them to work offline?!?! come on. just give them everything they would have in a normal working environment. do you really want to not hire someone because they forgot to add one little thing? because they didn't have access to the documentation for whatever tools they are using? I am of course saying this all because I'm one of those people who doesn't memorize. I just remember the best places to look when I need a reference for any of the number of languages I've done work with.
also, 90% of work is on the job training... do you expect people to be a perfect match walking in the door? wouldn't you rather have someone intelligent, adaptable and dependable, than someone who really really knows css and frontpage?
I ate my sig.
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."
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...
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.
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.
Good question. Now how much effort do you think it would require to achieve mastery in a particular instrument(hint: a lot)
The same can be said of any discipline, programming included.
No, Thursday's out. How about never - is never good for you?
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!
contract to hire.
The Kruger Dunning explains most post on
Hey, thanks for saving me the trouble of figuring it out again! I was a little confused at first, because I misread your definition of N as (b-a)/(D+1); guess I need to check up on that "reading comprehension" thing I hear so much about.
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)
... 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?
The question isn't phrased very well. A serial-line BREAK signal isn't a "character" -- it's sent by switching from mark to space level for longer than a character's length. By asking for the break "character" you are implying that you do in fact want an ASCII value. Seems to me that almost any value could be justified on some system or another -- certainly 0x03, 0x00, 0x19, 0x1A, 0x1B and so on come to mind.
Of course maybe that's the point -- the variety of values you get might give you an idea of the platforms your candidate has used before...
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.
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
Exactly.
At my current job, I've developed a reputation as guru with Microsoft Excel. I don't have encyclopedic knowledge of everything in Excel. Most times when someone has a problem and asks me to help, I don't know the answer.
BUT I've used Excel enough to know how things are laid out and I'm able to find the answer within a minute or two. It's the same with a lot of problems.
The funny thing is that my job is to write queries in SQL and support a Domino database... but the bulk of the acclaim I get in my job is related to what I've done in Excel.
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 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.
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.
On Multics machines, it's the @-character. (0100 octal)
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
Check there spelling.
This Sig has been depreciated.
The correct answer is:
number = 0x3ff
for i = 0 to 9:
number &= ~(1 (num[i] - 1))
return log2(number)+1
I found this a worthy enough read to bookmark it. The author has some good ideas about preparing for an interview and formulating a meaningful evaluation of that individual's skills beyond the basic text-book Q/A dialogue. http://www.joelonsoftware.com/articles/fog00000000 73.html
Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. ~A. Perlis
Having sat on both sides of the table (being at the moment on the interviewee side as I'm looking for a job) here's my two cents worth (and worth every bit of sense you can get out of it too).
I don't trust exam type things - especially with pen and paper and looking at specific skills. Indeed, I personally don't tend to care much about specific skills - the organization may need those today, but what about next year? Things change.
The "here's a puzzle, stand at the board and talk about it" is always a good way to find out what how the person works - but don't just go for the right answer - go for the method and how the person reacts to getting stuck and to hints.
(On one such exam (PHD qualifiers actually) I got stuck completely and spent an uncomfortable amount of time trying to unstick myself - but when the examiner said "how about this" - I saw the answer immediately and said "Ah..." It was the "Ah" that the examiner had been seeking. )
I do always ask about a previous project that they enjoyed, and about one they hated (these can be school type projects). For each I try to find out what was the best part, the hardest problem, the worst part... And I'll usually encourage them to talk about team problems as well.
Finally, in the case that the interviewee is undergoing a number of interviews with people in the organization) I encourage interviewees to just relax and take the time with me to decompress (to the extent that they can) and try to just chat about whatever. This gives me a chance to find out if they can talk and know something besides geekdom - which I think is a nice plus.
But you might want to do just the opposite of my ideas - I've managed to make some quite wonderful mistakes. One of my favorites was very talented, but very inexperienced - he had the bright notion that it would be a good thing to send a 2000+ line program to the compiler writers and insist there was a bug in the compiler because it didn't work.
Hmm, come to think of it, that would be a good question : "Have you ever found a bug in a compiler? - How do you know?"
2. Pick a problem you're currently facing. Ask him about it. Does he sound like he can come up with a solution that will work for you? Does his approach mesh with your group's current style?
I'll probably get crucified for this....
If you have to include a "technical interview", not to mention 2 of those, then your company is shit. If your hiring manager can't get by with interviewing the guy/gal with some of his/her folks doing an informal interview (that do have some probing tech questions), then your entire structure is fucked.
A bit ago I went through a tough time at my company, so I started out interviewing. I got 3 tech interviews that asked me questions like "what is the command to increase the frame relay delay timing", "what is the public number for public MIBs", and what are the arguments to display only workstations in a Tivoli system?"
Give me 2 minutes with my books, I would have no problem. Expecting me to memorize all this random shit is just beyond stupid. Go find a 5th grader who memorized the nation and state capitals on the 1st try if this is what you want. If you want someone who actually solve a problem, maybe you want to hire someone who can research the problem and come up with a better solution.
I'm still with my first company out of college. The hiring manager didn't even ask about my skills- he wanted to know if I wanted to learn, if I wanted to gain new skills, and if I was willing to put in the time to learn new stuff. Of course, I'm a DoD system and network consultant, so I need to learn and master new stuff all the time. The couple of corporate projects I've been on have so focused on one single aspect that they get a llama that can program in Java, and they still hire the llama. (Yes, that was mostly facitous).
So go interview the guy/gal about who they are, what they want to do in life and in thier job, how they like to do their work. Don't worry about what languages they can program in (unless thi is what you are looking for), any literate computer person can learn a new language in a few days.
In summary, look at the person, not thier certificatons and answers to crazy technical questions.
Vote monkeys into Congress. They are cheaper and more trustworthy.
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
I heard this a while back and it's been true in the majority of the technical situations I've been in:
The number of women present is less than or equal to the number of men named David.
- AlanH
(* I think the 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.
Simple question to ask the interviewee: To find the answer to a technical problem, do you consult the 1000+ page spec book, or head to groups.google.com?
The college kids with no practical experience will go for the books. People that have enough experience to realize that the implementation never matches the specs go to google.
I don't think I am such a bad programmer, but i don't like the MS type riddles. They annoy me in that there is a single, pre-defined answer. When I am dreaming up a technical solution to a request, I am thinking up something that doesn't have a pre-defined answer. I have seen plenty of solutions that work, but merely parrot the previous solution and ignore any new possibilities that may have come up since. All that results is that we get bogged down in old technology and methods.
Microsoft - Where would you like to go today, Maybe Jail?
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.
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
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 ;-)
If a company asks me a Microsoft-style riddle, I'm outta there. You might as well ask a Trivial Pursuit question instead - it's just testing whether you've seen that riddle before, not testing any brain-power.
The important thing to test in an interview is *method*. Not whether the answer was right, but whether they went through the right steps to get there. If they got the right answer by some random guess, that tells you nothing, but if they went through the right steps and made a mistake, in the real world they can back-track and find the mistake.
Grab.
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!
BSOD's usually a simple hardware problem and can be troubleshooted by reading which driver that caused it.
I told them that after I noticed they weren't laughing at the Clippy comment. Heh.
"Derp de derp."
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
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)
Everyone works differently... accept it. Thus I don't think your comment is correct. Especially in programming. And now on to some heartfelt flaming.
5 years to learn a language? Shesh. No offense, but anyone with a good year or two solid with a language should be able to handle team lead using that language. Even more so if that person took the time during college to really learn good design. And yes, I do know what I'm talking about, and yes I do have the experience. And no, you can't hire me =) And no, please don't reply saying you wouldn't hire me anyway because blah blah blah...
I ate my sig.
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.
learn perl in a few days biotch =) all of it, modules, libs, etc. learn java in a few days biotch... all of the classes and intricacies of the language. We're not talking java in 21 days here pal. now be honest and tell me i'm right in this case... or can you honestly delude yourself into thinking one can really learn everything in a few days? just as one needs to know the right way of designing complex systems, one must truly know the ins and outs of the tools (languages) they use to implement the design.
i've written the usual smorgasboard of web apps, wireless apps (client and server), UI and middleware for embedded devices using c. worked on full projects: design, implementation, and debugging... from scratch. i've done everything from lowly QA to team lead... what have you done? lately? and what freaking college are these people coming from?
I may be a fool, but i'm a damn well paid one, and respected by my peers. Thats enough for me. Can you say the same?
I ate my sig.
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.