127 lines
5.2 KiB
Markdown
127 lines
5.2 KiB
Markdown
# 🧠 Interview Questions Pack
|
|
|
|
> Purpose: structured interviews to elicit tacit development rules that later become `steerings/` documents.
|
|
> Audience: senior engineers, leads, or architects who already maintain part of the repo and its delivery flow.
|
|
|
|
---
|
|
|
|
## 1. Codebase Topology & Ownership
|
|
|
|
**Goal:** clarify how the repo is organized, what "ownership" means, and when to reuse vs. create new code.
|
|
|
|
- Where do shared types, schemas, and business logic live?
|
|
- What files or directories are considered "do-not-touch" zones?
|
|
- When is it acceptable to add a new module vs. reuse an existing one?
|
|
- How do you decide ownership of a package or folder?
|
|
- What are the boundaries for editing shared libraries or common utilities?
|
|
- How do versioning and `workspace:*` dependencies affect this structure?
|
|
|
|
---
|
|
|
|
## 2. Architecture & Design Invariants
|
|
|
|
**Goal:** surface the invisible structure that keeps the system stable.
|
|
|
|
- What architectural layering patterns are enforced (controller/service/repo, hexagonal, CQRS, etc.)?
|
|
- Which dependency directions are allowed or forbidden?
|
|
- What naming or import alias rules exist (`@core/*`, `@features/*`, etc.)?
|
|
- What design patterns are mandatory or discouraged (events vs. sync calls, DTOs, decorators)?
|
|
- What are your caching, concurrency, or idempotency expectations?
|
|
- How do you define acceptable performance budgets (latency, memory, N+1 queries)?
|
|
- What are the conventions for APIs (REST, GraphQL, gRPC) and versioning/compatibility?
|
|
|
|
---
|
|
|
|
## 3. Business Domain Contracts
|
|
|
|
**Goal:** capture business logic invariants that constrain code behavior.
|
|
|
|
- What are the key domain entities and their invariants?
|
|
- How are permissions, roles, and entitlements enforced?
|
|
- Are there licensing tiers or feature flags that affect code paths?
|
|
- What money-handling or compliance rules shape the design (audit logs, consent, retention)?
|
|
- Are there region-specific or client-specific quirks?
|
|
- What are the naming or event rules for domain models?
|
|
|
|
---
|
|
|
|
## 4. Quality & Style Assurance
|
|
|
|
**Goal:** uncover what "high-quality" and "mergeable" mean in this context.
|
|
|
|
- What naming, formatting, and readability standards are non-negotiable?
|
|
- What must be true before merging a PR ("Definition of Done")?
|
|
- How do you enforce dependency discipline (adding/removing libs)?
|
|
- What are the rules for logging, error handling, and observability?
|
|
- What steps are included in a quality check (`pnpm qc`, lint, type-check, tests)?
|
|
- What are examples of commits or PRs that would be rejected outright?
|
|
|
|
---
|
|
|
|
## 5. Testing & Verification Strategy
|
|
|
|
**Goal:** understand how the team proves code correctness and stability.
|
|
|
|
- What test types are required for each layer (unit, integration, e2e, contract)?
|
|
- How are test folders and fixtures structured?
|
|
- What is your coverage target or philosophy (e.g. 70% meaningful coverage vs. 100%)?
|
|
- How do you treat flaky or brittle tests?
|
|
- What are "known fragile" modules or flows that require extra attention?
|
|
- How are test data and mocks handled (real DB, Docker, fake API, etc.)?
|
|
|
|
---
|
|
|
|
## 6. Risk & Historical Landmines
|
|
|
|
**Goal:** map the organization's collective memory of past failures.
|
|
|
|
- What modules or flows are risky or easy to break?
|
|
- What parts of the system "look wrong but are intentional"?
|
|
- Are there legacy shims, vendor workarounds, or design debts everyone should know?
|
|
- Which incidents led to new "never again" rules?
|
|
- What kind of changes are considered dangerous or need special review?
|
|
|
|
---
|
|
|
|
## 7. Security, Data & Compliance
|
|
|
|
**Goal:** surface hidden security expectations that engineers internalize but rarely document.
|
|
|
|
- What are the authentication/authorization boundaries?
|
|
- How should secrets and tokens be stored and accessed?
|
|
- What patterns are unsafe (direct DB access, unvalidated inputs, inline secrets)?
|
|
- How is PII or PHI classified and protected?
|
|
- What redaction or anonymization rules apply to logs and metrics?
|
|
- What are allowed inbound/outbound service communications?
|
|
- How are incidents, breaches, or audit events handled?
|
|
|
|
---
|
|
|
|
## 8. Delivery Lifecycle & Change Flow
|
|
|
|
**Goal:** make implicit shipping rules explicit.
|
|
|
|
- What is the preferred branching model and commit message format?
|
|
- How should PR templates and changelogs be filled out?
|
|
- What artifacts are required for a feature (migration plan, rollout doc, flag plan)?
|
|
- What is the usual rollout → canary → rollback flow?
|
|
- How is configuration managed (`.env` → validated config → injected)?
|
|
- What approvals or sign-offs are required before deploy?
|
|
|
|
---
|
|
|
|
## 📘 Outcome Mapping
|
|
|
|
Each interview section contributes to a steering document:
|
|
|
|
| Interview Section | Derived Steering |
|
|
|--------------------|------------------|
|
|
| Codebase Topology & Ownership | `steerings/code-ownership.md` |
|
|
| Architecture & Design Invariants | `steerings/architecture-invariants.md` |
|
|
| Business Domain Contracts | `steerings/domain-invariants.md` |
|
|
| Quality & Style Assurance | `steerings/quality-and-style.md` |
|
|
| Testing & Verification Strategy | `steerings/testing-strategy.md` |
|
|
| Risk & Historical Landmines | `steerings/risk-registry.md` |
|
|
| Security, Data & Compliance | `steerings/security-and-compliance.md` |
|
|
| Delivery Lifecycle & Change Flow | `steerings/delivery-lifecycle.md` |
|