With the rise of PHP for rapid intranet development, one sees more and more adverts recruiting PHP developers for serious development/consulting positions. One of the issues which are raised by this is that of testing. How exactly do you go about testing someone’s proficiency in PHP?
It’s not as though PHP is taught at the university level. PHP remains primarily a self-taught discipline, and although one may succeed in slipping PHP into one’s job tasks (via prototyping or constructing a test framework) it remains difficult to evaluate a candidate’s strengths. Certification has certainly gone a long way to providing a means of proving a certain base knowledge, but as of the writing of this article Zend’s certification program seems to be lagging somewhat, with PHP 5 having been released several months ago and no PHP5 certification program in sight.
Moreover, the Zend certification is not a holy grail either, as it suffers from the same pitfalls as any other certification program. In theory it hints that the certified developer has had some experience with the language — and having taken it myself I can attest that it would be quite difficult to have passed it without practical knowledge of how the language works — but that is not really verified. The object of testing a potential developer must instead be to establish that he/she can quickly put together a working, simple web application from scratch. In this way knowledge evaluated not in a question-answer context, but instead in a real-world one. You’ll at least know that the developer can, in fact, get up to speed in a new or existing project.
The other pitfall comes with fielding candidates which have academic credentials in computer science. Obviously there’s nothing wrong with having more extensive computer knowledge, but you’re probably not looking for someone to build a J2EE application. Web development is a fairly restricted field and the methods of development are fairly limited; you probably don’t want to hire a computer engineer and have him learn its limitations.
A good test would be held in two parts:
- An application test, which tests the candidate’s ability to create a simple web application on the fly, and
- A bug-fix test, which tests the candidate’s ability to work with legacy code
The application test
In general terms, the test consists in building a simple application from scratch. The candidate has a certain amount of time to create the application. It seems deceptively simple — I say deceptively, because it’s not quite as simple as it seems.
Job parameters
It is important to set the test parameters clearly, in written form, from the beginning. The aspect of setting a given amount of time, for example, is crucial in testing the candidate’s time-management skills. This simply cannot be done when the time parameter is given as, say, “2.5 to 3 hours”; if the clock is stopped at 2:30, the candidate may not have the chance to complete a crucial piece and end up with a non-working application.
Another important concept is that of milestones. Given a simple requirement it’s very easy for candidates to produce strictly what is asked for; however that only leads to a ‘pass-fail’ paradigm of grading which may well fail to inform you as to who among your candidate pool would be the best fit for the job. To accomplish this it is best to have a project baseline, and then a list of milestones to achieve. In theory whoever completes the most milestones is best for the job. It also provides the candidate with an idea of what can be expected, and which might not be obvious. For example if I sit someone down and ask him to design a site with a two-level user system without giving any information as to what type of back-end is used, he may reasonably assume that he is not expected to perform authentication; however if user authentication is listed as a milestone then clearly he is expected to figure it out.
The list of milestones should be a fairly long one. In theory there should be too much work for the time allotted. This will give the recruiter some idea of the candidate’s time management skills. If the candidate finishes with only one milestone “in progress,” that’s reasonable. More than one, and you’ll know that this can be trouble in a real-world situation.
Among other elements inclued in the job parameters document is the version information on the available tools. Like it or not there is a big difference between PHP4 and PHP5 when it comes to object handling and a variety of other specific areas, so it’s important that the candidate have some idea what to use. Frankly this is information that should be communicated to the candidate ahead of time. A list of available tools should also be included in the job specification. Example of tools include the IDE at use in the work environment, or at least a developer-grade text editor, and an online guide such as the PHP manual (same goes for MySQL as appropriate). The idea is to let the candidate know what’s expected.
Hints & Tips
Tips should be added indicating job parameters which are not, strictly speaking, part of the requirements, but indicate more general criteria for the work to be done. For example:
- If you want to see comments in the code, that should be mentioned. Generally a developer will skip commenting code when given a time-limited test of this type.
- If you like to see HTML code indented, be sure to mention that also. People who create and review HTML code all day don’t need this, but obviously a quick review of code will be enhanced by proper indenting. The best case is really to use an editor which indents code automatically if it’s important.
- If there is something in particular you would like the candidate to do — such as use object-oriented programming instead of procedural programming — it is best to indicate it. Otherwise you’re basically just hoping that the candidate will correctly guess what you want, which isn’t a very smart way of going about it.
Judging the results
Giving the test is only half the answer. Correctly judging the results of said test is also extremely important. Merely assuming that you’ll “know good when you see it” is a terrible approach that will more likely than not give you something different from what you want. From a candidate’s point of view it looks unprofessional when four reviewers are unable to agree whether an objective was accomplished or not, and even worse when a reviewer is just wrong about one or more accomplished objectives and has to be corrected. That just looks amateurish.
Where possible, all reviewers should be looking at the resulting code together. This way it’s impossible for some to miss certain aspects that others have noticed.
Ahead of time there should be a concensus as to what accomplishing each milestone actually means. It’s important that this sort of thing be pre-determined, if only to avoid disputes at judging time.
To keep everything objective each one of the milestones should be pre-determined to be “worth” a number of points, mostly based on the complexity of the task. Since some milestones or tasks are generally combined to make a functionality block, points should be awarded for completing such a block.
Any disagreements over whether a milestone has been achieved or not must be dealt with among the judges before giving the candidate the results. Otherwise it looks like the judges are “winging it,” and there may be an impression that the question of whether to retain the candidate or not has been made because of other factors.
If necessary a “style” criteria can be established to cover things like code commenting/indentation, as mentioned in the “Hints & Tips” section. However it should be very clear that this section will only account for a very small part of the overall judging.
Finally, in instances where the test contained a MySQL component some time should be taken to review the candidate’s SQL code.
The bug-fix test
This is another simple and not-uncommon test. Essentially the candidate is given a web application to look over; that application contains bugs which are already known and have already been fixed in the “cleaned up” version of the application. Based on bug reports, the candidate is to find the bugs, identify how the correction should take place, and optionally (as a milestone) fix them in the code.
Job parameters
As with the application test, the application should be explained in writing and the candidate needs to be able to look at that introduction before starting the test. Trying to quickly show and verbally explain the application while a candidate looks over one’s shoulder is a tempting and common pitfall; the instructor generally does not have the sort of training needed to do this, and often he may not have the verbal skills to do it either; he may speak too fast, use common jargon, or gloss over aspects of the application which he knows a lot about but which the candidate has little idea of.
The requirements and milestones also need to be set down in writing, as do the milestones. In this case it should be important to note that it is as important for the candidate to be able to explain what the issue is about as it is to be able to fix them.
Obviously in this test there should be as few references as possible to hidden APIs developed in-house, because there is no way an outside candidate could know much about them. Again, there should be a strict and foreknown time limit for this, and that time limit should be respected in a strict manner. This is to avoid unpleasantness later.
Judging the results
Results are judgeable in more of a straightforward way, although it is more interactive than with the application test. The candidate should be called on to show, explain and show fixes for the bug found. Points should be allocated for both explaining and fixing the code, and scoring criteria should be established to determine the quality of the fix offered combined with the explanation given for the fix.
The important thing, ultimately, is to establish the criteria ahead of time and give them a weight that can be mathematically determined.
Conclusion
Remember that this is only a method for testing the candidate’s abilities in PHP, not necessarily a guide for hiring people. Clearly the latter requires more knowledge of personality traits and how well someone can fit in a given team; the former simply measures proficiency in an arbitrary discipline. By reducing the variance of results obtained you will have a better idea of the candidate’s strengths and, hopefully, a better idea of whether you should ultimately hire the candidate or not.