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.