November Musings About Hiring Issues

You may have noticed my most recent post was back in October (ouch). That’s because of the past 6 weeks, I’ve been out of town 5. With that much travel, something has to go, and some of my blogging is it.

In any case, I hadn’t stopped thinking about hiring issues, I just momentarily stopped writing about them. So, here are the musings from my hiring notes for the month of November:

  • Some hiring managers are still stuck on alphabet soup for potential candidates. Remember that technical people tend to learn new technologies quickly. Don’t make technical experience the cornerstone of your hiring filters. Perform a job analysis before you decide on which technical skills are really filters.
  • Think about your auditions. I met a number of hiring managers who use pairing in an audition, but don’t pair on projects. Or, they think that testers and developers need the same audition.
  • If you are a hiring manager, don’t decide on a candidate for the team; help the team decide with you, or for you.

I thought I had more notes, but my notes are not arranged by category; they are in chronological order. As I use them, I’m sure I’ll think of more issues.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in hiring strategy and tagged , , . Bookmark the permalink.

7 Responses to November Musings About Hiring Issues

  1. Pingback: Tweets that mention November Musings About Hiring Issues | Hiring Technical People -- Topsy.com

  2. Johanna, since I have 4 positions open at the moment, 2 in management, I’ve been doing a lot of reflection on the feedback on candidates from interviewers. I trust and respect my interview team, but we can’t reject every candidate. Finding a candidate where every wish list item matches is nearly impossible, so I have to prioritize what is the most important to the team that will be working with the candidate. I’ve been reading the book “Good to Great” by Jim Collins (required reading for Sr. Mgmt @ Constant Contact). In this book Jim talks about hiring the right people to put on the bus before deciding where you are going. It supports your thoughts of “Remember that technical people tend to learn new technologies quickly. Don’t make technical experience the cornerstone of your hiring filters.” I’m shifting my focus a bit to zero in on the core competencies and cultural fit aspects of what I need for management and technical leaders in my team, over what their exposure to technology is. Thanks for sharing your thoughts.

    David Jellison, QE Dir, Constant Contact, Inc.

  3. Ross Patterson says:

    I’m back to being a front-line geek again, but when I was a development manager, some of my best programming hires were folks who C# well when I needed Java, or vice-versa. Good programmers are always learning, and can pick up almost anything in reasonable time.

  4. I agree that there is way too much focus on alphabet soup over core competencies. I am also a big fan of pairing on an interview. Pairing provides a great opportunity to figure out how someone thinks, what design skills they have, whether they understand patterns, and how they will work with others. Even if pairing is not part of your day-to-day practices I still think it is worth trying out as an interview technique, assuming the interviewer has solid pairing skills.

    There are some good tips in this article about hiring for an Agile team, including tips from James Shore about the process he has used as well as advice from you regarding communication.

    I am about to enter a hiring phase and am using James’ suggestion of creating a barrier to entry. Since XP is a big part of our developer culture I am asking candidates to provide their understanding or past use of XP practices in the cover letter and how it would pertain to our industry. I will be curious to see what percentage of folks provide that information.

  5. Apparently entering raw HTML is not one of my core competencies. LOL

  6. johanna says:

    That’s ok, I fixed it!

  7. PhilM says:

    I have been in s/w industry since 1983 and I have interviewed a lot of candidates over these years as an engineer/manager in startups and big companies. The culture of peer interviews is getting to be ridiculous, at least in the bay area where I live. So often, engineers conduct these interviews with little clue as to their efficacy. Check out any interview and you will see that many people ask very clever questions (something that may have started with Microsoft’s why-is-the-manhole-round question). The irony is, in almost all cases, the interviewer found this question and the answer with some research and access, but expects the candidate to do the same in an extremely high pressure setting. If the candidate is lucky to have prepared well and has seen the question before, well he comes off looking like a hire. If not, it is a no-hire. This style of interview selects people who have read the same book/blog as the interviewer but not necessarily the ones who will shine as programmers.

    It is even worse for management positions. Just how many people in a team know how to assess a candidate’s management skills? Most management hires are based on prior positions held and essentially try them out. I have seen managers/directors/VPs who have failed spectacularly at their jobs. Some even caused irreparable damage to their companies.

    In reality, how well someone works out as an tech employee is very unpredictable. The only effective strategy for me was to hire people I have already worked with and referrals from people I really trust. In all other cases, it’s been a long drawn effort ending up as a frustrated exercise and hiring someone out of desperation. In my experience, peer interviews are rarely effective in finding the right person. I would say, if your team is rejecting candidates that seem good to you, you will need to do a thorough analysis of negative feedback. I think you will find some interesting things about the interviewer him/herself.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>