Would you hire a programmer who was good with technologies, but couldn't
write a quicksort or some other type of recursive algo on demand?

"Mason Verger" <mason_verger@skincare.com> wrote in message
news:0Yj1b.24064$kK4.18927@nwrddc02.gnilink.net...
"Good with technologies"?

A programmer who doesn't understand recursion isn't a programmer; at best
he's a script-hacker. That said, most "programming" jobs are actually
script-hacking jobs.

Regards
David Turner

"Mason Verger" <mason_verger@skincare.com> wrote:
That depends. Is the hypothetical programmer allowed to type quick sort
into google?

I'd expect a good programmer who claims experience of even simple database
work to know that quick sort exists and it's strengths and weaknesses
compared to other sorts.

Bill, not interviewing today.

Mason Verger <mason_verger@skincare.com> wrote:
If you were representing CAD software company, would you hire programmer
who can disassemble -O3 optimized code but has no glue about mechanical
engineering or would you hire mechanical engineer who passed one
semester of C++?

Btw, those recursive algorithms are hard to profile and they are slower,
so maybe you should consider loop-based alternatives.

In article <0Yj1b.24064$kK4.18927@nwrddc02.gnilink.net>, Mason Verger wrote:
can whip up a sort algorithm on demand, but recursivity in general could get
to be a very painful lack in his skills - but not something I wouldn't be
able to work around by assigning tasks that don't involve recursivity until
I've found the time to explain it to him.

If the guy (or gal) has experience on software engineering and meets the
requirements of the job I want him for, I'd probably hire him (but put him
on a three-month probation just in case). Testing is a good idea, but I'd
rather test with real-life examples than re-writing qsort..

<anecdote>
The CEO of my previous company once hired a guy without any testing and put
him in my team. We're in France - the guy didn't speak french (but fortunately
I speak english). He said he was a Java developer - we didn't do any Java
but we needed a Perl hack - he didn't know any Perl.

I asked him to write a simple daemon program in the language of his choice -
he chose C (which I found odd, him being a Java programmer 'n all) and took
about a week to come up with something that didn't compile OOTB and basically
did nothing.

I asked him to write a program to convert a hash table (in Perl) to a C table.
It took me 20 minutes and another developer in my team 30 minutes - but we both
got the job done (and the other developer wasn't a Perl monger either). The
guy the CEO hired because of his experience and qualities as a developer took
eight (8) ours to produce a script that produced a non-compilable C table.
This latter test was after two months of learning Perl.

Finally, I handed him over to another development team - I was still his
manager, but as I didn't have anything for him to do and the other team might,
I assigned all his time to the other team. Thay gave him some first-year-student
level tests to do - he failed all of them. \

We fired him the next day.

All this took three months - mostly because it was, after all, the CEO who hired
him. It cost the company three months of his pay, plus the time I spent teaching
him the basics of Perl (it took a very long time for him to understand hashes).
</anecdote>

Ciao,

rlc

Mason Verger wrote:

I couldn't care less about a programmer who couldn't write a quick
sort from scratch. I would care *greatly* about a programmer who
didn't understand recursion.


--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

Doesn't it depend on what you want them to program?

Would you hire a CSci trained programmer who knows all about sorting routines
to write a Finite Element program to analyze buildings?

It's all relative.

Dan :-)

On Fri, 22 Aug 2003 09:42:54 -0500, Programmer Dude
<cjsonnack@mmm.com> wrote:

Agreed. In fact, unless the programmer wrote a quicksort yesterday,
I'd prefer that he go to a book to refresh his memory before starting.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

"Mason Verger" <mason_verger@skincare.com> wrote in message news:<0Yj1b.24064$kK4.18927@nwrddc02.gnilink.net>. ..
yup. My first day as a programmer, I did not *know* how to write
a quicksort algorithm. my shell scripts never needed it :-)

then I learnt C, and found qsort()

goose,
I dunno how to write the 3-des functions that I use
currently. If the need arises, I will.

"Mason Verger" <mason_verger@skincare.com> wrote in message
anyone who didn't understand it wouldn't be eligible for anything other than
a trainee position.

However writing quicksort on demand isn't a particularly fair test. A really
well-trained university educated programmer ought to be able to do it, but
plenty of perfectly competent people won't know quicksort offhand. In
reality you would probably cut and paste the code anyway.

On [GMT+0100=CET],
Malcolm <malcolm@55bank.freeserve.co.uk> thought hard and spewed:

What about IT programmers who haven't done any hard-core algorithm
programming since college? Why are they disqualified from IT jobs(web
development) because they can't write out a recursive-calculation method on
the whiteboard? You might say that it's reasonable way to see how a
programmer thinks, regardless of the type of development, but I would be
more interested in knowing how well the person understands how to use the
technologies I need to hire for. Of course, if you're talking about some
graphics, games type development, algorithms are vital, but there seems to
be no understanding among hiring managers(particulary at Redmond) that IT
programmers don't really need to know how to implement a hashtable.

From: "Malcolm" malcolm@55bank.freeserve.co.uk

