mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/skills/graceful-degradation/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: graceful-degradation
+version: 1.0.0
+min_mindforge_version: 10.0.9
+status: stable
+triggers: graceful degradation, circuit breaker cascade, fallback hierarchy, reduced functionality mode, health-based routing, partial availability, degraded response, feature shedding, load shedding, priority-based degradation, degradation strategy, availability tier
+---
+
+# Skill — Graceful Degradation
+
+## When this skill activates
+Any task involving resilience under failure, circuit breakers, fallback hierarchies,
+load shedding, feature shedding, or priority-based degradation design.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Classify all features into availability tiers (critical/important/nice-to-have).
+2. Define fallback hierarchy for each external dependency.
+3. Identify degradation triggers and corresponding responses.
+
+### During implementation
+- Circuit breakers on all external service calls.
+- Fallback responses for every dependency (cache → static → error).
+- Feature flags to disable non-critical features under load.
+- Load shedding with priority-based request classification.
+
+### After implementation
+- Chaos test: kill dependencies, spike load, verify partial functionality.
+- Verify system remains usable when any single dependency fails.
+- Document degradation playbook for on-call.
+
+## Availability Tiers
+
+| Tier | Policy | Examples |
+|------|--------|----------|
+| Tier 1: Critical | Never shed | Auth, payments, data persistence, core API |
+| Tier 2: Important | Shed under extreme load | Search, recommendations, notifications |
+| Tier 3: Nice-to-have | Shed early | Personalization, A/B tracking, social features |
+
+## Load Shedding
+
+```
+Priority 1 (Critical):  Health checks, auth, payment finalization
+Priority 2 (High):      Core reads/writes, search
+Priority 3 (Normal):    Recommendations, analytics, batch
+Priority 4 (Low):       Prefetching, enrichment, non-critical webhooks
+```
+
+- At 80% capacity: reject P4. At 90%: reject P3+P4. At 95%: P1 only.
+- Return 503 with `Retry-After`. Never reject P1 (that means full outage).
+
+## Fallback Hierarchies
+
+```
+Live data → Cached (recent) → Static default → Graceful error (hide widget)
+```
+
+- Each level independently deployable and testable.
+- Fallback data pre-computed and stored close to consumer.
+- Never let fallback failure cascade. Log fallback frequency as health signal.
+
+## Circuit Breaker Design
+
+- **Closed** (normal): requests flow, track failure rate.
+- **Open** (tripped): return fallback immediately, no calls to dependency.
+- **Half-Open** (probing): allow 1 request to test recovery.
+- Config: 5 failures/30s → OPEN, 30s timeout → HALF-OPEN, 3 successes → CLOSED.
+
+### Cascade Prevention
+- Timeout hierarchy: A→B=2s, B→C=500ms. When C trips in B, B returns fallback to A.
+- A never sees C's failure — only potentially degraded but fast responses from B.
+
+## Health-Based Routing
+- Each instance reports health score (0-100) based on CPU, errors, latency, memory.
+- Score >80: full traffic. 50-80: reduced traffic. <50: no new traffic, drain.
+
+## Feature Shedding (Shed First)
+1. Search-as-you-type / autocomplete.
+2. Personalized recommendations (ML model calls).
+3. Real-time analytics / activity feeds.
+4. Image/video transcoding.
+5. Non-critical webhooks.
+
+Automated via feature flags tied to system load. Re-enable gradually after recovery.
+
+## Self-check before task completion
+
+- [ ] Are all features classified into availability tiers?
+- [ ] Is there a fallback for every dependency (cache → static → error)?
+- [ ] Are circuit breakers on all external calls?
+- [ ] Is load shedding priority-based with correct request classification?
+- [ ] Does the system remain usable when any single dependency fails?
+- [ ] Are feature flags in place for non-critical shedding?
+- [ ] Is the degradation playbook documented for on-call?

