🧠 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`

5.2 KiB Raw Blame History