Re: python interview quuestions

Discussion in 'Python' started by James Mills, Aug 6, 2010.

  1. James Mills

    James Mills Guest

    On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <> wrote:
    >> I would like to aquint myself with Python Interview questions

    >
    > This came up a while ago:
    >
    > http://www.mail-archive.com//msg168961.html
    >
    > Most of that thread is still relevant (perhaps throw in some py3l questions
    > too)


    A common thing you can do in interviews is ask
    your interviewee to write (in Python) a solution
    to the "FizzBuzz" problem. Any good competent
    Python programmer should be able to do this
    in 5-10mins (5 if you're good).

    cheers
    james

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Aug 6, 2010
    #1
    1. Advertising

  2. James Mills <> writes:

    > On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <> wrote:
    >>> I would like to aquint myself with Python Interview questions

    >>
    >> This came up a while ago:
    >>
    >> http://www.mail-archive.com//msg168961.html
    >>
    >> Most of that thread is still relevant (perhaps throw in some py3l questions
    >> too)

    >
    > A common thing you can do in interviews is ask
    > your interviewee to write (in Python) a solution
    > to the "FizzBuzz" problem. Any good competent
    > Python programmer should be able to do this
    > in 5-10mins (5 if you're good).
    >
    > cheers
    > james


    Fizzbuzz is annoying in interviews.

    I've never worked at a job where I was under a timer while a group of
    people sat across from me and scrutinized everything I was doing.

    I don't see how it can honestly tell you anything useful about the
    person you're interviewing either. Do you really think that what you
    assume about the interviewee based on characteristics you can infer from
    their solution to be really, honestly true? They might even completely
    bomb the solution and still be a brilliant programmer, but you'll never
    know that if you trust this simple "fizzbuzz" test.

    I've been in those interviews on both sides of the table. Neither side
    was a good experience.

    If a test is necessary, make it a take-home or demand source code if
    they have it. Read their code and judge for yourself the quality of
    their work.

    Any questions in an interview should be the usual "get to know you" type
    stuff. "What was the most difficult challenge you've faced on the job?
    How did you respond?" That sort of thing.
    J Kenneth King, Aug 10, 2010
    #2
    1. Advertising

  3. On Tue, Aug 10, 2010 at 1:44 PM, J Kenneth King <> wrote:
    > James Mills <> writes:
    >
    >> On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <> wrote:
    >>>> I would like to aquint myself with Python Interview questions
    >>>
    >>> This came up a while ago:
    >>>
    >>> http://www.mail-archive.com//msg168961.html
    >>>
    >>> Most of that thread is still relevant (perhaps throw in some py3l questions
    >>> too)

    >>
    >> A common thing you can do in interviews is ask
    >> your interviewee to write (in Python) a solution
    >> to the "FizzBuzz" problem. Any good competent
    >> Python programmer should be able to do this
    >> in 5-10mins (5 if you're good).
    >>
    >> cheers
    >> james

    >
    > Fizzbuzz is annoying in interviews.
    >
    > I've never worked at a job where I was under a timer while a group of
    > people sat across from me and scrutinized everything I was doing.
    >
    > I don't see how it can honestly tell you anything useful about the
    > person you're interviewing either.  Do you really think that what you
    > assume about the interviewee based on characteristics you can infer from
    > their solution to be really, honestly true?  They might even completely
    > bomb the solution and still be a brilliant programmer, but you'll never
    > know that if you trust this simple "fizzbuzz" test.
    >


    The interviews where I've been asked to write code, the interviewers
    had almost no interest in the code I actually wrote. They wanted me to
    think out loud, to see how I approached the problem. To make sure I
    did actually know how to program and not just copy/paste from a text
    book.

    > I've been in those interviews on both sides of the table.  Neither side
    > was a good experience.
    >
    > If a test is necessary, make it a take-home or demand source code if
    > they have it.  Read their code and judge for yourself the quality of
    > their work.
    >
    > Any questions in an interview should be the usual "get to know you" type
    > stuff.  "What was the most difficult challenge you've faced on the job?
    > How did you respond?"  That sort of thing.
    > --


    Now those questions are completely useless for those of us still in
    school. Because almost nothing we've done so far really says anything
    about how we'll do on the job. When I get an interview like that, I
    usually end up with the same 2-3 responses to every single question,
    because those are the only experieces I've had outside of "well I had
    this tough homework assignment".
    Benjamin Kaplan, Aug 10, 2010
    #3
  4. James Mills

    Peter Guest

    Agreed. Although anything that involves "take home" or reading of
    "their" code runs the risk of the candidate presenting somebody else's
    work...

    It was never a good experience being responsible for the hiring of
    somebody based on how well they sell themselves in an interview - some
    people are hopeless "sales people" and yet could be fantastic
    programmers! I mean lets face it, if you were good at selling would
    you still be a programmer? :) I know who makes the most money! Of
    course there is the question of job satisfaction...

    I usually just tried to get a feel for their stated experience and ask
    some questions just to make sure they weren't presenting somebodies
    else's (fictitious even!) resume. You generally make the best decision
    based on a number of factors about each candidate and depend on the 3
    or 6 month "trial" period to weed out any bad mistakes you may have
    made during selection!

    I remember one team I managed had an individual from overseas (I won't
    mention the country or anything) - and therefore background checks by
    HR were not really possible. The person made so many fundamental
    mistakes that I went to the project manager and asked to see the
    resume - there was no way in this world that they had ever done even
    1/100th of what their resume stated! :) Obviously the interviewers
    for that person where completely conned and missed the (what should
    have been) obvious signs that the resume and candidate did not match.
    This was one of the many reasons why I decided on a career change and
    went back to being a dumb and happy programmer! That was 14 years ago
    now and I haven't regretted the decision one single day of that
    time :)

    Peter

    On Aug 11, 6:44 am, J Kenneth King <> wrote:
    > James Mills <> writes:
    > > On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <> wrote:
    > >>> I would like to aquint myself with Python Interview questions

    >
    > >> This came up a while ago:

    >
    > >> http://www.mail-archive.com//msg168961.html

    >
    > >> Most of that thread is still relevant (perhaps throw in some py3l questions
    > >> too)

    >
    > > A common thing you can do in interviews is ask
    > > your interviewee to write (in Python) a solution
    > > to the "FizzBuzz" problem. Any good competent
    > > Python programmer should be able to do this
    > > in 5-10mins (5 if you're good).

    >
    > > cheers
    > > james

    >
    > Fizzbuzz is annoying in interviews.
    >
    > I've never worked at a job where I was under a timer while a group of
    > people sat across from me and scrutinized everything I was doing.
    >
    > I don't see how it can honestly tell you anything useful about the
    > person you're interviewing either.  Do you really think that what you
    > assume about the interviewee based on characteristics you can infer from
    > their solution to be really, honestly true?  They might even completely
    > bomb the solution and still be a brilliant programmer, but you'll never
    > know that if you trust this simple "fizzbuzz" test.
    >
    > I've been in those interviews on both sides of the table.  Neither side
    > was a good experience.
    >
    > If a test is necessary, make it a take-home or demand source code if
    > they have it.  Read their code and judge for yourself the quality of
    > their work.
    >
    > Any questions in an interview should be the usual "get to know you" type
    > stuff.  "What was the most difficult challenge you've faced on the job?
    > How did you respond?"  That sort of thing.
    Peter, Aug 10, 2010
    #4
  5. James Mills

    Roy Smith Guest

    In article
    <>,
    Peter <> wrote:

    > Agreed. Although anything that involves "take home" or reading of
    > "their" code runs the risk of the candidate presenting somebody else's
    > work...


    I expect a candidate to emphasize their positive qualities, perhaps even
    exaggerate a little. The point of a technical interview is to assess
    just how much of each :) What I do NOT expect is outright
    prevarication. I go into the interview with the assumption that the
    candidate is, if nothing else, honest.

    In any case, if the candidate were to submit somebody else's work, it
    would come out pretty quickly as we discussed their code. I suppose one
    question I might ask would be, "Can you explain why, when I copy-paste
    one of your comments into a google search box, your entire program
    appears?"

    > I usually just tried to get a feel for their stated experience and ask
    > some questions just to make sure they weren't presenting somebodies
    > else's (fictitious even!) resume.


    Amazingly enough, that does happen. I once got two resumes in the same
    pile which were word-for-word identical, except for the name on the top.
    I've been around the block a few times, but I was still shocked. I'm
    not sure what was more shocking; that people could be that dishonest, or
    that they could be so clumsy and stupid about it.
    Roy Smith, Aug 11, 2010
    #5
  6. James Mills

    Terry Reedy Guest

    On 8/10/2010 8:08 PM, Roy Smith wrote:

    > In any case, if the candidate were to submit somebody else's work, it
    > would come out pretty quickly as we discussed their code. I suppose one
    > question I might ask would be, "Can you explain why, when I copy-paste
    > one of your comments into a google search box, your entire program
    > appears?"


    Mostly likely because I wrote the original...

    would be my answer.
    --
    Terry Jan Reedy
    Terry Reedy, Aug 11, 2010
    #6
  7. James Mills

    Tim Chase Guest

    On 08/11/10 01:24, Terry Reedy wrote:
    > On 8/10/2010 8:08 PM, Roy Smith wrote:
    >> In any case, if the candidate were to submit somebody else's
    >> work, it would come out pretty quickly as we discussed their
    >> code. I suppose one question I might ask would be, "Can you
    >> explain why, when I copy-paste one of your comments into a
    >> google search box, your entire program appears?"

    >
    > Mostly likely because I wrote the original...
    >
    > would be my answer.


    Unfortunately there are candidates who would give your answer but
    then have trouble with "Then why are the Last-Modified HTTP
    headers showing a date several months before our interview?"
    It's as bad as the phone-interviews I've done where in the
    background I can hear the person on the other end typing my
    questions into a search box and reading off answers. On the
    bright side, those are short interviews... ;-)

    -tkc
    Tim Chase, Aug 11, 2010
    #7
  8. On Tue, 10 Aug 2010 16:44:17 -0400, J Kenneth King wrote:

    > Fizzbuzz is annoying in interviews.


    It's not for the benefit of the interviewee, but for the interviewer.

    > I've never worked at a job where I was under a timer while a group of
    > people sat across from me and scrutinized everything I was doing.
    >
    > I don't see how it can honestly tell you anything useful about the
    > person you're interviewing either. Do you really think that what you
    > assume about the interviewee based on characteristics you can infer from
    > their solution to be really, honestly true? They might even completely
    > bomb the solution and still be a brilliant programmer, but you'll never
    > know that if you trust this simple "fizzbuzz" test.



    I think you've missed the point of the FizzBuzz test. Nobody should judge
    your skill as a programmer from whether you can write FizzBuzz in 3
    minutes during an interview. The test is to weed out the people who
    aren't programmers at all, but think they can bluff their way into a
    programming job.

    Sounds ridiculous, but apparently there are vast hordes of people who can
    barely program "Hello World" applying for programming jobs. One figure
    bandied about -- how accurately, I don't know -- is 199 out of every 200
    job applicants for programming jobs are barely capable of writing a line
    of code.

    http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

    Fizz Buzz and similar tests aim to weed them out, *quickly*, so you can
    spend more time interviewing people who actually are programmers.

    I personally know somebody who got his start as a professional programmer
    through pure bluff. He had read up just enough about the language to be
    able to toss in the odd buzzword, his CV was a masterpiece of
    imagination, and he was applying for a job during the Y2K panic when
    companies would hire anyone who could spell COBOL correctly by the third
    attempt.

    The other reason for starting with something like the Fizz Buzz test is
    precisely to see how the interviewee will react. Do they ask for
    clarification if the question is underspecified? That tells you they're
    smart enough to *notice* when something is underspecified, and confident
    enough to raise the issue in an interview. That's 100 bonus points right
    there. Do they go to pieces? That tells you they don't perform well under
    pressure. Do they argue with you that the question is pointless? That
    tells you that they're very confident, and quite likely arrogant enough
    not to worry about offending a potential employer (and maybe even
    deservedly so). This means they are potentially difficult to deal with.
    That doesn't mean you don't hire them: some people are so good that they
    deserve to be prima donna. But if you're not looking for a prima donna,
    then it's better to find out early, so you don't waste either your time
    or the other guy's.


    > I've been in those interviews on both sides of the table. Neither side
    > was a good experience.
    >
    > If a test is necessary, make it a take-home or demand source code if
    > they have it. Read their code and judge for yourself the quality of
    > their work.


    Getting interviewees to do a take-home problem just means you hire the
    guy who is friends with a good programmer, rather than the good
    programmer.



    > Any questions in an interview should be the usual "get to know you" type
    > stuff. "What was the most difficult challenge you've faced on the job?
    > How did you respond?" That sort of thing.


    I *hate* those questions. For many people, the honest answer would be
    "Nothing I've ever done in my job has been even half as difficult as
    getting through the interview, because I'm bad at selling myself", but if
    you say that, it just sounds like you're trying to bullshit your way
    through the interview.


    --
    Steven
    Steven D'Aprano, Aug 11, 2010
    #8
  9. James Mills

    Roy Smith Guest

    In article <4c6298c1$0$11101$>,
    Steven D'Aprano <> wrote:

    > Sounds ridiculous, but apparently there are vast hordes of people who can
    > barely program "Hello World" applying for programming jobs. One figure
    > bandied about -- how accurately, I don't know -- is 199 out of every 200
    > job applicants for programming jobs are barely capable of writing a line
    > of code.


    By the same token, there are lots of people with advanced degrees in
    computer science who can't code their way out of a paper bag.

    One advantage of the take-home test is that you can prepare the test
    once and amortize the preparation cost over many applicants. It's a big
    investment of time to interview somebody. By the time I get up to
    investing an hour or so of my time on a phone screen, I'd like to weed
    out the obvious rejects as cheaply as possible.

    Even more interesting is to publish some problems on your web site and
    instruct applicants to submit a solution to one of them along with their
    resume. This makes the per-applicant cost to administer the exam
    essentially zero. It also has the nice side-effect of weeding out the
    resume spammers. To be honest, I've never done this, but I've seen
    companies that do. I may try it sometime.

    I still want to see the candidate write some code during the interview.
    This gives me a chance to feed them a problem incrementally and see
    where they take it.
    Roy Smith, Aug 11, 2010
    #9
  10. On Wed, Aug 11, 2010 at 6:04 AM, Roy Smith <> wrote:
    > In article <4c6298c1$0$11101$>,
    >  Steven D'Aprano <> wrote:
    >
    >> Sounds ridiculous, but apparently there are vast hordes of people who can
    >> barely program "Hello World" applying for programming jobs. One figure
    >> bandied about -- how accurately, I don't know -- is 199 out of every 200
    >> job applicants for programming jobs are barely capable of writing a line
    >> of code.

    >
    > By the same token, there are lots of people with advanced degrees in
    > computer science who can't code their way out of a paper bag.
    >
    > One advantage of the take-home test is that you can prepare the test
    > once and amortize the preparation cost over many applicants.  It's a big
    > investment of time to interview somebody.  By the time I get up to
    > investing an hour or so of my time on a phone screen, I'd like to weed
    > out the obvious rejects as cheaply as possible.
    >
    > Even more interesting is to publish some problems on your web site and
    > instruct applicants to submit a solution to one of them along with their
    > resume.  This makes the per-applicant cost to administer the exam
    > essentially zero.  It also has the nice side-effect of weeding out the
    > resume spammers.  To be honest, I've never done this, but I've seen
    > companies that do.  I may try it sometime.


    I can't recall who it was, but I remember being very impressed by a
    company that did a variant of this a few years ago: they put
    programming problems on the sides of pay phones, taxis, etc. with a
    note that said 'If you can solve this, call us'. I have zero doubt
    that they got some top talent that way.

    Geremy Condra
    geremy condra, Aug 11, 2010
    #10
  11. James Mills

    Paul Rubin Guest

    geremy condra <> writes:
    > I can't recall who it was, but I remember being very impressed by a
    > company that did a variant of this a few years ago: they put
    > programming problems on the sides of pay phones, taxis, etc. with a
    > note that said 'If you can solve this, call us'. I have zero doubt
    > that they got some top talent that way.


    Several companies have done that. You might be thinking of ITA
    Software:

    http://www.itasoftware.com/careers/puzzle_archive.html
    Paul Rubin, Aug 11, 2010
    #11
  12. James Mills

    Peter Guest

    On Aug 11, 8:50 pm, Tim Chase <> wrote:
    > On 08/11/10 01:24, Terry Reedy wrote:
    >
    > > On 8/10/2010 8:08 PM, Roy Smith wrote:
    > >> In any case, if the candidate were to submit somebody else's
    > >> work, it would come out pretty quickly as we discussed their
    > >> code.  I suppose one question I might ask would be, "Can you
    > >> explain why, when I copy-paste one of your comments into a
    > >> google search box, your entire program appears?"

    >
    > > Mostly likely because I wrote the original...

    >
    > > would be my answer.

    >
    > Unfortunately there are candidates who would give your answer but
    > then have trouble with "Then why are the Last-Modified HTTP
    > headers showing a date several months before our interview?"
    > It's as bad as the phone-interviews I've done where in the
    > background I can hear the person on the other end typing my
    > questions into a search box and reading off answers.  On the
    > bright side, those are short interviews... ;-)
    >
    > -tkc


    I know we are straying somewhat here :) But as an interviewer way
    back when in the never-never, I used to look at the interviewee's work
    history i.e. 18 months here, 12 months there, 6 months here etc and
    pretty much wipe them from my short-list based on that alone :)
    Because it takes at least 3 months for a programmer to get "up to
    speed" fitting into your company and on your applications, they are
    usually only really productive and really "hitting their stride" at 6
    months - somebody who "job hops" will already be looking for the next
    job by that time!

    I really did't have time to waste on these people - then there was the
    agents fee for finding them for you - big investment for zero return.

    So I would recommend to anybody that they attempt to maintain a stable
    work history in this respect. For example, my personal work history is
    8, 7.5, 8.5, 0.5, 3, 3, 8 (years that is). My current company is
    extremely stable, I enjoy the work, so I don't see any reason why I
    won't be here until I retire (or die at my desk - whichever comes
    first :)).

    Peter
    Peter, Aug 11, 2010
    #12
  13. On 11 August 2010 13:34:09 UTC+1, Steven D'Aprano
    <> wrote:
    > Getting interviewees to do a take-home problem just means you hire the
    > guy who is friends with a good programmer, rather than the good
    > programmer.


    We give a take-home problem. If we like the code we see, we invite the
    candidate to come in and pair with one of our devs in adding a simple
    feature or two to their own code. It's time consuming, but not so time
    consuming as hiring a weak dev.

    --
    Cheers,
    Simon B.
    Simon Brunning, Aug 13, 2010
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim Chase
    Replies:
    0
    Views:
    687
    Tim Chase
    Mar 4, 2009
  2. Steve Holden
    Replies:
    0
    Views:
    390
    Steve Holden
    Mar 4, 2009
  3. James Mills

    Re: python interview quuestions

    James Mills, Aug 6, 2010, in forum: Python
    Replies:
    3
    Views:
    245
    geremy condra
    Aug 7, 2010
  4. Tim Chase

    Re: python interview quuestions

    Tim Chase, Aug 7, 2010, in forum: Python
    Replies:
    7
    Views:
    247
    Terry Reedy
    Aug 9, 2010
  5. reema
    Replies:
    0
    Views:
    243
    reema
    Aug 26, 2008
Loading...

Share This Page