package/.mindforge/skills/graphql-patterns/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: graphql-patterns
+version: 1.0.0
+min_mindforge_version: 0.3.0
+status: stable
+triggers: graphql pattern, schema design graphql, resolver architecture, N+1 dataloader, graphql subscription, graphql federation, persisted query, graphql pagination, graphql error handling, schema stitching, graphql caching, type-safe graphql
+---
+
+# Skill — GraphQL Patterns
+
+## When this skill activates
+Any task involving GraphQL schema design, resolver implementation, DataLoader usage,
+subscriptions, federation, or GraphQL performance optimization.
+
+## Mandatory actions when this skill is active
+
+### Before designing a GraphQL API
+1. Identify the domain entities and their relationships.
+2. Consider consumer needs (what data do clients actually fetch together?).
+3. Plan the pagination strategy for all list fields.
+
+### Schema design principles
+
+**Entity types:**
+```graphql
+type User {
+  id: ID!
+  email: String!
+  name: String!
+  createdAt: DateTime!
+  orders(first: Int, after: String): OrderConnection!
+}
+```
+
+**Input types for mutations:**
+```graphql
+input CreateUserInput {
+  email: String!
+  name: String!
+  password: String!
+}
+
+type CreateUserPayload {
+  user: User
+  errors: [ValidationError!]!
+}
+```
+
+**Enum for fixed sets:**
+```graphql
+enum OrderStatus {
+  PENDING
+  PROCESSING
+  SHIPPED
+  DELIVERED
+  CANCELLED
+}
+```
+
+**Rules:**
+- Never expose database columns directly (abstract the data model).
+- Use non-nullable (!) for fields that always have a value.
+- Mutations return the modified entity (not just success/failure).
+- Input types are separate from output types (different validation needs).
+- Use Connections (not arrays) for all list fields.
+
+### N+1 problem and DataLoader
+
+**The problem:**
+```
+Query: { users { orders { items } } }
+1 query for users
+N queries for orders (one per user)
+N*M queries for items (one per order)
+```
+
+**The solution — DataLoader:**
+```javascript
+const orderLoader = new DataLoader(async (userIds) => {
+  // ONE query for ALL user IDs
+  const orders = await db.orders.findMany({ where: { userId: { in: userIds } } });
+  // Map results back to the correct user
+  return userIds.map(id => orders.filter(o => o.userId === id));
+});
+
+// In resolver
+resolve(user) {
+  return orderLoader.load(user.id);
+}
+```
+
+**Rules:**
+- Use DataLoader for ALL nested resolvers that fetch from a data source.
+- Create a new DataLoader instance per request (request-scoped caching).
+- Batch window is one tick of the event loop.
+- DataLoader handles both batching AND per-request caching.
+
+### Pagination (Relay Connection spec)
+
+```graphql
+type OrderConnection {
+  edges: [OrderEdge!]!
+  pageInfo: PageInfo!
+  totalCount: Int
+}
+
+type OrderEdge {
+  node: Order!
+  cursor: String!
+}
+
+type PageInfo {
+  hasNextPage: Boolean!
+  hasPreviousPage: Boolean!
+  startCursor: String
+  endCursor: String
+}
+```
+
+**Implementation:**
+- Cursor = opaque base64-encoded value (e.g., `base64(id:123)`).
+- Forward pagination: `first` + `after` (cursor).
+- Backward pagination: `last` + `before` (cursor).
+- totalCount is optional (expensive on large tables — make nullable).
+
+### Subscriptions
+
+**Transport:** WebSocket (graphql-ws protocol).
+
+**Design rules:**
+- Filter server-side, not client-side (don't push all events to all clients).
+- Rate-limit expensive subscriptions (e.g., max 1 update per second).
+- Include subscription-specific authentication (WebSocket auth on connection_init).
+- Handle reconnection gracefully (client should re-subscribe on disconnect).
+
+**Example:**
+```graphql
+type Subscription {
+  orderStatusChanged(orderId: ID!): Order!
+  newMessage(channelId: ID!): Message!
+}
+```
+
+**Backend:**
+- Use pub/sub (Redis, Kafka) for horizontal scaling.
+- Single server: in-memory EventEmitter is fine for development.
+- Production: external pub/sub so any server instance can publish.
+
+### Federation (microservices)
+
+**Split schema by domain team:**
+```graphql
+# Users service
+type User @key(fields: "id") {
+  id: ID!
+  email: String!
+  name: String!
+}
+
+# Orders service (extends User from users service)
+extend type User @key(fields: "id") {
+  id: ID! @external
+  orders: [Order!]!
+}
+```
+
+**Rules:**
+- Each service owns its types and resolvers.
+- `@key` directive defines how entities are referenced across services.
+- Gateway (Apollo Router, Cosmo) composes the supergraph.
+- Services must resolve `__resolveReference` for federated entities.
+- Schema changes require composition check in CI (schema registry).
+
+### Persisted queries
+
+**How it works:**
+- Build time: extract all queries from client code, hash each one.
+- Client sends hash (not full query text) in production.
+- Server looks up query by hash from allowlist.
+
+**Benefits:**
+- Smaller request payloads (hash vs full query text).
+- Prevents arbitrary queries (only allowlisted hashes accepted).
+- CDN caching possible (GET requests with query hash as key).
+
+**Implementation:**
+- Use `graphql-codegen` or `relay-compiler` to extract and hash.
+- Reject unknown hashes in production (security hardening).
+- Allow full queries in development for iteration speed.
+
+### Error handling
+
+```graphql
+type Mutation {
+  createOrder(input: CreateOrderInput!): CreateOrderPayload!
+}
+
+type CreateOrderPayload {
+  order: Order
+  errors: [UserError!]!
+}
+
+type UserError {
+  field: [String!]
+  message: String!
+  code: ErrorCode!
+}
+```
+
+**Rules:**
+- Use payload types with `errors` field for expected user errors (validation, business logic).
+- Use GraphQL errors (top-level `errors` array) only for unexpected failures.
+- Never expose internal error details (stack traces, SQL errors) to clients.
+- Include error codes (enum) for programmatic client handling.
+
+### Caching
+
+**HTTP caching (persisted queries via GET):**
+- Cache-Control headers on responses.
+- CDN caching for public, non-personalized queries.
+
+**Normalized client cache (Apollo Client, urql):**
+- Entities cached by `__typename + id`.
+- Mutations automatically update cache when returning modified entities.
+- Use `cache.evict()` for deletions.
+
+**Server-side (DataLoader per-request + Redis):**
+- DataLoader: automatic per-request deduplication.
+- Redis: cross-request caching for expensive computations.
+- Set appropriate TTL based on data freshness requirements.
+
+### Type safety (end-to-end)
+
+- Generate TypeScript types from schema: `graphql-codegen`.
+- Generate typed hooks for client queries: `@graphql-codegen/typescript-react-apollo`.
+- Schema-first development: change schema → regenerate types → compiler catches mismatches.
+- CI check: generated types must be up to date (no uncommitted codegen changes).
+
+## Self-check before task completion
+- [ ] Did I follow the mandatory actions for this skill?
+- [ ] Did I apply the patterns appropriate to the context?
+- [ ] Did I verify the implementation meets the criteria above?
+- [ ] Did I document decisions and trade-offs made?

package/.mindforge/skills/guardrails-and-safety/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: guardrails-and-safety
+version: 1.0.0
+min_mindforge_version: 10.0.7
+status: stable
+triggers: guardrails, ai safety layer, hallucination detection, output validation layer, content filtering, ai boundary enforcement, graceful degradation pattern, confidence calibration, refusal pattern, safety guardrail, output quality gate, ai output control
+---
+
+# Guardrails and Safety
+
+## When this skill activates
+
+This skill activates when designing safety layers for AI systems, validating AI outputs, detecting hallucinations, filtering harmful content, enforcing behavioral boundaries, or implementing graceful degradation. Use this skill whenever AI-generated output is consumed by users or downstream systems and correctness, safety, or trustworthiness is a requirement.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Risk assessment** — Classify the risk level of the AI output. High risk: medical/legal/financial advice, code that handles money/auth, user-facing claims. Low risk: internal summaries, creative brainstorming, non-critical formatting.
+2. **Define failure modes** — Enumerate what can go wrong: hallucinated facts, malformed output, harmful content, scope creep, leaked system prompts, confidently wrong answers.
+3. **Identify stakeholders** — Who consumes this output? End users, other AI agents, automated systems? Each requires different guardrail approaches.
+4. **Establish ground truth** — Determine what sources can be used to verify AI claims. No verification source = higher hallucination risk.
+
+### During
+
+#### Output Validation (Schema Check, Reference Grounding, Claim Verification)
+
+**Schema validation:**
+- Parse all structured outputs through a schema validator (Zod, Pydantic, JSON Schema).
+- Reject outputs that don't conform. Never silently accept malformed data.
+- Validate semantic constraints beyond syntax: dates in the past, IDs that exist, values within valid ranges.
+
+**Reference grounding:**
+- For factual claims, require the AI to cite specific sources from the provided context.
+- Verify citations actually exist in the context window. Reject fabricated references.
+- Cross-reference extracted facts against the source document. Flag discrepancies.
+
+**Claim verification pipeline:**
+```
+AI Output → Extract claims → Match claims to source → Score confidence → Flag ungrounded claims
+```
+
+- Claims with no source match receive a "unverified" flag.
+- Claims contradicting source receive a "contradicted" flag.
+- Only claims with verified source matches pass without flags.
+
+#### Hallucination Detection
+
+- **Citation requirement** — For factual tasks, require inline citations: "[from file.ts:42]". Absence of citations on factual claims is a hallucination signal.
+- **Self-consistency check** — Ask the same question multiple times (temperature > 0). If answers diverge significantly, confidence should be low.
+- **Source comparison** — Compare AI output against retrieved context. Claims not present in context are hallucination candidates.
+- **Knowledge boundary awareness** — Train the system to say "I don't have information about X" rather than fabricate. Reward refusal over confabulation.
+- **Confidence scoring** — Implement a scoring function:
+  - 1.0: Directly quoted from source
+  - 0.8: Clearly supported by source
+  - 0.5: Plausible inference from source
+  - 0.2: Not supported, model's general knowledge
+  - 0.0: Contradicts available evidence
+
+#### Content Filtering
+
+**PII detection:**
+- Scan outputs for patterns: email addresses, phone numbers, SSNs, credit card numbers, physical addresses.
+- Use regex for structured PII + NER models for unstructured PII (names, locations in context).
+- Action: redact, mask, or block output containing PII not explicitly requested.
+
+**Toxicity filtering:**
+- Apply toxicity classifiers to AI outputs before delivery.
+- Threshold: block outputs scoring above toxicity threshold (adjust per use case).
+- Log blocked outputs for review and model improvement.
+
+**Off-topic detection:**
+- Compare output topic to the requested task.
+- If the AI produces content unrelated to the request, it may be following injected instructions.
+- Action: flag for review, re-generate with stronger constraints.
+
+#### Boundary Enforcement (Scope Limits, Capability Declaration)
+
+- **Capability declaration** — The system prompt must explicitly state what the AI can and cannot do. This is not optional.
+- **Scope fencing** — Define topics/actions that are in-scope vs out-of-scope. Out-of-scope requests receive a structured refusal, not an attempt.
+- **Action restrictions** — List dangerous actions the AI must never take (delete production data, send emails without confirmation, execute unreviewed code).
+- **Escalation triggers** — Define conditions that require human review before proceeding: confidence below threshold, ambiguous instructions, high-impact actions.
+
+**Boundary enforcement template:**
+```
+You CAN: [list of permitted capabilities]
+You CANNOT: [list of restricted capabilities]
+When uncertain: [escalation procedure]
+When asked to do something restricted: [refusal response]
+```
+
+#### Graceful Degradation
+
+- **Partial answer over no answer** — If the AI can answer part of the question confidently, provide that part and explicitly flag what it cannot answer.
+- **Confidence flagging** — Prefix uncertain claims with qualifiers: "Based on the provided context...", "I'm not certain, but...", "This may be incomplete because..."
+- **Fallback hierarchy:**
+  1. Full confident answer (ideal)
+  2. Partial answer with uncertainty flags (acceptable)
+  3. Structured "I cannot answer because..." (acceptable)
+  4. Silent failure or confident wrong answer (unacceptable)
+- **Degradation transparency** — Always tell the user what information is missing and why the answer may be incomplete.
+
+#### Confidence Calibration
+
+- **Calibration principle** — Expressed confidence must match actual accuracy. "Definitely" = right >95% of the time.
+- **Banned phrases when uncertain** — "certainly", "definitely", "obviously", "without doubt" unless grounded in verified source.
+- **Required phrases when uncertain** — "likely", "based on available information", "this appears to be", "I'm not certain but".
+- **Metacognitive awareness** — The AI must identify gaps in its knowledge: "I don't have enough context to answer this part."
+
+#### Refusal Patterns (When to Refuse)
+
+**Refuse when:** harmful content requested, clearly out of scope, insufficient context with high stakes, capabilities not available, or safety boundaries would be violated.
+
+**Refusal format:** "I cannot [action] because [reason]. What I can do instead: [alternative]."
+
+- **Never refuse without explanation.** Always state why and offer alternatives.
+- **Never refuse legitimate requests.** Overly cautious refusals degrade trust and usability.
+
+### After
+
+1. **Audit guardrail triggers** — Review what was blocked/flagged. High false-positive rate means guardrails are too aggressive.
+2. **Measure hallucination rate** — Sample outputs and verify claims against sources. Track rate over time.
+3. **Test adversarially** — Attempt to bypass guardrails with injection, social engineering, and edge cases. Patch gaps.
+4. **User feedback loop** — Collect reports of incorrect outputs that passed guardrails. These are the most valuable signals.
+
+## Self-check before task completion
+
+- [ ] Output validation schema is defined and enforced programmatically
+- [ ] Hallucination detection is active for factual claims (citation requirement or source comparison)
+- [ ] PII filtering scans all user-facing outputs
+- [ ] Capability boundaries are explicitly declared in system prompt
+- [ ] Graceful degradation is implemented (partial answers > silent failures)
+- [ ] Confidence calibration prevents false certainty on ungrounded claims
+- [ ] Refusal patterns provide clear explanation and alternatives
+- [ ] Guardrails have been tested adversarially with bypass attempts
+- [ ] False positive rate is monitored and acceptable
+- [ ] Escalation path exists for edge cases guardrails cannot resolve

package/.mindforge/skills/healthcare-systems/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: healthcare-systems
+version: 1.0.0
+min_mindforge_version: 10.2.0
+status: stable
+triggers: healthcare system, HIPAA compliance, HL7 FHIR, PHI handling, clinical workflow, EHR integration, health data exchange, medical record system, healthcare interoperability, patient data protection, health information exchange, clinical data model
+compose: compliance-as-code
+---
+
+# Skill — Healthcare Systems
+
+## When this skill activates
+This skill activates when designing, building, or auditing healthcare systems that handle Protected Health Information (PHI), integrate with Electronic Health Records (EHR), implement clinical workflows, or require HIPAA compliance and healthcare interoperability standards.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Conduct HIPAA compliance audit: identify all PHI touchpoints (patient names, DOB, SSN, medical records, diagnoses, prescriptions) and document encryption requirements (AES-256 at rest, TLS 1.3 in transit)
+2. Review HL7 FHIR resource specifications for all clinical data models (Patient, Observation, Condition, MedicationRequest, Encounter) and validate against FHIR R4 or R5 conformance requirements
+3. Map clinical workflows to business requirements: patient registration, provider authentication, order entry (CPOE), medication administration records (MAR), clinical notes (SOAP), discharge summaries, and continuity of care documents (CCD)
+
+### During implementation
+- Implement BAA-compliant audit logging for all PHI access: capture user identity, timestamp, action type, resource accessed, IP address, and store logs in WORM (write-once-read-many) storage with 7-year retention
+- Enforce role-based access control (RBAC) with principle of least privilege: separate roles for physicians, nurses, pharmacists, billing staff, and patients, with explicit consent workflows for data sharing between organizations
+- Use FHIR-native authentication (SMART on FHIR) with OAuth 2.0 authorization code flow, patient-level scopes (patient/*.read), and refresh token rotation for mobile health apps
+- Implement de-identification pipelines for research datasets: remove 18 HIPAA identifiers (names, dates, geocodes, phone numbers, medical record numbers) using regex patterns and NLP entity recognition
+- Design interoperability interfaces using FHIR REST APIs with proper content negotiation (application/fhir+json), search parameters (?patient=123&category=vital-signs), and batch/transaction bundles for atomic operations
+
+### After implementation
+- Execute security testing: penetration testing for OWASP Top 10 healthcare vulnerabilities (SQL injection in patient search, XSS in clinical notes, broken authentication), vulnerability scanning, and threat modeling for ransomware/data exfiltration scenarios
+- Validate FHIR conformance using HL7 validation tools: check resource structure, cardinality constraints, required terminology bindings (LOINC for labs, SNOMED CT for diagnoses, RxNorm for medications), and profile compliance
+- Conduct end-to-end clinical workflow testing with real provider scenarios: patient check-in, vital signs capture, order placement, results review, prescription writing, and documentation with audit trail verification
+
+## Self-check before task completion
+- [ ] All PHI is encrypted at rest (AES-256) and in transit (TLS 1.3), with key management via HSM or cloud KMS
+- [ ] Audit logs capture all PHI access events with user attribution and are tamper-evident (cryptographic hashing or blockchain anchoring)
+- [ ] FHIR resources validate against published profiles, use standard terminologies (LOINC/SNOMED/RxNorm), and implement proper search parameters
+- [ ] Access control enforces least privilege, requires MFA for administrative access, and implements automatic session timeouts (15 minutes idle)
+- [ ] Business Associate Agreement (BAA) requirements are documented, including breach notification procedures and subprocessor agreements
+- [ ] Clinical workflows have been validated by domain experts (physicians, nurses) for safety and usability

package/.mindforge/skills/hiring-engineering/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: hiring-engineering
+version: 1.0.0
+min_mindforge_version: 10.3.0
+status: stable
+triggers: hiring engineer, technical interview design, coding challenge creation, system design interview rubric, candidate evaluation rubric, hiring pipeline engineering, technical assessment, technical interview scorecard, take-home assignment design, hiring committee, engineering recruitment, technical screen design
+compose:
+  - technical-interview-design
+---
+
+# Hiring Engineering
+
+## When this skill activates
+
+This skill activates when designing technical interviews, creating coding challenges, evaluating engineering candidates, building interview scorecards, designing take-home assignments, or participating in hiring committees. It applies to senior engineers, tech leads, and engineering managers responsible for growing their teams.
+
+## Mandatory actions when this skill is active
+
+### Before starting the hiring process
+
+1. **Define the role requirements explicitly** — List must-have skills (e.g., 3+ years backend Go, experience with Postgres, strong testing discipline) and nice-to-have skills (e.g., distributed systems, Kubernetes). Vague requirements attract the wrong candidates.
+2. **Identify assessment dimensions** — What are you evaluating? Common dimensions: coding ability, system design, debugging, communication, collaboration, problem-solving, learning agility. Map each interview stage to 1-2 dimensions.
+3. **Calibrate the bar** — Look at your current top performers. What skills/behaviors do they exhibit? Use that as the hiring bar. Don't hire people you wouldn't be excited to work with.
+4. **Design the interview pipeline** — Typical stages: recruiter screen → technical phone screen → take-home or live coding → system design → behavioral → hiring committee. Each stage filters for different signals.
+
+### During interview design
+
+#### Technical Phone Screen (30-45 minutes)
+
+- **Goal** — Validate basic coding competency before investing in longer interviews. Filter out candidates who can't code at all.
+- **Format** — 1-2 small problems (e.g., manipulate a string, traverse a tree). Real-time coding in a shared editor (CoderPad, Replit).
+- **Pitfall** — Don't make it a LeetCode grind. Focus on practical problems similar to your day-to-day work, not algorithmic olympiad questions.
+- **Scoring** — Pass/Fail. Pass if candidate writes working code with prompting. Fail if they can't produce a solution even with hints.
+
+#### Coding Challenge (Take-Home or Live Coding)
+
+**Take-Home Assignment Design:**
+- **Scope** — Should take 2-4 hours. Respect candidate's time. Projects that take 8+ hours are disrespectful.
+- **Realism** — Design problems that resemble actual work. Building a mini REST API is better than "implement quicksort."
+- **Evaluation criteria** — Code correctness, test coverage, edge case handling, documentation, architecture. Provide a rubric upfront.
+- **Pitfall** — Don't make it too open-ended. Candidates will over-engineer. Give constraints: "Use language X, don't spend more than Y hours."
+
+**Live Coding Session:**
+- **Duration** — 45-60 minutes. One medium-difficulty problem.
+- **Interactivity** — Treat it as pair programming, not an exam. Ask clarifying questions, give hints if stuck, discuss tradeoffs.
+- **What to look for** — Can they break down the problem? Write clean code? Test edge cases? Communicate their thought process?
+- **Pitfall** — Don't stay silent while they code. Engage. The goal is to simulate real collaboration.
+
+#### System Design Interview (60 minutes)
+
+- **Goal** — Assess candidate's ability to design scalable, maintainable systems. Evaluates architectural thinking, tradeoff analysis, and communication.
+- **Format** — Open-ended problem: "Design a URL shortener" or "Design a chat system." Candidate drives the conversation.
+- **What to evaluate** — Requirements gathering, high-level architecture, component design, data model, API design, scale considerations, tradeoffs.
+- **Pitfall** — Don't expect candidates to know your exact tech stack. If they propose Redis but you use Memcached, that's fine. The pattern matters, not the tool.
+- **Hints to look for strength** — Do they ask clarifying questions? Do they consider scale and failure modes? Do they make tradeoffs explicit?
+
+#### Behavioral Interview (45 minutes)
+
+- **Goal** — Assess collaboration, communication, adaptability, conflict resolution, and learning agility.
+- **Format** — STAR questions (Situation, Task, Action, Result): "Tell me about a time you disagreed with a teammate. How did you resolve it?"
+- **What to evaluate** — Self-awareness, ownership, growth mindset, team orientation, handling of ambiguity.
+- **Pitfall** — Don't accept vague answers. Probe: "What specifically did you do?" "What was the outcome?" "What would you do differently next time?"
+
+#### Debugging/Troubleshooting Interview (Optional, 45 minutes)
+
+- **Goal** — Assess candidate's ability to diagnose and fix production issues. Especially valuable for senior hires.
+- **Format** — Give candidate a broken codebase or system. Ask them to identify the issue and fix it.
+- **What to evaluate** — Debugging process, use of tools (logs, debuggers, metrics), hypothesis testing, communication.
+- **Pitfall** — Don't make it obscure. The bug should be findable with reasonable effort (30-40 minutes).
+
+### During candidate evaluation
+
+#### Scorecard Design
+
+- **Use a consistent rubric** — Each dimension (coding, system design, communication) gets a 1-4 score: 1 = Strong No, 2 = No, 3 = Yes, 4 = Strong Yes. Define what each score means.
+- **Provide evidence, not just scores** — Don't write "Communication: 3." Write "Communication: 3 – Candidate clearly explained their architecture choices and responded well to probing questions."
+- **Avoid bias** — Don't let the candidate's similarity to you inflate scores. Evaluate against the rubric, not your personal preferences.
+- **Distinguish between "not demonstrated" and "weak"** — If the candidate didn't have a chance to show a skill (e.g., debugging wasn't tested), mark it as "N/A," not a low score.
+
+#### Hiring Committee Best Practices
+
+- **All interviewers submit scorecards before the meeting** — Prevents groupthink. If everyone reads each other's feedback first, later voters anchor on early opinions.
+- **Discuss discrepancies first** — If one interviewer gave a Strong Yes and another gave a No, discuss why before discussing the overall hire/no-hire decision.
+- **Avoid "they're not a culture fit" as a veto reason** — That phrase often masks unconscious bias. Be specific: what behavior or value misalignment did you observe?
+- **Use the "would you want this person on your team?" test** — If the answer is no, it's a no-hire. Hiring mediocre engineers lowers the bar and demoralizes high performers.
+
+#### Red Flags in Candidates
+
+- **Can't explain their own code** — If they wrote it but can't articulate the reasoning, they likely copy-pasted.
+- **Blames teammates for failures** — "My team was slow, so the project failed." Red flag for collaboration and ownership.
+- **Doesn't ask clarifying questions** — Jumps into coding without understanding requirements. Shows poor communication and product sense.
+- **Over-engineers simple problems** — Proposes microservices for a CRUD app. Shows lack of pragmatism.
+- **Dismissive of feedback** — When given a hint or suggestion, becomes defensive. Shows poor learning agility.
+
+#### Green Flags in Candidates
+
+- **Admits when they don't know** — "I haven't used Kubernetes, but here's how I'd approach learning it." Shows humility and learning agility.
+- **Communicates tradeoffs clearly** — "Option A is faster but harder to maintain. Option B is slower but more reliable." Shows architectural maturity.
+- **Writes tests without prompting** — Shows quality-first mindset.
+- **Asks insightful questions** — About architecture, team culture, technical challenges. Shows genuine interest.
+- **Handles ambiguity well** — When the problem is open-ended, they ask clarifying questions and propose a structured approach.
+
+### After interviews
+
+- **Debrief immediately** — Submit scorecards within 24 hours while memory is fresh. Delayed feedback loses fidelity.
+- **Provide candidate feedback (if rejected)** — Not legally required, but considerate. Keep it high-level: "We were looking for more depth in system design." Don't critique their personality.
+- **Track hiring pipeline metrics** — Pass rates at each stage, time to hire, offer acceptance rate, source of hire (referrals, LinkedIn, etc.). Optimize the bottlenecks.
+- **Improve interview questions over time** — If a question doesn't differentiate strong vs weak candidates, retire it. Iterate based on hiring outcomes.
+
+## Self-check before task completion
+
+- [ ] Role requirements are explicit with must-have and nice-to-have skills
+- [ ] Assessment dimensions are mapped to specific interview stages
+- [ ] Interview pipeline is designed with clear goals for each stage
+- [ ] Take-home assignments are scoped to 2-4 hours with clear evaluation criteria
+- [ ] System design interviews focus on tradeoff analysis, not memorized solutions
+- [ ] Scorecards use a consistent rubric with evidence, not just scores
+- [ ] Hiring committee reviews scorecards independently before group discussion
+- [ ] Red flags (can't explain own code, blames teammates) are documented and weighted appropriately