Why pre-screen knowledge engineers before the technical panel
Experts rarely know their own rules. They make a judgement in seconds and reconstruct a justification afterwards that does not match what they did. Getting to the real rule takes case walkthroughs, edge cases and a lot of patience, and it is the part of the job that cannot be automated. Engineers worth hiring can describe two experts who disagreed and how they resolved it. A short screen asks for that.
What actually matters when screening Knowledge Engineer candidates
- 01
Technical proficiency
Check fluency in OWL, RDF, SHACL and SPARQL: ask how they modelled a domain, chose between reification patterns, and validated instance data against shapes.
- 02
Systems and trade-offs
Probe graph architecture choices: triplestore versus labelled property graph, GraphDB or Neo4j or Stardog, entity resolution strategy, inference at load time versus query time.
- 03
Evidence and rigour
Test how they measured knowledge quality: competency questions, gold-standard sets for entity linking, precision on extraction pipelines, ontology reuse against SNOMED, FIBO or schema.org.
- 04
Collaboration and communication
Assess how they extracted knowledge from subject-matter experts: elicitation workshops, taxonomy sign-off, translating vague business rules into machine-readable axioms downstream teams query.
Pre-screening questions to ask Knowledge Engineer candidates
11 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Systems that decided
3 questions01Could you describe a knowledge-based system you worked on and your role in it?
Listen forA system in real use with the decisions it made, and their own scope on the project.
Systems that stored and retrieved documents only, or projects that never went into use.
02Could you explain your experience developing expert systems?
Listen forRule bases they built and maintained, with how conflicting rules and exceptions were handled.
Expert systems described from theory, or rule conflicts never encountered.
03Can you illustrate a complex data modelling problem you have solved?
Listen forA modelling problem where the domain resisted a clean structure, with how they resolved it.
Modelling described as schema design, or no case where the domain broke the model.
Getting it from experts
3 questions04What process do you follow to acquire knowledge from domain experts?
Listen forCase walkthroughs and edge cases used, recognising that stated rules differ from actual practice.
Elicitation described as interviews, or experts' stated rules taken at face value.
05Can you explain your understanding of how AI relates to knowledge engineering?
Listen forA clear view of where explicit rules beat learned models, particularly where reasoning must be inspectable.
Everything framed as a learning problem, or no view on when explicit representation is required.
06Can you explain your experience with machine learning?
Listen forEnough to combine learned components with explicit rules, and to say which suits which part.
No familiarity at all, or learned models proposed for decisions that must be explainable.
Representation that fits
3 questions07What tools have you used for knowledge representation and reasoning?
Listen forRepresentation chosen for the reasoning required, with the expressiveness and cost trade-off understood.
One representation applied to everything, or tools named with no reasoning about fit.
08What are the primary languages you have used in your projects?
Listen forLanguages matched to the work, with integration into ordinary production systems handled.
Research languages used with no integration path, or no production deployment experience.
09Do you have experience with logic or symbolic programming languages?
Listen forReal use where declarative reasoning fitted the problem, with performance limits understood.
Languages listed from study, or no awareness of where symbolic reasoning becomes expensive.
Validated output
2 questions10What strategies do you use to validate the results of a knowledge-based system?
Listen forHeld-back cases run blind against expert judgement, with disagreements investigated rather than explained away.
Validation by asking the expert to review the rules, or no independent test set.
11How would you explain what knowledge engineering involves to a new stakeholder?
Listen forA plain explanation that sets realistic expectations about effort and expert time required.
An explanation full of terminology, or expert availability treated as a minor input.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names concrete ontology decisions (property chains, disjointness axioms, SHACL constraints) and explains why alternatives were rejected.
Systems and trade-offs
25%5Weighs reasoner cost, query latency and schema churn openly, citing a graph they scaled past millions of triples.
Evidence and rigour
25%5Reports measured accuracy of linking or classification and shows competency questions driving each modelling change.
Collaboration and communication
15%5Describes running expert elicitation sessions and turning contested definitions into agreed, documented, queryable vocabulary.
Experts make a judgement in seconds and justify it afterwards with a rule that is not what they used. A one-way video screen asks how they got past that.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish systems they built, test their elicitation method, and check how the output was validated.
How does this differ from a machine learning engineer screen?
The distinguishing skill is elicitation and explicit representation. Weight how they extract rules from people and encode them so the reasoning can be inspected, rather than model training experience.
Evaluating answers
What is the strongest signal when screening this role?
Two experts who disagreed and how it was resolved. Engineers who have done real elicitation always hit this. Anyone whose experts agreed on everything interviewed one person or asked shallow questions.
How do I judge their validation practice?
Ask how the system was tested before it was used. Real answers cover held-back cases run blind against expert judgement. Anyone validated by asking the expert to review the rules has tested the wrong thing.
























