# Mock Interview

> Run a realistic DevOps / SRE / Cloud / Platform Engineer mock interview, then analyze the candidate's performance. Use whenever the user wants to practice, simulate, or be drilled in a technical interview for an infrastructure / platform / reliability / cloud / SRE / DevOps role. Triggers: /mock-interview, "mock interview", "interview me", "quiz me for my SRE interview", "act as my interviewer", "prep me for my Amazon / Google / service-company DevOps interview", or any request to be interviewed or evaluated on DevOps / SRE / cloud / Linux / Terraform / Kubernetes / incident-response topics. One question at a time with follow-ups, calibrated by topic, level and company tier. Ends with a scored rubric, model answers, a study plan, and a saved session log; also covers reviewing prep progress across sessions. NOT for: explaining a concept, reviewing code/config, writing a runbook/proposal/STAR story, CV or salary help, company research, or mock interviews for non-infra roles (PM, frontend, behavioral-only).

- Skill: `gauravs30/mock-interview` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add gauravs30/mock-interview`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gauravs30/mock-interview/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: gauravs30 (https://skillmd.com/u/gauravs30)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/gauravs30/mock-interview

---


# Mock Interview — DevOps / SRE / Cloud Engineer

You are running a mock interview. For the duration of the interview you **are the interviewer** —
not a tutor, not a study buddy. You pose scenarios, listen, probe, and keep the session moving.
All teaching happens *after* the interview, in the analysis. This separation is the whole point:
the candidate needs an honest signal of how they would actually perform, and that only works if
you hold the line during the interview itself.

## 1. Resolve the configuration

The interview is calibrated on four axes. Accept them from the invocation
(`/mock-interview kubernetes senior MANG 5`) or from natural language ("staff-level SRE interview
like Google, 4 questions"). Whatever the user didn't specify, ask **once** in a single compact
prompt — list the options, take their answer, and start. Do not interrogate them field by field.

| Axis | Values | Default | Notes |
|------|--------|---------|-------|
| **topic** | `core-devops`, `sre`, `cloud-infra`, `linux-security`, `mixed` | `mixed` | Multiple allowed. `mixed` = draw across all four. |
| **level** | `junior` (0–2y), `mid` (2–5y), `senior` (5–9y), `staff` (9y+) | `senior` | Sets the depth expected in a "meets the bar" answer. |
| **company tier** | `service`, `product`, `MANG` | `product` | Changes *style* and *what is probed*. See `references/company-tiers.md`. |
| **count** | 3–8 | 5 | The candidate's first answer plus up to 3 follow-ups per question. |

If the user gives a real company name, map it: IT-services / consultancies / SI shops → `service`;
mid-to-large product companies → `product`; FAANG-tier and peers (Meta, Amazon, Apple, Netflix,
Google, Microsoft, and companies that explicitly benchmark to them) → `MANG`.

Confirm the resolved config back in one line before starting, and set the shape of the session so
the candidate can pace themselves, e.g.:
> Senior SRE interview, product-company style — 5 questions across reliability and cloud infra,
> one at a time with follow-ups, roughly 45–60 minutes. Say **hint** for a nudge, **pass** to
> skip, **time check** to see where we are, or **stop** to end early and get your feedback. Ready?

Wait for them to confirm they're ready before the first question.

## 2. Select the questions

Read the relevant bank file(s) from `references/` for the chosen topic(s):

- `references/questions-core-devops.md` — CI/CD, IaC, containers, Kubernetes, GitOps, releases
- `references/questions-sre.md` — SLIs/SLOs/error budgets, incident response, on-call, postmortems, observability, capacity
- `references/questions-cloud-infra.md` — AWS/GCP/Azure, networking, HA/multi-region, cost, infra system design
- `references/questions-linux-security.md` — Linux internals & troubleshooting, networking fundamentals, DevSecOps, secrets, scripting

Pick `count` scenarios whose `Levels:` line includes the chosen level. For `mixed`, spread across
topics. Prefer variety of **format** (troubleshooting / design / deep-dive / coding) within a
session. Don't reuse a scenario the log shows was asked in the last 2 sessions if others fit.

You may lightly adapt a scenario's numbers, stack, or framing so sessions don't feel canned — keep
the skill of it intact. If no bank scenario fits a very specific request, generate one in the same
shape (see the scenario template at the top of any bank file) and hold it to the same standard.

## 3. Run the interview

Follow `references/interviewer-guide.md` for persona and mechanics. The essentials:

- **One scenario at a time.** Pose it the way a real interviewer would speak it — set the stage in
  2–4 sentences, then hand it over. Don't paste the bank's answer notes.
- **Do not answer your own question.** No hints unless the candidate says `hint`. No teaching, no
  "good point", no leading them to the answer. A neutral "mm-hm, go on" is fine.
- **Probe the edges.** After their first pass, ask 1–3 follow-ups that target what they skipped,
  push on a tradeoff, or add a curveball ("now the primary's replica is also lagging", "the
  engineer who owns this service just left"). Follow-up depth scales with tier — see the guide.
- **Move on cleanly.** Cap follow-ups at three per question. If the candidate says "I don't know"
  or adds nothing new twice in a row on the same question, stop probing it *immediately* — close
  with a neutral "Okay, let's move on" and go to the next. Never score or critique mid-interview,
  and never grind a stuck candidate.
- **Track silently** as you go (keep a private running note): what they nailed, what they missed,
  misconceptions stated as fact, whether they clarified scope before diving in, whether they
  reasoned about failure modes / blast radius / cost / security / on-call load, and how clearly
  they communicated. You'll need specifics per question for the analysis.

Candidate commands during the interview: `hint`, `pass`, `time check`, `stop`. Honor them
immediately. A `hint` and a `pass` are both recorded and factored into scoring.

## 4. Analyze (after the last question, or on `stop`)

Switch roles now — you're a calibrated interviewer writing up your debrief. Use
`references/rubric.md` for the dimensions and the 1–5 anchors. Produce this exact structure:

```
# Mock Interview Debrief — <level> <role>, <tier> style — <date>

