[Tutor] Python Interview Questions..

[Steven D'Aprano]

Marc Tompkins wrote:

>> And anyone who starts down that road will be weeded out very quickly.
> 
> Not quickly enough!  They should be weeded out IN SCHOOL, or before they
> even commit to a computer-science track.  It's cruel to students,
> inefficient for business, and disastrous for consumers if they don't get
> weeded out until they're already employed as programmers.


I'd like to point out a blog post by Jeff Atwood asking why programmers 
can't program. Not program well, but program *at all*.

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

Actually, the blog post title is provocatively wrong, since Jeff isn't 
*actually* saying that 99.5% of working programmers can't program, but 
that 99.5% of applicants for programming jobs can't write a simple 
beginner program. Or sometimes even a single line of code.

(The correct figure for working programmers is more like 80% *wink*)

Hilariously, about half the people writing in to say they easily solved 
the FizzBuzz problem actually *got it wrong*.

One commenter defended the can't-program-programmers by saying:

"The people who couldn't solve the fizzbuzz test you describe in your 
article, might be great at solving well defined problems."

Presumably he meant well-defined problems *except* the fizzbuzz problem.

Follow the links in Jeff's post for more controversy, hilarity and/or 
analysis of the problem of finding good programmers.


>>  Software can only be written by programmers, its the definition of the
>> term.
> 
> 
> You knew what I meant; don't be coy.  Anybody with a wrench and some pipe is
> a plumber.  Doesn't mean I'm letting him work on my dishwasher.

Not here in Australia you're not. You can only call yourself a plumber 
if you are properly licensed and certified. That usually means having 
gone through *at least* a five(?) year apprenticeship and that they at 
least know that water flows downhill.



> The point I was trying to make, which apparently I didn't state clearly
> enough, was: Professional programmers - I really supported the effort, years
> back, to protect the term "software engineer" - should be familiar with the
> ins and outs of computers, not just with the quirks of the language they are


Well, that depends on what you mean by "familiar". I like to think that 
any good programmer should understand that there *are* hardware issues 
to consider, even if they don't actually know how to consider them. They 
should know about Big Oh notation, and be able to explain in general 
terms why bubblesort is so slow and quicksort is usually fast but 
sometimes becomes slow. If they can actually calculate the best/worst/
average Big Oh running times for a function, that's a bonus.

A good programmer should be aware that hardware caches invalidation will 
make your code run slow, even in a high-level language like Python. A 
*great* programmer will be able to tell you exactly which code will 
invalidate the hardware cache, and what to do to stop it.

But let's not mistake ignorance with stupidity. An ignorant programmer 
may have merely never learned about the difference between O(1) and 
O(2**n) running times, by some accident of education and work 
experience, but still be a good programmer. A stupid programmer still 
writes Shlemiel the painter's algorithms even after having them pointed 
out again and again.

http://www.joelonsoftware.com/articles/fog0000000319.html



> employed to use.  To use my dishwasher analogy from a moment ago, I'm sure
> we've all been visited by the appliance repairman (or auto mechanic, or
> whatever) who only knows how to replace a single component, and who
> therefore sees every malfunction as requiring a new control board.  I don't
> want him either!

Not such a good analogy, since modern consumer goods are getting to the 
point where they are almost unrepairable except by replacing the control 
board. It often costs you *more* to fix a broken widget than to throw 
the machine away and buy a new one, e.g. monitors, TVs, DVD players...

That's also often the case with computers unless you value your time 
very low. In my day job, if I have the choice in paying one of my junior 
techs more than 4 hours to diagnose a flaky piece of hardware, I'd 
rather just hit it with a hammer and replace the likely suspects 
(memory, motherboard... whatever is likely to be causing the symptoms). 
Obviously its a sliding scale -- I don't replace a $14,000 server 
because a hard drive is broken, but neither do I spend three days trying 
to be absolutely 100% sure that a $60 power supply is flaky before 
replacing it.

Coming back to programming, sometimes the right answer is to throw more 
memory at a problem rather than to write better code. A GB of RAM costs, 
what, $100? That's like what, 1-3 hours of developer time? If it takes 
you three hours to lower your application's memory requirements by half 
a gig, you might be throwing money away.

That's partly why we program in Python: use a relatively heavyweight 
language environment (at least compared to C or assembly) that allows us 
to be 10-30 times as productive for the cost of 10 times slower code and 
twice as much memory.


-- 
Steven