岗位
后端
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
1216 道问题
本页为扩展题库第 401–450 题，共 1216 题。
C · 价值判断与方向规划31
- 公司的资金只够撑 12 个月，而你要补的关键能力需要约 18 个月才能长出来，市场窗口又只剩 6 个月。你的规划会怎样处理这些不同步的时间尺度？
- 规划接下来半年时，你会从已有的资源和现状往前推，还是从目标倒推？两种推法得出的结论一致吗？
- 你的季度规划里有几件重要但本期不做的事。请说明你怎样记录它们，使下次有人想翻案时，讨论能基于判断而不是重新争论重要性。
- 你怎样确认团队的目标和公司的战略目标是一致的？发现不一致时，是调整团队的目标，还是去影响上面的目标？
- 如果让你为一个技术方向做三到五年的规划，你会怎么做？怎样避免它变成一份无法检验的愿景清单？
- 公司增长放缓，老板让你探索一个陌生且竞争激烈的新市场，只给了有限预算。前 30 天你会先了解什么、验证什么，并依据哪些证据决定继续或停止？
- 市场窗口很短，完整方案要两个月；现在可以用一周做可撤销试点，但无法验证所有长期风险。你会怎样决定投入顺序？
- 回头看你已经完成的工作，哪三件现在觉得不值得做？当时为什么做了，现在的判断又变在哪里？
- 团队资源不足，短期收入项目、战略探索和技术重构都需要投入。你会用哪些标准比较并排序？对于难以直接量化的战略价值或维护风险，你会怎样说明判断依据？
- 一项新产品探索已投入两个季度，试点用户完成率持续低于目标；团队认为再加一项能力就能改善。你会如何判断继续投入的证据和停止条件？
- 评审会上三个候选项目都被各自负责人标成 P0，理由都是“很重要”。你会怎样让评审从争论排序，变成可以检查的取舍？
- 回看过去半年，你做过的最值得的三件事是什么？为什么是它们，带来了什么效益，你是怎样确认这些效益的？
- 选一个你正在参与的项目。依据什么目标和排序标准，最重要的三件事是什么，最可以暂缓或砍掉的两件事又是什么？
- 发布窗口提前两周，团队只能完成原计划六项中的三项。业务、可靠性和合规负责人都说自己的工作不可延期。你会怎样核实哪些承诺确实不可妥协，指出无法同时满足的约束，并决定交付什么或向谁升级？
- 行业里的这些做法，你是怎样应用到当下的业务上的？哪些直接适用，哪些需要改造，哪些你认为不适用，为什么？
- 你们把一个高流量流程改成连续步骤后，整体完成率提高了，但客服投诉显示用户更难找到退出、撤销或改选入口。你会如何判断这是真正的体验改善、分群差异还是指标定义造成的假象？
- 说一次你对市场或技术变化作出的预测。当时的证据和作用机制是什么，后来发生了什么？哪些证据本可以说明预测是错的？
- 你说这个方案在行业内是最先进的，依据是什么？拿什么对象、按什么维度、在什么时间点比较的？
- 一项老功能只有少数客户使用，但承担月底对账；维护成本持续上升。你会怎样比较迁移、收费维护和退役方案？
- 讲一个你参与的产品决策：当时某项短期指标变差，但团队认为它可能带来长期价值。你依据什么作出决定？后来有哪些证据说明结果与这个决定有关？还有哪些外部因素可能解释结果？
- 新流程使每周上线功能数增加一倍，但用户任务完成率没有改善，支持工单还略有上升。你会怎样判断应该继续、调整还是停止？
- 讲一个你参与的技术平台改造项目：上线后使用团队很少，业务结果也不明显。你当时根据什么数据或假设决定投入？后来哪些判断被证据推翻，你增加了什么验证方式？
- 需求是“给订单列表页增加导出 Excel 的按钮”。请演示你怎样从表层请求追问到用户的行为障碍，再追问到价值结果。
- 同事提议给某个功能加一个设置开关。在讨论组件怎么做之前，你会先问哪几个问题，来判断这个开关是否值得做？
- 开户流程的整体转化下降，漏斗显示地址验证步骤退出最多，但客服记录显示问题常从身份校验开始。你会如何决定研究和修复优先级？
- 技术怎样真正驱动业务，而不只是支持业务？说一次技术带来了业务上原本没有的可能性的经历，你怎么判断它不只是技术自娱自乐？
- 你做调研时，行业整体水准、这个方向上最好的做法、公司内已有的水准，分别是什么？你的方案落在哪一档，为什么？
- 请选择一项你持续关注的技术变化。结合已有资料和实际观察，你认为未来两年哪些类型的公司最可能受影响？请说明证据和推断、它对本公司的意义，以及你已采取哪些行动来验证或应对。
- 团队想“多用自己的产品”，但上次体验之夜只收到零散的感觉。你会怎样设计，让自用变成一条从真实任务到修复验证的反馈回路？
- 平台有迁移、稳定性和效率三条工作线，但全年资源只够推进两条。你会怎样确定季度顺序和取舍？
- 团队计划停止支持一项旧技术，但关键系统仍依赖它且替换成本很高。你会怎样制定退役路线？
当前目标在这里暂无匹配题。 ·
D · 交付执行与持续运营19
- 面对一个还不清晰的大问题，你怎样规划需要多少人和资源？在不确定的情况下怎样给出估计，怎样分阶段投入，又怎样向上申请？
- 团队连续几个月靠加班守住交付，你怎样判断这是个人问题还是容量缺口，并怎么处理？
- 团队每个迭代都被事故和恢复任务打断，路线图连续延期；管理层要求保持既定日期，同时不希望增加人手。你会如何提出容量和目标调整？
- 团队连续几个季度都因线上支持、客户升级和跨团队求助偏离路线图。有人建议统一预留 20% 容量，但团队间中断频率差异很大。你会怎样确定预留方式？
- 你怎样算出团队下个周期真正能承诺的容量，而不是“人数乘以工作日”？
- 做这个决策时，你手上有哪些资源，协作的范围有多大？这些限制对你的选择产生了什么影响？
- 业务方提出的问题还不清楚。你会先查找哪些资料、找谁核实，并怎样区分已确认的事实和推测？最后如何把结论整理成可执行的方案？
- 不同团队对同一个业务问题给出了相反的数据和解释，而项目已经排进本季度。你会怎样决定先查什么、暂缓什么？
- 说一个你负责过的最复杂的功能。你怎样把一个模糊的业务诉求，一步步拆成没有逻辑漏洞的需求文档？遇到断网、账户异常这类边缘情况，你怎样设计容错和交互？
- 项目过半时可用人力突然减少一半，但目标日期不变。你会如何重排工作并与相关方重新约定结果？
- 客户要求“给我一个实时大屏”，但访谈中提到的问题可能只是每天晚些时候才发现库存错误。你会如何推进讨论？
- 接到一个你从没做过的需求，你怎样拆分任务，并给出一个之后可以被检验的估算？
- 一次大促在夜间上线后因请求过多而卡住，大量用户无法领取优惠券并开始投诉。作为参与活动的工程师，在恢复系统的同时，你会怎样与运营和客服协同，评估并落实临时业务措施？
- 一个系统总是反复出问题，补一次又出一次。你怎样找到根本原因，怎样让团队从救火转向真正的修复，又怎样证明它不再复发？
- 线上服务突然大面积失败，你在第一个小时里会按什么顺序行动？
- 一次重大事故产生 18 条改进行动，涉及架构、监控、培训和流程；各团队已有季度承诺。你会如何筛选真正降低复发风险的行动？
- 怎样避免同类的个人失误再次发生？你改进的是流程和工具，还是只是提醒自己以后小心？怎么知道改进有效？
- 说一次你以工程师身份参与的用户促活或裂变活动。你负责哪些系统、数据或交付工作，如何与运营确认预算及关键用户行为，并核验活动的增量和自己的实际贡献？
- 促销活动的策略已经确定，由你负责执行。上线前你会确认哪些目标、规则、资源、风险和验收条件？
当前目标在这里暂无匹配题。 ·