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 depth on accelerator microarchitecture: systolic or dataflow MAC arrays, on-chip SRAM hierarchy, HBM3 bandwidth budgeting, INT8 and FP8 datapaths, and PPA trade-offs at a named process node.
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
Explains their own datapath choices with real numbers: TOPS/W achieved, SRAM per tile, arithmetic intensity, and why HBM was chosen over LPDDR.
02
Evaluation factor
Work that shipped
30% weight
Ask which silicon or boards actually taped out or shipped: RTL they owned in SystemVerilog, emulation runs on ZeBu or Palladium, timing closure sign-off, and post-silicon bring-up results.
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 specific parts through tapeout and bring-up, describes their block, and cites yield, frequency, or MLPerf numbers on real hardware.
03
Evaluation factor
Diagnosis under uncertainty
20% weight
Probe how they chased hard bugs: intermittent SerDes link errors, power delivery droop, thermal throttling, or a mismatch between RTL simulation and post-silicon behaviour.
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 a real debug from symptom to root cause using waveforms, scan dumps, or lab instruments, and states what the fix cost in area or power.
04
Evaluation factor
Working across the org
15% weight
Assess collaboration with compiler, kernel, and model teams: negotiating ISA or instruction extensions, board and package constraints with mechanical, and schedule pressure against foundry deadlines.
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 concrete co-design outcomes, such as changing an instruction after profiling kernels, and shows they held their ground with data.
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.
