…“This guy threw lasers, he could throw under tight spots, he had the arm strength, he had the size, he had the intelligence.” Shonka got as misty as a two-hundred-and-eighty-pound ex-linebacker in a black tracksuit can get. “He’s a concert pianist, you know? I really—I mean, I really—liked Joey.” And yet Harrington’s career consisted of a failed stint with the Detroit Lions and a slide into obscurity. Shonka looked back at the screen, where the young man he felt might be the best quarterback in the country was marching his team up and down the field. “How will that ability translate to the National Football League?” He shook his head slowly. “Shoot.”This is the quarterback problem. There are certain jobs where almost nothing you can learn about candidates before they start predicts how they’ll do once they’re hired. So how do we know whom to choose in cases like that?”
That’s the same problem as in technical teams, which is why we try to use auditions. But even an audition alone in front of one person or with a whiteboard is no guarantee of on-the-job success.
Read the whole article, because Gladwell relates this problem to the teacher problem: how do we detect great teachers: it’s not their degrees or strictly technical competence in their field–it’s more about how they engage everyone in the room and how they give feedback (and take feedback, although that’s just implied in the article).
Does that sound familiar to you? Working in a technical team partly about technical competence, because that’s how you get in. But that’s not how you stay in or become successful. You become successful in a job because you know how to help a team to evaluate and make a good decisions, to take and give feedback to peers, to use good judgement. These interpersonal skills are key to becoming successful in a technical job.
You can still be successful technically if you’re not superb at these interpersonal skills. But you can’t manage anything well unless you master enough of these (and other interpersonal) skills. Pay attention to your interpersonal skills in addition to your technical skills.
A bunch of my clients are having trouble filling their positions. They can’t find a bazillion years of Java or .Net or something else.
There is a relative candidate shortage, compared to the candidate glut of a few years ago. But of people start looking for attitude and general problem solving ability and ability to collaborate, they won’t need to look for technical skills. See what Anton says he’s looking for.
You can send someone to a class and they can learn a particular tool. If you then buddy that person with someone else, you’ve got a great coaching/mentoring relationship, and the new person will be up to speed quickly.
But if you don’t hire for the more intangible things, such as initiative or teamwork or problem solving, you won’t find the right people who can make a huge difference in your organization.
Last week, I was in Eindhoven, in the Netherlands. I arrived Sunday afternoon, and my host took me to the Van Abbemuseum, a museum of contemporary art. It was great.I geeked out in the elevator, however. We started at the top floor and went down to the bottom. The elevator had musical accompaniment. A high-pitched voice started at the top and went down to a lower-pitched voice as we descended the floors. I thought this was great, and when I couldn’t hear a break in recording between floors, I decided we’d try a few more combinations. (Luckily, my host had a great sense of humor and wasn’t upset by this We tried a few more combinations of starting at different floors and going up and down so I could reverse engineer the algorithm. I think I understood it. (I’m not sufficiently literate with music description to describe it, sorry.)This kind of curiosity is necessary for developers and testers. I suspect that what we label geekiness is more often curiosity.
“So please enlighten me : how do you decide, with only interviews/auditions, whether a candidate will be a good addition to a team or a disruptive element“
I’m assuming you’ve already asked questions such as, “Tell me about the project you’re on now. … What’s your role on the project? … How much of your time do you work with other people? … How do you work with them? … What have you learned from working with (so-and-so)? … What one thing will you do again? … What one thing won’t you do again? … Why?” or some other combination of closed and behavior-description questions to establish this person’s experience working with others. You’ll learn from the candidate by listening to these answers. Oh, and don’t forget to ask how people work with their office-mates. I may have been hired once on the basis of how I maneuvered my office-mate into cleaning up his part of the office
Once you’ve asked those questions, reconsider how you create technical auditions. Certainly, you need a technical audition for any candidate you’re considering. An audition where someone works alone — debugging, designing, testing, writing, whatever — will provide much more information about a person’s approach to technical problems than any other technique. But maybe you haven’t considered an audition for how people work with each other. This audition is trickier to create, but certainly worth the time you invest.
Let’s take Sorin’s example, of wanting to know whether a person can work well with others or prefers to be a loner. You could create an audition in at least these ways:
Invite the candidate to pair-work. I’ve done this as part of a second round of interviews, after the person has performed an initial technical audition and has passed the first round of interviews. “We’d like to see how you perform as if you were working here. We’d like you to work with Pat and pair-design (or test or write or whatever).” Work with Pat in advance to set up the most suitable product situation. (If you have product where the candidate needs a clearance or to sign a non-disclosure, consider using open-source products for this part of the audition.)
Ask the candidate to participate in some way that mimics the area you’d like to investigate more. If you want to make sure a developer works well with others, ask him or her to participate in a design or code review. You’ll need to provide enough background material for the candidate to be able to intelligently participate.
Consider an extended audition. Especially if the candidate doesn’t have a lot of experience working with people professionally, consider a temporary-to-permanent position. Hire the candidate as a contractor for a specified period of time (8-12 weeks) and provide feedback every week, especially about those interpersonal skills you’re concerned about. (I realize that while this is common in the USA, other countries’ labor laws may not make temp-to-perm an option.)
The key when creating an interpersonal skills audition is to consider which interpersonal skills you want to examine. You’ll create auditions differently if you’re looking for general communication skills than for facilitation skills.
Once you decide how to create the audition, you’ll have work to do. But, once you’ve invested the time to create the interpersonal skills audition, you can reuse the same audition repeatedly.
Sorin’s comment got me thinking. How do you make the decision that a candidate’s technical skills aren’t worth the candidate’s lack of relationship, communication, listening, or some other soft skill? Esther was talking about collaborative teams, so someone who won’t or can’t collaborate is not going to work in your environment. But there are other qualities, preferences, or skills you may not realize you want in a candidate. If you don’t realize you want these in a candidate, you won’t ask about them.
You’ll need to evaluate your environment. In Sorin’s other comment, he said “a hiring manager should look for is the ability and willingness to learn”. I haven’t met a technical environment in which those qualities weren’t necessary. But what if you find someone who knows your technology now, understands your product, has the requisite functional skills, but is not willing to learn a lot more? My answer is: it depends. It depends on how desperate you are for a candidate who can be productive tomorrow, at the expense of the high probability you’ll have to hire someone else in a couple of years.
What’s most important is to consider the qualities, preferences, and skills you require in candidates. Sorin’s right, the perfect candidate doesn’t exist, but knowing the kind of person you want is necessary, so you can make the most appropriate decisions. I have a bunch of qualities, preferences, and non-technical skills listed in my book. (Here are some: initiative, flexibility, tasking preferences, goal orientation, how the person takes on responsibility, teamwork and collaboration skills, facilitation, oral and written communication skills, curiosity, perseverance.) In Buckingham and Coffman’s First, Break All the Rules: What the World’s Greatest Managers Do Differently, there’s an appendix of what they call “talents.” I’m traveling right now, so I don’t have access to their book for examples. As you consider these qualities, preferences, and skills, you’ll need to consider which few are essential and which are desirable. Then you can ask the candidate questions about the essential and desirable skills.
If a candidate can’t meet your environment’s needs for your essential qualities, preferences, and non-technical skills, then drop the candidate. (Yes, be nice Because how a person works is as important to their success in your environment as their technical knowledge.
Most people don’t lie on their resumes or in interviews. However, if you’re not sure about a candidate, here’s a checklist to help you detect the truth about a candidate:
Always check references. I ask for a minimum of three references from a candidate, at least one of which is a manager. Develop a reference checklist or script, so you ask the questions for which you need answers.
Always check the current manager or the employee’s HR department as a reference. If a candidate is currently employed, the candidate may be reluctant to provide his/her current supervisor as a reference. You can always make the offer contingent on an accurate reference of just title, salary, and length of employment. The candidate’s HR rep can supply that information.
If you suspect the candidate is stretching the truth, ask open-ended pointed questions of the reference, “Can you tell me about the candidate’s contribution to that project?”
If a candidate’s background matters enough to you, perform a check on the candidate’s schooling. (If your company is a services firm, the kinds of degrees and schools may matter.)
Verify the candidate held each job listed on the resume for the amount of time on the resume. You can call the HR departments of each company listed on the resume.
Even people who don’t consider themselves out-and-out liars sometimes stretch the truth. If someone claims some number of years of tool, technology, or industry experience, ask pointed questions or use an audition that they should be able to answer
We tried a few more combinations of starting at different floors and going up and down so I could reverse engineer the algorithm. I think I understood it. (I’m not sufficiently literate with music description to describe it, sorry.)This kind of curiosity is necessary for developers and testers. I suspect that what we label geekiness is more often curiosity.
, there’s an appendix of what they call “talents.” I’m traveling right now, so I don’t have access to their book for examples. As you consider these qualities, preferences, and skills, you’ll need to consider which few are essential and which are desirable. Then you can ask the candidate questions about the essential and desirable skills.