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. 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.
@phpdeveloper.org