I can't believe that's the most popular choice! I've been unemployed for some time now, the typical person who interviews me doesn't have a clue as to what to ask me. I'm back out on the street before I realize they haven't asked me any real questions. I'm learning that I need to force feed them, because all they're going to ask me is "What kinds of projects did you do in C++". He who lies best gets the gig.
Come up with a test, make them write some code. You'll be able to evaluate the guy who was here last week vs. today objectivly.
Anonymous wrote: Come up with a test, make them write some code.
I couldn't agree with you more. That's what we do (in a professional and non-threatening manner) at our company. We don't use a formal test, but we do ask specific programming questions that help us better judge the candidate's knowledge. Interestingly, all the good developers we speak to seem to enjoy the interview.
There really needs to be an option for "Hiring? We don't hire people anymore"
Aside from that.. we did several interviews with candidates, both technical ("tricky" questions) as well as what they did at their previous company. We also took them out to lunch with most of the group they would be working with (3-4 people), to see how they got along with everyone on a personal level. We even got evil a couple of times.... we'd have the first interviewer show them around and tell them things about what we make - then have the last interviewer ask them questions about our product to see what they remember.
Suprisingly enough.. the best success I've had with an interview question is to ask them to implement the insert function for a linked list. The good engineers will stop, think about it for a second, and write out a quick design (or at least speak it out loud), being sure to note the error cases (inserting at the end, inserting into an empty list). You'd be suprised how many people with "5 years C/C++ experience" simply COULD NOT do this. We think it's because it's so simple. Interviewing pressures people, and there's an unspoken feeling that it's such a simple question they need to look like they can do it without any thought involved.
If you think that is a good test, your a fool! What is the capital of Iran? How do you change a tire? Your question is as good as my 2 previous questions. What if the poor fellow doesnt even know what a linked list is? He may know how to do it, but as he has learned to code by himself, he doesnt know that, what you call a "linked list", is for him a "F%&& pain in the a$$ list". You look like my programming teacher from my first year in college. Also, you're looking for a guy that creates a solutions in a timespace of days/weeks. He doesnt have to know it all in the tip of his thongue!
If you want to know if he is a good engineer, you'll have to ask him about things not connected to programming.
Btw, i dont believe that, in general, programmers are engineers. I havent met a single guy that had a degree in computer programming who was a real engineer.
u missed the point. he may know what it is...
Ill give u an example:
I had a friend of mine who was a great programmer and he learned it by himself. He mastered all the basic structures, bla bla bla but he didnt knew some of their names. For example, instead of knowing what an 'array' is, he knew what a 'vector' is. So, if you ask a guy to perform some kind of operation on an 'array', he wouldnt know for a start what an array is, as he knows it as a 'vector'.
Remember that English is not the first language for most of the world, so sometimes people dont get the ideia cause they dont understand the basic mean of the word. For example, it took me a while to realize what the name 'thread' meant (it has no relevant translation to my native tongue), although i perfectly knew how to use it. If it was called 'dog', it wouldnt make a difference to me, as i knew what it was for, and, because of my poor english, i would'nt try to associate it with a meaning right away.
I don't believe it's possible to be fully versed in data structures and not know the term array, especially if one already knows the term vector.
I'm not saying companies shouldn't make some allowances for non-native English speakers, but that's overboard. In case you haven't noticed, all major programming languages use English class names. The name of the Thread class doesn't change if you program in Spanish or Italian. (I might could see the confusion with the word "array", since it's rarely used explicitly in code, but not linked list.)
With very minimal proding, it should be possible to get any semi-skilled programmer to explain the workings of a linked list. Otherwise, I must again say that he or she is not skilled enough. Anyone who has done any sizable amount of work will know the basic ADTs.
As one of the lead developers I do interview all new candidates to add to our team. I think a lot can be learned in an interview more than just the yes / no questions. I usually ask a lot of do you know... What kind of ... Did you ... These questions hold some value but you are sometimes not sure if they are telling the truth. But then I get into discussing what I do and that is where I learn the most about what a candidate actually knows. If they have no clue what I am talking about it is usually very easy to tell...
If it were up to me (clearly it's not ), I'd rely mostly on internships and contract/temp positions. You can then evaluate somebody more realistically after a few months of actual work than you can in any type of interview.
Remember, even if you win the rat race, you're still a rat.
Yeah very true, this is a very good solution, I was hired on a contract position for a period of six month, I was not sure wheather my contract would be extended or i will be back at home without any job. So i attened interviews and got selected in one of the top company in India. My present company didnt want to loose me so they offered me a permanent post and good salary increase
Besides interviewing the development candidates and giving them some questions to answer, I also like to get to know what kind of person they are, such as if they like to explore new ideas and research on their own time because they're truly interested, or if they think that what they learned in couple classes is all they need to know (which is utter BS). Unfortunately, the former seems to be harder to come by these days, but since we're a growing company trying to stay on the cutting edge, it always pays off.
There has been once or twice that the CEO or CFO has forced me to hire an intern because they are cheap or free (over someone that we'd have to pay a little more) and it never fails that these people have no ambition to learn more and just don't really get it (i.e., development and practices). I typically waste more time (which is money) "babysitting" these people than the difference in wages.
Heath Stewart wrote: There has been once or twice that the CEO or CFO has forced me to hire an intern because they are cheap or free (over someone that we'd have to pay a little more) and it never fails that these people have no ambition to learn more and just don't really get it (i.e., development and practices).
Sounds like you need to apply the same practices you use to weed out bad full-time candidates. Sure, there are a lot of lazy [and|or] clueless people looking for internships - there are also a few of us who have the knowledge and the drive, but whose Work Experience resume section is a tad thin. Better yet, if you make a mistake, it's often a lot easier/cheaper to be rid of a bad intern than a bad FT employee.
How do you move in a world of fog, That's always changing things? Makes me wish that i could be a dog, When i see the price that you pay.
Of course, Access violation, crash or undefined are all acceptable answers.
Still, I can differentiate those who think that memory is just magically there
from those who know better. At school, they learn to use "string" or CString,
but before long, they will need to know a little more of what's going on
under the hood.
I am not surprised that those who post on this forum have the proper answer.
Newbies will not. Often, I can tell the value of a candidate by watching them
recover after they realize their mistake. I ask a supplemental question such
as "where does the memory for new_title come from ?
Those that never catch on are better left to VB shops...
I prefer to stick to old style "c" types as a basic interview foundation.
Of course, when I start working with newbies, I insist on "bool" (not BOOL), TCHAR (not char), LPCTSTR (not const char*) as well as const correctness, assertions and 1,000,000,000 little bits and pieces that make the code clear and fun to read.
Navin wrote: Come on, man, we don't program in an English-centric world anymore, gotta worry about those non-ASCII characters.
Actually, I speak french and it so happens that french, like most western countries have managed to map their character set in the 8 bit address set of ASCII. (extended ascii, if you prefer, since pure ascii is a 7 bit)
So it's not a question of English-centric world, it's a western hemisphere centric world