_  _ _  _  
(_|| | |(_|><
 _|   

Nice, here's another good site to check out for some programmer interview questions: http://www.programmerinterview.com/

• I make him talk, to avoid the question/answer scheme which stress a lot of people
  (they feel it as an exam and it reduces their efficiency)
  furthermore the more they talk the more I learn about them.
• Being kind, make them more confident the shy one will be more efficient,
  the sneaky one will lower his guard, the average guy will just have a more pleasant interview
• I avoid direct precise questions to avoid the 'exam stress' and beccause anyway you learn more (IMHO)
  through open questions than trough precise (closed) questions.
  Moreover I don't judge people on what I know that they don't know but rather on what they know that I don't.
  
• When you 'chase the "good"' you tend to ignore less people potential
  (which is more important FOR ME than current experience/skill).
  Anyway each coin has two side :
  Creative people tends to be less organized.
  Specialized poeple adapt slowly than genralized one.
  You got the Idea...
  It's may be a cultural point of view, as you (american people) seems to estimate people more on their current skills,
  but I tend to estimate people on their potential/personality and then try to see how I could exploit their strengths.
  You may say that sometimes you're looking for the 'right person' to do a 'well defined job' and you can't afford to teach the newcomer.
  But any 'newcomer' has to adapt to the way of working in the company, learning new skills is often not so expensive...
  

If an applicant is familiar with a skill/language, they should be able to apply that skill/language to a simple example or provide some examples of problems they have recently solved. dws's node (see above) talks about implementing Minesweeper, and another example is the Game of Life (Conway) -- both probably involve two nested for loops somewhere, and a programmer should be able to figure that out. Get examples of their logic to solve the puzzle, along with boundary conditions (that's important) like "What happens when you get to the edge?" and some idea of how to store the game board (two arrays, maybe?).

One of the links about interviews that I read recently frowned on the "Solve this mental challenge" type questions because either you got the trick or you didn't -- it wasn't really a good measuring stick for smart, methodical, get it done right type programmers. Without the "Aha!" moment, the applicant's sunk.

So, if they claim to know SQL, ask about doing a join. If they ask if you want an inner or an outer join, they may be showing off, or they may really know their stuff. You could also ask about the efficiency of using different fields for indexes. Or what foreign indexes are (hint: nothing to do with some other country's stock market).

If they claim to know Perl, ask some regex questions, some array questions, some reference questions, and about what resources they use when they get stuck (they must get stuck sometimes). Do they have any of the excellent O'Reilly books? What on-line resources do they use? Do they have a favourite module? A favourite authour?

Finally, shoot them through a little test -- I used to give candidates a one hour test. It pretty clearly showed whether their skills matched the contents of their resume. One more quick story: part of my test was to code a bubble sort in C (yes, I know it's N*N and not always that efficient). One applicant wrote out the code for the QuickSort algorithim instead. Later, I typed his code in: it compiled and ran correctly the first time. However .. I had not asked for "any" sorting algorithim, I had asked specifically for a bubble sort. So I rejected that candidate, because in my opinion he would go off and do his own thing after being told what to do, and that's not the kind of person I wanted to hire.

On a personal note..
Having just applied for a full-time job here in Toronto (recent post on PerlJobs) I am dreading the interview thing (if I make it that far), not because I don't know my stuff, but because I tend too often to give the two minute answer when all that's really required is the ten second answer -- I can't help it, that's just my personality -- I don't want to leave anything out. The result is often a glazed look on the interviewer's eyes that seems to say "Thank you. Next please."

--t. alex

"Excellent. Release the hounds." -- Monty Burns.

START QUOTE
code a bubble sort in C (yes, I know it's N*N and not always that efficient). One applicant wrote out the code for the QuickSort algorithim instead. Later, I typed his code in: it compiled and ran correctly the first time. However .. I had not asked for "any" sorting algorithim, I had asked specifically for a bubble sort. So I rejected that candidate, because in my opinion he would go off and do his own thing after being told what to do, and that's not the kind of person I wanted to hire.
END QUOTE

So I would ask how big the list was to sort and try to work out which sort is the best for that. So you wouldn't hire me because I'm not a brainless idiot who just does what you want???

--
My opinions may have changed,
but not the fact that I am right

Wow. I think rejecting the candidate over the sort algorithm implemented was probably not the best idea. Maybe he is confused about which sort is which, or doesn't know bubble sort but does know quicksort. Me, I don't even know either sort, and wouldn't bother to remember the bubble sort if it is known to be generally less useful (as your own statement indicates). Finally, the test you gave only tests a specific piece of knowledge and you discarded the most important information you got from it. This coder wrote working code the first time through-- code that probably satisfied the real requirements of "sort this list efficiently".

Personally, I think a better one hour test would be something like spending an hour solving some random problem-- something like scoring a bowling game or a golf game (as in +/- par) or giving the candidate a calculation for something fun like compound interest and making them implement an interface for several views of it. But in addition to the code itself, watch how they solve it, do they ask good questions about requirements, how do they validate their code, are they fluent or do they rely on compiler warnings to get code correct, etc. Of course, I say all this as a mostly impartial observer-- not as a hiring manager in a programming shop, nor as a programmer looking to get hired.

I think we'll have to agree to disagree on this one.

I did write up a pretty succinct description of the algorithim required for the test -- so it was really an assignment to implement a given algorithim in C. This was clearly not a real-world situation (that is, I didn't engage the applicant in a discussion of sorting algorithims), but then few tests are.

To relate it a little more closely to the work I was doing at the time -- imagine if a legacy system requires that you do A, B, C, D then E, but the programmer you assign to do that task ignores that information and spends a week coming up with a much better solution that does B, E, D, C then A. It's coded beautifully, it's lightning fast .. but it's wrong because it's not what you asked for. What then?

Finally, I am flexible. I remember one situation where I went to my best programmer to plan an approach to a particular problem -- I had one idea, and he had another idea. The result? Aha! A melding of the two ideas which was miles better than either of the original ideas. We were both happy with the decision, and the company got a great solution.

--t. alex

"Excellent. Release the hounds." -- Monty Burns.

1. Candidate should send example of his code with his resume. This code is reviewed. Sometimes resumes were rejected at that step (usual reasons for rejection are absence of use strict, absence of indents, homebrew parser of query parameters in CGI).
2. Before interviewing candidate they were given tests to do - relatively simple programming tasks. Tests were specially designed to stress required skill.

--
Ilya Martynov (http://martynov.org/)

"Of course I know what use strict is DAMMIT! What, am I an idiot?!?"

Don't worry so much about insulting their ego, but if they get set off by simple questions, "Do you really want to work with them?"

Working with people is more than knowing your stuff, it's about working with people. Many companies have questions just to see how the interviewee responds to insulting questions.

My latest interview had some questions on a rather broad area and they also sent a screening test over to me. According to them, I got a good percentage correct, though some of the answers were open to interpretation. The face to face interview had a few technical questions, but there were more that tested my tolerance or what my procedures would be. I seem to have done OK since I start next tuesday.

Update: I should of phrased better. I don't like the obviously insulting questions any better. I had one interview where I had up front said I didn't know the specifics of Solaris for Intel having just dealt with Sparc based. I was then harrassed with questions that only dealt with Intel. Annoying.

However, if you get insulted if a question is simple, then you might have a problem.

Working with people is more than knowing your stuff, it's about working with people. Many companies have questions just to see how the interviewee responds to insulting questions.

imho this is pretty hateful. I'm getting very tired of interviews where they're trying to find out about my personality by asking trick questions.

I agree 100% that there's no use knowing your stuff if you can't work with other people, but if they want to find out what I'm like as a person, why can't they just take me out to lunch! >G<

At least in a (fairly) genuine social situation, a potential employer would get to know me. Trick questions in a technical interview just mean I have to guess the answer they're looking for - for example, some interviewers are testing your assertiveness, and want you to stand up for yourself, whereas others just want you to agree with them.

Oh for better trained interviewers.

andy.

And I have been in the situation where we didn't ask enough of the personality questions, and we did take the guy out to lunch. It turned out he was completely unresponsive to requests to work, but he kept himself busy with rewriting our stuff that worked so that it had problems!
None of that came out in the interview or at lunch.



"That that is, is... for what is that but that? and is but is?" Shakespeare, Twelfth Night, Act IV, Scene 2 "Yet THAT which is not neither is nor is not That which is!" Frater Perdurabo (pseud. Aleister Crowley), Liber CCCXXXIII, The Book of Lies

If things get any worse, I'll have to ask you to stop helping me.

The first part of my most recent interview was pretty cool:

• "Hey, Matt, do you know awk?"
• "Nope, but I know a bit of Perl...."
• "Good. Here's an editor, gawk, two awk references, seven problems, and ninety minutes. Get as far as you can."

I ended up learning regexes the hard way, in those 90 minutes. The process seems to work with people other than me, too; we don't have anyone in the computing group here who doesn't pull their weight. I'm quite a fan of the "practical" interview, now.

Update: I was recently (Aug. 2002) reminded that we got 60 minutes, not 90....

--
:wq

A simple search for interview in the little box at the top of the page will get you a whole lot of threads about this topic, with questions to ask, various techniques and examples of interviews, from both sides of the fence.

The QA session should get their blood running enough to show their enthusiasm. We do put them through a lot, but we are very nice about it. If they don't like it, then they won't want to work for us and we can move on to the next prospect.

It's also important to note that we begin serious QA over the phone, before they ever come down. You can eliminate much of the 'lies' and 'exaggerations' before you waste a lot of anyone's valuable time.

If you're trying to prepare for a programmer interview, check out: http://www.programmerinterview.com/