你做的一个功能出了 bug，但不知道谁负责这个服务，找了 3 个人都说"不是我"，你该怎么办？
不要陷入"谁都不认"的推诿。先通过客观信息定位：服务代码仓库的 CODEOWNERS、Git 提交历史里最近改动者、oncall 名单、告警/监控系统的归属配置、服务治理平台的 owner 字段。找到最接近的负责人后，把"具体 bug 现象 + 复现 + 我为什么认为是这个服务"讲清楚，请他确认或指认正确负责人。同时把问题记录在案，避免丢失。
靠"问人"容易遇推诿，靠"客观信息"可以锚定归属。先自查代码所有权和监控配置，再带着证据去问，既高效又避免制造对立。若确实找不到，升级到团队负责人让其裁定。
你做的功能上线后发现依赖的服务有变更，你不知道找谁问，你该怎么找到该服务的 owner？
先通过服务治理平台、服务目录、API 文档查该服务的 owner 和联系方式；若没有，再查该服务代码仓库的提交历史、CODEOWNERS 或最近一次变更的 MR 记录，找到变更提交人。把"依赖服务的变更具体是什么、影响了我哪个功能"整理清楚，先发消息给 owner；若 owner 缺失，则升级到该服务所在团队或基础设施负责人。
服务 owner 通常有结构化记录（服务目录、CODEOWNERS），先查这些客观来源。没有则用变更历史回溯。核心是带着具体影响去问，让对方快速理解并响应，而不是空泛地问"谁负责"。
你做的功能依赖了 5 个内部服务，每个服务的 owner 你都不认识，你该怎么找到他们？
先做一张依赖清单：把 5 个服务的名称、作用、依赖关系列出来，然后通过服务目录、API 文档、代码仓库 CODEOWNERS、治理平台批量获取每个服务的 owner 和联系方式。找到后，一次性向各 owner 发一条结构化说明（我是谁、在做什么、依赖了你的什么服务、为什么需要联系），并建立一张可复用的依赖-owner 对照表，方便后续维护。
面对多个依赖，不能逐个临时找人，而应系统化梳理。借助服务目录和 CODEOWNERS 批量定位，再统一发起沟通，效率高且专业。建立依赖清单还能沉淀为团队资产，避免重复劳动。
你做的功能使用了团队老的内部 API，文档上写的维护者已经离职，你该怎么办？
先查该 API 对应代码仓库的提交历史、MR 记录、CODEOWNERS，找出离职者之后实际负责或最近改动的人，他们更可能是当前维护者。同时查看该 API 的调用方、测试和告警来理解其真实行为。找到负责人后，把"文档已过时、维护者已离职"这个信息补充给团队，推动更新文档归属，避免后来人再踩坑。
文档维护者可能过时，但代码提交历史是相对客观的。通过历史记录找实际维护者，再主动更正文档，既解决当下问题，也把经验沉淀下来。体现出对团队信息资产的责任感。
你想联系另一个组的接口人，但对方说"找我们 leader"，而该 leader 很忙，你该怎么办？
不要被"找 leader"挡回。先整理清楚的背景：我想对接什么问题、需要对方组做什么、为什么必须由那个 leader 决策、有没有更简单的替代路径。把这条信息以简洁书面形式发给对方 leader，同时请接口人代为转达或安排一个 15 分钟短会。如果 leader 确实忙，明确询问一个合适的时间或可委托的具体负责人，避免无限等待。
"找 leader"往往是因为对方不愿做决定或怕担责。把问题讲清楚、给对方低摩擦的决策路径，能显著推进。备好替代方案和具体时间请求，体现专业与尊重，避免被"忙"这个理由无限拖延。
入职后你想画一张团队依赖图，但 leader 说"没必要"，你该怎么用价值说服他？
不要强调"画图本身"，而是说明它解决的具体问题：新人上手快、减少"找不到 owner"的沟通成本、定位故障更快、避免重复依赖。可以先低成本做一个最小版本（只覆盖核心服务），用真实案例证明它帮团队解决了什么问题（比如某次找人花了很久），再让 leader 评估是否值得完善。让价值先行，而不是图纸先行。
leader 说"没必要"往往是没看到 ROI。把抽象动作转化为可量化的收益（省时间、降风险、少踩坑），并用最小成本先行验证，是说服的关键。先证明，再推广。
入职后发现团队的 Confluence 上有很多文档，但不知道哪份是权威的，你该怎么判断？
用几个信号判断权威性：文档的最近更新时间和作者是否权威、是否有"官方/标准/规范"标识、是否被广泛引用或链接、内容是否与代码/配置一致。必要时交叉验证：把文档里的关键信息与代码库、配置、实际操作对照。若仍不确定，直接问团队里资深的同事或文档责任人在哪，并可以主动在各文档中标注"以哪份为准"。
权威文档通常有"最近更新 + 明确作者 + 被引用 + 与代码一致"的特征。交叉验证比单看标题可靠。问人确认是兜底，把"哪份为准"沉淀下来能帮后来人，也是团队知识管理的加分项。
你想选一个有挑战的项目来证明自己，但导师说"新人先做简单的"，你该怎么 argue？
先理解导师的顾虑（可能是风险、进度、你对系统的熟悉度），然后针对性地回应：说明自己为这个挑战项目做了哪些准备（已熟悉相关代码、读过文档、有相关经验），并给出分阶段方案——先做核心的小模块、由导师把关，降低风险。同时表态会把现在的基础工作做好，不因想挑战而态度敷衍。用"我能承担风险 + 有保底"来争取。
导师说"先做简单的"是出于风险控制，不是否定你。argue 的关键是降低对方的风险感知：证明自己有能力、给出分阶段执行和兜底方案，同时尊重当前安排。先赢信任，再谈更大挑战。
你选的第一个项目上线后出了 bug，leader 质疑"是不是你经验不够"，你该怎么 argue？
先不反驳，先承认事实并求真：把 bug 的根因、产生环节、上线前哪些环节本可拦截（测试、review、灰度）分析清楚。然后区分这是"经验不足"还是"流程/测试覆盖不足"，坦诚地承认自己可以改进的部分，同时给出具体的整改方案（补测试、加监控、走 review、灰度发布）。用"复盘 + 行动"回应质疑，而不是用嘴硬。
leader 的质疑有时是压力测试，有时是真实关切。专业回应是承认问题、给出根因和整改，而非辩解。把"能力"与"流程"分开，能体现清晰的归因能力，让 leader 看到你从错误中成长。
你选的第一个项目被 leader 改了三次需求，你怀疑 leader 没想清楚，你该怎么办？
不要把"改需求"当成 leader 的错，而是先理解每次变更背后的业务原因。主动把三次变更的差异整理出来，分析哪些是必要调整、哪些是信息缺失导致的返工，然后在正式沟通中温和地提出：建议在开发前先做一轮需求澄清和设计评审，把关键假设列出来和 leader 对齐。用"帮大家减少返工"的立场，而不是"你想法不清"的指责。
需求反复常源于前期澄清不足，而非态度问题。把变更趋势客观呈现，并提出"评审前置"的机制，能同时改善进度和关系。从协作角度而非指责角度切入，leader 更容易接受。
你选的第一个项目是你独自完成的，没有人 review，leader 质疑"为什么不协作"，你该怎么办？
先承认这个环节的不足：独立完成确实错失了 review 带来的质量与风险把控。解释原因（可能是觉得项目小、或担心打扰别人），然后立即改进：主动把代码提交给团队 review，邀请有经验的同事审阅，并说明希望得到什么反馈。同时主动在后续项目中主动拉人评审、结对，把协作变成习惯。
review 不只是质量把关，也是协作与信任的体现。leader 质疑是提醒你重视团队机制。坦诚承认 + 立即补上 review + 建立后续协作习惯，比辩解"我一个人能做"更成熟。
入职后你想了解团队的代码仓库结构，但仓库连 README 都没有，你该怎么自己梳理？
从几个客观入口入手：看构建/部署配置（如 Dockerfile、CI 配置、pom/package.json）理解模块边界和运行方式；看目录结构、入口文件、包名/命名规范推断职责；看 git 提交历史了解模块演进；必要时问资深同事确认。把梳理结果整理成一份简单文档（模块、职责、依赖、入口），标注"我整理的，待确认"，主动分享给团队，既验证准确性又弥补 README 缺失。
没有 README 时，配置、入口、历史是天然的"文档"。逆向梳理 + 主动沉淀分享，既帮助自己理解，也补全团队知识，还能通过他人确认纠偏。这是新人快速建立全局认知的有效方式。
入职后发现团队的 oncall 名单里没有你，但实际的事故却都找你处理，你该怎么处理？
先理解现状：事故找你可能因为你熟悉相关服务或时间凑巧，但这不是正式责任。主动和 leader 澄清：当前 oncall 名单里没有你，但实际事故都在找你，这样既影响正式责任人的明确性，也让你没有相应保障。建议要么把你正式纳入 oncall 轮值（获得相应支持与认可），要么明确事故通知的归属和升级路径。同时先把手头的事故处理完，避免出问题。
责任与资源不匹配是隐患：你承担了 oncall 的活却没有正式地位和保障。核心是"名实相符"——要么正式纳入轮值，要么把责任归属理顺。用澄清而非对抗的方式，既负责又维护权益。
入职第一周你如何建立"求助网络"（谁懂什么、遇到什么问题找谁），并验证信息的准确性？
先通过观察和人脉建立初步地图：看组织架构、oncall 名单、代码所有权、大家常被拉进哪些群，把"谁负责什么、谁懂什么"记录下来。然后通过两种方式验证：一是在实际工作中遇到问题去问对应的人，看他能否快速给出准确答案；二是把二手信息（别人告诉我的）与公开信息（文档、代码）交叉核对。最后把验证过的求助网络整理成一张自己私有的清单，随着项目经验持续更新。
求助网络的价值在于"准确"，而准确性需要在实践中验证。先建立初稿，再用真实问题检验、用公开信息交叉核对，逐步迭代。这样既能快速求助，又能避免被错误信息误导。
你选的第一个项目上线后效果不如预期，leader 建议"换个项目做"，你该怎么办？
先接受 leader 的调整，不固执己见。主动做一次复盘：项目效果不如预期是目标问题、执行问题还是资源问题，把经验教训提炼出来。然后向 leader 表明你理解了调整的原因，并带着复盘结论去新项目，把经验转化为行动。问清楚新项目的期望，避免重蹈覆辙。
项目效果不佳而换项目，是正常的业务调整，不是否定个人。成熟的姿态是复盘、接受、改进。把"为什么没达到预期"想清楚，才能在新项目里避免同样问题，这也让 leader 看到你的成长性。
入职第一个月你想选一个高 ROI 的项目，但 leader 说"先做杂活熟悉环境"，你该怎么办？
先接受"做杂活"这个安排，理解这是让你熟悉环境、建立信任的必要过程。但不要只是被动接活：在杂活中主动挖掘价值（比如把重复杂活工具化、记录过程中发现的痛点），把杂活做出亮点。同时与 leader 沟通，说明你希望在熟悉后逐步承担更有挑战的工作，并给出你学习的进度。让 leader 看到你既有耐心又渴望成长。
高 ROI 项目通常需要信任和熟悉度做前提。新人先做杂活是建立信任的路径，关键是把杂活做出价值、同时表达成长意愿。用成果而非态度去换取机会，才是稳妥策略。
你选择的第一个交付切片如何与 leader 约定"完成标准"，避免做了很久才发现方向不对？
在动手前就和 leader 明确"完成标准"：交付物是什么、满足什么条件算完成、优先级如何排序、有没有硬性 deadline。把标准拆成可验证的小里程碑，并约定在每个里程碑同步一次，让 leader 及时纠偏。同时主动提出"先做最小可用部分，确认方向后再深入"，用小步快跑降低方向错误的风险。
方向错误的根源往往是"完成标准"模糊。前置对齐验收标准 + 拆分里程碑 + 定期同步，能把大风险切成小步校验。这样即使方向有偏差，也能在早期发现并纠正，避免大量返工。
