|
Any Programmers Agree on Reasonable Interview Q's?
After reading some of the two threads, "interview question" and "stupid specific interview questions", I have one comment to make...
It appears that most programmers deeply resent being tested on their basic competency, consider it demeaning even when the audience doesn't know them personally, and also won't suggest a constructive way to measure a candidate.
I hold that it is absolutely unreasonable to expect a hiring party who is paying you an upper middle class salary to have no specific expectations of your competency and to simply take on your word of mouth that you've done great things in the past.
It seems to be the case that all specific technology questions off limits; all ways of stating a question suspect because you are not "honoring" the candidate's dyslexia, verbal incompetency, inability to understand a question, cultural differences, etc...
Also, all basic programming exercises are suspect because for heaven's sakes, the person may have only done OS internals and won't have any idea what console IO does. Or the person, who claims to have written a text in the language, has never picked up a text on that language themselves and therefore won't understand the phrase "Hello World".
So basically, many of you guys/gals seem to be saying that it limits, stereotypes, pigeonholes, the candidate to ask them to answer or do anything.
Each of you presumably would do it "better" and in a less demeaning way, ... but HOW???
??? I am confused. ???
Bored Bystander
Monday, December 1, 2003
A theme you're overlooking is "Ask me why or how, not what or do."
As me why I chose to do a certain thing, why I would consider something impossible or possible, why I coded an object as I did or why I use setters and getters, why I prefer arrays over dictionaries, or why I treat every variable as a string in my sql. (exaggerated for your convenience)
Don't ask me to write a class or a function and then critique it without having a conversation about the choices made. Coding is not a hard science where there is only one way. There may be preferred ways, but there is often more than one acceptable way. So let's talk about those choices, why they were made and how I came to the conclusions I did.
Don't ask me what the difference is between your favorite array type and mine, ask me why I prefer mine and where I find yours useful instead.
Those conversations (and I stress the word) will get you much more information than any "WHAT and DO" interview.
Lou
Monday, December 1, 2003
I agree Lou. You basically said the same thing I said in the other post.
icancyuwudbeshy
Monday, December 1, 2003
Set a coding problem, give them a week to provide a solution (they may already have a fulltime job, they may be attending other interviews, etc).
Walter Rumsby
Monday, December 1, 2003
>> "Ask me why or how, not what or do."
That's reasonable.
Actually, I would be a softie about the "would this printf() compile" question posed by Steve in one aforementioned thread. If the candidate said "no it would not compile" I would challenge the candidate to describe the error the compiler would generate and why the compiler rejected it, since C compilers don't check argument lists (or do they...?)
However, I also don't suffer fools. I would probably do as you say, but buttressed by a clear question that really demanded just one type of answer. The fools could hit the bricks when they started to make up stories...
(Is there not a place to ask trivial and specific "what" questions about the technology du jour?)
Bored Bystander
Monday, December 1, 2003
Well, you know what, my "standard out in a daemon" wasn't necessarily for programmers.
Many times, *nix installations have "system administrators". I think I'm being completely reasonable when I ask a sys admin candiate about "standard out" and "daemon". If they haven't encountered this situation, that's perfectly fine. BUT TELL ME WHAT YOU DO KNOW ABOUT IT-"it" being standard out and daemons.
I work on fairly complex installations. If someone offers a "I don't know" answer (to such a simple question) and then just sits there, I'm feel bad (okay, no I don't!) but I'm not going to hire you.
This has happened to me in interviews many more times than I care to remember.
One of my old managers once taught me: Never bring problems to management. Always bring solutions. No matter how kludgy, junky, or out of this world.
A journalist once asked Buzz Aldrin if he would write a last letter or open a valve to space to end it quickly if the ascent stage engine of the Lunar Lander wouldn't work and the Buzz & Neil would be stranded on the moon.
The journalist was taken aback by the quizzical look on Buzz's face when he responded quickly, "I'd reckon I spend my last moments trying to get that engine to work!"
That's the attitude I happen to be looking for...
Steve Forest
Monday, December 1, 2003
I think some bad programmers hate technical questions because they are incompetent, and some good programmers hate them because they think they are demeaning. It really isn't too hard to get an idea of a person's technical ability if you are a good interviewer. You simply talk about that person's past projects. If the person is fresh out of school, certifications and tests become more important. Of course, you not only want people that know the technical material, you want them to be good THINKERS. That again comes out if you know how to interview.
BUT... The best way to find candidates is also the best way to find jobs: NETWORKING. You learn who is good and who to stay away from by building a list of people you trust.
tech recruiter
Monday, December 1, 2003
Tech recruiter, I mostly agree with you.
However, I worked around a fellow a few years ago who was said to have taught C++ in a tech school environment. Oh, he knows his stuff, oh yeah. Right.
Then I had to maintain his code when he was ousted. What an "abortion" of crap. The guy had everyone snowed. His stuff displayed basic lack of comprehension of C++ as well as failing to meet basic workmanship standards (initializing members in constructors and other "geek detail" quibbles.)
It's experiences like this, repeated over the years, that make me say "yeah, so and so has great contacts and great experience, NOW, does he know specifically what this statement does....?"
IE, someone's network and their past accomplishments, and even their personal demeanor, are *just talk*.
Bored Bystander
Monday, December 1, 2003
Would you buy a car you saw for 10 minutes?
Would you marry after knowing someone a few hours?
Why would you expect to learn much of anything from an interview? Sixty minutes of in your face, how well do I make you feel about me, do we share common interests and ideas, topped off with: "can you answer the jeopardy question of the day?" questions.
Hiring is hard. It is tedious, long, drawn out and often flawed. While you do not suffer fools, good developers feel the same way about you. Questions I have been asked:
- Name seven internal database tables in DB2. {It was an oracle position, but they did not have those answers)
- When should you throw exceptions in an application? {Never was the answer they were looking for, but they did not know why. I did get an offer, but was scared off by how they got this way.}
- Are you willing to work long days and weekends to make a project date? {OK - I laughed}
- In 1998, I was told they were looking for someone with seven plus years of Java experience. I saw on this board a similar request being made to someone with C# experience in the past few months.
So how to do it?
- Figure out what you need. What exact skills and recognize that this is like anything. It is all a trade-off. (Bill Joy will not come for 32k/year)
- Ask you best people. It amazes me that companies go out and hire, but rarely pursue from within. Forget "we posted it on the company web site." Go ask Ace. She is a great developer and most likely will know others. Ask her for a specific recommendation on people. The list grows shorter when you ask people to vouch for someone else.
- Figure out if you like the person. Do they fit in with your organizations ideals, attitude and direction. Are they a "can do" or "will follow." Which do you need?
- Weigh business knowledge versus technical skills Is it worth the trade off?
- If you must look at code, then give a small request. Something that should be done in one to three hours. Ask them to do it, as I would every day. Then look at it. (Don't penalize stupid stuff unless you plan to give them a compiler)
Finally, recognize you are not getting married. If you hire Jim-Bob and he is a moron, or had someone else do his work, or doesn't play well with others, fire him.
MSHack
Monday, December 1, 2003
One last thing. I just reread your post. The guy I'm describing would have washed out because he had absolutely no network that would vouch for him. And he had moved around enough to have gotten some sort of (good) reputation in place, if he had deserved one.
So, you're right.
Bored Bystander
Monday, December 1, 2003
>> "BUT... The best way to find candidates is also the best way to find jobs: NETWORKING. You learn who is good and who to stay away from by building a list of people you trust. "
Black listing someone because they aren't on your "network of goody goody friends" or because they didn't answer your question to your satisfaction isn't the brightest idea either.
Monday, December 1, 2003
I have no clue as to where stdout goes in a daemon, so I guess I wouldn't get a job from you. I'll have to keep my job as the sole, part time sysadmin for a distributed web cluster that undergoes the equivalent of the slashdot effect on a daily basis.
techie
Monday, December 1, 2003
re: goody goody friends.
You misunderstand. Even if I don't know the person, and none of my contacts know the person, odds are that one of my contacts knows somebody that worked with that person. 7 degrees of seperation and all. So if Bill doesn't know Joe, I ask Bill if he knows anybody that worked for Acme industries, and keep on working the line until I find SOMEBODY that has heard of the guy.
As far as not being the best way to hire people, my customers and my employer have been very happy with me so far!
tech recruiter
Monday, December 1, 2003
I think the reason the printf question annoyed people was that they suspect that under the pressure of the interview process their answer would have been something like:
"No!......ummm hang on that's that multiple argument thing, what's it called? I guess it would compile but would probably crash when you executed it."
Thing is, you don't keep the fact that printf uses varargs in the front of your head because you don't need to - it's an implementation detail abstraced away by the interface. Now, no competant C programmer is going to tell you that printf("%d"); is going to work but they might not have instant recall on exactly why.
Having said this I think there is value in having questions that sort the complete fakers from the competant (and it's amazing how many fakers you get). I don't even think you need to get as tricky as the printf question.
I reckon you could cull a good percentage of applicants with the following
2) Comment on this design
class Engine {};
class Car : public Engine {};
AndrewR
Monday, December 1, 2003
Hi BB,
Imo, the problem isn't that employers want to test for "programming language knowledge/competency" it is the amount of importance put on them
BB I believe you mentioned in an earlier post that you are an independent developer and that you mostly write business apps? Let me ask you a question. What do you do for your clients? Do you simply sit down and start coding applications for them or is what you do (the services you provide) a little more complicated than that?
IMO, very generic technical competency tests can and probably should be taken by all potential job candidates. However, "specific programming language knowledge/competency tests" should only be used in situations where the job candidate is going to be spending most of their time writing source code according to some pre-defined spec. I haven't been able to find such a pure heads down coding position in ages. I know that they are out there, unfortunately, I haven't been able to land any of them. Why? Most of them seem to be reserved for individuals with little if any work experience (i.e. recent college grads).
Monday, December 1, 2003
<< Then I had to maintain his code when he was ousted. What an "abortion" of crap. The guy had everyone snowed. His stuff displayed basic lack of comprehension of C++ as well as failing to meet basic workmanship standards (initializing members in constructors and other "geek detail" quibbles.) It's experiences like this, repeated over the years, that make me say "yeah, so and so has great contacts and great experience, NOW, does he know specifically what this statement does....?" >>
Hey, I think I knew that guy... all I can say is, "Amen, brother".
What I actually like to do for interviewing is a two-step process. First, I give them a C++ test on which any idiot should be able to answer the first five questions (see my previous threads, but just for example: "What's a virtual function?"). I grade these extremely gently, and not because I'm a nice guy, but to attempt to include as many candidates as possible.
Next, I sit down and "shoot the breeze" with them. The goal in the "shoot the breeze" phase is to eventually ease them into talking to me as one "propeller-head" to another. "Wow, you worked with the XYZ technology? How'd you like it? Yeah, doesn't its ABC suck?" And so on. You'd be suprised how quickly "propeller-heads" (like me) will relax and just *talk*.
After "shooting the breeze" like this for about 30 minutes (rapidly changing subjects to touch on as much as possible, without destroying the flow of the conversation), I have a pretty good "order-of-magnitude" feel for their relative skill level. That is, I can very reliably group them into one of these categories:
o Total faker
o Beginner
o Advanced
o Demi-god
Notice that I'm not trying to slot them into a 39-level hierarchy here. And remember that I've spent 30 minutes talking tech stuff with them:
o "Total fakers" don't make it the whole 30 minutes; they're usually too embarrassed to continue.
o "Beginners" are, by convention, anyone *much* less skilled than myself. This is pretty easy for anyone to guage.
o "Advanced" are, by convention, anyone who is anywhere near my skill level. It takes one to know one, essentially.
o "Demi-gods" are the ones that know more than I do. These are easy to spot, too: they're the ones you learn a lot from during the interview!
Next, I ignore the fakers; this reduces the candidate pool by about 90%. No, I'm not kidding.
Finally, all I have to do is decide if the job requires a "Beginner", and "Advanced", or a "Demi-god". Then I bring in a handful for a round of interviews with the PHB, which gathers even more information about them, and we're done. Obviously, a lot of intangibles (positive, can-do attitude, etc.) are factored in at this point.
See how easy this is?
Grumpy Old-Timer
Monday, December 1, 2003
Just to clarify on this subject - the reason people are sceptical of much conventional testing is that the tests look for irrelevant esoterica rather than the abilities that are actually important.
One of the commonest reasons for such inappropriate tests seems to be poor judgement and capability on the part of the hiring managers.
In other fields this is perhaps not quite so important, because there are standardised processes for obtaining a right to work at a certain job, and interviewers can rely on that. Then they just have to see that they like the candidate and it's finished.
Monday, December 1, 2003
Tech Recruiter's viewpoint is worth noting because it's often not possible to be an expert in the field you're trying to hire. So, an alternative technique is to look at the people "around" the candidate. If the candidate knows people who seem competent who speak well of him, then by inference the person may not be a total loser.
Actually, I think you guys rock. There are a lot of ways of looking at the same issue and there are a ton of good ideas on the subject being presented here. I just thought that the collective consciousness deserved a hard kick in the nuts today. ;-)
Bored Bystander
Monday, December 1, 2003
Bored Bystander:
I guess what is wrong with this type of questions is that they test just a small snippet of knowledge which more often than not is tailored on whatever knowledge the interviewer happens to posses. I was a prolific printf and memcpy user in 1996. Seven years later, I upgraded my skill set many times and I did not use the core C functions ever since. So if I don’t remember if printf compiles or not on a specific platform makes me a bad candidate?
In my experience the projects are so different from each other that I have yet to use the same knowledge for two different companies. Even more, the number of skills required in today’s programming is so vast (just read the employment ads) that asking the candidate to remember some printf peculiarities proves that the interviewer didn’t quite wet his feet with real world problems.
Why would be the printf so special and important when compared with the other one million of C, C++, C#, VB, SQL, Oracle, Asp, .Net, CLR, multi threading, HTTP, Web services, HTML, DHTML, XML, XLT, XLS, CSS, Javascript, deployment, scalability, remoting possible questions. Do you expect the candidate to know all the answers at the time of interview? Do *you* know all the answers?
coresi
Monday, December 1, 2003
"2) Comment on this design
class Engine {};
class Car : public Engine {}; "
That's a perfect question for a C++ design job, because you can have a 15 minute conversation about composition vs. inheritance, perhaps spiraling off to a language design discussion, and it actually tells you something about the interviewer.
Jason McCullough
Monday, December 1, 2003
>> "You misunderstand. Even if I don't know the person, and none of my contacts know the person, odds are that one of my contacts knows somebody that worked with that person. 7 degrees of seperation and all. So if Bill doesn't know Joe, I ask Bill if he knows anybody that worked for Acme industries, and keep on working the line until I find SOMEBODY that has heard of the guy."
Judging a person by hearsay is never a good thing. If a person has only heard of someone and doesn't know them, how can they judge them? Isn't it illegal to call around asking about people who know people and obtaining specific information about them? Seems like a shady practice to me? Doesn't the prospective employee have to give you permission to contact their previous employer and/or co-workers? What if this person was mistreated at their previous position and these people don't know the whole story so they all give you false information? I think you're treading pretty thin water
Monday, December 1, 2003
I'd hire someone who could walk on water, thin or not.
pdq
Monday, December 1, 2003
Grumpy Old Timer, I think this is really the perfect interview process. I too like to have my bosses give all candidates easy tests. (I don't have hire/fire power, but I get some input due to seniority at the company). Its amazing how many people get weeded out by silly, basic questions. I also agree that shooting the breeze is a great way to know someone. The only thing that you can't tell, is how good/fast someone is. From what i've seen, there are two types of people who pass the "shooting the breeze" section, and are categorized as advanced. Type A: People who know a lot, and are good programmers, and type B: people who know a lot, and are out-freaking standing programmers who can code 3x as fast as type A. And you can't really distinguish the two from each other.
Vince
Monday, December 1, 2003
Reasonable interview questions:
1. How much do you want?
2. When do you want it by?
3. Can you suck up to corporate management?
You
Monday, December 1, 2003
Some people can shoot the breeze and talk about programming until the cows come home, but are completely incapable of writing practical, working code too.
No test is foolproof, unfortunately.
Sum Dum Gai
Monday, December 1, 2003
I disagree with the early poster who said "Ask me why or how, not what or do."
The problem with "why" questions is that there are lots of good pontificators who are lousy programmers. I ask one of "why" questions, mainly to test whether the interviewee can make a coherent argument. Then I ask them to defend the opposite position.
Instead, I focus on "how" or "do" questions, to tests general problem-solving skills. I've got my own variations of Joel's "How do you invert an array in place?" question.
Julian
Tuesday, December 2, 2003
"The best way to find candidates is also the best way to find jobs: NETWORKING" - tech recruiter
Which would mean no more agencies.
Tuesday, December 2, 2003
Dunno about the 'hiring mates' stategy. Something I once posted on /.
At a job a few years ago, someone decided to hire his mate - "He's a really good programmer".
Ray duly came in, sat down and got to work. Ray asked a lot of questions "How do you make the menu come up when you click the right mouse button?", "Why doesn't the FTP control work?" and so on. Reasonable questions, but not what you'd expect from a 'really good' programmer.
One day, Ray asked "How do I get a value out of a subroutine?"
Huh? While my brain tried to figure out what he was actually asking - make it a function, parameter passing, passed by reference, Ray solved his own problem.
"Never mind, I'll just make everything global!"
Luckily, everyone else eventually realised he was useless. Even the managers. Ray exits stage left.
AJS
Tuesday, December 2, 2003
I must admit that I don't really understand the problem some people seem to have with 'bad' interview questions. As far as I'm concerned you can ask me what ever you want as long as you let me talk. I'm learning as much, if not more, about you as you are about me. Ask really daft questions and you'll fail and I wont work for you :)
If you start asking me about things that I don't know the answer to I'll tell you I don't know and ask you how important these things are to the role. If it's something that I expect I could work out pretty quickly, or if your response indicates that it's something similar to something else I've done then I'll try and explain the similarity to you. Often in these situations I'll start talking as I think, so you can see the thought process; I can also then watch your reactions to my "workings" and that often helps me come to the answer that you're looking for. If it's a nitty gritty technical issue and I should know and I don't then I'd like to be able to walk away from the interview knowing the answer so that my time spent wasn't wasted. Sometimes a 'difficult' question will be asked and the interviewer has the wrong answer in front of them but doesnt know it (usually when the interviewer isn't technically knowledgable enough to pass the interview tests). How the interviewer reacts to having the correct answer explained to them, and where they fit in the management hierarchy I'd be expected to work with often determines if they pass and if I'd work for them...
I've no interest in working with a client where we have a bad fit, it just causes stress for both sides. Then again I rarely go into an interview where I'm thinking "I really want to work with these people", or "I really need this job/client" so I guess that puts a different spin on things. I also love nitty gritty C++ tests so perhaps I'm just a freak ;)
Len Holgate (www.lenholgate.com)
Tuesday, December 2, 2003
oookkkkaaaayyyy......
1) If somebody recommends a dud, I don't ask for their recommendations anymore. 4 years, hasn't happened yet.
2) Yes, relying on word-of-mouth reputation has some drawbacks. There is no perfect system.
3) Sure, I'm just waiting for friendster to put us all out of business - NOT!
tech recruiter
Tuesday, December 2, 2003
Tech Recruiters and Recruiters in general just plain suck.
1. They post fake advertisements for jobs. Fake jobs suck. If you want my name and address and resume for your precious little database why not go out and get some real positions and then put up and ad for them? I know you all have the education level of a 1st grader but it's not that hard not to decieve and lie to people.
2. When an opening comes up, they simply forward every fucking resume they have with the buzzwords on it to the potential client? Hrm... I thought you were working for me and would at least only submit the resumes you can give personal attention to. I guess not you crazy scum of the earth you.
Don't even bother replying tech recruiter, everything that spews from your mouth is shit.
Tuesday, December 2, 2003
#1 is done by people that don't have a network.
#2 is done by people that don't have a network.
What you don't understand, is that I don't work for you.
I work for the company that has an opening.
I'm not going to blast my customer with resumes - I'm going to find the best match possible for them. In this way, I provide them with a VALUABLE SERVICE. Sometimes, that means telling them that I don't have anybody.
What you are describing is the work of hacks. What you don't understand is that they will not be in business long because they offer no VALUE to their customers.
I'm sorry you've had bad experiences, but remember that we are in a BUSINESS and you need to be careful about who you enter into association with. I'm not your friend trying to find you a job. I have a duty and responsibility to fulfill.
tech recruiter
Tuesday, December 2, 2003
Grumpy Old-Timer: I do for once agree with you.
I follow the same reasoning as you but there is one flaw though. You measure the candidates against your own skills. I consider myself advanced. Still I went to interviews where the interviewer was a fake and believed himself to be a demigod. This kind of people don’t even realize how limited their knowledge is but still they ask you a printf question they read in a book and thought is the crux of programming.
coresi
Tuesday, December 2, 2003
>> "What you don't understand, is that I don't work for you."
Hey dumbass, let's get something straight. I'm your customer also. You work for me. Without me you would be nothing. Face it, you're are the scum of the earth. You're comparable to someone who sells slaves. The problem with you recruiters is that you have pretend to serve two masters when you are only interested in yourself. You said it yourself, "my customer is the company I find recruits for"... Bullshit. You have two customers to please. The company and the candidate. You only get money from one so it's in your best interest to suck up to them... You're just a floundering fool. You can't deny the workings of your own business. Crooked very crooked.
Tuesday, December 2, 2003
Wow. Somebody's angry.
I've learned in life that recruiters aren't looking out for my best interests, Real estate agents aren't looking out for my best interests, Insurance adjusters aren't looking out for my best interests, and a lot of times even lawyers I pay aren't looking out for my best interests. Let me just cut this short: I am solely responsible for safeguarding my own interests and you are solely responsible for safeguarding yours.
I've learnt these lessons the hard way too. Being bitter about it only hurts you. It doesn't solve any problems.
ted
Tuesday, December 2, 2003
I agree, don't shit all over the stray technical recruiter who comes in here. You/we may not always like or respect the team they play on, but they *do* have valuable things to tell us about how the larger world actually works.
"Tech recruiter" was being pretty nice, really. I've dealt with some real pricks in that business too.
Bored Bystander
Tuesday, December 2, 2003
I think a good interview question for C programmers is "will this printf statement compile? Why or why not?"
What I took issue with was making it a go/no-go for the entire interview. Take an hour with a candidate to get a feel for their scope of knowledge, but don't say if they don't know this specific data point they're obviously lying about it (that *is* the implication - you wouldn't be interviewing them if their resume didn't look like what you wanted).
The best interview is a broad, interactive one that isn't just a quiz show.
Philo
Philo
Tuesday, December 2, 2003
 Recent Topics
Fog Creek Home
|
