是和我的背景非常非常match的技术产品,因此也抱有比较大的期待。但是可能因为面试时间拖得比较久,在hr面当天突然改为加一轮业务面,在这一轮业务面(三面)挂了。比较遗憾。
字节跳动-飞书基础架构-产品经理实习生
可以理解为主要是做研效工具和tob交付。研效方面包括内部的开发工具(比如代码编辑),CI/CD,运维;tob交付主要是给大客户的私有化部署做标准化版本。
如果想了解,可以看看字节跳动飞书为什么选择 Zadig 实现主干开发、主干发布
面试那段时间比较忙,很多个要交付的作业,因此基本没准备,所以面经也拖到现在才写。答得也比较乱,后续也有针对这一***露的问题在表述上做了改进,主要是数据分析实习的部分。最后反问的问题不太好,显得我比较好高骛远。
先总结一下这段问答。主要在介绍门户页设计方面表述的不是特别好。门户页的功能是信息聚合+对外宣发,信息聚合可以通过知识库实现部分,但是也会有更新的问题。文档可能会因为人员经手,更新很多个版本,知识库有检索最新文档的困难,当然这也和知识库的维护规则有关。网页只需要更新链接,就可以指向最新版本的文档。但对外宣发是一定通过门户页实现的,作为一个统一的入口;内部工具的聚合也需要门户页维护多个工具的链接入口。
内部有知识库,可以更轻量地实现门户页的文档聚合功能。为什么用门户的形式
门户是解决方式之一,之前确实没考量到这么多。静态页面开发成本也低。
后续问答会补充上,对外宣导和内部工具链接的聚合还是要通过门户实现的。
重新复盘,有什么方式可以解决文档更新聚合的问题
后面就一直在找补,总的过程大概就是第一点,不做赘述。
大盘数据接入、日常取数是基本需求,需要运营方做短暂配合,比如新游戏接入要运营方收集提供基本信息。宣导过程有比较大的沟通成本,需要引导运营通过看文档了解接入流程和周期。数据质量检查工具为此服务,保证基础服务的质量和可信度。
关于数据科学的实际应用,数分需要主动联系游戏运营,实现数据科学方案的更深度合作而不是简单取数,这是部门的业绩。
相比于游戏运营侧,数分手里有更多个同品类的数据源和这方面的分析经验,可以从更高的视野做横向对比,从而可能设计出更贴合品类的方案。
聚合高频操作入口
降低信息管理成本
方案宣发推广
没有产品同事,独立评估和排期设计开发功能,向同事(需求方)论证可行性,向上汇报。
论证难点
数据质量检查的可信度。mt希望展示部分数据,我觉得这种方式并不能保证可信。最后解决方案之一是出具检查报告pdf,列清检查指标和规则。
游戏活动上下线的日历可视化。多方调研确认后发现数据量与同事预估有出入,会影响可视化效果和异常处理方式。对比了普通日历、甘特图等多种方式,确认活动类型和数量范围,最后通过个人配置+部分信息折叠在表格中的方式,避免信息过多影响可视化效果。
暂时没有强烈的秋招需求,优先打算留学,但遇到合适的工作也会考虑转置。
下一份实习主要想确认职业规划是否可行,同时也验证个人发展是否对技术产品这个方向有利。
对效率工程非常感兴趣,所以有比较强烈的意愿来飞书实习。
答得很奇怪,有点天马行空,甚至吐槽起专业hh。事后被好朋友评论“太把面试官当自己人”。整场面试都有点容易跑偏的感觉。
技术和产品的工作没有太多区别,需要拆分模块分摊到个人实现。
前面我提到了俞军产品方法论里认为产品是利用有限资源规划创造价值的系统。面试官强调产品落地还是需要注意前面说的小细节,书里的概念还是比较宏观的。
这一轮的面试官应该是设计出身,对我的经历表述都比较认可,聊的挺开心。反问环节老实确认了部门职能,很心水。
相同-为同一个业务目标努力(设计一款产品)。
区别-关注细节不同。
产品更关注产品定位、功能优先级和未来规划、产品边界,主要是逻辑细节。
研发关注开发合理规划、需求排期、系统架构(性能与开发效率的平衡),主要是实现细节。
主要做了几个内部的数据工具,涉及数据质量检查、门户、部分可视化。
追问数据质量检查部分,如何保证检查结果。
过往由分析师手动编写sql检查,标准不一且容易遗漏。工具改进点在于集成部门内的经验设置检查模板。
过往由微信口头转达。改进点在于生成检查报告,展示检查指标和检查规则,以及检查结果异常时可能的归因。
总结,为主观的过程设定客观量化的标准。
追问可视化(游戏活动上下线情况的日历展示)。提效处在哪,解决了哪些问题?
游戏活动是比较常见的数据异常波动归因之一,日历的作用是为了快速定位数据异常是否由游戏活动造成(如停服时活跃降为0)。
常见操作(查看开停服、活动)的快捷入口,作为信息聚合,根据业务需求调整聚合条件(监控哪些业务)。
追问主要负责的部分。
实习中的成长。
获得一个独立思考和设计产品的机会,主动沟通需求,证明可行性。
对设计方案的思考、调研求证和取舍的过程。
设计和实现都由自己完成,前后端从零开始快速上手。同事更像是需求方,需要我说服他们理解我的设计逻辑。
比较遗憾的是同事没办法给到产品设计上的帮助,也因此有下一份实习转岗产品的想法。
竞品区分点:
定价区间
用户身份定位:校友关系
亮点功能的用户反馈
项目商业化问题
有点为爱发电的性质,不抽成,希望建立成类似知乎的社区。
社区中人的身份会更模糊,可以兼具提问和回答方。
涉及第2,3点的地方,因为没有实际上线,有点慌,所以答得比较跑题。
使用的契机:竞品(腾讯文档)协作时有严重的排版和卡顿问题。
竞品对比:觉得腾讯文档的交互不合理,以入口页为例。
飞书的优势:tob的部分服务以比较低的成本下放到个人应用,比如文档管理、知识库。
解决的问题:
作为saas,个人资料的云端协同
更短的流程带来的流畅交互(登录权限认证有更长的保质期)
markdown语法程序员友好,关注内容而非排版,便于多平台适配
优化建议:
用的比较顺畅,建议没有从飞书文档本身提及。
以飞书im为例,讲了自己一次通过im想在公用电脑和个人设备之间同步图片和消息,结果网络波动导致图片聊天记录全部丢失的事情。觉得交互不够醒目和合理,没有注意到图片发送失败的问题。
飞书研发项目管理,CI/CD
私有化部署的标准化版本交付
运维
研发效能工具
在hr面之前突然被加了这一轮面试。整理面经时发现飞书妙记没有记录到这一场面试的完整内容,可能是录音被其他应用(比如电话)打断了,只记得一两个问题,不过大部分还是简历面。之前飞书妙记也有遇到类似的问题,但只是影响转译的速度,不知道是不是一个bug。但是下次有得说了哈哈哈~感觉面试官没有很在意这场面试,反问环节反问了面试官提的问题,结果他也是随便问的。最后感觉是因为面试时间线拖太久,有后来者居上被横向比较了。哎!真的有些遗憾。
B站由用户从多个推荐item中主动选择,抖音用户只能被动接受。
考虑到推荐的召回率的话,可能还是B站更好,因为提供了更多选择。抖音的信息流更依赖于算法准确率。
有点答得不明不白,反问的时候问了这个问题,结果面试官也是随口问的。
本文使用飞书文档撰写并同步修改更新至飞书知识库,欢迎在文档中评论和批注。更多分享及知识库链接请见公众号:KKCHANNEL
#产品##实习##面经##字节跳动##面经刺客#