Re: python interview quuestions
Gary Herron
> Hi all,
> I would like to aquint myself with Python Interview questions . I am a
> Python Scripter, so if u could orient the pointers in the same
> direction it would be very handy
> Regards
Huh???
Tim Chase
This came up a while ago:
http://www.mail-archive.com/pytho...@python.org/msg168961.html
Most of that thread is still relevant (perhaps throw in some py3l
questions too)
-tkc
James Mills
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"
Tim Chase
> On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase<pytho...@tim.thechases.com> wrote:
>>> I would like to aquint myself with Python Interview questions
>>
>> This came up a while ago:
>>
>> http://www.mail-archive.com/pytho...@python.org/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).
Another common thing you can do on a newsgroup is mention the
"FizzBuzz" problem. Any good competent newsgroup will produce a
multitude of proposed solutions, the majority of which will be
wrong. ;-)
-tkc
James Mills
> Another common thing you can do on a newsgroup is mention the "FizzBuzz"
> problem. Any good competent newsgroup will produce a multitude of proposed
> solutions, the majority of which will be wrong. ;-)
That's actually a very good point! Someone should post this very problem to
this newsgroups/list and see how many active python programmers here
actually "get it right" :) *evil grin*
--james
geremy condra
<prol...@shortcircuit.net.au> wrote:
> On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <pytho...@tim.thechases.com> wrote:
>>> I would like to aquint myself with Python Interview questions
>>
>> This came up a while ago:
>>
>> http://www.mail-archive.com/pytho...@python.org/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).
>
> james
If I had to wait 5 minutes while a candidate tried to solve this
problem I would not hire them.
One minute, fine- maybe you're just a little rusty or nervous, or the
rare person who has to back away from real-world programming concerns
to deal with a trivial problem like this. If English isn't your native
tongue I might double or even triple that. Otherwise, no way- I'm
going to spend more time hanging over your head than you'll save me.
Geremy Condra
James Mills
> 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
Steven D'Aprano
> On Sat, Aug 7, 2010 at 6:28 AM, geremy condra <deba...@gmail.com>
> 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
Roy Smith
> 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.
geremy condra
<st...@remove-this-cybersource.com.au> wrote:
> On Sat, 07 Aug 2010 06:37:05 +1000, James Mills wrote:
>
>> On Sat, Aug 7, 2010 at 6:28 AM, geremy condra <deba...@gmail.com>
>> 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
Tim Chase
> On Sat, Aug 7, 2010 at 6:28 AM, geremy condra<deba...@gmail.com> 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.
>
>
> 7 if you're not very familiar with Python.
While it *can* be done in one line, I'm not sure it's the most
legible solution. Though I must say I like this one-line python
version:
for i in range(1, 101): print ((i%3==0 and 'fizz' or '') +
(i%5==0 and 'buzz' or '')) or i
(adjust "3" and "5" for your local flavor of fizzbuzz)
I'm not sure I'd hire a candidate that proposed this as a
solution in earnest, but I'd have fun chatting with them :)
-tkc
Peter Otten
You mean you'd go for the candidate who took the conservative approach and
got it right:
print 1
print 2
print 'Fizz'
print 4
print 'Buzz'
print 'Fizz'
print 7
print 8
print 'Fizz'
print 'Buzz'
print 11
print 'Fizz'
print 13
print 14
print 'FizzBuzz'
print 16
print 17
print 'Fizz'
print 19
print 'Buzz'
print 'Fizz'
print 22
print 23
print 'Fizz'
print 'Buzz'
print 26
print 'Fizz'
print 28
print 29
print 'FizzBuzz'
print 31
print 32
print 'Fizz'
print 34
print 'Buzz'
print 'Fizz'
print 37
print 38
print 'Fizz'
print 'Buzz'
print 41
print 42
print 43
print 44
print 'FizzBuzz'
print 46
print 47
print 'Fizz'
print 49
print 'Buzz'
print 'Fizz'
print 52
print 53
print 'Fizz'
print 'Buzz'
print 56
print 'Fizz'
print 58
print 59
print 'FizzBuzz'
print 61
print 62
print 'Fizz'
print 64
print 'Buzz'
print 'Fizz'
print 67
print 68
print 'Fizz'
print 'Buzz'
print 71
print 'Fizz'
print 73
print 74
print 'FizzBuzz'
print 76
print 77
print 'Fizz'
print 79
print 'Buzz'
print 'Fizz'
print 82
print 83
print 'Fizz'
print 'Buzz'
print 86
print 'Fizz'
print 88
print 89
print 'FizzBuzz'
print 91
print 92
print 'Fizz'
print 94
print 'Buzz'
print 'Fizz'
print 97
print 98
print 'Fizz'
print 'Buzz'
Well, almost right, but one error per 100 lines at the first try is near-
genius anyway...
Peter
Terry Reedy
>
> You mean you'd go for the candidate who took the conservative approach and
> got it right:
>
> print 1
> print 2
> print 'Fizz'
> print 4
> print 'Buzz'
> print 'Fizz'
> print 7
> print 8
> print 'Fizz'
> print 'Buzz'
Way too verbose. How about
print("1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n
etc.
--
Terry Jan Reedy
Peter
And to hell with the code being maintainable afterwards? :-)
Personally I would FIRE somebody who produced code like this. Assuming
I was a manager or in a position to hire (I used to be in a previous
life), then I would be looking for somebody who was capable of writing
good, solid and MAINTAINABLE code (love those subjective words? :-)).
Realistically, if the application is anything other than trivial then
it will most likely have somebody poking around in it at some stage
who isn't the brightest spark in the firmament. Anybody who produces
nice, readable and straight forward code in my books gets the tick of
approval.
No offence intended, but anybody who tried to prove how "bright" they
are by producing the least number of (unmaintainable) lines of code
would not get past the first interview - unless they were prepared to
sign a contract that guaranteed they would be available to maintain
the application for its entire lifecycle. Generally (in my experience)
people who write code like this don't hang around long - certainly not
long enough to maintain their monstrosity!
Peter
Steven D'Aprano
> On Aug 9, 6:49 am, Terry Reedy <tjre...@udel.edu> wrote:
>> On 8/7/2010 7:53 AM, Peter Otten wrote:
>>
>> > You mean you'd go for the candidate who took the conservative
>> > approach and got it right:
>>
>> > print 1
>> > print 2
>> > print 'Fizz'
>> > print 4
>> > print 'Buzz'
>> > print 'Fizz'
>> > print 7
>> > print 8
>> > print 'Fizz'
>> > print 'Buzz'
>>
>> Way too verbose. How about
>> print("1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n etc.
>>
>> --
>> Terry Jan Reedy
>
> And to hell with the code being maintainable afterwards? :-)
I'm pretty sure both Peter Otten and Terry Reedy were being sarcastic and/
or ironic.
--
Steven
Roy Smith
<388041a0-4bc5-4f65...@l25g2000prn.googlegroups.com>,
Peter <peter.m...@gmail.com> wrote:
> Realistically, if the application is anything other than trivial then
> it will most likely have somebody poking around in it at some stage
> who isn't the brightest spark in the firmament. Anybody who produces
> nice, readable and straight forward code in my books gets the tick of
> approval.
What he said.
The first test of good code is that you can understand what you wrote
six months after you wrote it.
The second test is that you can explain it to some junior programmer a
couple of cubes away from you, two or three years after you wrote it.
The ultimate test is that some poor schmuck, long after you've moved on
to another project (or company), can figure out what the heck you wrote,
ten years later. And, oh, yeah, the junior programmer who you explained
it to in the previous paragraph, may be 9 or 12 time zones away from the
team who is currently maintaining your code, if he's around at all.
Peter
I'm sure you're right - and I repeat that I meant no offense.
My comments were intended in the spirit of what to do or do not do in
an interview for (any) programming job. Peter and Terry just offered
some good examples of what you don't want to do (IMO) :-)
So, I apologise if anybody has taken my comments as a slur on Peter
and/or Terry's posts - they were not intended as such.
Peter
Terry Reedy
>> I'm pretty sure both Peter Otten and Terry Reedy were being sarcastic and/
>> or ironic.
About the most I ever am ;=)!
> I'm sure you're right - and I repeat that I meant no offense.
>
> My comments were intended in the spirit of what to do or do not do in
> an interview for (any) programming job. Peter and Terry just offered
> some good examples of what you don't want to do (IMO) :-)
>
> So, I apologise if anybody has taken my comments as a slur on Peter
> and/or Terry's posts - they were not intended as such.
I was not sure if you were taking me seriously or not, but rather than
be insulted, I am delighted that I gave you an opportunity to both get
something off your chest and say something worthwhile.
When I was hired in part to maintain and extend someone else's work, it
was in pretty good shape and the outgoing person, with more experience
than me, gave me a quick head's about about it. But I realize that many
others have been less fortunate, but of course cannot throw a fit in
their new place of employment, as appropriate as it might seem.
--
Terry Jan Reedy
J Kenneth King
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.
Benjamin Kaplan
> James Mills <prol...@shortcircuit.net.au> writes:
>
>> On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <pytho...@tim.thechases.com> wrote:
>>>> I would like to aquint myself with Python Interview questions
>>>
>>> This came up a while ago:
>>>
>>> http://www.mail-archive.com/pytho...@python.org/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".
Peter
"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 <ja...@agentultra.com> wrote:
> James Mills <prolo...@shortcircuit.net.au> writes:
> > On Sat, Aug 7, 2010 at 4:32 AM, Tim Chase <python.l...@tim.thechases.com> wrote:
> >>> I would like to aquint myself with Python Interview questions
>
> >> This came up a while ago:
>
> >> http://www.mail-archive.com/python-l...@python.org/msg168961.html
Roy Smith
<507f1970-9c15-4200...@a4g2000prm.googlegroups.com>,
Peter <peter.m...@gmail.com> 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.
Rolando Espinoza La Fuente
<pytho...@tim.thechases.com> wrote:
[...]
>> More over, it can be done in just a single line of Python.
>>
>> 7 if you're not very familiar with Python.
>
> While it *can* be done in one line, I'm not sure it's the most legible
> solution. Though I must say I like this one-line python version:
>
> for i in range(1, 101): print ((i%3==0 and 'fizz' or '') + (i%5==0 and
> 'buzz' or '')) or i
>
> (adjust "3" and "5" for your local flavor of fizzbuzz)
>
> I'm not sure I'd hire a candidate that proposed this as a solution in
> earnest, but I'd have fun chatting with them :)
I didn't believe it could take more than 5 minutes, but this took me
~10 minutes,
though I'm familiar with python and I did the FizzBuzz one-liners before:
http://gist.github.com/518370
Well.. I tried to use generators to make it "cool" but changed it for
a test-friendly approach.
I'll find hard to remember the one-liners in an interview and get it right.
Rolando Espinoza La fuente
www.insophia.com
Terry Reedy
> 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
Tim Chase
> On 8/10/2010 8:08 PM, Roy Smith wrote:
>> 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?"
>
>
> 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
Steven D'Aprano
> 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
Roy Smith
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> 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.
Ben Finney
> 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?"
My response: “Ha! That's a trick question; ‘Last-Modified’ is a field in
the header, not a header itself”.
That might lead to the “why are you interested in leaving your current
position” question rather precipitously, though.
--
\ “Courage is not the absence of fear, but the decision that |
`\ something else is more important than fear.” —Ambrose Redmoon |
_o__) |
Ben Finney
geremy condra
> In article <4c6298c1$0$11101$c3e...@news.astraweb.com>,
> Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> 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
Paul Rubin
> 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:
Peter
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
Simon Brunning
<st...@remove-this-cybersource.com.au> 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.