With the rise of PHP developer as career, many are trying to get their share in the pie. Lately I've met a number of developers who have worked for more than one/two years in developing PHP applications in various companies and they consider themselves as "senior" developers.

Key things to keep an eye out for are the "more talk, less code" they tend to do and the lack of dedication to the tasks at hand. These bad developers then follow up with the typical blame to the junior developers, noting that it was them being difficult that caused all of the "real" problems.

• Lorna Mitchell (advocating women to get into PHP and the PHP Women group)
• Ivo Jansch's talk
• An interview with Zeev Suraski
• A talk with Marco Tabini of php|architect
• Their own general overview of the conference itself.

Check out all of the videos from Bachelor-ict.nl's list on the Vimeo website.

I recently caught up with Michael Kimsal, author of the newly-released PHP Job Hunter's Handbook from php|architect that can be ordered now in both PDF and print versions. I wanted to get inside his head and find out all about the reasons behind the book, his experience in writing it and any tips he had to share, so I had him answer a few questions. Read on for the interview...

Q: So, first off, what inspired you to write a book for those developers out there looking to land that perfect position?

I had the initial idea in 2006, and had started a draft then. The idea came to me after looking back at the ups and downs of my web career over the previous 10 years. As I thought about it more, I realized that there wasn't a book that spoke specifically to some of the things web developers face that may be slightly different from other career paths.

My initial idea was to write a larger book that spoke to a wider audience of "web developers", but I decided to tackle at least a first version specifically focusing on PHP developers. PHP's become a giant force in the web industry, and is certainly one of the major skills many employers are looking for. Having a more clear notion of who the book is targetted at made it easier to keep the book focused on PHP.

Q: Who is the target audience and how could picking up a copy of the book help them out?

The book is aimed primarily at early-stage PHP developers. There's a wide variety of PHP technologies out there, and the book gives an overview of some of the ones you should be aware of. One certainly can't be an expert at every single technology out there, and I don't think many employers expect that, certainly not of early- to mid-stage developers. However, if you're interviewing at a PHP shop and you've never heard of Zend Studio, or Symfony (or perhaps even something more esoteric like Xdebug) you certainly stand less of a chance of landing the job.

Another aspect that I think will help people get an idea of what to expect when job hunting is the interview section with the hiring decision makers at some PHP-oriented companies. By getting a no-nonsense look at how these people think - what's important to them, what skills they're looking for, what turns them off, etc. - people will have a better idea of how to prepare for an interview process.

Q: How was your experience in writing the book? Any advice to offer potential authors?

The book was written in 2 stages - an early draft, and then a second stage a few months later of finishing it off then reviewing and updating some areas. On a second book, I would not leave as much of a gap between those phases. I also had some collaborative input from people, and if/when I write again, I would try to make an effort to meet a collaborator in person, if only once. It might seem a minor thing, and maybe not important at all to some writers, but it's something that I'd still like to try to do.

I'd done the whole first draft in OpenOffice, but that's not what php|architect uses for publishing, so there was a conversion process (which Elizabeth Naramore handled for me!) and some learning curve associated with that, but not much.

Q: How much outside input did you get for the advice that's in the book (like others in the community)?

Honestly not as much as I would have liked. I tried to get as much input as I could, but there wasn't as great a turnout for this first edition as I'd hoped. The input I did get, both from the hiring companies and from some PHP community members, was great. I'd like to think that if a second edition eventually comes out, people will have a better understanding of the project and help contribute their input and experiences more.

Q: Do you think this book could be used for the other side of the equation (managers not experience in interviewing PHP developers) as a sort of guide on what to look for?

In the course of writing this, I learned there's at least one book series already focused on that aspect, but not specifically focused on PHP. I really didn't have that audience in mind when writing, but thinking about it now, it probably would help some companies. Companies that already have strong tech leadership likely already know what they're looking for. Smaller companies that perhaps inherited a PHP website from a designer who's abandoned them would likely get some benefit, if only in the tech section, which gives a rundown of some of the more current PHP technologies. It would help non-PHP managers detect some technical BS at a bare minimum.

Q: Do you have any "quick tips" of your own to offer to developers headed out to interviews?

