[Tutor] Python Interview Questions..

[Alan Gauld]

"Walter Prins" <wprins at gmail.com> wrote

>>> Java just isn't a hard enough language to separate great 
>>> programmers
>>> from plodders (neither is Python, for that matter) because 
>>> pointers
>>> and memory allocation are taken care of automagically.
>>
>> I fundamentally disagree with his stand on this.
>>
> Not sure what you're saying here Alan -- are you saying you consider 
> Java
> "hard enough language to seperate great programmers from plodders"

Yes, I'm saying the language just isn't that significant.

> you saying that you don't agree with the distinction drawn (that 
> some
> programmers are plodders and others are not) or what?

No, there are plodders and greats, but I'm disagreeing about
what constitutes great.

>>  When you're hiring programmers, (Joel says) you want people
>>> who understand what the computer is actually doing under
>>> all the chrome,

Thats where I disagree, you might occasionally need a few
of those, but not often and not many.

> you want people who are smart enough to have actually
> passed classes where they had to do that stuff.

And I do want them to have studied the subject and be
qualified - either by exam or by experience.

> their view as, "you want people who have some understanding of how 
> the code
> you've written will actually ends up being executed by the computer 
> in terms
> of the effective time and space complexity (as well as other 
> potentially
> problematic aspects) of the code."

The efficiency of an algorithm is one thing. The way a computer
executes it? That's much harder to guess since much depends
on the compiler/interpreter. A good algorithm is usually independant
of those things. (So an algorithm that creates zillions of objects in
memory is a bad algorithm and you need to be aware of the impact,
but you don't usually need to be aware of how the computer is creating
those in memory.)

> point: The same pseudocode/algorithm realised in 2 different 
> languages can
> have wildly different performance characteristics depending on the 
> nature of
> the underlying languages and the exact form of the realisation.

I would say slight differences depending on language, the same
algorithm will generally have the same *relative* performance
regardless of language. The quality of the optimiser is likely
to be far more important. And in most real world scenarios
the quality of data structure design and database choice and
network usage are far more likely to cause performance issues
than the code. I'd rather have someone who can design a good
code structure than someone who can write "tight" code any day.

> programmer will never even know unless you have a more
> than superficial understanding of the language you program
> in and have some awareness that these types of issues exist

I'd have agreed with that 10-15 years ago. Nowadays thats
rarely an issue. I haven't had to deal with those kind of issues
in a project for at least 10 years. I've had lots of performamce
issues to resolve, but the code is the last place I look.

> what the different performance characteristics of various
> algorithm classes are.

Here we agree. Redesigning the algorithm (and the data
structures) are far more likely to solve a performance
issue than tightening the code to suit the CPU
characteristics. Tightening code can save a few seconds
tightening the algorithm/data will save minutes or even hours.

Alan G.