| name | technical-interviewing |
| version | 0.1.0 |
| description | Use this skill when designing coding challenges, structuring system design interviews, building interview rubrics, calibrating evaluation criteria, or creating hiring loops. Triggers on interview question design, coding assessment creation, system design prompt writing, rubric building, interviewer training, candidate evaluation, and any task requiring structured technical assessment.
|
| category | operations |
| tags | ["interviewing","hiring","rubrics","coding-challenges","system-design"] |
| recommended_skills | ["interview-design","recruiting-ops","system-design","clean-code"] |
| platforms | ["claude-code","gemini-cli","openai-codex"] |
| license | MIT |
| maintainers | [{"github":"maddhruv"}] |
When this skill is activated, always start your first response with the 🧢 emoji.
Technical Interviewing
Technical interviewing is both a skill and a system. The goal is not to find the
"smartest" candidate - it is to predict on-the-job performance with high signal
and low noise while treating every candidate with respect. A well-designed
interview loop uses structured questions, clear rubrics, and calibrated
interviewers to make consistent, defensible hiring decisions. This skill covers
the full lifecycle: designing coding challenges, structuring system design rounds,
building rubrics, calibrating panels, and reducing bias.
When to use this skill
Trigger this skill when the user:
- Wants to design a coding challenge or take-home assignment for a specific role
- Needs to create a system design interview question with follow-ups
- Asks to build a scoring rubric or evaluation criteria for interviews
- Wants to structure a full interview loop (phone screen through onsite)
- Needs to calibrate interviewers or run a calibration session
- Asks about reducing bias in technical assessments
- Wants to evaluate a candidate's performance against a rubric
- Needs interviewer training materials or shadow guides
Do NOT trigger this skill for:
- Preparing as a candidate for interviews (use system-design or algorithm skills)
- General HR hiring workflows not specific to technical assessment
Key principles
-
Structure over gut feel - Every question must have a rubric before it is
used. "I'll know a good answer when I see it" is not a rubric. Define what
strong, acceptable, and weak look like in advance. Structured interviews are
2x more predictive than unstructured ones.
-
Signal-to-noise ratio - Each question should test exactly one or two
competencies. If a coding question tests algorithms, data structures, API
design, and communication simultaneously, you cannot isolate what the
candidate is actually good or bad at. Separate the signals.
-
Calibrate constantly - The same "strong" performance should get the same
score regardless of which interviewer runs the session. Run calibration
exercises quarterly using recorded or written mock answers.
-
Respect the candidate's time - Take-homes should take 2-4 hours max (state
this explicitly). Onsite loops should not exceed 4-5 hours. Every minute of
the candidate's time should produce meaningful signal.
-
Reduce bias systematically - Use identical questions per role, score before
discussing with other interviewers, avoid anchoring on resume prestige, and
ensure your rubric tests skills not proxies (e.g. "uses our preferred
framework" is a proxy, not a skill).
