March 5, 2006
I’ll add (or expand on) a few, which are my personal pet peeves. (Disclosure: I’ve yet to be the person with the final go/no-go for a hiring decision, so my pet peeves are often counter-balanced by others with their own pet peeves. I consider this a good thing.)
Back up your skills with experience
My biggest pet peeve is people who list every possible technology that they might have ever touched in the course of their work…and then fail to back up (read: reference) half of those supposed skills in their list of projects. If you must list a skill that you haven’t used for at least a month professionally (um, why?), put it as an addendum at the end under “Additional Professional Interests” or something. Or work it into your short-term goal.
I experimented early on in my career with various resume formats. The ones that worked the best for me even then, as far as getting interviews with teams that fit what I was looking to do, were those that trimmed my skills list back to only those I was most competent in. And at this point in my career, I wouldn’t need to put anything I haven’t done professionally. Anybody who does, with more than 3-4 years experience, is probably not a good team player.
I know people exaggerate, and try to skirt by keyword scanners. But it just always leaves a bad taste in my mouth. There have been times I’ve spent 45 minutes liking somebody, then found out that they included stuff they’ve never used professionally, and all my liking just faded in an instant.
List your specific role within the team/project
I (and my co-workers, actually) have wasted so many interviews over the years just trying to figure out what a candidate’s specific duties were in a project. Even the ones who have nothing at all to hide/exaggerate often fail to utter these four little magic words: “What I did was…”
How I wish that was part of every resume. Some people make a go at it, but it comes out so generic that I still have to ask again in the interview/phone screen.
Even if the most exciting, most successful project was led by someone else, that’s fine. Not that I am interviewing at the present time, but if I were, I would have no trouble at all giving credit to my co-workers for some of the projects I wish I had been more involved in. That’s actually a good sign, in my opinion. If you can talk about what you specifically did, and also give credit to others, it means we’re going to get along.
Be specific about your goal
Interviewing is expensive. Most teams interview when they have specific needs. Don’t be wishy-washy. If you’re the high-level team-lead/manager type who has no real interest in getting your hands dirty in the day-to-day mundane coding necessities…don’t pretend that that might interest you. There’s nothing wrong with thinking about problems at a very high level. Teams need those kinds of people. But it’s just a waste if you try to hide your intentions, and even worse if you try to pretend your coding skills are still fresh.
Learn to love HR
A good HR department is invaluable for screening applicants, because, unless your team is large and your workload light, nobody on your team has the time to screen everybody. I’m not saying they’re perfect, but there is not any perfect candidate screening. Even if you hire by referral only, you often get candidates who aren’t good fits for your needs.
I’ll say this: anybody who comes into an interview with an attitude (seen in the comments of those blogs) like “I make $75 per hour, and that idiot over in HR only makes $12 per hour, so why the hell should I have to answer to him?” is sooo not getting hired on my team. Technical people suffer enough from the “If I were King” syndrome, without allowing blatant economic elitism to run rampant.
So remember these points, too, Future Me, the next time you go looking for a job…
February 4, 2006
I admit it, I suck at interviewing.
My interviews usually fall into a pattern:
- read candidate’s resume
- based on experience level of candidate, make up a couple of coding/design questions
- meet candidate
- completely ignore pre-made coding/design questions
- ask candidate to use the whiteboard to explain the workings of one or two of her previous projects, including architectural diagram, class hierarchies/design patterns, and data model
- shout “oh shit!” when I realize I’m already over my allotted time