In my career as a software developer I’ve been lucky. I’ve been lucky that finding work has never been terribly difficult. The longest I’ve ever been out of work is a month and a half. Six weeks might seem like a long time, especially in software; in my case I was unfortunate enough to experience a two-week delay in my interviewing thanks to the Snowpocalypse of 2010 and the aftermath of that event. When I’ve actively looked for work I’ve been pretty fortunate to have a good resume, good skills, and most importantly, a strong job market for the particular field I’m in.
What I’ve often struggled with is finding the right job. There are lots of bad jobs out there; many developers are in them. I’ve been in them. You know the type: jobs that have managers who think that being salaried means they own your every waking moment. Jobs with non-compete clauses that would force you out of your profession if they were enforced. Jobs that advertise for “good under pressure” people or “detail oriented” individuals.
During my last job, I occasionally was invited to interview candidates for the web development team. Usually I’d receive a copy of their resume a few days beforehand with the instructions to review it, and I’d take a few minutes to read their resume and usually pop them into Google to take a look at their online presence. Throughout this process I began noticing things that I saw to be mistakes, probably propagated by the avalanche of resume advice that permeates the job seeking culture. This caused me to rethink my own resume, and I’ve wanted to share these things for a while.
It’s important to note here that I see the technical resume (and any resume, really) as a marketing tool. It is, in essence, the brochure that we build for ourselves highlighting what we can do for a customer (that is the employer). But technical resumes, like many resumes, aren’t written that way. Here are three common things I see as mistakes on technical resumes.
Five months ago, I had an opportunity to accept a contract to work at Mozilla as part of the webdev team. There was a match for my skills on a contract basis, and even though it meant leaving permanent employment for the uncertain world of contracting, I knew it was something I would never forgive myself if I didn’t engage. I didn’t know then just how right my decision was, but after spending a week in Portland with the team at OSBridge, I was shown just how right my decision had been.
Mozilla, along with Emma, hosted a party during OSBridge. During the party, we asked attendees a simple question: “What do you want the web to be?” A video was compiled with their responses, which you can view here:
Last week I wrote about all the reasons that recruiters are bad for your career. For a variety of reasons I highlighted the reasons job seekers should avoid enlisting the services of recruiters that solicit them, and the traps that recruiters employ to disadvantage job seekers while improving their odds of collecting a commission.
On more than one occasion, people asked me “if I shouldn’t use recruiters, how should I find a job?” For me, there are a number of strategies I’ve used to find jobs in the past. It’s also worth pointing out that I have never received an offer while using a recruiter, but I have received offers through all of these methods here.
At some point or another, every technical person will conduct a job search. And either by design or accident, they will encounter the nemesis of job searching: The Recruiter. These individuals are employed by companies whose sole purpose is to serve as an intermediary between job seekers and potential employers. Their marketing literature will say that they match you to potential jobs, and since they spend their days looking around for potential job openings, they have a better grasp of whats out there than you do. It’s their claim, anyway.
The big problem with recruiters is that they are typically paid based on two criteria: the salary of the jobs they put people in, and how many people they place. This might sound like a win-win, but really, it’s a win for the recruiter and a loss for the job candidate. What common strategies do recruiters use to lure job applicants, and why are they bad for you? Let’s take a look…
There are a large number of PHPers looking for jobs right now. After having just gone through the process myself, I wanted to put together some of the most common PHP interview questions. These questions are all non-technical, but do represent the soft side of PHP interviewing. I cannot help you if you don’t have the technical skills to answer the technical questions, but answering these questions correctly is often the key to making or breaking your chances with an interviewer who otherwise has fine technical candidates.
Why did you leave your last position?
This question is a hard one to answer, particularly if (like me) your departure was public. However, no employer wants to hear you beat up on another employer. They also don’t want to hear that you “outgrew” an employer (I learned that lesson the hard way). They fear they’re going to be next.