Who Created PHP?

18 May 2008

This past week, I noticed several feeds I poll for Planet Chris are broken. In a few cases, it's because the site is offline. In most cases, it's because people don't maintain URLs when they change blog engines. (Hint!)

I've been thinking about changing my feed URLs as well, because /feed doesn't let me gracefully offer more than one. (URL vanity strikes again.) I'll be sure to maintain the old ones, though.

Questioning the completeness of my own planet's coverage, I visited Planet PHP for the first time in a while, and Hasin Hayder's post I don't give you a damn, if caught my eye. Not wanting to be denied a damn, I read the post to learn more. The title completes:

You came to an interview for PHP Developer and you said you don't know the name Rasmus Lerdorf.

He poses an interesting question. How well should someone know a particular technology's history, community, or culture to be considered adequately proficient?

It's easy to draw parallels between this and other debates surrounding indicators of proficiency, such as the Zend certification. A common straw man is to say the indicator alone proves nothing. In this particular case, Hasin's initial comments are strong enough that this argument is understandable, but he later clarifies. Another illogical argument is that we can't possibly know the creator of everything we use. (Examples include the internal combustion engine, the toaster, fire, and the wheel.) Hasin's comments aren't directed at those who use PHP tangentially; he is seeking those for whom PHP is a core competency.

Personally, I look for people who are passionate about what they do, because I want to surround myself with others who enjoy coming to work as much as I do. Knowing Rasmus created PHP doesn't prove passion, but it does make sense to use this as an indicator. I have never asked this question in an interview and probably never will, but I suspect everyone I have hired knows the answer. The real question is whether it's valuable enough to justify asking in an interview. I'm pretty sure there are better questions.

Aside from standard technical questions, what do you do to evaluate candidates? Is there anything you've found to be especially helpful?