About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

Who Created PHP?

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?

About this post

Who Created PHP? was posted on Sun, 18 May 2008. If you liked it, follow me on Twitter or share:


1.Brian Dailey said:

How about, "What other languages do you know?" As a language agnostic developer (who uses PHP primarily for the convenience and widespread use) I find it more important to be a good developer, using whatever tools are at my disposal, than to know the back story of every language I employ.

Hasin's post annoyed me (hopefully I made this obvious in the comments on his blog). As the guy doing the hiring, it's (of course) his prerogative to decide the criteria for hiring. If you need someone that is a PHP cheerleader, then maybe he's on the right track. I'm just not sure his question lends itself to finding good developers.

My point is that PHP is a tool. A means to an end. I have a Craftsman tool set sitting directly behind me, and I've used it to rebuild engines, fix bicycles, you name it, but I don't know who started Crafstman. If someone wanted to hire a mechanic, would they want someone that knew about Craftsman, or someone how to use the tools (whether they be Crafstman or some other brand) to fix a car?

Mon, 19 May 2008 at 03:22:43 GMT Link

2.Chris Shiflett said:

You make a good point, Brian, and I think asking about proficiency in other technologies (languages included) is an example of a better question. (We also take pride in being technology agnostic.)

Out of curiosity, does his post annoy you because of its aggressive nature, or because you think there's no value at all in asking such a question?

Mon, 19 May 2008 at 03:37:37 GMT Link

3.Jordi adame said:

When evaluating candidates I usually ask some PHP and SQL related questions, but we assume any good programmer can answer those questions.

What we really care about is the real life problem questions, "if you had this problem, how would you solve it?, how would you explain your job to a 5 year old kid?" and those kind of questions.

We also ask random nonsense questions like "dogs or cats?, Barcelona or Real Madrid?, if you could (and no one would notice) would you steall $1'000,000.00?" it's amazing the things you learn from these questions.

Anyways, I don't think knowing who created PHP really means you are a good/bad programmer, but it surely shows that you are not really passionate about PHP

Mon, 19 May 2008 at 03:39:55 GMT Link

4.Chris Shiflett said:

Barcelona or Real Madrid?

Barcelona, of course. :-)

Mon, 19 May 2008 at 03:41:46 GMT Link

5.Jonathan said:

I really liked this post. As one might say as a radio show listener, I'm a long time subscriber to your blog, first time commenter :-) I love your blog and hope to see an appearance by you sometime near Dallas.

As an evaluator, this is definitely one way of judging someone's interest and enthusiasm. As a student of computer science, I enjoy learning the history of some languages or technology. I am especially passionate about web development, so I have grinned at the history of the PHP acronym, pondered at Rasmus' 30 Second AJAX Tutorial (and then repondered his use of "AJAX" after reading your entry on the matter), and I have laughed myself to tears at Samy Kamkar's account of the MySpace worm history and his subsequent interviews on the subject. I have especially looked at the PHP history over the years and I could point out Rasmus', Andi's, and Zeev's pictures from a lineup at the drop of a hat. In fact, I could even point out that Zend is formed from Andi's and Zeev's names.

I'd like to think I'm a passionate developer in PHP, but also in Java, which my CS program requires. While I could build spectacular applications in Java just as I could in PHP (though, probably slightly less spectacular), I could not tell you a thing about the name Java. I could not tell you who created it. I could not tell you what year it was created in. However, just as I could with the PHP language, I could detail key concepts and features in Java, including describing what changes between the versions.

I would liken it to math. Like most programmers, I'm very enthusiastic about math. I take higher math courses just for fun and am very proficient and passionate about it. While I know it is very fascinating, I could not tell you much about the history of math or even the key people. I can associate theorems with the men they're named after, but that's just about it. If I did study the history, I don't think I'd be any more passionate than I already am.

The point of all of this is yes, knowing the key people and history would serve as a possible indicator, but it certainly falls short. I would think a much better indicator would be listening to the person and how they speak on the subject. While I could not tell you much about the history of math, I would definitely get very excited detailing "math rushes" I have had, such as when first being confronted with the Monty Hall problem.

