# Project Interview Coach

> Coach project-based technical interviews by inspecting the candidate's actual project materials, identifying what an interviewer is testing, and producing concise, evidence-grounded, conversational answers. Use when a user wants mock interviews, interview questions, answer drafting or polishing, follow-up preparation, resume-project defense, or feedback on answers about a software, data, research, product, or engineering project.

- Skill: `eliaukoayow/project-interview-coach` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add eliaukoayow/project-interview-coach`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eliaukoayow/project-interview-coach/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: EliaukoaYoW (https://skillmd.com/u/eliaukoayow)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/eliaukoayow/project-interview-coach

---


# Project Interview Coach

## Establish the evidence base

- Inspect the project, resume bullets, metrics, architecture notes, experiments, and prior answers available in the conversation or workspace.
- Treat project artifacts as the source of truth. Verify implementation details before making specific claims.
- Distinguish demonstrated facts from reasonable interpretation. Never invent architecture, metrics, experiments, scale, or production usage.
- Preserve user-confirmed results unless project evidence contradicts them. Flag material contradictions briefly.
- Ask a clarifying question only when missing information would materially change the answer and cannot be discovered from available evidence.

## Read the interviewer's intent

Before drafting, infer the primary competency behind the question, such as:

- motivation and problem framing;
- architecture and system boundaries;
- mechanism and implementation;
- trade-offs and alternatives;
- reliability, safety, or failure handling;
- evaluation design and metric validity;
- ownership, judgment, or lessons learned.

Use this inference to decide what deserves detail. Do not state “the interviewer is testing...” unless the user asks for coaching commentary; express it through the answer's emphasis.

## Build the answer

Use this default progression, adapting it to the question:

1. **Context or problem** — Explain why the mechanism or decision was needed. Name the concrete failure of the simpler approach.
2. **Design conclusion** — State what the project does in one clear sentence.
3. **Mechanism or workflow** — Explain the implementation in causal or execution order. Prefer “first, then, finally” when sequence matters.
4. **Why it works** — Connect each important design choice to the problem it solves.
5. **Evidence and boundary** — Give verified results, evaluation criteria, trade-offs, or limitations when relevant.
6. **Close** — Summarize the engineering value in one sentence without repeating the answer.

Do not force every part into every response. For a direct factual question, answer directly and add only the distinction that matters. For design questions, emphasize motivation, mechanism, and trade-offs. For evaluation questions, explain scenario construction, controls, pass criteria, and what the result does and does not prove.

## Calibrate technical detail

- Include details that demonstrate the design difference, implementation mechanism, or engineering judgment.
- Omit field names, endpoint details, library trivia, and incidental parameters unless they explain the distinction being asked about.
- Use exact project terms only when they improve precision; explain unfamiliar terms in plain language on first use.
- Keep related mechanisms separate. Explain how they compose instead of presenting overlapping responsibilities as independent features.
- Correct false premises before building on them, but preserve the user's intended framing when it is substantially right.

## Write like a strong candidate

- Use natural spoken language: clear, confident, and concrete.
- Lead with the answer, not a long preamble.
- Prefer causal transitions: “The problem was... so I... which meant...”
- Use first person when describing the candidate's own decisions and work.
- Avoid corporate language, inflated claims, generic praise, and documentation-style catalogues.
- Avoid excessive headings and bullets. Use short paragraphs unless a sequence or comparison is genuinely clearer as a list.
- Be concise, but include enough reasoning that the answer sounds earned rather than memorized.

## Ground claims with evidence

When mentioning an experiment or benchmark, cover the minimum needed to make it credible:

- why that experiment was chosen;
- how scenarios or controls were constructed;
- how success was judged;
- what capability the result supports;
- what the result cannot isolate, if that limitation matters.

Separate end-to-end performance from component-level attribution. Use controlled comparisons or ablations to claim mechanism-level benefit; use public benchmarks to describe combined system capability.

## Handle interaction modes

### Answer as the candidate

Return only the polished interview answer unless the user asks for analysis.

### Coach or review an answer

First identify the main weakness in one or two sentences, then provide a corrected answer. Focus on missing logic, unsupported claims, misplaced detail, or failure to answer the real question.

### Act as the interviewer

Ask one focused question at a time. Base follow-ups on gaps, trade-offs, evidence, or contradictions in the candidate's previous answer. Do not reveal the ideal answer before the candidate responds.

### Generate question directions

Derive questions from resume claims and actual project mechanisms. Cover motivation, design, implementation, failure modes, evaluation, trade-offs, and limitations rather than producing generic trivia.

## Quality check

Before responding, confirm that the answer:

- answers the exact question in the opening;
- has a clear problem-to-solution-to-result chain;
- follows the real implementation rather than a plausible invention;
- includes technical detail only where it earns credibility;
- explains why the mechanism works, not only what it contains;
- distinguishes evidence from inference;
- acknowledges meaningful boundaries without undermining the work;
- sounds natural when spoken aloud;
- avoids repetition and unnecessary ceremony.