Hawk’s Babble-Log

I took a PHP 5 test recently. I was actually looking forward to it. I had forgotten what it was like to take a test (it’s been a long time).

The first question went something like this:

$a = 1;
echo (++$a * $a++) + $a;

What is the output?

I thought, “This is CAKE!” I got it wrong. That set the theme for the whole test. Throughout the entire test, I was trying to do bit-shifting, modulus, and other math equations in my head. I got ‘em all wrong. I did not get all the questions on the test wrong, just the ones about stuff I don’t use and the ones requiring me to do math in my head. I was never all that great at math, but I understand formulas pretty well. As it turns out, it was a suppressive test. Let me explain…

If I were to go through the documentation for PHP, pick out the most obsecure and difficult items, and then build questions and queries around these, requiring the person to do math in their head, then I would have a suppressive test. Does it test if the person can use PHP to do something useful?

To be fair, not all questions were like this. In fact, I got a simple one wrong. It was the one about the function which converted an array to a string with a string seperator between each element. I chose explode() instead of implode(). I totally got it wrong and realized my mistake after I had hit the submit button. I made this mistake because I was so upset about failing most of the test.

After this test, I began to doubt my own abilities with PHP. I thought to myself, “Well, maybe I don’t really know PHP…” Then I took a look at my products. A “product” is that thing which you were trying to create (or a service), which is complete, and is valuable (can be exchanged for something).

I get products almost every day with PHP. I built a full singles website in L.A.M.P. (Linux, Apache, MySQL, PHP). It works, I just haven’t done anything with it. I wrote it all from scratch. I wrote a mailing list manager in PHP from scratch for work and they love it so much they wrote me a commendation. I wrote a database interface for a specific application in PHP and it works wonderfully. In fact, I can think of about 6 I’ve written, from scratch, in PHP, and they all work. I wrote an online focus-group system composed of about 38 scripts, MySQL on the backend, and about 17,000 lines of code, and it all works. I wrote it all from scratch over many years. I have created web-based systems in L.A.M.P. (from scratch) which I can’t talk about, but which are products. They work, are complete, and are valuable. So I can get products with PHP.

I’m getting so good these days that I can write something, a function, for example, from top to bottom, including an SQL query, make it return the data properly, and it works the first time.

After thinking about my products with PHP, I realized it was a suppressive test. The average for this test is 50%. I got 33%. Some of the ones I got wrong, I should have gotten right. I was upset that I was getting so many of them wrong, and I was on a timer. Being under the gun on a time schedule is always annoying. It’s like playing chess with a time limit; my mind is on the clock, not the game. As it turns out, I should not have been concerned with the time as I had plenty of it.

Much of the test was about bit-shifting. I don’t use bit-shifting except in the config file. I don’t use it in every-day programming. It would have been better to focus on aspects of PHP which were in every-day use. Some of the test was about modulus. I don’t know how to do modulus in my head. Here’s how I use modulus in every-day programming:

$alternating = ( 0 == $count++ % 2 ) ? 'alt_1' : 'alt_0';

… which alternates the background colors of rows so that they are easier to differentiate. Here’s another example:

if( 0 == $row % 10 ) echo $table_header;

If you do a database query and get 10,000 rows of results, then throw them all into a table, you’re going to have a very long webpage. If a person is scrolling down this mile-long list of results and stops on a certain row and says, “Wait a sec here… which column is this?” Now they’re going to have to scroll all the way back up to the top of the list to see the table header and the column names, then scroll all the way back to where they were. To solve this problem, I repeat the table headers every x number of rows (usually 10). This is very useful, I use it all the time. But if you look at the results of my test, you might say to yourself, “This guy doesn’t even know how to use modulus!”

To find out if someone can get products with PHP, give them a task and let them do it in PHP. This is how you find out if someone is competent in PHP.

When in school, I met a guy who could practically ace any test. He did this by memorizing. He’d memorize any datum he could, any datum which might be on a test. He tested very well, got high scores. I never did that, instead focusing on using the material.

This guy I’m talking about, he had a hard time using his material. This is because he didn’t really know it. Instead, he memorized it. So if he were asked to do a task with the material, he could not do it. But he could ace the test! He had trouble applying his memorized data.

When at SpeedyClick (a dot-gone), a network admin was hired to help maintain the internal network. This guy had certifications all over his resume. It was very impressive. No one gave him a task to see if he could do it or to see how he would handle it. He didn’t know his stuff, didn’t know his data. When we asked him to handle a problem, all he could do was restart the server. One time, I witnessed him daisy-chain a bunch of hubs together in a rack. That’s the most inefficient way to connect up a series of hubs, creating the most number of hops and the most collision-prone network path. He probably tested well, but he couldn’t apply his data. We let him go within his first month.

This is the difference between memorizing data, and knowing it. When the rubber meets the road, you should understand your subject, not just memorize the data so that you can pass the test.

While at SpeedyClick, when I was hiring a Perl programmer, I did not give the candidates a Perl test. Instead, I had the person sit down at my station and bang out a Perl script which would output a 10 x 10 grid of random numbers to a browser window. This script only required basic Perl skills to complete. And the random part wasn’t even important. It could have been consecutive numbers. That was not the point. The point was to see if they could perform a simple task in Perl. Some could do it, some couldn’t. Some got up and walked away.

So… if you know your stuff and take a test on it and don’t do so well, don’t get upset. Realize it was a suppresive test and move on.

If you can create products (that work, are complete, and are valuable), don’t let a test shake your certainty. Rock on.