Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Interview with a Programmer

by notsoevil (Pilgrim)
on Jan 04, 2002 at 05:59 UTC ( #136182=perlmeditation: print w/replies, xml ) Need Help??

No, this isn't the beginning of a bad Anne Rice novel about undead Perl Programmers (but that would be great, right?!).

Recently, my company had to fire a programmer (my replacement since I've 'moved up the ladder' so to speak) because he wasn't living up to his reputation. This was because he sold himself up during our interviews.

Interview Q: "I see you have worked with Perl. How long and how comfortable are you with it?" Interview A: "Two Years. I'm not an expert but I'm not a novice either. I've written CGI scripts for just about every site in my resume."

Reality Q (after hired and noticing some problems): "Uh, what do you mean 'what is a hash'?" Reality A: "Is that a kinda variable? I'll have to email Matt Wright about that .."

Interview Q: "What about databases? Are you familiar with db connectivity? MySQL? PostgreSQL? Do you know SQL" Interview A: "Yes. MySQL. And I am not an expert with SQL, but I am familiar with it"

Reality: He knew OF THE EXISTENCE of MySQL, but had not actually worked with it. SQL .. that's an acronym right?

I have more examples, but I'll spare everyone. You can see a pattern right? See the "not expert, not novice" misdirection going on?

I am posting this to ask (didn't seem appropriate for SOPW though), how have you grilled/quizzed/tested/interviewed a potential hire without insulting his/her intelligence or ego in the process.

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

Or, if you have been the subject of a good interview that accomplished better screening of your skills, how did that go?

Jeremiah 49:32 - And their camels shall be a booty. . .

Replies are listed 'Best First'.
Re: Interview with a Programmer
by gmax (Abbot) on Jan 04, 2002 at 12:55 UTC
    A candidate should be given some practical tests to solve.
    When I interview for database programmers, I usually start with background and theory knowledge. I show them a Entity-Relationship diagram and ask to describe the links between some given tables.
    Then, I ask the candidate to write me some quick SQL code to solve a practical problem, using that diagram.
    If (s)he comes this far, then it's time to talk about programming languages, and I ask to solve the same problem as before, only this time not manually, but programmatically, and I want to see a flow chart or some pseudocode before the actual code is laid out.
    Later, we discuss the code, and this is when programming language details come up.
    A few years ago I used to do the opposite, starting with discussing programming languages and then painfully skimming through elusive answers to come to the sad truth that the candidate didn't have the faintest idea about databases.
    Latest time I hired, I was able to detect inflated skills within fifteen minutes for each candidate. Some of them, challenged with the E/R diagram, found a quick excuse to leave immediately.
    This strategy gives me more time to dedicate to the more promising applicants, since I know that when we come to the "chatting" part, some evidence of skills already exists.
    As a final test, to determine how good a candidate is, I ask him/her to document the code just written.
    I don't know if this is the best strategy, but it worked for me.
     _  _ _  _  
    (_|| | |(_|><
      Nice, here's another good site to check out for some programmer interview questions:
Re: Interview with a Programmer
by talexb (Chancellor) on Jan 04, 2002 at 10:12 UTC
    Having been on both sides of the table, a few comments:

    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.

      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.

      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.

Re: Interview with a Programmer
by arhuman (Vicar) on Jan 04, 2002 at 16:23 UTC
    I'm far from an expert, but I've interviewed some people,
    and use the simple same method which worked quite well for me :

    I try to make the candidat comfortable/confident, make him talk a lot,
    and try to only seek/look for the good sides, I'm not filtering the "bad", I'm chasing the "good".

    It's not just rethoric, or "over-kind" attitude let me rationalize this to all of you who think that buziness is buziness
    and that we only have to find to right person for the job, not be 'kind' in anyway.

    • 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...

    Let me give some examples :

    I know linux.
    Q: What distro do/did you use ? what do you enjoy most with this distro ?

    I know SQL/Databases.
    Q: What is your favourite database and WHY ?
    Or if he only uses/knows one : What is your favourite feature, what is the one missing to your mind ?

    Even for those who stay elusive, you can learn a lot without 'examining' them :
    I've written CGI scripts for just about every site in my resume.
    Q: Which one is your favourite ? The one which makes you feel proud. can you tell me more about it ?

    As you see, I ask them to speak about what they say they know,
    and then try to estimate their answer based on what I know, and their way to answer.
    It's not so difficult to check the veracity based on what you know.
    Often simple details that match your personnal experience are enough :
    'mod_perl just run fine, I just got bitten once with a script using __DATA__'
    'The custom server install was a little buggy, especially with the network settings'
    'It took me sometimes, before I remembered the BYPASS_DBA_AUTHORIZATION modif to do in the registry'...

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re: Interview with a Programmer
by IlyaM (Parson) on Jan 04, 2002 at 07:44 UTC
    Company where I worked has following policy:
    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.
    Most candidate were rejected on these steps without interview at all. I belive your programer would not be able to pass them too.

    Ilya Martynov (

Re: Interview with a Programmer
by lemming (Priest) on Jan 04, 2002 at 12:10 UTC

    "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.


        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

(shockme) Re: Interview with a Programmer
by shockme (Chaplain) on Jan 04, 2002 at 08:20 UTC
    Our very own dws has a good perspective on this subject.

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

Re: Interview with a Programmer
by FoxtrotUniform (Prior) on Jan 04, 2002 at 22:13 UTC

    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....


Re: Interview with a Programmer
by mirod (Canon) on Jan 04, 2002 at 06:27 UTC

    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.

Re: Interview with a Programmer
by theirpuppet (Sexton) on Jan 05, 2002 at 07:07 UTC
    Actually, at my company we prefer more complete answers. We often give detailed scenarios and ask how they would go about solving the problem. We also give them a 50 question test covering much of the basics.

    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:

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://136182]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2023-12-02 18:28 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (18 votes). Check out past polls.