While this is pretty simple, it bears repeating: Don't Lie. Even be careful when stretching the truth. One of the things I've found has worked for me (and others I've spoken with) is being at times overly truthful about your skills, accomplishments and limitations. One of the worst things you can do is get hired in under false pretenses, as more often than not this leads to many problems pretty quickly.

Network, network, network. The 'not what you know but who you know' adage still applies in web development as in just about every other field.

Specific to web developers, have a web-based portfolio accessible from anywhere, or better yet, bring a laptop with your code and samples. While it sounds rather obvious, it still seems to be a pretty rare (though growing) thing. I'm suspicious of any company I interview at that refuses to look at my code or online work. To be fair, I *did* take a job once at a company with that policy, but it was in spite of that policy.

If you don't have code samples available, because your work has been all 'internal' work at previous companies - make your own code samples. Even if it's just a few code samples, it's going to be more than most of the competition will have, putting you at an advantage. It may only take you an hour or two to put together some example code you've written and put it online some place, but that can pay off greatly when looking for that perfect job.

During the last six month or so, I've been looking to hire a PHP programmer for at least three companies. I have spoken to quite a few people on the phone, reviewed a bunch of resumes, and even interviewed a few. Out of all those candidates I recommended to hire exactly zero.

Some of the "roadbumps" he experienced along the way include the interviewees inability to write down code without a computer and them giving either the wrong or no answers to simple, common knowledge computing questions. So, he came up with a list of what he calls the "roots of the problem". Included in the list are things like:

• PHP is an ugly language
• PHP is rich with secondary reasons
• PHP is getting mature
• PHP avoidance

Also be sure to check out this response from Nick Jenkins to Leonid's post.

UPDATE: Leonid has also posted a follow-up post with a few corrections and clarifications of the original post.

Here's an interview that Paul recorded with Elizabeth M. Smith, a while back. There's some good info in here on PHP on Windows. Paul & Elizabeth discuss builds, 5.3, and other related topics.

You can grab this latest show in one of two ways - either grab it directly or subscribe to their feed.

Although I am certain that having a PHP certification is not the only way to demonstrate that a PHP developer is really qualified, I am sure that it helps hinting employers about his skills, and so become more open to negotiate better salaries. Having a PHP certification also helps a developer stand out from the crowd of developers that apply to a job but do not have any certification.

In the interview Manuel talks with Mauricio (a Brazilian PHP developer) about whether or not he feels the certification is worth it, how a developer can take it and what they need to do to prepare for it as well as a mention of a book that might help.

Michael Kimsal has also posted some of his own thoughts on the certification issue (and of the comments made during the interview).

From Hasin Hayder's original post:

The reason behind writing this blog post is I've interviewed some candidates recently and They dont know the name of the developers of PHP, MySQL or almost any other libraries they make their living on. They dont even know the history of these tools.

Both Vidyut Luther and Chris Shiflett have posted their opinions on the approach, both supporting his ideas noting that good PHP developers are passionate about what they do. That passion usually shows itself in learning as much as they can about the language, both knee deep in code and in finding out about the community around it.

Christopher Kunz thinks a bit differently, however:

I have to ask myself: What are you guys taking? Are you seriously discussing any kind of name-dropping as an interview subject? It's not only irrelevant who created a programming language, it's even a hindrance for interviewers since all that small-talk bullshit takes precious time off the actual knowledge assessment.

Derick Rethans provides solutions for Internet related problems. He has contributed in a number of ways to PHP, including the mcrypt, Date and input-filter extensions, bug fixes, additions and leading the QA team. He now works as project leader for the eZ components project for eZ systems A.S. In his spare time he likes to work on Xdebug, watch movies, travel and practice photography.

The three usual ways to get this latest show are all still there - just the mp3, using the in-page player or by subscribing to the feed to get this and more great PHP content.

Today I'm going to talk to Zak Greant. Zak's web page tells us: Zak Greant's love of Free Software and Open Source is turning him into a penguin. When not practicing how to waddle or wear a tuxedo, he passes the time running the Foo Associates strategic consultancy and by working with various Free Software and Open Source projects and companies.

There's three ways to grab this episode - the mp3, the in-page player and, of course, the feed you can drop in your aggregator of choice to keep up to date.

Oracle Magazine's May/June 2008 issue contains a "Developer Nation" article. In it, David Kelly interviews Levi Dixon from Community Connect about using PHP and Oracle.

The article references the Oracle/PHP "strange combination" that used to exist and how it's evolved into a vital, living part of Oracle's stack (like with the OCI8 extension).