(Not very succinct, but hey, I'm very passionate about it :-D)

Mon, 19 May 2008 at 04:15:15 GMT Link

6.Chris Shiflett said:

Thanks for the thoughtful comment, Jonathan, and especially for the kind words.

I have laughed myself to tears at Samy Kamkar's account of the MySpace worm history

Me, too! For anyone who hasn't read Samy's story, take a few minutes to enjoy his detailed account of the first few hours:


The point of all of this is yes, knowing the key people and history would serve as a possible indicator, but it certainly falls short. I would think a much better indicator would be listening to the person and how they speak on the subject.

You make a very good point, and you demonstrate it nicely. :-)

Mon, 19 May 2008 at 04:37:01 GMT Link

7.john said:

Hi Chris. I agree with you... these days things move quickly and I would rather a coder know the specific differences between PHP 4 and PHP 5 than who Rasmus is or who started the jQuery project. Of course I would be duly impressed if a qualified candidate also knew those things... it might prompt me to ramble off into discussions of the old days when PHP was a script library you could use to add "popovers" to your HTML pages.... and test the patience of the potential employee ;-)

Mon, 19 May 2008 at 05:38:04 GMT Link

8.Pádraic Brady said:

I think anyone who shares Hasin's views are being too demanding bordering on psychotic. I mean seriously... I consider myself an above average developer and I probably could not, on the spot, recite PHP's history in its totality. Same for Perl, Java, C, C++, Ruby, Erlang, Javascript, Cobol and any other language I've gotten around to learning (even that VB thing).

I am such a bad developer - please don't hire me because I'm not a history buff, and ergo I am obviously not worthy even if my skills are demonstrable and more than sufficient to do the job.

I will never ask who invented PHP of a candidate. I would hire them for demonstrating skill, not historical general knowledge for the annual pub quiz ;).

P.S. My blog was one of those offline recently. Back up now assuming the DNS has fully resolved globally over the weekend.

Mon, 19 May 2008 at 08:21:57 GMT Link

9.Anonymous Coward said:

Come on, this is the PHP world.

Ruby seems to have this quasi-religious cult about their 'great leader' but PHP?

I think the more professional a technology gets, the less important become the single persons who where at some point deeply involved with it. And that's not necessarily a bad thing.

Mon, 19 May 2008 at 09:13:08 GMT Link

10.Brian Jones said:

In my experience, the most important thing is to get (and keep) the interviewee talking. If you can generally be a good conversationalist and direct the conversation, you can get an amazingly large amount of information about a candidates skills, how they solve problems (technical or otherwise), and how much of their resume is fluff.

There are some techniques for keeping a candidate talking that I've picked up from other good interviewers over the years, and from my experience in sales (in a former life). One good one is to pick something on their resume you want to know more about, and ask about it. Then, whatever the last thing they say is, repeat it back as a question. So if he says "so we had to parse the bin and reallign the IO defragglers" you could repeat back "... parse the bin...?", and off the interviewee will go talking all about it.

I prefer the interview to be a conversation rather than a quiz. I only ask a couple of questions in an interview that have answers that are definitely right or wrong. A conversation allows the interviewee to be more relaxed, and maybe let their guard down a bit and talk "off the resume", which is incredibly revealing. It also lets you know more about who they are as a human being that you're going to have to work with every day.

I also do agree with Brian's point above that I would like to know more about other languages the developer has used. This is something I put a little more emphasis on when interviewing PHP candidates, because PHP has the title for being the first language of probably more people than any other language except for maybe VB. When we advertise for a 'senior php developer', what we *really* want is a 'senior developer with a focus on PHP', and that's much harder to find.

Mon, 19 May 2008 at 12:54:11 GMT Link

11.Tim Stiles said:

I think knowledge of specific personalities involved in open source technologies is not so much a measure of passion or expertise as it is a marker indicating the level of engagement an applicant has with the larger PHP community. To work professionally in PHP and not be able to name founders and experts in the field (or specific disciplines such as security :-) ) may indicate someone who is book learned and perhaps not inclined to keep up with the most recent information. The important part is not so much knowing who these people are as it is to know where they hang out, because most of these names are not merely historical facts, they remain active participants in the course of the communities they helped establish.

