Archive for December, 2004
When I was in Israel earlier this month, Roy Osherove interviewed me. The interview is hosted at IT Conversations.
Roy asked questions about why I wrote the hiring book, and what people would get out of it. We also spoke about managing projects and managing people, including the biggest mistake I ever made as a manager.
The interview is an hour long. (When Roy interviewed me, we spent close to two hours, so he’s clearly done some cutting and organizing. It sounds great.)
I appreciate you, Roy, for taking the time to organize the questions, edit the interview, and pursue the IT Conversations link. I hope you will let me interview you when I’m in Israel next March.
I appreciate Doug Kaye, the producer of IT Conversations, for his support and guidance, and willingness to host the conversation.
December 30th, 2004
We’re teaching my older daughter to drive. She’s had her permit since late August, and we try to make sure she drives 2-4 hours/week. In reality, that’s not a lot of driving. Just commuting to work most likely takes you 5 hours/week. But this past weekend, my daughter drove back from our ski weekend in Vermont to Boston, in the nor’easter.
Here in New England, nor’easters are a fact of life. In the winter, they dump a bunch a snow, or frozen slush which turns to ice. In the fall and spring, they dump a lot of rain, which sometimes turns to ice. Because some form of precipitation is a common part of driving, New Englanders who learn from their driving experiences tend to be fairly good at driving in snow, ice, and rain. It’s not fun, but it’s doable.
There are people who never learn from their driving experience in snow or ice. Every year, they’re surprised by the snow or the ice, and they drive too fast (or too slow). These people may have plenty of years of driving experience, but it’s the same year repeated over and over again.
Some parents want to protect their kids from driving in treacherous conditions. I have to admit, that was me on Sunday. But Mark said, “Do you want her to learn how to drive in the snow and the ice with one of us in the front seat or by herself?” Ok, Mark is clearly the thinking one here 
You’ve probably met people who claim 5, 10, 17 years of experience doing something, and you’d like to make sure they really do have that experience, not one year of experience several times. If you’re not sure how to detect someone with the same year of experience several times, here are some questions you can adapt for your needs:
- “Tell me about the first time you did that kind of work…”
- “What was similar and different about this last time (use the candidate’s resume for example projects)? …”
- “Tell me a about a new skill you learned.” … “What steps did you take to learn it?” … “How did you know you’d mastered that skill?”
- “How can you tell you’ve learned this skill/technique/practice?”
People who know the difference between the same year of experience multiple times and multiple years of experience have answers to these questions. People who do the same thing year-in, year-out don’t have good answers.
We’re trying to help our daughter gain that full year of experience that the graduated driver’s license requires, without putting her or other people at risk. She’ll have a year of experience driving. She still might not like driving in ice and snow, but she’ll be able to do so. How about you? Can you see differences in your work now and last year? If not, make sure you’re not acquiring the same year of experience all over again. And when you interview people, ask questions to see how a candidate has learned and grown in their work over time.
December 28th, 2004
Take a look at Ask My Advice. If you’re hiring a senior manager, it’s difficult to imagine not using a recruiter. But the recruiter fees can be a heavy tax to pay. But, take A (Anthony?)’s advice:
- Ask why someone would want to work at your company
- Negotiate with a smaller recruiting firm for a smaller percentage by building a strategic relationship with the firm
(BTW, the person who asked the question now has free marketing to help find people.)
December 23rd, 2004
I had dinner recently with someone who said, “We put our candidates through the wringer. First we test them, then we interview them, then we give them another test.” I spoke with someone else whose manager wants an extensive role play to pit candidates against each other (sounds a little like The Apprentice to me). And Keith Ray pointed me towards Permutation Algorithms and Job Interview Questions (scroll down a bit to get to this part).
In addition to the puzzle questions, all of these are techniques to trip candidates, not true auditions. OK, if you are having trouble finding people who know your specific language and you can’t take the time or money to train them (why the heck not?), then maybe some sort of test is acceptable. But not a whiteboard test. People program on a computer. If you want to test their knowledge of a programming language, make the test something they do on a computer. And don’t kid yourself, the test is not an audition. Solving puzzles, particpating in role plays, developing any kind of software that doesn’t reflect your product — all of those are tests — are not auditions. They tell you little or nothing about how the person will work at work.I liked what Kaplan said in his essay
I don’t think quickly on my feet and I get “stage fright”. Even for algorithms that I’ve written many times, like in-order binary tree traversal, I’ve frozen and been unable to recall the algorithm.
Most of us are nervous in an interview and can’t always quickly recall our accomplishments. Rapid-fire interrogations, puzzles, programming algorithms you can look up — all of those are intellectually interesting and not suitable for auditions.If you want to see how a person will work at work, develop a real audition — a technique to see the person’s work behaviors. If you want a programming problem solved, give the person a computer and access to whatever tools that person needs. If you want to extend a design, ok, that’s something that can be done at a whiteboard. (Don’t you find design generally a discussion among people? Wouldn’t you participate in that too?) But whatever you do, give the candidate time to think. People don’t have to solve problems on their feet at work — they have time to think. The faster you want to move, the more time you need to think. When you remove the access to generally available software libraries, time to think, or even discussions on the web, you’re removing the very tools a fine candidate may use daily at work. Why would you do that?
When I test my students in my classes, I use essay questions, because I want to know what they’ve learned. The essay questions take longer and are harder to grade, but they give me insight into what students learned (and what I didn’t teach). Behavior-description questions in an interview are similar. And, auditions, are a form of behavior-description question, except that you can watch the behavior or discuss the results of some work. Don’t make your interviews like multiple-choice tests. You’ll get people who can talk the talk, but may or may not be able to do the work.
December 16th, 2004
I’m in the midst of changing commenting systems, so you can’t see all the old comments. I hope to import them shortly. In the meantime, please use this commenting system to comment.
December 13th, 2004
I’m in Israel this week, teaching project management. In one class, a student asked, “How technical does a PM have to be?” The inevitable answer: it depends.
A project manager needs to understand the dynamics behind the work of the project. I was teaching software (and hardware) project management today. A PM for a software project needs to understand: how people gather and rank requirements, how to ask if the design is done, how to evaluate technical risks as well as schedule risks, what it means to have a configuration management system and how to effectively use it, and the results to expect from testers. The PM needs to be able to select from the varied review activities to choose the review activities for this project. This doesn’t mean a PM needs to know how to do these things in detail, but the PM needs to know how to organize the activities of the project so that all of these things happen.
In addition, the PM needs to rapidly gain an understanding of the domain, specifically problem-space and the architecture part of the solution-space. If you don’t know what problem(s) you’re trying to solve with the project, how can you know when the project is done? And, if you don’t know the architecture, you can’t understand the technical risks. You may not understand all the technical risks, but without understanding the architecture, you don’t even know what questions to ask.
Note that there’s nothing about reading or writing code (or tests) in here. While being a developer or tester may help someone learn the dynamics of software projects, being a good developer or tester does not imply that you will be a good PM. The functional skills are different.
Certainly, a PM can be more technical than this. I don’t see how an effective PM can be less technical than this.
December 7th, 2004
In Handwriting and Your Job Search, Maya refers to It’s All in the Handwriting. Maya, you’ve been had.I wrote about this on the Bostonworks HR blog, see Debunking Graphology.Graphologists (if you can even honor them with a scientific-sounding name) are selling snake oil. I bet your handwriting looks a lot like your mother’s, or your father’s, or one of your grade school teachers, with slight modifications that you’ve made. What a surprise. These were the people who trained you to write, or whose writing you saw most while in your formative years. And, if you’re like me, a turned lefty (my first grade teacher made me sit on my left hand), your writing is sometimes legible. Not enough data to determine what kind of an employee I’d be.People turn to graphology and other “scientific” tests when they can’t figure out how to know if a person will fit the position. Develop behavior-description questions and auditions — they’ll tell you if a person will fit. Graphology is fun for a slumber party. It doesn’t belong at work.
December 1st, 2004