Warp wrote:

>   As I have commented previously somewhere, I have heard about this here
> as well. What's worse, at least in the past companies actually hired people
> for programming positions just on the basis that those people *claimed* to
> be competent programmers even though they hadn't ever written a single line
> of code.

I don't think this is unique to programming. From what I've seen, most 
managers get hired based on their ability to spout impressive-sounding 
BS rather than their ability to actually manage a department.

>   Why do people apply to programming jobs even though they have no experience
> whatsoever? My guess is that their rationale goes like: "I need a job badly.
> Programming is really easy; heck, even kids can do it, so how hard can it be?
> I'll ensure the job first, and learn the programming part later. It'll
> probably take just a week or two."

I would imagine that quite a few of then know damned-well that they 
can't program, and expect to be able to just con somebody into hiring 
them. I imagine this is the same for every profession.

The difference is that if, say, you claim to be a brick layer, and they 
ask you to build a small wall, and it looks like a piece by Picasso, 
then you don't need to be an expert builder to tell that this person is 
lying out of their arse. On the other hand, a broken program doesn't 
look "obviously" different to a working program. An expert can tell 
immediately, but to the casual observer, it's not so clear. So it's 
harder to tell whether somebody can program.

In a similar vein, there's probably a greater opportunity for 
self-delusion. If you try to build a wall and it's rubbish, you start to 
realise that building a wall is far more complicated than you expected. 
But if your program doesn't compile... it there just some small thing 
you need to fix? Or is it because your code is gibberish?

I'm sure I must have told you the tale of the MSc student who begged me 
to "fix me Java, yah?" He claimed it was nearly working, but it just 
needed a few small tweaks. So I sat down and read his "Java". What he 
had written was a bunch of Java language keywords, lots of curly 
brackets, nice indentation, but... IT WAS NONESENSE! It wasn't Java. It 
was gibberish that bore a superficial resemblance to Java. Lots of 
hopeful-sounding variable names, but not even approaching being 
syntaxually correct.

To this day, I'm genuinely not sure whether the guy was just writing 
gibberish and hoping to bluff his way through (or get somebody to do it 
for him), or whether he actually believed his code was nearly correct...

Finally, if you sculpt a work of art, everybody looks at that and goes 
"oh, that's great, it must have been really hard to make that". It's not 
nearly so obvious that programming is hard. (Especially when vendors 
keep trying to sell whizzy tools that make it all "easy" for "anybody to 
do".)

>   On a side note, interviewers should, on the other hand, be careful with
> what they consider "trivial" assignments. Sometimes a problem might sound
> quite easy and trivial, when in fact it isn't.

If the interviewer asks you to solve the Travelling Salesman Problem so 
that it can find a route between 500 cities in just a few seconds, you 
probably don't want to work for them. ;-)

>   As an example, the basic principle between binary searching (searching an
> element in a sorted array in O(log n) time) sounds quite trivial. However,
> it's surprisingly difficult to implement correctly.
> 
>   Take 100 experienced, competent programmers and give them the task of
> implementing binary search on paper in the programming language they are
> most fluent with, and perhaps 5 of them will give you a correct
> implementation. (The rest will fail in some cases mostly due to off-by-one
> errors.) A correct implementation requires surprising amounts of attention
> to detail, and a quick&dirty naive implementation will most probably be
> incorrect. And this for a piece of program that requires maybe 10 lines of
> code at most.

Hmm, OK. This doesn't sound especially hard. So let me see if I can 
implement it, and then everybody can laugh at how badly I got it wrong...

   find :: (Ord y) => (x -> y) -> y -> IArray x -> (Int,Int) -> Maybe x
   find field target array (base,size)
     | size <  0 = error "invalid subrange size"
     | size == 0 = Nothing
     | size == 1 = if field (array ! base) == target then Just (array ! 
base) else Nothing
     | otherwise = find field target array (base, size `div` 2) 
`mappend` find field target array (base + size `div` 2, size `div` 2)

Now I suppose I better go run that and see if it actually works.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message