Another recent blog entry promoted on php-planet noted that even though PHP may be weak on established "best practices", examination of code from developers taking part in national competitions shows that there are, in fact, best practices in use: they are apparently spread socially (through user groups, mailing lists, blogs and tutorials) rather than through the official documentation or book publication. Knowing names is at least an indicator that the applicant tries to keep up with current trends.

Mon, 19 May 2008 at 14:00:41 GMT Link

12.Federico said:

The problem is not the software developer asking the wrong questions, it's the software developer doing the interview in the first place.

Hasim is a good example of a software developer conducting an interview, and the interview going completely wrong.

So, why do we think that we can hire people? What makes us the expert? What do we know about recruitment strategies, psychology, sociology, body language or human relationships? Yes, those insignificant things that people spent years studying.

A software developer hiring people is like an accountant looking after the server.

Mon, 19 May 2008 at 14:04:40 GMT Link

13.Brian Jones said:

Federico, I have to disagree with that a little bit based on these points, from my own experience (I'm sure others share some of these):

1. The vast majority of interviews conducted by people who are supposed to know how to conduct an interview also go horribly wrong, are conducted "on-the-fly", with no real (apparent) preparation, in a haphazard manner. While it might seem best to keep a sociologist or psychologist or some other "professional interviewer" on staff, the reality is that the frequency with which that actually happens approaches "never".

2. There's nothing wrong with a developer being involved in interviewing candidates. I'm not sure I'd give that developer the "final word" on whether a candidate gets hired, but if that developer has taken it upon himself to learn how to conduct an interview and has proven that he can hire good candidates, and can back up his reasoning well, why not?

3. To add to point 2, if you're a developer (or, really, anyone else) in a position where you'll be interviewing candidates, it behooves you to learn how to conduct an interview, how to assess knowledge, how to evaluate body language, tone of voice, use of language, etc., in the context of performing an interview. If a developer takes the initiative and learns these things (not that you can just read a book to learn them, but that's certainly a start), there's no reason a developer can't perform a successful interview and hire good candidates.

My $.02.

Mon, 19 May 2008 at 14:26:31 GMT Link

14.Daniel said:

At work, we use https://vx.valex.com.au/tests/season/

It covers off all of the tools we use day to day, has a few domain specific things thrown in, has some obvious errors, has some not as obvious errors...

It really really helps weed out those that have skills from those who don't.

It also shows you a lot about how they work, and their attitude.

Mon, 19 May 2008 at 15:55:32 GMT Link

15.Geoff said:

I read somewhere recently in an article on memory that experts in certain fields (such as programming or chess) can recall large quantities of "stuff" because they break it down into idiomatic patterns. for example, it might be hard for us to memorize 130 moves in chess, but for a master it might actually be many fewer patterns (sicilan defense... to boden's mate... to...).

anyway, the article was mostly about chess, but it mentioned as an aside that programming expertise has been (somewhere) measured by the amount of a program a person is able to reproduce. since reading that, I've wanted to present an interviewee with a short but idiomatic program, let them look at it for a few minutes, then ask them to write it again. just as an experiment, nothing serious - there's a lot more to hiring a good programmer than performing tricks like this (or answering sly questions, for that matter :)

Mon, 19 May 2008 at 19:24:13 GMT Link

16.Chris Shiflett said:

Federico, I agree with Brian. It makes sense for a developer to interview another developer. Those who lack proficiency themselves are not qualified to evaluate someone else.

Thanks for the link, Daniel.

Geoff, that sounds like a really neat idea. Thanks.

Mon, 19 May 2008 at 20:02:23 GMT Link

17.Lakshmi Mareddy said:

Chris, Interesting post!

Just yesterday, my husband and I were discussing the very same topic, albeit in a different vein. You would be surprised as to how people 'prepare' for interviews. We both agreed that we would probably flunk all these wonderful interviews. , as our book knowledge is not very good. Most college types and newbies do very well in such interviews.

I have to my amusement seen a laundry list of such "interview questions" being flouted. And if the interviewer also happens to have one such list in his hand, Im pretty sure, (and no offence here), that even you with your excellent experience, may flunk such interviews:)

In a typical hire we look at different kinds of people. The right fitment of these people to the jobs at hand makes an excellent HR manager.

Knowing guru names behind technologies tells me that either you are very interested, or have a good head for names and trivia (therefore more tech marketing material than developer) or specifically learnt 'Rasmus' and carefully drop it especially if Hasin is interviewing :) (Smart and know what to do, therefore will not stay long here.. etc.)

I just feel that Hasin is looking at passionate in a very warped way. There are several signs to indicate passion, and other soft skills such as aim to please, learning curve etc. that I feel is more critical. We can always look up Rasmus' name, but cannot look up a better team player :)

Tue, 20 May 2008 at 04:53:20 GMT Link

18.Asanka Dewage said:

I believe that the market saturation of a particular language/product also makes a difference. This is speaking relative to the time one starts programming.

For example, when I entered programming, PHP and MySQL are already standard, I read history a bit, yet my focus is getting to know the functionality. The language itself have become something like a "wheel" or a "toaster", you just use it without digging deep.

When I discovered jQuery, I knew programming well enough and I felt respectful for the person who came up with the framework that make me look like a genius to my fellow workers, so I made an effort to learn about him. In my opinion, jQuery is not as widespread as PHP is.. yet. In 6 years time, the newcomers will not know about John Resig, however, they will know jQuery by its 'color'.

When interviewing web developers, I tend to ask questions like "What is your favourite FireFox extension?" and I expect the answer to be "FireBug" or the "WebDeveloper Toolbar". This doesn't show any proficiency of any sort, however, any web developer will tell you how FireBug can be a "lifesaver" .. but who is Joe Hewitt ..?

Tue, 20 May 2008 at 12:34:15 GMT Link

19.Federico said:


Yes, I agree that a developer should be part of the interview process to help measure job-related attributes, but based on my experience a developer should not conduct an interview all by himself. How does he measure passion or motivation? How does he judge attitude, ability, team work, honesty or personality? Does a developer know that a motivated person is easier to train than a qualified person is to motivate? I mean, knowing the difference between print and echo, or the history of a programming language, it's just half of the story. If we fail to see beyond the technical skill, it's possible that we'll also fail to hire the best person for the job.

Great post, interesting debate.

Tue, 20 May 2008 at 15:18:24 GMT Link

20.Chris Shiflett said:

Thanks for clarifying, Federico. I think it makes sense for both types of people to be involved in the interviewing process. (I think the same can be said for the entire recruiting process, in fact.)

Tue, 20 May 2008 at 15:25:54 GMT Link

21.Darryl Patterson said:

As an employer, I like to hold 2 rounds of interviews. The first interview, I'm looking for 2 things: general PHP knowledge, and personality. For round 1, I ask these kinds of questions (I shortened them for this post):

1) How long have you been coding?

