- Define the job's requirements.
- Define the essential and desirable qualities, preferences, and non-technical skills for a successful fit.
- Identify corporate cultural-fit factors.
- Define the necessary technical-skill level and the required educational background.
- Identify essential technical skills.
- Identify desirable technical skills.
- Evaluate educational or training requirements.
- Define all elimination factors.
- Think twice about elimination factors.
- Complete the job analysis worksheet.
- Points to Remember
This chapter is from the book
This chapter is from the book
This chapter is from the book
Define the necessary technical-skill level and the required educational background.
The third part of the analysis involves defining the required minimum educational background a candidate needs to be successful in your organization, and the minimum technical skills required for the candidate to complete the deliverables. Consider the work you need performed and the background required to perform it. Determine if your organization has assumptions about required educational background for technical people.
Prior work experience
A candidate with prior work experience can be very valuable, but you’ll want to look beyond what is stated on the résumé. Define the work experience required of a candidate before you consider him or her for the job. Consider functional skills, product domain, tools and technology, and industry experience.
Functional skills experience
A candidate who has functional skills experience possesses a technical understanding of how to perform the work required in the position. When you define functional skills experience, define what evidence you’ll require to confirm that the skills you’re looking for are present.
For developers, functional skills include proficiency in reading and writing code, as well as skills in designing, programming, and debugging. For testers, functional skills include boundary-condition testing and equivalence partitioning. For writers, functional skills include proficiency in grammar. For project managers, functional skills include knowing how to apply lifecycles to a project, as well as how to estimate, measure key project metrics, and run a meeting.
Functional skills experience is both technology-independent and tools-independent. Functional skills experience is gained in school and on the job. However, candidates may need specific functional skills to be successful in your environment, such as understanding how database schema are developed and used. Or, you may require a person with varied knowledge of data structures, or how to create and use watchdog timers, or with an understanding of how to avoid race conditions in real-time systems. If the position requires specific functional skills, include those skills in the activities and deliverables, for example, noting that you need someone to “design and implement the watchdog timer for ModuleA by June 1.”
Product-domain experience
For a candidate to have product-domain experience, he or she must have knowledge of the product—either of the problems the customers want solved by this product, or the internal architecture of the product, or both. You may want someone who already understands how the product works and why your customers use the product. Or, you may want someone new to this kind of product, so that you receive the benefit of fresh eyes and attitude. For example, when I worked in machine-vision companies (companies whose products use cameras and software to “see”), our goal was to hire developers with machine-vision experience, so that they already understood the domain issues. When we wanted to hire testers, we needed people who had real-time and embedded systems experience, but not necessarily machine-vision experience, because we wanted the testers to be open to alternative testing possibilities.
When you assess your hiring needs, judge each candidate’s product-domain experience in the context of your products. When you define a position and assess candidates, judge their experience against the products they’ve already worked on.
I identify product-domain experience as either problem-space or solution-space:
- With problem-space domain expertise, the candidate understands how the users use the product. Candidates generally have exposure to and a general understanding of product externals. They understand how the product interacts with the users or, from a black-box level, how the products’ interfaces work to solve the customer’s problem. Technical people acquire this level of expertise quickly.
- With solution-space domain expertise, the candidate understands how the product works on the inside—that is, the architecture of the product. We expect developers to have this expertise; if they don’t, we expect they can acquire it by reading the code. Writers can acquire this expertise, depending on the kind of documentation they write. Testers and technical support staff members can acquire this kind of expertise if they can read how the product works on the inside, or if they are taught about the internal workings.
A candidate who has the ability to acquire both problem-space and solution-space expertise is likely to be most valuable to you. As you define the job (and later, as you review résumés or interview candidates), determine how much expertise the candidate must have both in how the product works (solution-space expertise) and in how to solve the problems of the customer (problem-space) using his or her functional skills. People with both kinds of domain experience understand the specifics of how the product works, and can understand how to relate their functional skills to improve the product. At the senior level, developers, testers, designers, and architects all are likely to have this expertise. It’s easier to obtain this level of expertise if the candidate already can read and write code, but it’s not required. All technical staff members can acquire both problem-space and solution-space domain experience if they have the ability to understand the product and are educated about it.
How the different kinds of domain expertise work together is illustrated in the following example: If you have a multi-threaded product, one in which numerous instances of the product can be run simultaneously on one machine for multiple users, then a candidate has reached problem-space expertise if he or she knows that the product is multi-threaded and why the product requires multi-threading (for performance or throughput or whatever). With solution-space expertise, the candidate knows what kicks off multiple threads, and understands how to use that knowledge to develop pieces of the product appropriately or to create tests that test the product differently than if the product were single-threaded.
Technology and tools experience
Having experience with the hiring company’s specific programming language, operating system, database, or other tools gives a candidate somewhat of an advantage over applicants without suitable technology and tools experience. Mastery of the specific technology and tools can be easily taught to a candidate who is fully qualified for the job in all other areas. However, technology and tools experience may or may not be a consideration in whether you or your company will decide to hire a candidate. The decision more likely will depend on how quickly you want him or her to start being productive in your environment. For example, if you’re starting up a company that will use an Oracle database for a server and a Java front-end for a client, you want to hire people who know how to use Oracle databases and Java front-ends, as well as how to use the specific architecture to design, develop, test, document, and support that kind of a product.
If you’re not doing the phone-screens and interviewing yourself, make sure you specify to the people who are performing those tasks whether you need to hire a person with experience using a specific tool or someone with general tool experience. For example, if you’re looking for a person to perform test automation, experience with any of the test automation tools may be acceptable. However, if you’re looking for a person to coach your team members as they write automation using a specific tool, then experience in that tool is probably necessary. Similarly, a project manager with experience using any of the project scheduling tools may be acceptable, unless you also want that project manager to teach new project managers how to use the tool. Teaching, coaching, and mentoring activities may require a good working knowledge of a specific tool. Otherwise, general tool experience is probably sufficient.
Industry experience
A candidate who has industry experience understands not just who your customers are, but how your customers will react, and what they expect from their systems. Industry experience relates to how people use the product; product-domain expertise is knowledge of the products’ internals.
You may want to hire a candidate with experience specific to your industry so that he or she understands your customers and their expectations, and has an understanding of the types of problems you encounter in your work. For example, people who work on software for airplanes understand that their products will be audited and their processes will be assessed to ensure that the product development group hasn’t created an unsafe environment. Someone who’s worked in the shrink-wrap, commercial-product-development world might not welcome all these assessments and audits, but a veteran of the aeronautical industry must be more accepting of them. The pharmaceutical industry is another example of an industry in which process rigor and audits are common practice.
Focus on the experience necessary for the job you have to fill. Don’t worry about planning too far ahead—it’s too hard to predict the future. I’ve found that when I plan too far into the future, my candidates don’t have the skills to perform the work that I need done now.