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...
[break] 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. Theidea came to me after looking back at the ups and downs of my webcareer over the previous 10 years. As I thought about it more, Irealized that there wasn't a book that spoke specifically to some ofthe things web developers face that may be slightly different fromother career paths.
My initial idea was to write a larger book that spoke to a wideraudience of "web developers", but I decided to tackle at least a firstversion specifically focusing on PHP developers. PHP's become a giantforce in the web industry, and is certainly one of the major skillsmany employers are looking for. Having a more clear notion of who thebook 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 awide variety of PHP technologies out there, and the book gives anoverview of some of the ones you should be aware of. One certainlycan't be an expert at every single technology out there, and I don'tthink many employers expect that, certainly not of early- to mid-stagedevelopers. However, if you're interviewing at a PHP shop and you'venever heard of Zend Studio, or Symfony (or perhaps even something moreesoteric like Xdebug) you certainly stand less of a chance of landingthe job.
Another aspect that I think will help people get an idea of what toexpect when job hunting is the interview section with the hiringdecision makers at some PHP-oriented companies. By getting ano-nonsense look at how these people think - what's important to them,what skills they're looking for, what turns them off, etc. - peoplewill 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 secondstage a few months later of finishing it off then reviewing andupdating some areas. On a second book, I would not leave as much of agap between those phases. I also had some collaborative input frompeople, and if/when I write again, I would try to make an effort tomeet a collaborator in person, if only once. It might seem a minorthing, and maybe not important at all to some writers, but it'ssomething that I'd still like to try to do.
I'd done the whole first draft in OpenOffice, but that's not whatphp|architect uses for publishing, so there was a conversion process(which Elizabeth Naramore handled for me!) and some learning curveassociated 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 muchinput as I could, but there wasn't as great a turnout for this firstedition as I'd hoped. The input I did get, both from the hiringcompanies and from some PHP community members, was great. I'd like tothink that if a second edition eventually comes out, people will havea better understanding of the project and help contribute their inputand 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 bookseries already focused on that aspect, but not specifically focused onPHP. I really didn't have that audience in mind when writing, butthinking about it now, it probably would help some companies.Companies that already have strong tech leadership likely already knowwhat they're looking for. Smaller companies that perhaps inherited aPHP website from a designer who's abandoned them would likely get somebenefit, if only in the tech section, which gives a rundown of some ofthe more current PHP technologies. It would help non-PHP managersdetect 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 becareful when stretching the truth. One of the things I've found hasworked for me (and others I've spoken with) is being at times overlytruthful about your skills, accomplishments and limitations. One ofthe worst things you can do is get hired in under false pretenses, asmore 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 otherfield.
Specific to web developers, have a web-based portfolio accessible fromanywhere, 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 atthat 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 ofthat policy.
If you don't have code samples available, because your work has beenall 'internal' work at previous companies - make your own codesamples. Even if it's just a few code samples, it's going to be morethan 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 codeyou've written and put it online some place, but that can pay offgreatly when looking for that perfect job.


Interview: Michael Kimsal On "php|architect's PHP Job Hunter's Handbook" - Read More...