NYCPHP Meetup

[David Krings]

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