Posts filed under 'technical skills'
I’ve been reviewing job descriptions from clients that are a laundry list of tools. Or, that ask for “significant experience” with a particular technology.
No, no, no. People are not tools. They are human beings who have specific qualities, preferences, and technical and non-technical skills.
When you think about those personal qualities, think about these questions:
- With whom does this person work?
- What kind of deliverables does this person have in the short term and the long term?
- What kinds of interpersonal skills does this person need to do their job well?
Take a look at the job analysis template to see more questions. Now you’re ready to think about technical skills.
Here’s how I categorize technical skills: functional skills, subject matter domain expertise (problem-space and solution-space), tools and technology, and industry skills. Of these four areas, functional skills–how good a developer, tester, architect, designer, etc the person is, and subject matter domain expertise–how quickly the person can learn the internals of your system, matter the most. Most people can learn new tools relatively quickly. But it takes much longer to learn how to test first, or use combinatorial testing, or see the whole picture and what can go wrong, and so on. Functional skills require experience, and more than the same year of experience again and again.
When you think about the people you need, think hard about those technical skills, and which skills you really need. Tools, and familiarity with a particular tool may not be as important as the ability to work in small chunks and finish things. Or to explore the product to find really bad defects. Or to see how the system flows–or doesn’t–together.
People are not tools. Look for people, not tools.
Tweet This Post
October 23rd, 2009
I recently spoke with a recruiter. “I don’t understand the QA market anymore. No one is hiring except for agile people. And they want people who are developers. What’s happening to QA?”
Manual testing was never quality assurance; it was testing. And, manual testing is low-value, high cost work, especially when you compare it to automated regression testing. Now, before you assume I mean there is never a time for manual testing, no, I did not say that.
There is a time and place for exploratory testing, which tends to be more manual. There is a time and place for opportunistic testing. But the kind of system-level testing that says “Does this feature meet its acceptance criteria, and does the rest of the system still work and can we know that within a two-week timebox?” is not primarily manual testing. That’s what agile projects need. (If you’re using an incremental or iterative lifecycle, you need to know this too, just not in a two-week timebox.)
That means that agile testers have different technical skills and provide different deliverables (and value to the project) than the kinds of testers this recruiter is accustomed to.
These testers have different functional skills, solution-space domain expertise, and tool capabilities than strictly manual testers. See Four Dimensions of Technical Skill for more information. In agile teams, some of the testers don’t look much different from developers, except that their code doesn’t release. Some of the testers might be better at sitting with a product owner and saying “What does done really look like for this feature?”
Whatever their skills, these testers are multi-dimensional people, capable of much more than manual testing. They are not second class citizens, but are valuable members of the product development team.
For you recruiters, think about what value the testers add to a project team. If you’re a tester, what skills do you need to acquire to provide more value to your project team? And, managers, does this make sense to you? Does knowing about the state of the product often provide you more value than having to wait days or weeks until you can manually finish a test run make more sense?
Tweet This Post
October 2nd, 2009
I just read Most Likely to Succeed: How do we hire when we can’t tell who’s right for the job? by Malcolm Gladwell. He talks about how a football recruiter agonized over his decisions:
…“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.
Tweet This Post
June 25th, 2009
As part of an interview, a reporter asked me what the single biggest mistake managers make when hiring. Unfortunately, I see three common mistakes:
- Hiring based on a tools checklist (some number of years of Java or WinRunner or some other tool) as opposed to hiring someone who can adapt his/her knowledge to the products at hand. This is the biggest one I see.
- Hiring for the future instead of the present. (I see this one almost as much.) Hiring someone who the manager thinks will have the skills to grow into a new/different role in the future. This is different from hiring to create the future.
- Not considering how a new hire will fit into (or not!) the team. People are not just a collection of technical skills. If they can’t get along with the rest of the team, it can be close to impossible to use their technical skills to move the work forward.
I’ve written before about not hiring tools, but hiring people here. If you see a laundry-list job description, go back and separate all the technical skills into the categories that deliver value to the people with whom this candidate will work. And, remember to think about the non-technical skills, such as responsibility, adaptability, initiative, how quickly someone can learn your product, communication skills, all that stuff.
I’ll address the other two mistakes in later posts.
Tweet This Post
November 1st, 2004
Laurent has a great posting on Hiring Programmers. Note that he doesn’t say people have to be great writers. On the contrary, the bar is fairly low: awareness of spelling and typos, introduction, structured discussion, conclusion — that’s it. My kids practice this kind of writing all the time in school (in preparation for the standardized tests they need to pass in order to receive a high school diploma — MCAS for those of you in Massachusetts).
I agree with Laurent, don’t forget to add an audition. But definitely, ask people who need to be able to communicate in writing to write for you.
Tweet This Post
June 1st, 2004
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.
Tweet This Post
April 13th, 2004
There are two kinds of domain expertise: solution-space and problem-space. When a candidate understands the technical issues behind how your product solves the customers’ problems, that’s solution-space domain expertise. When a candidate intimately understands the problems your product is trying to solve, that’s problem-space domain expertise. One kind of domain expertise does not imply the other.Here are some examples:
- A developer has worked on embedded systems before and discusses the merits and tradeoffs of differing architectures with you. The developer has solution-space domain expertise of the embedded systems architectures.
- A writer has documented systems internals before and discusses how she organized the documentation, comparing that to your systems internals. The writer has solution-space domain expertise about internals and how to document them.
- In an audition for a tester on database system, the tester turns to you and asks about the stored procedures and the schema. Based on your answers, the tester modifies his approach to testing. The tester has domain expertise about testing database systems.
These people understand the insides of the product. They understand the implications of how the product is organized (its architecture or design), and the kinds of issues your product team considered when designing or implementing.People with solution-space domain expertise tend to be expert system users, or can learn to be. They understand the problems the customers have, and why solving those problems will benefit the customer.People who can easily learn solution-space domain expertise tend to be more expensive than people who can only learn problem-space domain expertise. As a hiring manager, your job is to determine which candidates require which kind of expertise.
Tweet This Post
March 16th, 2004
In Michael’s comment to When Candidates and Interviewers Disagree About “The Answer” he raised a critically important point: how much does the the candidate know about this issue and how hard will the candidate push to make sure that the interviewer hears his or her side of the issue?
First, let’s separate the two issues (I’ll bring them back later). Part of the technical interview is asking technical questions. Some of them have one right answer, “What’s a linked list?” But most technical answers have a variety of answers, best discussed in the context of the work the candidate has completed. “Give me an example of a time you used a linked list. Where did you have issues in design? In coding? In debugging? After the product was in the field for a few months? A few years?”
That’s the easy part of asking technical questions. Now comes the hard part, the second part of the issue. Part of working in a technical group is being able to succeed in the culture of the group. If you work in a group that’s constantly challenging each other, you want to know if a candidate can succeed in that culture. So, you can ask questions that see how well a candidate deals with that environment. Part of the way you can determine whether the candidate can fit in the culture is to see how well the candidate answers questions that reflect the way the environment works.
When I’m interviewing for a group that likes a lot of give and take, I make sure that the first couple of people on the interview team ask questions in a way that doesn’t require that back and forth — unless I’ve already explained the group’s culture to the candidate. I want to make sure the candidate is comfortable. Then, I’ll schedule the technical audition. Assuming the candidate has done well on the technical audition, I’ll then ask the next interviewer or two to ask more technical questions, looking for how well the candidate stands up to the interviewer. Here are some examples, especially post audition:
- For a tester: “That’s not really a defect.” I’m waiting for the tester to say, “Yes it is and here’s why.”
- For a developer: “That design doesn’t work.” I want to hear the developer say, “Sure it will, and here’s why.”
- For a project manager: “You can’t schedule a project that way.” I want to hear “Here’s why that schedule will work.”
You see the pattern. Take a piece of the work the candidate has just completed, disagree with it, and see what happens. As the interviewer, you especially want to hear why the candidate believes in that work.
Consider when to ask these questions. If you need testers who can stand up to developers (a common problem), make sure to integrate these kinds of questions into the audition. Don’t ask, “How do you advocate for defects?” without also checking the answer to that question with an audition.
Your interview style should reflect your culture, especially if you have an abrasive, challenging culture. Either explain the group’s culture to the candidate, or first help the candidate over his or expected nervousness with a couple of “easy” interviews. But certainly, don’t scrimp on interviews that test the candidate’s mettle, if he or she will deal with that every day. And, don’t forget to ask references about how well a candidate advocates for what he or she believes.
For many organizations, whether they are challenging or not, consider using these kinds of questions after an audition. You’ll hear more about what the candidate was thinking.
No matter what your culture, make sure you treat the candidate with respect. Even if you have a bunch of arrogant know-it-alls, there’s no reason to be rude to candidates.
Michael, thank you for making me think harder about your comment
Tweet This Post
March 1st, 2004
Since there’s a (temporary in my mind) glut of candidates, some hiring managers are asking for specific industry expertise, such as: consumer product, enterprise-wide application, or web-content expertise. Unfortunately, that’s shorthand for what I believe people are really looking for: a specific mindset that meets the cultural requirements of the product development process.
Here’s an example. My colleague Chad has over 8 years managing enterprise server & application test teams. He’s a great test manager. In my opinion, he’s adaptable, having practiced several kinds of methodologies and test approaches. But he’s having trouble getting interviews with non-enterprise product organizations, because those folks don’t know how to translate their needs (for example, for consumer product experience) against his background.
If you’re a hiring manager try this. Instead of shorthand for industry expertise, decide what’s important about your industry expertise. Is the ability to cycle through a project quickly? Is it adaptability to a variety of projects? Is it understanding what your customers value and when they want the product? Is it how a candidate works on small products vs. large products in terms of process and procedures? Is it knowledge of real-time applications or transaction processing? The more you define what industry expertise means to your open position, the more successful your resume screening, interviewing, and hiring will be.
If you’re a candidate, first make sure you research the company so you can be ready for the phone screen and interview. That way you can anticipate potential industry expertise questions. Assuming you actually land a phone screen, if the problem of industry expertise arises, ask the interviewer what problem(s) they’re trying to avoid. Then if the interviewer says something like this, “Well, we want someone who’s flexible with the testing process for our small products,” you can say, “When I started with so-and-so, the product was small. Here’s what I did to organize the testing (and tell your behavior-description story).
As the product evolved, here’s how I responded (and explain when you took steps to do what).”It is useful to check for industry expertise, but functional skills and domain expertise (or the ability to quickly learn the domain) outweighs any tools/technology or industry expertise. In fact, I’ve found that when I’ve hired people from outside the industry, they come with new and novel ideas that are often useful. When I’ve had an option, I’ve selected people with superior problem-solving skills, adaptability, high functional expertise, and the ability to quickly acquire domain expertise. It’s worked for me.
Tweet This Post
November 18th, 2003
I’ve been working on an article for about a year now, trying to discuss how to decisions about which kinds of testers to hire when. The only good thing about working on an article that long is that I’m finally learning how to describe what I mean (I think).
I’d like your feedback on these terms:
Solution-space knowledge: The knowledge that arises from the person’s ability to understand the product, maybe by looking at the code, maybe by understanding the architecture and design. Example: testers who can read code or who understand how to test different architectures. If testing a payroll system, testers who understand when data structures change, and how to test for those changes, or that the payroll needs to complete in a certain amount of time, and stress the system to test for the time.
Problem-space knowledge: The knowledge of an expert user of this system, or one similar to it. Example: testers who know how the system should work. If testing an ultrasound system, are radiologists, so they can verify the software’s interpretations of the results.
Do these terms make sense to you?
Tweet This Post
July 3rd, 2003
Previous Posts