2) The hardest developer job?

3) What size of teams? What roles in the team?

4) Follow any coding standards?

5) Experience with multi-lingual sites?

6) A few security questions (XSS, injection, etc)

7) Questions about design patterns

8) Long & short terms goals

The first interview is quite casual, and as suggested by previous comments, I try and get the candidate to talk.

2nd interview, I actually give a PHP test, on paper. The test has a range of questions and is designed to take a competent PHP dev about 20 minutes... I give them 30 minutes. I then sit down with them and go over the answers with them, very much like a code review would run. This give me a sense of how well they handle pressure, as well as the kinds of co-operative criticism they receive during a code review... some folks can get downright hostile. ;)

Tue, 20 May 2008 at 19:41:58 GMT Link

22.Andrew Ellis said:

I personally have never been in the position to hire someone, but I have been asked two questions in particular that I felt really encompass a lot of what is needed to be a good developer.

The first question was an extremely difficult one, that I don't actually remember. The point of it was to get me to say that "I don't know, but I can google it." The person in charge of hiring wanted to see that a new hire was capable of solving problems without direction and using common resources.

The second question was "Are you a rockstar programmer?" Again, this was testing less of my actual knowledge and more how I dealt with problems. After getting the position I asked why they asked this and was told "we want people who are self confident and are willing to tackle any problem, if you said 'no' we would know that you weren't the sort of programmer we were looking for."

