Phase 1 (interview prep) is unchanged. Phase 2 adds a structured workflow for organizing post-interview feedback into the Greenhouse scorecard format, with a clear source priority hierarchy (voice dictation > meeting notes > transcript > resume context only when interviewer references it).
273 lines
14 KiB
Markdown
273 lines
14 KiB
Markdown
---
|
|
name: prep-tech-screen
|
|
description: This skill should be used when the user says "prep for this interview," "prep a tech screen," "prepare for this technical interview," "tech screen prep," "interview prep," "organize my interview feedback," "write up my interview notes," "generate scorecard feedback," or provides a candidate's resume/PDF and asks to prepare interview questions for a Verkada Enterprise Solutions Engineer peer technical interview. Also trigger when the user pastes or references a candidate resume and mentions an upcoming interview, tech screen, or peer screen. Trigger after an interview when the user wants to turn their notes and voice feedback into structured scorecard input.
|
|
---
|
|
|
|
# Tech Screen: Prep and Feedback
|
|
|
|
A two-phase skill for Verkada Enterprise Solutions Engineer peer technical interviews. Phase 1 prepares the interview. Phase 2 organizes post-interview feedback into the Greenhouse scorecard format.
|
|
|
|
## Role Context
|
|
|
|
Verkada is an IoT company making physical security for enterprises: security cameras, access control, intrusion alarms, air quality monitoring, video intercoms, cellular connectivity devices, and visitor management. Solutions Engineers need broad technical knowledge across networking, storage, cloud, IAM, and physical security. The interview is 30 minutes and conversational, not a grilling session.
|
|
|
|
---
|
|
|
|
# Phase 1: Interview Prep
|
|
|
|
## Step 1: Get the Resume
|
|
|
|
The user will provide a resume. This is commonly a PDF. The model cannot read PDFs directly, so extract text first:
|
|
|
|
```bash
|
|
pdftotext "/path/to/resume.pdf" -
|
|
```
|
|
|
|
If the resume is already text or markdown, read it directly.
|
|
|
|
## Step 2: Analyze the Candidate
|
|
|
|
From the resume, identify:
|
|
- **Current and previous employer(s)**
|
|
- **Years of experience** and career trajectory
|
|
- **Certifications held** (CCNP, PCNSE, CISSP, etc.)
|
|
- **Technical domains listed** on the resume
|
|
- **Likely area of expertise** (networking, storage, cloud, IAM, physical security, or other)
|
|
|
|
Read the Peer Tech Screen Guide for reference on question topics and depth levels:
|
|
|
|
```
|
|
skills/prep-tech-screen/references/peer-tech-screen-guide.md
|
|
```
|
|
|
|
## Step 3: Create the Meeting Note
|
|
|
|
Create a meeting note at:
|
|
|
|
```
|
|
~/notes/mt/YYMMDD-candidate-name-tech-screen.md
|
|
```
|
|
|
|
- `YYMMDD`: date of the interview (two-digit year, zero-padded month and day)
|
|
- `candidate-name`: first and last name, lowercase, hyphen-delimited
|
|
- Example: `260423-charles-oliver-tech-screen.md`
|
|
|
|
Use this structure:
|
|
|
|
```markdown
|
|
# Candidate Name - Peer Tech Screen
|
|
|
|
**Date:** YYYY-MM-DD
|
|
**Role:** Enterprise Solutions Engineer (region/info if known)
|
|
**Recruiter:** (if known)
|
|
**Candidate:** Name | Location | Phone (if available)
|
|
|
|
## Candidate Background
|
|
|
|
- **Current:** Title, Company (dates)
|
|
- **Previous:** Title, Company (dates)
|
|
- **Education:** Degree, University
|
|
- **Certifications:** List from resume
|
|
|
|
## Likely Area of Expertise
|
|
|
|
One or two sentences identifying the candidate's strongest technical domain(s) based on their resume. This is where the interviewer should go deep.
|
|
|
|
## Interview Questions
|
|
|
|
(See question structure below)
|
|
```
|
|
|
|
### Question Structure
|
|
|
|
Organize questions into these sections, each with `- [ ]` checkboxes. The interviewer checks them off during the interview.
|
|
|
|
**Opener (area of expertise / current role)**
|
|
- Start with a technically relevant question about their current position. No generic icebreakers. The first question should connect to one of the required technical areas. Good openers: "Walk me through a typical engagement," "What does your day-to-day look like technically," "Describe the lifecycle of [project type from their resume]."
|
|
|
|
**Networking (required, go deep)**
|
|
- Always include the "plug into a fresh network" scenario question
|
|
- Include the Verkada-specific scenario: segmenting Verkada traffic on a physical network, or bandwidth considerations for cloud backup
|
|
- Tailor follow-ups to what's on the candidate's resume (e.g., if they list firewall experience, ask about NAT/PAT and firewall filtering in the context of the scenario)
|
|
- For candidates with strong networking backgrounds, include advanced follow-ups: DORA, DNS resolution hierarchy, TCP handshake, TLS handshake details
|
|
|
|
**Identity & Access Management**
|
|
- Cover auth vs authorization, IDPs, MFA, SSO, Zero Trust basics
|
|
- For candidates with IAM experience, go deeper: SAML vs SCIM, SP vs IDP-initiated, hybrid identity, NAC
|
|
- Always include a Verkada-relevant IAM question (badge integration, directory sync, etc.)
|
|
|
|
**Cloud Technologies**
|
|
- Cover hybrid cloud, public cloud providers, compute/storage/archive concepts
|
|
- Connect to Verkada's hybrid cloud model (cameras on-prem, management in cloud)
|
|
- If the candidate lists specific cloud platforms, tailor accordingly
|
|
|
|
**Storage**
|
|
- Cover HDD vs SSD, RAID, NAS, retention sizing
|
|
- For candidates with storage background: IOPS, fabric, scale-up vs scale-out, storage protocols
|
|
- Include a video storage sizing question (e.g., "How would you size storage for X cameras at Y resolution for Z days?")
|
|
|
|
**Physical Security**
|
|
- Cover NVR, PoE, fail secure vs fail open, H.264 vs H.265
|
|
- For candidates with physical security background: PPF, RTSP vs ONVIF, OSDP vs Wiegand, low voltage, fire alarm integration
|
|
- This is often the weakest area for candidates; cover basics unless the resume shows depth
|
|
|
|
**Culture Fit / Wrap-up**
|
|
- Home lab, hobbies, what drew them to Verkada
|
|
|
|
### Question Selection Guidelines
|
|
|
|
- **Go deep** on the candidate's area of expertise. If they're a networking person, spend the most time there with advanced follow-ups. If they're IAM-heavy, drill into SAML/SCIM/hybrid identity.
|
|
- **Cover basics** on the other areas. Once basic knowledge is confirmed, move on. Don't spend 10 minutes on storage if the candidate clearly knows it.
|
|
- **Network questions are always required**, regardless of the candidate's stated expertise.
|
|
- **Keep it conversational.** Use scenario-based questions. Avoid rapid-fire lists.
|
|
- **Be Verkada-relevant.** Frame questions around Verkada's products where natural (camera bandwidth, AC integration, badge sync, hybrid cloud).
|
|
- **Respect the 30-minute window.** Aim for 12-18 total questions across all categories. The opener, networking, and the candidate's expertise area should take the most time.
|
|
- **Generate original questions** based on the specific resume. Don't just copy the guide word for word. If the resume mentions specific technologies, vendors, or project types, write questions that probe those directly.
|
|
|
|
## Step 4: Link in Daily Note
|
|
|
|
After creating the meeting note, add it to the corresponding daily note (`~/notes/dn_YYMMDD.md`) under the `## for verkada` section:
|
|
|
|
```markdown
|
|
## for verkada
|
|
- [[mt/YYMMDD-candidate-name-tech-screen|Candidate Name - Peer Tech Screen]]
|
|
```
|
|
|
|
If the daily note doesn't exist, create it following the existing format (see `dn_*.md` files for reference).
|
|
|
|
## Step 5: Summarize for the Interviewer
|
|
|
|
After creating the meeting note, give the interviewer a concise summary:
|
|
|
|
1. **Who the candidate is** (one sentence: current role, years of experience, key certs)
|
|
2. **Area of expertise** and how deep to go
|
|
3. **Interview strategy** (where to spend time, what to surface-check, where the gaps likely are)
|
|
|
|
Keep it brief. The interviewer has reviewed the resume already; they need the strategy, not a recap.
|
|
|
|
---
|
|
|
|
# Phase 2: Post-Interview Feedback
|
|
|
|
After the interview, organize notes into the Greenhouse scorecard format. This phase runs when the user says something like "organize my interview feedback," "write up my notes," "generate scorecard," or similar.
|
|
|
|
## Data Sources (in priority order)
|
|
|
|
The feedback section must be grounded in what actually happened in the interview. Use these sources in this order:
|
|
|
|
1. **Voice evaluation dictation** (highest priority): The interviewer's raw verbal feedback recorded after the call. Query `notes.dictations` in MongoDB for dictations from the interview date that mention the candidate's name or contain interview evaluation content. This is the primary source for ratings and qualitative assessments.
|
|
2. **"# my thoughts" section in the meeting note**: The interviewer's handwritten notes taken during or immediately after the interview. These capture real-time observations.
|
|
3. **Interview transcript dictation** (if available): A recording or transcript of the actual interview conversation. Use this to verify and expand on claims from the other sources.
|
|
4. **Meeting note** (context only): The prepared questions and candidate background section provide context, but do NOT use resume bullets as evidence for ratings.
|
|
|
|
**Critical rule:** Attribute feedback to the actual conversation, not the resume. If a question wasn't asked, note that it wasn't asked. Don't infer competence from resume claims that weren't demonstrated in the interview. Exception: the interviewer's voice evaluation dictation may reference resume context when assessing fit, and that should be included.
|
|
|
|
## Step 1: Gather Sources
|
|
|
|
Query MongoDB for today's dictations:
|
|
|
|
```bash
|
|
uv run --with pymongo python3 -c "
|
|
from pymongo import MongoClient
|
|
from bson import ObjectId
|
|
client = MongoClient('mongodb://root:3wwfoUjyk2E2zWELXFlLuHqfw1ALlOp4pb2H5Vq3TImbMIHL2h1u8Jej2mjzCPl@docdb.connorrhodes.com:35563')
|
|
db = client['notes']
|
|
coll = db['dictations']
|
|
for doc in coll.find({'created_at': {'\$gte': 'YYMMDD'}}).sort('created_at', -1):
|
|
print(f'ID: {doc[\"_id\"]}')
|
|
print(f'Created: {doc.get(\"created_at\")}')
|
|
print(f'Title: {doc.get(\"title\", \"N/A\")}')
|
|
content = doc.get('content', doc.get('text', ''))
|
|
preview = content[:500] if content else 'N/A'
|
|
print(f'Content preview: {preview}')
|
|
print('---')
|
|
"
|
|
```
|
|
|
|
Identify the relevant dictations:
|
|
- One will be the **voice evaluation** (post-interview thoughts, ratings, recommendation)
|
|
- One may be an **interview transcript** (the actual conversation)
|
|
|
|
Read the full content of relevant dictations using their ObjectId.
|
|
|
|
Also read the meeting note at `~/notes/mt/YYMMDD-candidate-name-tech-screen.md` for the `# my thoughts` section and question check state.
|
|
|
|
If a PDF was provided for the interview (e.g., Greenhouse scorecard template), extract it:
|
|
|
|
```bash
|
|
pdftotext "/path/to/file.pdf" -
|
|
```
|
|
|
|
## Step 2: Generate the Feedback Section
|
|
|
|
Append the following section to the end of the meeting note. Fill in each field based on the sources in priority order.
|
|
|
|
```markdown
|
|
# Interview Feedback
|
|
|
|
1. What is the candidate's current/previous employer?
|
|
(Brief answer grounded in the conversation, not a resume dump. Include the interviewer's assessment of relevance.)
|
|
|
|
2. What is the candidate's area of expertise?
|
|
(One or two sentences identifying the area of expertise as demonstrated in the interview.)
|
|
|
|
3. Can they go deep into the indicated area of expertise? If so, how deep?
|
|
(Specific examples from the conversation: stories told, problems described, depth of technical detail.)
|
|
|
|
## Attributes
|
|
|
|
Does the candidate show clear competence in the following areas?
|
|
*(Rated on a scale from 1 to 5)*
|
|
|
|
* Networking (Required):
|
|
* Storage:
|
|
* Cloud:
|
|
* Identity & Access:
|
|
* Physical Security:
|
|
* Other:
|
|
|
|
(Rating guidelines below)
|
|
|
|
**Key Take-Aways (conclusions, pros, cons, and things to follow up on)**
|
|
|
|
**Did the candidate pass the interview?**
|
|
[ ] Definitely Not [ ] No [ ] Yes [ ] Strong Yes
|
|
```
|
|
|
|
### Rating Guidelines
|
|
|
|
- **1-2:** Evidence of a gap or weakness, either self-identified or demonstrated through inability to answer basic questions. Include what specifically was discussed or not discussed.
|
|
- **3:** Adequate but not impressive. Surface-level knowledge or the area wasn't deeply explored. Note what was and wasn't covered.
|
|
- **4-5:** Demonstrated strength. Include specific examples from the conversation that support the rating. Stories, troubleshooting examples, or architectural discussions are strong evidence.
|
|
- **Blank:** If the area was not discussed at all in the interview and the interviewer's voice note doesn't mention it, leave the rating blank with no prose.
|
|
|
|
### Attribute Prose Rules
|
|
|
|
- Ground every claim in the interview conversation or the interviewer's voice evaluation dictation
|
|
- If a question category was entirely skipped (unchecked on the meeting note), say so and don't fabricate a rating from resume claims
|
|
- Exception: if the interviewer's voice note explicitly rates an area that wasn't probed in the interview, include the rating and note that it's based on the interviewer's overall assessment rather than a specific question
|
|
- Do not list certifications or technologies from the resume as evidence of competence unless the interviewer specifically referenced them in their feedback
|
|
- Be concise. Two to three sentences per attribute is the target. More only if the candidate's performance in that area is a deciding factor.
|
|
|
|
### Key Take-Aways Structure
|
|
|
|
Organize into:
|
|
- **Pros:** What the candidate did well, relevant experience, cultural fit signals
|
|
- **Gaps:** Areas where the candidate is weaker, with context on whether the gap is addressable
|
|
- **Culture Fit:** Communication style, curiosity, questions asked, overall vibe (if the interviewer noted it)
|
|
|
|
## Step 3: Review with the Interviewer
|
|
|
|
Before appending, present the draft feedback to the interviewer for review. Ask about:
|
|
- Any ratings that seem off
|
|
- Whether to adjust the pass/fail selection
|
|
- Missing context they want added
|
|
|
|
After approval, append to the meeting note.
|
|
|
|
## Style Notes
|
|
|
|
- Skip the fluff. No "Here's your interview prep!" preamble. Go straight to the meeting note and strategy summary.
|
|
- Don't use em-dashes in the meeting note.
|
|
- Checkboxes only on questions, not on section headings.
|
|
- Keep attribute prose grounded and specific. Prefer "troubleshot X using Y to identify Z" over "demonstrated strong knowledge of X."
|