Interview scorecard template

Inclusive Design Engineer interview scorecard

Evaluate Inclusive Design Engineer candidates across 4 weighted areas: technical depth, work that shipped, diagnosis under uncertainty, and working across the org. Technical depth leads at 35%, so check command of WCAG 2.2 success criteria, ARIA patterns, EN 301 549 and ISO 9241-171, plus hands-on use of NVDA, JAWS, VoiceOver, switch access. Use the rubric to compare role-specific evidence consistently.

See AI scoring
engineering applied scienceaccessibilityassistive technologyco designwcag 2.2
TL;DR
For technical depth, look for evidence the candidate cites specific success criteria and ARIA roles from memory, and describes real behaviour differences between JAWS, NVDA and VoiceOver. For work that shipped, look for evidence the candidate names shipped artefacts with before and after audit findings, conformance statements or VPATs, and defect counts closed against a release date. Apply the written 1–5 anchors to every answer, record the evidence behind each rating, and use the factor weights to reach a consistent overall assessment.
Complete evaluation framework

What to assess and how to score it

Review the evidence signals before interviewing. Then use the anchored descriptions—not instinct alone—to choose the score that best matches each answer.

01
Evaluation factor

Technical depth

35% weight

Check command of WCAG 2.2 success criteria, ARIA patterns, EN 301 549 and ISO 9241-171, plus hands-on use of NVDA, JAWS, VoiceOver, switch access and eye-gaze input.

Evidence to listen for

  • Explains the physics or mechanism behind their work, not just the tooling
  • Names the standards, tolerances, and constraints they designed against
  • Can defend a design decision under follow-up questions
  • Distinguishes what they personally engineered from what the team delivered

Five-point scoring guide

1
Poor

Cannot explain the fundamentals of their own stated specialism.

2
Needs Improvement

Knows the vocabulary but not the underlying mechanism; struggles under follow-ups.

3
Satisfactory

Solid working knowledge for the role; depth thins out on edge cases.

4
Very Good

Strong command of the domain; explains trade-offs and defends decisions well.

5
Excellent

Cites specific success criteria and ARIA roles from memory, and describes real behaviour differences between JAWS, NVDA and VoiceOver.

02
Evaluation factor

Work that shipped

30% weight

Ask for products or components they made accessible end to end: design system tokens, focus management, captioning pipelines, adjustable enclosures, or anthropometrically sized controls.

Evidence to listen for

  • Names specific programmes, parts, or systems that reached production or field use
  • States their own scope inside the project
  • Can give measured outcomes: yield, cycle time, cost, failure rate
  • Explains what went wrong and what they changed

Five-point scoring guide

1
Poor

No delivered work; experience is coursework, lab-only, or purely observational.

2
Needs Improvement

Contributed to projects but cannot say what shipped or what their part was.

3
Satisfactory

Has delivered real work; outcomes described without numbers.

4
Very Good

Names shipped work and their scope, with some measured results.

5
Excellent

Names shipped artefacts with before and after audit findings, conformance statements or VPATs, and defect counts closed against a release date.

03
Evaluation factor

Diagnosis under uncertainty

20% weight

Probe how they diagnose ambiguous barriers: reproducing a screen reader bug across browser and AT combinations, or resolving conflicts between contrast, motion and cognitive load needs.

Evidence to listen for

  • Describes a real failure they chased to root cause
  • Shows a method: isolate variables, reproduce, measure, eliminate
  • Distinguishes correlation from cause
  • Says what they ruled out and why, not only what the answer turned out to be

Five-point scoring guide

1
Poor

No diagnostic method; guesses or escalates immediately.

2
Needs Improvement

Trial and error with no structure; cannot explain how they narrowed the cause.

3
Satisfactory

Reasonable method on familiar problems; less structured on novel ones.

4
Very Good

Clear systematic approach with a real root-cause story.

5
Excellent

Walks through an isolation path across AT and browser matrices, then explains the trade-off they chose and the user testing that confirmed it.

04
Evaluation factor

Working across the org

15% weight

Look for evidence of co-design sessions with disabled participants, plus how they moved product managers, legal and QA to adopt accessibility gates in CI or definition of done.

Evidence to listen for

  • Explains technical constraints to non-technical stakeholders without condescension
  • Has negotiated scope, cost, or timeline with manufacturing, product, or suppliers
  • Documents decisions so others can act on them
  • Takes review feedback without defensiveness

Five-point scoring guide

1
Poor

Cannot communicate outside their specialism; dismissive of other functions.

2
Needs Improvement

Communication gaps cause rework; avoids stakeholder contact.

3
Satisfactory

Works adequately with other teams; documentation is thin.

4
Very Good

Communicates clearly across functions; reliable collaborator.

5
Excellent

Describes paid participant recruitment, automated axe or Pa11y gates they introduced, and named partners who kept the practice running afterwards.

Evidence-led prompts

Interview questions for a Inclusive Design Engineer

Use these prompts to surface evidence for the weighted factors above and compare candidates against the same role-specific criteria.

  1. 01

    Can you describe a project where you designed for an underserved group?

  2. 02

    Can you describe adapting a design after feedback highlighted an access problem?

  3. 03

    Can you give an example of accounting for cultural differences in your designs?

  4. 04

    How do you gather feedback from people with disabilities?

  5. 05

    What methods do you use to test for accessibility?

See the complete Inclusive Design Engineer question set
Put this rubric to work

Score every candidate against the same standard

Add these weighted factors to Hirevire and let AI evaluate recorded answers against your rubric.

Explore AI Scorecards