全栈工程师

全栈岗最看重端到端交付力。选一个你能覆盖全链路的案例：需求理解→技术选型（前端框架、后端语言、数据库）→数据模型设计→接口设计→前端实现→部署上线→迭代运维。量化结果（用户量、性能、开发周期），并说明每个环节你的个人贡献。面试官会随机抽查任一层细节（为什么这个 ORM、索引怎么建的、状态管理为什么这么选），所以只写你真正亲手做过的部分，简历注水在全栈面试里几乎必翻车。

契约先行：接口定义（OpenAPI/Proto）在开发前评审定稿，双方按契约 mock 并行开发，变更走版本化（新字段兼容旧客户端、破坏性变更升版本）。工具链：OpenAPI+Swagger 文档自动生成、代码生成客户端 SDK、CI 里加契约测试防止实现漂移。全栈的独特优势是你能同时理解两端的成本，回答时强调你会为前端易用性设计接口（聚合端点、合理分页、错误码规范），而不是让前端迁就后端的表结构。

展示全栈视角的排查链路：先测量（Lighthouse/性能面板确认瓶颈在加载还是渲染）；前端层——资源体积（代码分割、图片压缩/懒加载、字体优化）、渲染（SSR/SSG 选择、关键 CSS、虚拟列表）；网络层——CDN、HTTP/2、缓存策略（强缓存+协商缓存）；后端层——接口耗时（慢 SQL、N+1、加缓存）、聚合多次请求（BFF）；数据层——索引、读写分离。关键是分层归因而非罗列手段，并能说明每层优化的收益量级与实施成本。

考察工程基建能力：项目脚手架（monorepo 还是分仓、目录规范）、CI/CD（测试、构建、部署流水线）、代码质量（lint/format/类型检查卡点、code review 流程）、环境管理（dev/staging/prod、配置与密钥管理）、可观测性（日志、错误监控、埋点）。讲清楚每个选择的理由与替代方案，以及团队规模如何影响选型（三人和三十人的答案不同）。加分点：谈踩过的坑与后来补的课，展示基建是演进而非一步到位。

好答案承认广度是全栈的定位而非缺陷，但要有 T 型策略：以一端为主深度（如后端的系统设计与数据库，或前端的渲染性能与工程化），另一端达到高效交付的水平；深度的维护靠刻意选择——参与该端的技术方案评审、读源码、跟进社区。用实际例子佐证：如「我后端为主，最近深挖了 Postgres 索引与查询优化，线上把慢查询降了 80%」。展示对自身能力结构的清醒认知，比宣称「两端都精通」可信得多。