Mon, 09 Jun 2008 at 14:33:07 GMT Link

23.Anupom Syam said:

I have already commented on hasin's post. My personal thought is very much like mr. rasmus himself. This is what he said on hiring PHP developer -

“PHP is not a new language. It doesn’t introduce any new concepts. This means that training programmers who already know any C, C++, Perl, or even Java to write PHP code is quite easy. I tend to look for people with C or C++ skills when I go looking for PHP developers for a project, the thinking being that you are much better off hiring experienced programmers than you would be if you hired someone who necessarily knows a lot about PHP. If they can handle those languages, PHP will be trivial for them. Of course, if they have experience with both, so much the better.”

- from one of his infamous article, “Do You PHP?”

I second his opinion!

Tue, 10 Jun 2008 at 04:17:07 GMT Link

24.Eric Marden said:

Interesting question for an interview. We are always trying to root out the passion, and also prove some technical chops. I may start asking this question (and some of the others listed above), but won't use it as a make or break. It just lets me know if you eat, sleep and breath PHP or not. Depending on the position, this may be important.

Good topic!

Mon, 16 Jun 2008 at 02:02:44 GMT Link

25.Tim said:

Although it's not a defining quality or a representation of your skills, history is important especially in your chosen profession. It may give no advantages other than being knowledgeable but it's certainly a good asset to have.

As to whether I'd use that type of question in an interview, I don't think I would unless the job really warranted it which would most likely not be the case for most jobs. Perhaps if you were expected to liaise the those head figures or the ongoing development team then maybe it would form some importance. Personally I like to try to get and know the person and understand their motives for applying to a job position first followed closely by the assessment of their skills, if I can't get on with a person working for me then even if they were the best there is, it simply wouldn't work.

Thanks guys for reminding me about Samy, not laughed at that in a while.

Wed, 25 Jun 2008 at 05:58:41 GMT Link

26.Marcin C said:

Hi Chris,

First of all, great article and discussion.

I'm a fresh graduate, so a bit different point of view regarding to knowing history behind coding skills.

I have a very pragmatic way of doing things and for me this thing with history keeps repeating. Almost always, more less in the middle of the process (learning new coding language or other tech) I start asking myself these historical questions

why this tech was created?

what was initially the problem?

who was the gay that solved it?

what was his background?

And I end up knowing pretty well a maturing process of this technology. Now, this gives a very nice perspective of tech industry which you probably cannot achieve while only coding. Knowing Tech history is also a key to innovation. If you look at problems that technologies were solving in the past, probably you could construct a better solution these days. Many people simply don't care, because they lack this historical perspective, and focus on 'earning money from coding efficiently'.

My personal opinion is that this knowledge is not necessary on the interview process, but it might be helpful of assessing ones large, local perspective and hence problems that this person may solve in work.



Wed, 02 Jul 2008 at 06:54:08 GMT Link

27.Charles Reace said:

Over the years I've come to the conclusion that most of the stock, pop-psychology questions and other prepared questions are of limited use. As a technical interviewer I'm interested in two main things: the applicants' breadth and depth of knowledge plus how well they will fit into our team. I'm really not qualified to measure anything else, and will leave that to the HR folks (all that "what do you want to be doing in 5 years?", or "what is your greatest weakness?" junk).

To that end, after getting the applicant comfortable with a few "simple" questions about their experience or education, etc., I've found the most useful approach to be something along the lines of getting them to tell me about what they perceive to be their most important job-related accomplishments. The important thing then is to dig down into why they feel it was important, what the challenges were, and how those challenges were overcome. You'll learn so much more about how they work and what they know than you will with, "If you could have any job in the world, what would it be?" >_<

Mon, 07 Jul 2008 at 05:30:58 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.