Urb LeJeune wrote:
I've been following this thread with interest. To a certain point I think
you're going about this in the wrong way. Programming is about
problem solving, it's about syntax, that's the easy part. I good
problem solver can use a book to lean the syntax to code a solved
problem. Someone who aces a programming test because they
have memorized a manual is non necessarily a good problem
solver.
I fully agree with that! I worked with many developers and the really
good ones weren't the ones who knew the latest tricks, but who
understood the business.
Try this on a candidate.
Write an algorithm (not language specific code) to do the following:
Players is a variable holding the number of players in a single
elimination tournament. If you loose a match, you're out. The
winner is determined when there is no one left to play.
Output the value of Matches which is a variable containing the
number of matches required in the tournament.
On problem that is non-trivial will have multiple solutions, we
want the most efficient.
Resist the temptation to express the algorithm in PHP or any
other programming language.
Huh? That is a mathematical, statistical problem of half-life periods.
IMHO is not that useful unless providing the logic behind it is
sufficient as an answer.
My objection is about asking for an "efficient solution". I think it is
much more important to stay with Confucius on this: the way is the goal.
I'd say that someone who gets this requests and asks for a pen and paper
to draw a picture is already a good candidate.
Asking for an efficient algorithm and a mathematical approach is
unfortunately in line how programming gets taught these days. No wonder
why people rather get MBAs instead of science degrees. Who wants to get
beaten with the math stick each and every time? Use math and logic if
common sense fails. I met many engineers who where math experts, but too
stupid to operate a screw driver. They could design complex machinery
for a site, but didn't bother checking if the parts would fit through
the doors. I studied EE and would have enjoyed it more (and probably be
better at it) if it wasn't always about some integral to be solved first.
I created quite many scripts that are in no way efficient, but they all
work and I got them to work reliably. When I look at them today I know
at least a dozen ways on how to improve them and do the same with less,
but at the core the path to finding the solution remains the same.
I also tried and dealt with many different programming languages and in
general they are all very similar, excluding machine code and assembler
(means 'real' programming). They all got their decision structures, they
all got their output commands, they typically use pointers for files,
database, etc., they generally all know about arrays. So yes, nailing
someone on a specific programming language doesn't mean all that much.
Although in this case knowledge of PHP is key and the more I look at
that script the more I think it is a good choice. One doesn't even need
to know anything about OOP in order to figure out what it does. Another
option is to ask what the steps are to accomplish this data mining process.
One other intriguing problem I came across recently was this:
I have a set of several file folders. They are all numbered
sequentially. I want to create three independent functions for adding
one folder, deleting one folder, and moving a folder to a new position
and each time end with consecutively numbered folders and have those who
are not affected by the operation keep their names.
Writing the code was somewhat easy after I figured out what I need to do
and in which order. In my case I also had to sync the changes with a
database table, so I had to make sure that one thing worked before doing
the other (I chose to first do the file system stuff, then change the db
record, but the other way around is as good/bad).
BTW, I personally think swapping the contents of two variables without a
temporary variables proves nothing. It's a trick we learned if we studied
assembly language. Tricks do not a good programmer make. When is
the last time you used an XOR is a real program?
Exactly! I think that using the temp variable is a good solution even if
it takes a few bytes more of memory. The days of 64kB RAM are over where
that really mattered. As long as someone doesn't answer this:
$a = $b;
$b = $a;
it is not a lost cause (but some may even stop after the first line!).
Take my example from above with moving the position of one folder within
the set of folders. Need to rename one folder first, then complete the
sequence until the new position for the folder is reached, and then
rename that folder. In case of two folders I have the same problem as
asked with exchanging the variable values. So, how do I XOR folders in a
file system? And how many XORs does it need to accomplish this for the
likely case of having more than two folders?
IMHO, any test that has a direct practical approach is way better than
some question about a nifty, but useless trick. In the end interviewing
and hiring people isn't any different than learning programming.
Practice makes perfect and one just has to be aware of the fact that not
everything works out as intended.
David
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