I dunno. What's so fundamental about it? I'd say ( not being a CSci person
) that it's a higher abstraction built on top of more fundamental techniques.
As for understanding how or what a recursive algorithm is and how it might be
useful... that is a no-brainer isn't it? Of course... learning how to write
recursive algorithms efficiently and where they are most useful... THAT is
what I would consider important.

Additionally... quicksort is a perfect example for demonstrating how a
recursive algorithm might be useful. It's also a perfect example for showing
that although a recursive algorithm may look elegant it is often true that a
more complex non-recursive algorithm is much superior.

Dan :-)

On Fri, 23 Aug 2003, Dan Tex1 wrote:
Depends on your viewpoint. From the mathematical point of view, of
course recursion is fundamental! Think of proof by induction. Think
of algorithms on trees. Think of functional programming. Think of
correctness proofs. All of these pretty much rely on "breaking down"
Problem(42) into Problem(6) and Problem(9), and then breaking those
down further, and so on. That's recursion. So from this point of
view, "recursion" is a very basic concept, down there with "lambda
calculus" and whatnot.

From the programming viewpoint, the viewpoint of assembly guys and
compiler writers, yes, recursion is always "built on top of" more
fundamental things like registers and addressable memory, which
combine to give you a stack, which can be used for recursion. Hey,
Fortran got along without recursion completely for a while, didn't
it? and I know that good ol' BASIC didn't recurse. So from this
point of view, "recursion" is an advanced concept, up there with
"lambda calculus" and whatnot.


Define "superior." ;-) I bet it's somewhat easier to prove that
a simple recursive sort is correct, than to prove that a complex
iterative sort is correct. OTOH, it's been said many times that
the iterative one will be faster. Depends on your viewpoint
again.

-Arthur

Malcolm wrote:
Not in the old Fortran and Cobol I remember :-) or even some
assembly languages. Recursion not allowed.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

In article <slrnbkc80n.khh.ronald@localhost.localdomain>,
ronald@landheer.com says...
<snip>

Sadly this scenario isn't rare. I've certainly experienced it myself,
although in my case it wasn't a CEO that did the hiring, but on one
occasion a manager for a group I transferred into right after the hire,
and in another a "director" from a hardware group made an offer to a
recent software grad on one of those (probably now extinct) "college
recruiting job fairs" where they decide that out of all the candidates
they look at, so many "reqs" will be filled that day.

In both cases the employee was a 0x90 (Intel) and had to be plonked.

In article <_Xs1b.1353$X41.672@nwrddc01.gnilink.net>,
mason_verger@skincare.com says...
Empirical evidence suggests the following:
A) Few IT employees have ever done "hard-core algorithm programming".
B) I've never encountered an actual "IT programmer", but there have
been plenty of IT "Meeting Attenders", "Resource Requesters" and
"Schedule Extenders" over the years.
C) They are often located in physical proximity to the marketing
department, which may have something to do with it, but I've never
had the funding to perform a throrough analysis of the topic.

YMMV.

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:3F46C33D.37C87071@yahoo.com...
You can implement a recursive algorithm like QuickSort in a non-recursive
language.
You maintain a stack in an array and do "tail-recursion". It is not required
that the language supports recursion.
How can assembly not support recursion? I don't understand that. It would
mean that you couldn't implement a language that supports recursion on that
CPU. Do you have an example?

Carsten Hansen

Carsten Hansen wrote:
Many older CPUs called subroutines with a JSR instruction, whose
function was to store the return address at the operand address,
and continue execution at the operand address + 1. The subroutine
then returned by executing a jump indirect via its own entry
point. IIRC the PDP8 was in this class.

This was the basic reason that Fortran and Cobol forbade
recursion.

Subroutine assembly code looked something like this:

name: dw 0; here the return address will be stored
code
....
code
jin name; exit

Of course you can build auxiliary stacks. But then you have to
know how much space to assign to those stacks, and bear in mind
that the routines that access them (push/pop) are not re-entrant.
The whole thing becomes a nightmare. All addressing is direct.

You could always build an interpreter for a more reasonable
machine language.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

CBFalconer wrote:
"simulated" trees made from parallel arrays, using ASSIGN'ed
GOTO statements to manage the recursive "returns". Worked great.

Since the tree was a "balanced" AVL tree, and I knew that there
would be on the order of 5,000 nodes, I programmed for no more
that 25 levels of recursion. 25 levels should handle 1,000,000
nodes, so even that modest number of levels gives me some room
for slop...

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

On Sat, 23 Aug 2003, CBFalconer wrote:
Wasn't Knuth's MIX assembler also in this category? My Knuth is currently
in transit (in a box somewhere), but I seem to recall that the above was
the subroutine mechanism used by Knuth too.
As you point out, it's not *impossible* to do recursion on this sort of
machine; in fact, I assume you can simply simulate the x86's PUSH and POP
opcodes with functions, and (after reserving a large enough stack area)
you're good to go. A compiler on such a machine, for a language that
supports recursion, would probably use that sort of "stack simulation."

"Forbid" as in, "undefined behavior" (to use the C term)? Or would it
be caught by the compiler and flagged? Or (simple answer) would a
recursive call turn into an infinite loop? Or (somewhat user-friendlier
answer) would a recursive call merely turn into a jump to the start of the
function again? Just curious.

-Arthur