岗位
数据工程
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
453 道问题
本页为扩展题库第 251–300 题，共 453 题。
A · 专业解题与实现22
- 团队委托研究验证新仪表盘需求，但多数用户表示当前报表已经够用，只有少数高阶用户提出新需求。项目负责人希望突出支持改版的访谈。你会如何总结？
- 两个请求几乎同时检查某个业务对象不存在，然后都尝试创建，应用层的“先查再写”偶尔产生重复数据。你会从事务隔离、唯一约束和冲突处理说明如何保证业务不变量？
- 给你一组可能大于内存容量的记录，需要分批处理并允许调用方取消任务。请说明或实现一个接口，使内存占用有界、错误可定位、取消后不再启动新批次。
- 服务刚发布时耗时正常，运行数小时后最慢 1% 请求逐步变慢，重启后暂时恢复；CPU 平稳，但连接数和堆内存缓慢增长。你会怎样拆解假设并设计低风险验证？
- 用户可在手机离线修改资料，同时也可能在网页端编辑；设备恢复联网后必须同步，且不能静默覆盖有价值的更改。你会如何设计版本、冲突检测、合并和用户确认机制？
- 一个入口服务同时调用多个下游，其中一个非核心依赖偶尔变慢，导致请求线程耗尽并拖累其他功能。你会如何设计超时、并发隔离、必要时关闭非核心功能和恢复策略？
- 一个共享库发布了向后兼容的版本，但多个应用仓库因依赖锁定、生成代码或发布窗口不同，无法及时升级；安全修复因此被长期阻塞。你会如何设计兼容策略和依赖升级流程？
- 一个 AI 助手在少数请求上会反复调用搜索、数据库和外部 API，最终耗时和费用远高于平均值。你会如何设计单次任务的预算、停止条件、避免重复操作的保护和审计记录？
- 核心服务的月度可用性仍达到目标，但故障额度消耗速度突然加快，且错误集中在一个新发布的功能。你会如何判断是否暂停发布或回滚？
- 新模型在离线测试集上的总体得分明显提高，但上线小流量后，某类真实用户的任务完成率下降，投诉也增加。你会如何判断评估集、指标和发布决策哪里失真？
- AI 助手会从多个业务系统检索文档，而用户在不同系统中拥有不同权限。你会如何确保检索、缓存、摘要和引用都遵循原文权限，并处理权限撤销？
- 同一提交在开发者本地稳定通过，但自动构建与检查流程偶尔因时区、随机顺序、共享缓存或并行竞争而失败。你会如何分类、复现并减少这类不稳定问题？
- 输入是一组可能重叠、端点可相接的时间区间，调用方需要查询某个时刻对应哪些记录。请说明或实现归并与查询策略，并明确边界是否包含端点。
- 事件会以流的方式到达，少量重复可能间隔数小时；程序需限制内存，并在进程重启后继续保持去重效果。你会如何说明时间窗口、持久化状态和误判边界？
- 客户端只看到一次提交，但服务端偶尔出现两条相同记录；问题通常发生在请求超时后重试，且日志没有明显异常。你会如何重建调用时间线并验证重复写入发生在哪一层？
- 移动端上传大文件时网络可能中断，用户会重复点击重试；系统还按成功处理量计费。你会如何设计分片、校验、续传状态、最终提交和计费时点？
- 一次业务规则修正要求重算多个服务产生的历史记录，但部分消费者已经发送通知或执行外部动作。你会如何列出影响范围，决定哪些历史数据需要重新处理，并防止重复触发外部操作？
- 某依赖服务变慢后，多个调用方同时增加重试，流量反而翻倍并使故障范围扩大。你会如何设计重试预算、退避、抖动和跨服务协调？
- 一个功能已全量发布，但多年未清理的开关仍控制多个代码分支；团队不清楚哪些开关可删除，回滚时也依赖人工记忆。你会如何建立开关生命周期和清理责任？
- 后端 API 同时生成 TypeScript、Java 和 Swift SDK，各语言的可空类型、枚举和错误模型逐渐不一致。你会如何设计接口约定源、生成流程和跨语言兼容测试？
- 生产环境发现一个依赖包与仓库标签对应的构建产物校验值不一致，团队无法确认来源是否经过预期的自动检查与构建流程。你会如何建立构建追溯、制品校验和发布授权？
- 分析助手可以把自然语言转换为 SQL 查询业务库，用户提出的请求可能诱导它读取敏感列或执行昂贵查询。你会如何设计只读权限、查询校验、资源限制和结果脱敏？
当前目标在这里暂无匹配题。 ·
C · 价值判断与方向规划19
- 你们的核心指标是怎么定义的？分子分母、时间窗口、去重和排除规则分别是什么，为什么它是核心指标？
- 你的漏斗是怎么搭起来的？每一步为什么这样划分，流失主要发生在哪里，怎样确认各步骤的定义不重叠也不遗漏？
- 漏斗各环节的变化，最终怎样作用到业务指标上？哪一环改善一点，业务指标的变化最大？这个判断依据是什么？
- 把你的指标换算成行业通用定义之后，它处在什么位置？换算过程中做了哪些假设，损失了什么信息？
- 一张看板放了几十项指标，团队的注意力总被最显眼的数字吸走。请选一条用户任务，说明你怎样给指标分级，并决定哪些进入核心清单。
- 指标达成了，但你觉得业务并没有真的变好。遇到过吗？你怎么发现的，怎么处理？
- 功能上线后，你怎样判断它有没有达到当初的目标？什么时候复盘，复盘之后你会做出什么不同的决定？
- 你上线的上一个新功能，核心指标（比如转化率、点击率、留存）上线前后的具体数据变化是多少？如果数据不如预期，你通常从哪些维度去排查原因？
- 新功能鼓励用户邀请朋友，邀请者和朋友可能分在不同实验组。实验结果显著，但组间传播无法完全隔离。你会怎样评估结论？
- 项目进行中用户结构或外部环境发生变化，改动前的数据已不再可比。你会怎样继续判断项目结果？
- 目标指标提升了，但退款、客诉或人工处理量同时恶化，你会怎样判断结果是否可接受？
- 功能上线初期效果明显，但几个月后逐渐消失，你会怎样判断价值是短期新奇效应还是长期改变？
- 最终业务结果要数月后才显现，但团队现在必须决定是否继续投入，你会怎样使用领先指标？
- 多个团队同时改了产品、价格和运营流程，整体结果变好了，你会怎样判断各项投入分别贡献了什么？
- 实验没有显示预期提升，但也没有证据证明方案无效，你会怎样决定继续、调整还是停止？
- 两个项目都达到部分目标，但一个项目单位投入带来的用户收益更高，你会怎样重新分配资源？
- 试点团队达到了目标，但推广到更多地区或客群后效果不稳定，你会怎样判断结果是否可复制？
- 新流程使每周上线功能数增加一倍，但用户任务完成率没有改善，支持工单还略有上升。你会怎样判断应该继续、调整还是停止？
- 一个重要流程完成改版后，团队预期的完成率没有提升，但客服求助量下降、老用户反馈更好，新用户行为却变差。你会怎样检查指标定义和用户分群，判断设计产生了什么影响，并决定下一轮行动？
当前目标在这里暂无匹配题。 ·
D · 交付执行与持续运营9
- 不同团队对同一个业务问题给出了相反的数据和解释，而项目已经排进本季度。你会怎样决定先查什么、暂缓什么？
- 一次大促在夜间上线后因请求过多而卡住，大量用户无法领取优惠券并开始投诉。作为参与活动的工程师，在恢复系统的同时，你会怎样与运营和客服协同，评估并落实临时业务措施？
- 说一次你以工程师身份参与的用户促活或裂变活动。你负责哪些系统、数据或交付工作，如何与运营确认预算及关键用户行为，并核验活动的增量和自己的实际贡献？
- 促销活动的策略已经确定，由你负责执行。上线前你会确认哪些目标、规则、资源、风险和验收条件？
- 在管理一个大型平台生态时，常伴随刷单、黑产薅羊毛、低俗内容打擦边球这类灰色地带。你怎样建立一套不伤害正常生态繁荣的治理机制？你怎样与风控、法务和技术团队一起筑起防线？
- 你要在线上跑一个增长实验，开跑前会准备哪些检查点和停止条件？
- 你怎样从单纯做活动、拉新用户，升级为建立自动化、策略化的用户生命周期管理？请讲一个用数据记录和算法，把过去人工运营整理成自动化规则的案例。
- 双边平台在某地出现供需失衡：高峰期订单多但运力不足，或新城市有供给却缺少用户。你会如何定位主要瓶颈，并调整价格、补贴或供给安排，同时控制成本和长期影响？
- 公司战略调整要求你立刻砍掉一项获客多、但长期亏损的业务。你怎样在最短时间里安抚成千上万受影响的合作伙伴，合规平稳地完成业务清退，并防止出现群体性的公关危机？
当前目标在这里暂无匹配题。 ·