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.