Deciphering Job Descriptions
Raven has a very funny take on what job descriptions really mean.
2 comments August 30th, 2007
Raven has a very funny take on what job descriptions really mean.
2 comments August 30th, 2007
Imagine this scenario. You have a number of openings, some for senior positions. Maybe you even work for a large company that’s highly attractive for potential candidates. To manage the phone screens and interviews, you send out a pre-interview set of questions. There’s a variety of questions, and the last one is about salary.Stop right there. Do not ask the salary question. Ok, maybe you can ask it of someone with up to 5-8 years of experience. Do not ask the question of an almost-senior person, and certainly not a senior-level person.Here’s why. The senior candidate has compensation in many forms: money and stock are just two obvious forms. More senior people may have more freedom to set strategy, both for their domain and for the business itself. They may have learning opportunities that are not obviously covered in compensation. They might have specific time off or the option to take more vacation. Maybe they get to fly business class for flights of a certain duration. (I do; I wouldn’t consider a job that made me fly coach over an ocean.) But senior people are not going to make these demands at the beginning of a salary negotiation. They want to discuss the context of the job with you, before they start asking.If you ask the salary question before you’ve built rapport in a phone screen or in an interview, you’re telling the potential candidate, “We want to save money on your position.” Of course you do. But do you want to save money before you know what the candidate has to offer?Be smart. Save the salary question for a real-time conversation with a technical hiring manager or a technical person. Too often, the HR folks don’t know the value of all the compensation pieces; just the cost.Salary is a complex issue the more senior the candidate. Don’t make it an elimination question for a senior person, unless you really do mean to eliminate people based on salary. And, if you need to make it an elimination question, why are you looking for someone senior?
1 comment August 29th, 2007
Read Sidu’s Avoiding hell at work by spotting Dilbertian job descriptions.Sidu’s on target. That’s why I suggest you do a real job analysis, and write the ad and/or job description with other technical people. People who are not in the industry dumb down the descriptions and ads, and make them worthless for people to filter themselves in or out for your job.
1 comment August 24th, 2007
Last week, at the Agile 2007 conference, I ran a tutorial called “Hiring for an Agile Team.” As part of the tutorial, I ask people to group themselves into threes, where one person interviews, one is the candidate, and one is the observer.It never fails. An interviewer thinks they’re asking one question, but the candidate hears something else. The longer the question, the more likely the candidate is to answer a different question.The session went well, but with all the fire alarms, I didn’t take my normal notes. I’m paraphrasing here what I think the interviewer asked and what the candidate heard:
Interviewer: Think back on your career. Can you tell me about a time you found yourself challenged? What did you do?Candidate: Where have I failed?
The interviewer’s question isn’t bad; it’s just a little much. Here’s one way to make it more clear:
On your current project, have you noticed any challenges?This is a closed question, and gives the candidate a chance to think. It’s also time-bound to the recent past. And, it doesn’t specifically ask for challenges to the candidate.Assuming the candidate says yes, you can use this question next: “Ok, give me an example.” Listen for that answer, and then ask, “Were you able to change the situation that caused the challenges?” Wait for the answer. Assuming a Yes, ask “How?” If a No, ask, “Can you give me an example on this project when you saw a problem and fixed it?”If necessary, walk the person to the project before the current one.
If you keep your questions short and focused on current or most recent projects, you’re more likely to hear an answer to the question you wanted to ask.
Labels: interview
Add comment August 21st, 2007
In Hiring the Best …, I recommend you hire for today’s projects, not for tomorrow’s projects.Now that we are back in a candidate’s market, it’s even more important to hire the people you need now. You can’t tell who you’ll need in the future. That “guaranteed” project? I’ve seen many of them postponed again and again. The plan to hire someone now and make that person a manager in several months? That always takes longer.A more agile approach says, “Here’s what we need to do now. which of the candidates will help us get the work done now?” If these people are good enough to help you finish the work, they’re good enough to learn the new work.
1 comment August 8th, 2007