腾讯游戏发行/运营培训生

今天阿里产品二面，一个小时，记录一下。 面试官上来直接问：你平时用什么工具做需求分析？ （这个问题让我愣了一下，准备了一堆业务框架，没想到先从工具切入。我说了Axure、飞书，顺手提了最近在用的网申助手——求职阶段管理投递记录和填表用的，面试官笑了说"挺实用的，效率意识不错"。） 之后进入正式题。 【题目1：设计一个功能，帮助用户在淘宝找到"值得买"的商品】 思路：先澄清"值得买"的场景——目的性购物、对比比价、随意浏览，三条路需求不同。重点放在比价场景：用价格历史曲线+差评关键词聚类，做成置信度评分，直观告诉用户当前价格在历史区间的...

看着像是已经挂了，但是又给我发笔试链接了（上周我自己申请的），还有必要做吗，刚好和b站的笔试冲突了

第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...