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 6:28 AM, geremy condra <> wrote:
    > If I had to wait 5 minutes while a candidate tried to solve this
    > problem I would not hire them.


    Yes you do raise a valid point. It should really only take
    you a mere few seconds or so to write a solution to this.

    More over, it can be done in just a single line of Python.

    7 if you're not very familiar with Python.

    cheers
    James

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

  2. On Sat, 07 Aug 2010 06:37:05 +1000, James Mills wrote:

    > On Sat, Aug 7, 2010 at 6:28 AM, geremy condra <>
    > wrote:
    >> If I had to wait 5 minutes while a candidate tried to solve this
    >> problem I would not hire them.

    >
    > Yes you do raise a valid point. It should really only take you a mere
    > few seconds or so to write a solution to this.


    Yes, but the point is to come up with a solution that is *correct*, not
    merely a solution. *wink*

    Just the mere typing time will be "a few seconds or so", so you're
    leaving zero time for actual thought, let alone running the code at least
    once to test it.

    Personally, I'd rather see how a potential hire *tests* his code than how
    he writes it. Writing code is easy. Testing code is harder. Testing it
    properly is harder still -- it's amazing how many people forget that it's
    not just necessary to test the function on data that *works*, but also on
    data that fails as well (unless, of course, you're happy with function
    behaviour that is unspecified in the face of errors).

    I also want to see when the coder thinks she's done. If I say "Write a
    function that does fizzbuzz", does she assume I want *just* the function,
    or does she ask questions like "Do you want documentation and tests? What
    sort of tests?". Does she assume that because the fizzbuzz function is
    small it doesn't need documentation or testing? The Fizzbuzz algorithm
    itself is the simple part. If I'm hiring a coder, I care more about their
    attitude to documentation and testing than their ability to code up a
    tiny algorithm in five seconds time. I want to see if they are a careful
    coder, or a cowboy.


    > More over, it can be done in just a single line of Python.
    >
    > 7 if you're not very familiar with Python.


    Or if you value readability over conserving newlines.



    Some months ago I wrote a version of FizzBuzz. By the time I read the
    description of the problem, re-read it to make sure I understood it and
    looking for any hidden traps ("seems too simple to me, what have I
    missed?"), wrote a first draft, tested it, fixed a silly typo, and then
    tested it again, it took about 3-5 minutes. I don't believe I have
    anything to be ashamed about that, especially not when I look at the
    number of comments by people who claimed the exercise was so trivial that
    they did it in ten seconds, AND GOT IT WRONG.

    Then I added error checking, tests and documentation, and the whole
    exercise took about 20 minutes. That was probably overkill, but I was
    bored :)

    (At least I didn't turn it into a class.)


    --
    Steven
    Steven D'Aprano, Aug 7, 2010
    #2
    1. Advertising

  3. James Mills

    Roy Smith Guest

    Steven D'Aprano <> wrote:

    > Personally, I'd rather see how a potential hire *tests* his code than how
    > he writes it. Writing code is easy. Testing code is harder. Testing it
    > properly is harder still -- it's amazing how many people forget that it's
    > not just necessary to test the function on data that *works*, but also on
    > data that fails as well (unless, of course, you're happy with function
    > behaviour that is unspecified in the face of errors).
    >
    > I also want to see when the coder thinks she's done.


    Perhaps I'm reading more into your choice of words than you intended,
    but I'm curious what you envision a "coder" does. I think of "coder"
    and a rather low-level job. Somebody who just writes code. I'm
    generally looking for somebody who is more of a software engineer.
    Somebody who is not just writing some code, but who is building a
    product. That means, as you suggest, that it's documented, tested,
    robust, maintainable, portable, all that good stuff.

    > If I say "Write a function that does fizzbuzz", does she assume I
    > want *just* the function, or does she ask questions like "Do you want
    > documentation and tests? What sort of tests?".


    I think this depends on the situation. For writing code at a whiteboard
    while i watched, I'd expect the candidate to concentrate just on the
    code itself. If it was an assigment, as in, "Write a program to do X,
    and mail it to me by tomorrow", I'd expect a much more complete
    treatment.
    Roy Smith, Aug 7, 2010
    #3
  4. On Fri, Aug 6, 2010 at 6:25 PM, Steven D'Aprano
    <> wrote:
    > On Sat, 07 Aug 2010 06:37:05 +1000, James Mills wrote:
    >
    >> On Sat, Aug 7, 2010 at 6:28 AM, geremy condra <>
    >> wrote:
    >>> If I had to wait 5 minutes while a candidate tried to solve this
    >>> problem I would not hire them.

    >>
    >> Yes you do raise a valid point. It should really only take you a mere
    >> few seconds or so to write a solution to this.

    >
    > Yes, but the point is to come up with a solution that is *correct*, not
    > merely a solution. *wink*
    >
    > Just the mere typing time will be "a few seconds or so", so you're
    > leaving zero time for actual thought, let alone running the code at least
    > once to test it.


    I wouldn't let them have access to an interpreter for this either. The
    goal is to see if they can put out something that looks reasonably
    close to a solution; if so, they're probably trainable. Otherwise,
    GTFO.

    > Personally, I'd rather see how a potential hire *tests* his code than how
    > he writes it. Writing code is easy. Testing code is harder. Testing it
    > properly is harder still -- it's amazing how many people forget that it's
    > not just necessary to test the function on data that *works*, but also on
    > data that fails as well (unless, of course, you're happy with function
    > behaviour that is unspecified in the face of errors).


    Absolutely. A great problem for this is the ACM programming challenge
    pig latin translator- it contains a logic error that makes a certain
    case ambiguous. Hire the ones that spot the problem before they touch
    the keyboard on the spot, and put the ones that test for it at the top
    of the heap.

    > I also want to see when the coder thinks she's done. If I say "Write a
    > function that does fizzbuzz", does she assume I want *just* the function,
    > or does she ask questions like "Do you want documentation and tests? What
    > sort of tests?". Does she assume that because the fizzbuzz function is
    > small it doesn't need documentation or testing? The Fizzbuzz algorithm
    > itself is the simple part. If I'm hiring a coder, I care more about their
    > attitude to documentation and testing than their ability to code up a
    > tiny algorithm in five seconds time. I want to see if they are a careful
    > coder, or a cowboy.


    I have things I'd rather do than sit around and watch a candidate
    write tests. If I wanted them to write tests, I'd send them the
    problem before the interview and have them sell me on their way of
    solving it during the interview.

    >
    >> More over, it can be done in just a single line of Python.
    >>
    >> 7 if you're not very familiar with Python.

    >
    > Or if you value readability over conserving newlines.


    I was thinking the same thing.

    > Some months ago I wrote a version of FizzBuzz. By the time I read the
    > description of the problem, re-read it to make sure I understood it and
    > looking for any hidden traps ("seems too simple to me, what have I
    > missed?"), wrote a first draft, tested it, fixed a silly typo, and then
    > tested it again, it took about 3-5 minutes. I don't believe I have
    > anything to be ashamed about that, especially not when I look at the
    > number of comments by people who claimed the exercise was so trivial that
    > they did it in ten seconds, AND GOT IT WRONG.


    Given the expectation of interpreter-ready code rather than just
    logically correct and close enough, 3 minutes isn't insane. 5 minutes
    is still pretty out there, though.

    Of course, getting it wrong doesn't win anybody points.

    > Then I added error checking, tests and documentation, and the whole
    > exercise took about 20 minutes. That was probably overkill, but I was
    > bored :)


    Just maybe ;)

    Geremy Condra
    geremy condra, Aug 7, 2010
    #4
    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:
    693
    Tim Chase
    Mar 4, 2009
  2. Steve Holden
    Replies:
    0
    Views:
    399
    Steve Holden
    Mar 4, 2009
  3. James Mills

    Re: python interview quuestions

    James Mills, Aug 6, 2010, in forum: Python
    Replies:
    12
    Views:
    497
    Simon Brunning
    Aug 13, 2010
  4. Tim Chase

    Re: python interview quuestions

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

Share This Page