岗位
通用工程
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
1313 道问题
本页为扩展题库第 451–500 题，共 1313 题。
C · 价值判断与方向规划14
- 你说这个方案在行业内是最先进的，依据是什么？拿什么对象、按什么维度、在什么时间点比较的？
- 一项老功能只有少数客户使用，但承担月底对账；维护成本持续上升。你会怎样比较迁移、收费维护和退役方案？
- 讲一个你参与的产品决策：当时某项短期指标变差，但团队认为它可能带来长期价值。你依据什么作出决定？后来有哪些证据说明结果与这个决定有关？还有哪些外部因素可能解释结果？
- 新流程使每周上线功能数增加一倍，但用户任务完成率没有改善，支持工单还略有上升。你会怎样判断应该继续、调整还是停止？
- 讲一个你参与的技术平台改造项目：上线后使用团队很少，业务结果也不明显。你当时根据什么数据或假设决定投入？后来哪些判断被证据推翻，你增加了什么验证方式？
- 需求是“给订单列表页增加导出 Excel 的按钮”。请演示你怎样从表层请求追问到用户的行为障碍，再追问到价值结果。
- 同事提议给某个功能加一个设置开关。在讨论组件怎么做之前，你会先问哪几个问题，来判断这个开关是否值得做？
- 开户流程的整体转化下降，漏斗显示地址验证步骤退出最多，但客服记录显示问题常从身份校验开始。你会如何决定研究和修复优先级？
- 技术怎样真正驱动业务，而不只是支持业务？说一次技术带来了业务上原本没有的可能性的经历，你怎么判断它不只是技术自娱自乐？
- 你做调研时，行业整体水准、这个方向上最好的做法、公司内已有的水准，分别是什么？你的方案落在哪一档，为什么？
- 请选择一项你持续关注的技术变化。结合已有资料和实际观察，你认为未来两年哪些类型的公司最可能受影响？请说明证据和推断、它对本公司的意义，以及你已采取哪些行动来验证或应对。
- 团队想“多用自己的产品”，但上次体验之夜只收到零散的感觉。你会怎样设计，让自用变成一条从真实任务到修复验证的反馈回路？
- 平台有迁移、稳定性和效率三条工作线，但全年资源只够推进两条。你会怎样确定季度顺序和取舍？
- 团队计划停止支持一项旧技术，但关键系统仍依赖它且替换成本很高。你会怎样制定退役路线？
当前目标在这里暂无匹配题。 ·
D · 交付执行与持续运营36
- 面对一个还不清晰的大问题，你怎样规划需要多少人和资源？在不确定的情况下怎样给出估计，怎样分阶段投入，又怎样向上申请？
- 团队连续几个月靠加班守住交付，你怎样判断这是个人问题还是容量缺口，并怎么处理？
- 团队每个迭代都被事故和恢复任务打断，路线图连续延期；管理层要求保持既定日期，同时不希望增加人手。你会如何提出容量和目标调整？
- 团队连续几个季度都因线上支持、客户升级和跨团队求助偏离路线图。有人建议统一预留 20% 容量，但团队间中断频率差异很大。你会怎样确定预留方式？
- 你怎样算出团队下个周期真正能承诺的容量，而不是“人数乘以工作日”？
- 做这个决策时，你手上有哪些资源，协作的范围有多大？这些限制对你的选择产生了什么影响？
- 业务方提出的问题还不清楚。你会先查找哪些资料、找谁核实，并怎样区分已确认的事实和推测？最后如何把结论整理成可执行的方案？
- 不同团队对同一个业务问题给出了相反的数据和解释，而项目已经排进本季度。你会怎样决定先查什么、暂缓什么？
- 说一个你负责过的最复杂的功能。你怎样把一个模糊的业务诉求，一步步拆成没有逻辑漏洞的需求文档？遇到断网、账户异常这类边缘情况，你怎样设计容错和交互？
- 项目过半时可用人力突然减少一半，但目标日期不变。你会如何重排工作并与相关方重新约定结果？
- 客户要求“给我一个实时大屏”，但访谈中提到的问题可能只是每天晚些时候才发现库存错误。你会如何推进讨论？
- 接到一个你从没做过的需求，你怎样拆分任务，并给出一个之后可以被检验的估算？
- 一次大促在夜间上线后因请求过多而卡住，大量用户无法领取优惠券并开始投诉。作为参与活动的工程师，在恢复系统的同时，你会怎样与运营和客服协同，评估并落实临时业务措施？
- 一个系统总是反复出问题，补一次又出一次。你怎样找到根本原因，怎样让团队从救火转向真正的修复，又怎样证明它不再复发？
- 线上服务突然大面积失败，你在第一个小时里会按什么顺序行动？
- 一次重大事故产生 18 条改进行动，涉及架构、监控、培训和流程；各团队已有季度承诺。你会如何筛选真正降低复发风险的行动？
- 怎样避免同类的个人失误再次发生？你改进的是流程和工具，还是只是提醒自己以后小心？怎么知道改进有效？
- 说一次你以工程师身份参与的用户促活或裂变活动。你负责哪些系统、数据或交付工作，如何与运营确认预算及关键用户行为，并核验活动的增量和自己的实际贡献？
- 促销活动的策略已经确定，由你负责执行。上线前你会确认哪些目标、规则、资源、风险和验收条件？
- 销售、客服和工程都能把客户问题标为最高优先级，值班队列因此无法区分业务中断和一般不满。你会怎样设计分级与升级机制？
- 在管理一个大型平台生态时，常伴随刷单、黑产薅羊毛、低俗内容打擦边球这类灰色地带。你怎样建立一套不伤害正常生态繁荣的治理机制？你怎样与风控、法务和技术团队一起筑起防线？
- 你要在线上跑一个增长实验，开跑前会准备哪些检查点和停止条件？
- 生产事故中，技术负责人要求关闭功能，业务负责人要求继续接单，客服团队又承诺了恢复时间。现场成员收到相互冲突的指令。你会如何组织响应？
- 你怎样从单纯做活动、拉新用户，升级为建立自动化、策略化的用户生命周期管理？请讲一个用数据记录和算法，把过去人工运营整理成自动化规则的案例。
- 公司战略调整要求你立刻砍掉一项获客多、但长期亏损的业务。你怎样在最短时间里安抚成千上万受影响的合作伙伴，合规平稳地完成业务清退，并防止出现群体性的公关危机？
- 一份关键运营手册仍被多个地区依赖，但原作者已离职，最近的系统和政策变化也没有同步进去。你会怎样判断哪些步骤仍安全、如何安排临时控制和更新责任，并验证新版本能被一线正确执行？
- 五个项目都报告同一平台依赖可能延期，但各自仍显示绿色。你会用什么证据判断应该调整项目组合，而不是继续逐项跟进？
- 上线前两周，业务方要求再加一个需求，你怎样决定接受、推迟还是拒绝，并留下什么记录？
- 这个项目里最大的挑战是什么？它为什么难，你当时是怎么推进的，最后怎样了？
- 业务负责人认为变更审批拖慢市场机会，要求团队在评审外直接插入需求。过去紧急项后来多次引发返工。你会如何设计例外流程？
- 发布日期已对外承诺，但多个团队仍提出新需求和缺陷修复。你会如何决定何时冻结范围、允许哪些例外，以及谁承担重新排期的后果？
- 研发告诉你，你提的这个功能因为底层架构原因要延期两周才能上，而业务方明天就要。你怎样在很短时间里砍掉一半功能，留下一个能上线的最小可行版本？你依据什么决定留什么、砍什么？
- 三个项目都把同一平台团队列为关键依赖，缓冲时间已被计划填满。新出现的监管需求又必须在季度末前上线。你会怎样重新安排资源和承诺？
- 你怎样度量研发效能？选哪些指标，怎样避免被刷出好看的数字，度量之后又怎样把它变成真正的改进？
- 一位负责人同时承担四个高优先级项目，状态汇报仍正常，但风险处理、跨团队决定和复盘都开始延迟。你会如何判断需要增加支持、重新分工还是缩减项目组合？
- 你推动一个需要研发、设计、运营一起完成的项目，怎样让大家明确共同目标和分工？各方的成功标准不一样时怎么办？
当前目标在这里暂无匹配题。 ·