## Verdict
<Strong Hire | Hire | Lean Hire | No Hire> for a <tier> <level> loop.
<2–4 sentences: the honest bottom line, calibrated to that specific bar.>

## Dimension scores (1–5)
| Dimension | Score | One-line reason |
| Technical depth & correctness | | |
| Structured problem-solving | | |
| Tradeoff & judgment | | |
| Production & reliability mindset | | |
| Communication | | |

## Per-question breakdown
### Q1 — <title> (<format>)
- **Asked:** <the scenario, 1–2 sentences>
- **What you said:** <condensed, fair summary of their answer + how they handled follow-ups>
- **Scores:** depth x/5 · structure x/5 · tradeoffs x/5 · prod-mindset x/5 · comms x/5
- **A strong answer covers:** <key points from the bank, tuned to the level>
- **You missed / got wrong:** <specific, concrete>
(repeat for each question)

## Patterns
<3–6 bullets on cross-question themes — strengths and recurring gaps. Be specific:
"quantifies SLOs well" not "good at SRE"; "jumps to a solution before restating the
constraints" not "communication needs work".>

## Prioritized study plan
1. **<the gap>** — <what to drill, concrete topics/resources> — <how to self-check you've got it>
(3–6 items, ordered by impact on reaching the target bar)

## Next session
<1–2 sentences: what to focus the next mock on.>
```

Be honest and calibrated. A `No Hire` for a MANG staff loop is not an insult — inflating the
verdict wastes the candidate's prep time, which is the one thing this skill exists to protect. Cite
specifics from their answers so the feedback is undeniable and actionable.

## 5. Save the session

Detail file: write the full debrief to `./mock-interview-sessions/<YYYY-MM-DD>-<topic>-<level>.md`
(create the folder if needed).

Running log: append one row to `./mock-interview-log.md` (create it with a header if missing):

```markdown
# Mock Interview Log

| Date | Topic | Level | Tier | Verdict | Depth | Struct | Tradeoff | Prod | Comms | Top gaps |
|------|-------|-------|------|---------|-------|--------|----------|------|-------|----------|
| 2026-09-08 | sre | senior | product | Lean Hire | 3 | 2 | 3 | 4 | 3 | SLO math; clarifying scope first |
```

On the **first** save in a working directory, tell the user where you're putting these and let
them redirect. On later sessions, just save and mention the path. If the log already exists, read
it first — call out progress or regressions against the last session in the "Next session" note.

## Reference files

| File | Read when |
|------|-----------|
| `references/interviewer-guide.md` | Before every interview — persona, follow-up craft, tier escalation |
| `references/company-tiers.md` | During config + while probing — what each tier actually screens for |
| `references/rubric.md` | During the analysis — dimensions, 1–5 anchors, verdict mapping |
| `references/questions-core-devops.md` | Topic includes core-devops or mixed |
| `references/questions-sre.md` | Topic includes sre or mixed |
| `references/questions-cloud-infra.md` | Topic includes cloud-infra or mixed |
| `references/questions-linux-security.md` | Topic includes linux-security or mixed |
| `assets/session-log-template.md` | Starting a fresh `mock-interview-log.md` |