试用期 leader 临时改了考核标准，你担心自己是被针对，你该怎么 argue？
先不要急着下"被针对"的结论，而是求证：请 leader 说明变更考核标准的原因、新标准的具体内容、以及变更前已完成的成果如何评价。把变更前后的标准差异和自己的进度以书面形式记录下来，和 leader 对齐新标准下的预期。如果确实存在不合理或针对性的迹象，可以在合适时机、用客观事实温和指出，并请 leader 明确考核的具体依据，让自己有可执行的改进方向。
考核标准变更若不透明，容易引发焦虑。先求证、再对齐、后留痕，是既冷静又保护自己的方式。把担忧转化为"我需要明确标准"的合理诉求，比情绪化对抗更能换来公平。
试用期 leader 给了你一个不可能完成的目标（例如 3 个月要做半年的活），你该怎么办？
先不要直接说"不可能"，而是把目标量化拆解：工作量、所需资源、现有基础、时间，算出在当前条件下是否真的无法完成。然后带着这份拆解和风险分析去找 leader，说明哪些部分可以完成、哪些部分需要额外资源或更长时间，并给出一个分级方案（必须完成的核心项、可延期的项、可减量的项）。请 leader 确认优先级，或调整资源与时间。
面对"不可能的目标"，要么是信息不对称，要么是 leader 在施压。用数据拆解 + 分级方案回应，既尊重目标又回归现实，让 leader 看到你在想办法而不是推诿。提前管理预期，避免试用期结束被"没完成"定性。
试用期 leader 给你评估"待改进"，但你不知道具体待改进什么，你该怎么办？
不要接受一个模糊的"待改进"就结束。主动约 leader 深入沟通，请他给出具体的、可观察的改进点（是代码质量、沟通、进度、还是协作），并请求具体事例或场景。把每个待改进点转化为可执行的动作和验收标准，并确认改进的截止时间。如果 leader 仍给不出具体内容，可以礼貌指出"为了改进我需要清晰的标尺"，推动评估的客观化，同时自己主动复盘找差距。
模糊评价无法指导改进，必须把"待改进"具体化。通过要求具体事例、转化可执行动作、确认时间表，把被动评价变成主动改进。这也是保护自己、避免被用模糊标准压制的关键。
试用期你做了很多工作，但没有人评估你，你该怎么主动推动 review？
主动、有节奏地推动 review：先向 leader 提出一次正式 review 的请求，说明你想了解自己试用期表现、明确改进方向，并附上自己已完成工作的清单和成果。把工作成果整理成有数据支撑的总结（做了什么、产出、影响），降低 leader 评估的门槛。若 leader 拖延，可温和地多次提醒并约定具体时间，同时请 HR 或 mentor 从旁协助安排。
试用期评估对被评估人至关重要，不能等被动。主动整理成果、发起 review 请求、推动时间落地，既让自己得到反馈，也避免"没被评估"导致试用期结论模糊。主动管理评估是职业成熟的表现。
试用期你完成了 KPI，但 leader 说"这只是基础"，你该怎么办？
先客观确认：完成 KPI 是否真的达标，以及 leader 说的"基础"是底线还是更高的期望。不要急着反驳，而是问清楚 leader 认为"做得更好"长什么样，把这份期望具体化，作为下一阶段的目标。同时可以把自己的成果价值量化（不只是"完成了"，而是"带来了什么影响"），和 leader 对齐价值如何被认可。如果确实只是完成了基础，就坦诚接受并规划进阶。
"这只是基础"可能是 leader 抬高期望，也可能是你确实只做到了及格线。核心是澄清期望、量化价值、制定进阶路径。用对齐而非对抗的方式，把评价转化为成长方向，同时避免价值被低估。
试用期你完成了一个大项目，但 leader 说"和 KPI 无关"，你该怎么办？
先确认 leader 的标准框架：KPI 具体考核什么、这个项目为什么不被计入。如果项目确实不在 KPI 内，说明一开始目标对齐就有问题，要反思并补上这个环节。同时不要否定项目本身的真实价值——整理项目带来的实际影响，向 leader 说明它可以作为加分项或下阶段 KPI 的一部分，争取合理认可。更重要的是以后在做项目前先和 leader 对齐其与 KPI 的关系，避免再次"白忙"。
大项目与 KPI 脱节，通常是立项时未对齐目标归属。核心是主动对齐、把项目价值讲清楚争取认可，并总结教训在前置对齐。这既体现结果导向，也避免贡献被标准忽视。
试用期已经过去 2 个月，leader 还没和你做正式 review，你担心会被"被动评估"，你该怎么办？
不要坐等可能被"被动评估"。主动向 leader 提出 review 请求，说明希望了解试用期表现、及时调整方向，并把这段时间的成果整理成结构化总结发给 leader。若 leader 没时间，请求一个简短的非正式沟通或书面反馈，同时持续积累工作证据（成果、认可、数据）。把"没有 reviews"的风险主动消除，避免试用期结束时被单方面定性。
试用期评估若缺乏及时 review，容易在结束时出现"被动评估"的不确定性。主动发起 review、留存成果、争取反馈，能掌控自己的评估节奏，也避免长期缺乏反馈导致方向偏差。成熟的做法是主动管理。
试用期的 KPI 和团队其他人不一样，leader 说"新人标准不一样"，你该怎么办？
先理解"新人标准不一样"是合理的（新人以学习、适应、基础交付为主），但要让标准明确具体：请 leader 说明新人的 KPI 具体是什么、达成标准如何、和团队标准差异在哪。把这些确认清楚并书面化，避免"标准不一样"变成模糊的操盘空间。同时主动了解团队其他成员的 KPI，明确自己与团队目标的衔接，确保自己的贡献未来能被正确评价。
新人考核标准不同是常见现象，但必须明确、可衡量、可对齐。核心是把"不一样"变成"清楚"，避免模糊标准导致的不确定性。同时保持与团队目标衔接，让试用期的工作有意义。
试用期的目标你完成了 90%，但 leader 说"还差一点"，你不知道差什么，你该怎么办？
不要停在"90%"和"差一点"的模糊地带。主动请 leader 把"还差的一点"说清楚：是数量、质量、还是某个具体产出，以及衡量标准是什么。请求具体事例或可验证的指标，把差距转化为可执行的任务清单。同时把已完成的 90% 整理成证据，明确哪些已经达标，请 leader 确认，避免你的努力被低估或差距被模糊放大。
"差一点"是典型的模糊反馈，可能掩盖真实差距也可能被夸大。把差距具体化、量化、可执行，是保护自己又推动改进的关键。同时用已完成的成果锁定认可，防止被笼统否定。
试用期的考核标准被 leader 临时降低，你怀疑是 PUA（打压手段），你该怎么办？
先冷静记录：标准被降低的时间、前后内容、leader 的说法，保留书面证据。然后向 leader 求证降低标准的原因（是否业务调整、目标下移），并对比团队其他成员的考核标准是否一致。如果降低标准伴随持续的贬低、不合理的否定，就要警惕。一方面继续做好本职工作、用事实维护自己的成果，另一方面通过 HR 了解考核的合规流程，必要时正式反映。关键是留存证据、不情绪化、依托制度。
考核标准临时降低本身不一定有问题，但若是 PUA 的征兆，会伴随持续贬低与不透明。处理的核心是记录证据、求证原因、对比公平、依托 HR 制度。保持专业和冷静，用事实和规则保护自己，避免被情绪化操作。
试用期你做了 leader 临时给的任务，但原定的 KPI 没有完成，你该怎么办？
先做复盘：为什么临时任务挤占了 KPI 时间，是 leader 的优先级调整还是自己排期不当。把临时任务的工作量和产出整理出来，向 leader 说明"原定 KPI 未完成很大程度是因为临时任务占用了时间"，请 leader 确认这是否是当时的优先级安排。同时建议把临时任务的成果纳入评估或调整 KPI，避免投入被忽视。以后遇到临时任务，先和 leader 确认与 KPI 的优先级关系，再执行。
临时任务与 KPI 冲突的核心是"优先级未被对齐"。通过整理工作量、说明因果、请求认可与调整，既能保护自己的贡献，也能推动管理透明。关键是把临时任务的价值讲清楚，避免既干活又不被认可。
试用期的 KPI 被改成不合理的目标，你该怎么办？
先量化拆解被改后的目标，判断其是否真的不合理（工作量、时间、资源的可行性）。带着数据和分析去和 leader 沟通，说明目标在哪些维度上难以达成，并提出一个既体现挑战又可行的替代方案（如调整范围、增加资源、延长时间）。如果 leader 坚持，也要明确记录目标与现实的差距，并请教如何分阶段达成，避免被"不合理目标"直接定性为失败。
不合理目标需要有理有据地反馈，而不是硬扛或硬拒绝。用数据评估可行性、提出替代方案、记录沟通，是既专业又保护自己的方式。关键是让 leader 看到你基于现实的责任感，而不是单纯抱怨。
你接手的遗留系统代码风格混乱（存在 10 种风格），你要不要统一风格？
不要急于一次性统一风格，因为大规模改动会引入风险、淹没在 review 和历史对比中。正确做法是：先引入统一的格式化工具（如 Prettier/EditorConfig）和 lint 规则，让"新代码"遵循统一风格，旧代码保持现状；涉及到的文件顺手格式化。这样既逐步改善风格，又不破坏现有功能。把"统一风格"定义为增量而非革命，向团队说明规则和收益，让大家一起遵守。
遗留系统风格混乱的根本问题是缺乏统一规则，而非现有代码本身。引入工具让新代码统一、旧代码渐进，是低风险高收益的做法。风格统一是工程规范问题，用工具和规则解决，比手工大规模改写更安全。
你接手的遗留系统数据库 schema 有 500 个表，你不知道哪些还在用，你该怎么办？
不要试图一次性搞清楚 500 个表。采用"数据驱动"的方法：从代码仓库里搜索表名被引用的地方，看代码中是否真的访问这些表；查数据库的访问日志、慢查询、监控，统计哪些表有实际读写；看是否有对应的 ORM 实体。把这些信息汇总成一张"使用率清单"，标注"活跃/低活跃/疑似废弃"。对存疑的表，可以谨慎地标记或加入监控，而不是贸然删除。先摸清现状，再决定是否清理或归档。
判断表是否在用，不能靠猜，要综合代码引用、访问日志、监控数据。先做盘点、再分级、后谨慎处理，是安全方式。核心是"先弄清楚再动"，避免删掉关键表造成事故。
你接手的遗留系统有 1 万多个文件，你不知道从哪里开始看，你该怎么分层了解？
不要试图逐文件读。采用"分层——从粗到细"的策略：先看系统的整体架构和入口（主配置、启动类、路由、目录结构），理解系统由哪些模块组成、边界在哪；再追一个核心业务请求的完整链路（从入口到数据库），理解数据流；最后按需深入具体模块。配合工具（代码搜索、调用链、依赖图）提高效率。把理解过程记录成架构笔记，逐步完善。
大型代码库的阅读，核心是"抓主干、追链路、按需深入"。从入口和核心流程入手能在较短时间内建立宏观认知，再逐步细化。避免陷入逐文件阅读的泥潭，用工具辅助理解。
你接手的遗留系统里有大量 TODO 注释，但一直没人处理，你怎么判断哪些该做哪些不该做？
不要把所有 TODO 都当任务。先按"影响面 × 风险"分类：影响线上功能、用户数据、安全性的 TODO 优先；纯代码风格、可选项、主观改进的靠后。通过查看 TODO 的上下文、关联的 bug 记录、上线时间判断其是否还有效。把值得处理的整理成清单，向团队说明价值并排期；对过时或重复的 TODO，可以移除并说明。关键是把 TODO 管理从"放任"变成"有序"。
TODO 的价值取决于影响面和现实风险，不能一刀切。先分类、再评估、后处理，把真正重要的纳入排期，避免被大量低价值 TODO 淹没。同时清理过时项，让 TODO 成为有效管理工具。
你接手的遗留系统里有已知的 bug，但一直没人修，你该不该主动修？
先判断这个 bug 的严重度和影响面，确定是否值得修（是否影响线上、是否阻塞业务、修复成本是否可控）。如果值得，主动向团队提出修复意愿，说明你对当前系统的理解、修复方案和风险，并先走 review 和测试流程，不贸然改。如果是低价值或高风险的 bug，可以先记录在案，纳入排期，不必冲动动手。主动修 bug 是加分项，但要以安全和负责为前提。
主动修遗留 bug 体现了责任心，但必须先行评估严重度、影响、风险和修复成本。先沟通、走流程、控制风险，避免好心办坏事。把"主动"建立在"安全"之上，才能既加分又稳当。
你接手的遗留系统里有"硬编码"（魔法数字、URL 等），你该怎么办？
硬编码（魔法数字、URL）是遗留系统常见问题，但不要一次性把所有硬编码都抽出来。先识别哪些硬编码有实际风险（如环境相关的 URL、易变关键参数），优先处理这些，把它们抽成配置或常量，并加注释说明。低风险的魔法数字可以顺手常量化。重构时保持行为不变，通过测试验证。同时推动建立规范，让新代码不再出现硬编码。
硬编码的核心风险是"不可配置、易出错、难维护"，但大规模抽离同样有风险。按"风险优先 + 渐进重构 + 行为不变"处理，既改善又安全。同时建立规范防增量，比一次性清存量更可持续。
你接手的遗留系统里有些函数有 20 个参数，你该怎么办？
20 个参数的函数是"重参数"症状，通常意味着函数职责过重或缺少对象封装。但不要贸然重构，先理解这些参数之间的关系和调用方。可以采用"参数对象"（把相关参数封装成一个对象）或拆分为多个职责单一的函数，逐步重构，保持行为不变。每次小步修改并用测试和调用方验证，避免破坏现有逻辑。如果函数是核心逻辑，先保证有测试覆盖再重构。
大刀阔斧重构 20 参数函数风险高。先理解、再用参数对象/拆函数渐进优化，保持行为不变并借测试保障。核心是"重构不改变行为"，让旧代码变可维护而不引入新风险。
你接手的遗留系统里有未提交到 git 的代码（原作者本地有），你该怎么办？
未提交到 git 的代码是最危险的"孤儿代码"——没有版本记录、没有保护。先不要直接使用或删除，联系原作者（或原负责人）确认这些代码的用途、状态和是否还在维护。如果确认有价值，引导把它正式提交到 git（哪怕先开分支），并补充说明和 review；如果确认废弃，明确记录并归档。同时先做好本地备份，防止丢失。核心是让"未入库"变成"有版本、有记录、有归属"。
未提交代码失控风险高，可能包含重要逻辑或半成品。处理的关键是确认归属、用途，再规范化提交或归档，同时备份防丢失。避免既不用也不理，造成信息黑洞。
你接手了一个 10 年没人维护的 Java 系统，文档没有、测试也没有，你该怎么迈出第一步？
第一步不是理解代码，而是先让系统"跑起来"并建立安全基线：确认环境能构建、能启动、能运行一个最小流程，并用文档记录部署和启动步骤。然后建立"可回滚"的能力（备份、版本、配置管理），再逐步加基础监控和日志。有了可运行、可观测、可回滚的基线，后续的代码理解、重构才有安全前提。之后再从入口和核心流程开始理解代码。
接手无文档、无测试的 10 年系统，最大的风险是"动一下就坏且无法恢复"。因此第一步是建立可运行基线 + 可回滚 + 可观测，把风险降到可控，再谈理解与重构。先保住系统，再改进系统。
