mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 04:17:17 +00:00
38 lines
5.9 KiB
Markdown
38 lines
5.9 KiB
Markdown
## 晋升答辩的逻辑是什么？
|
||
<img src="https://github.com/FantasticLBP/knowledge-kit/raw/master/assets/upgrageReviewMeeting.png" style="zoom:30%; align:left;">
|
||
|
||
> 来源是脉脉 App 的一张图，这里做简单的扯淡。这个老前端的具体背景是什么不清楚，评委还问了什么也不清楚。
|
||
|
||
|
||
## 面试官的提法有些尖锐
|
||
面试官的提法有些尖锐、不合理。但可能（😂为什么是可能？可能有些面试官就是在扯犊子）是在考核：极限施压，看你抗压和思维能力，另外想问你真的是否理解自己的价值，对自身有没有认证思考过
|
||
主要晋升名额少，上去的除了关系户，一定需要脑子清晰、业务和技术都很能打的人。同样的问题，回答好的人，在同一批里面，通过的概率更大。
|
||
|
||
假设您提法是对的，我觉得其项目会办法落地了的。什么意思呢？因为以您的逻辑来推导：
|
||
- idea 的提出者提出创意就好了，其他项目部门和同事没有任何价值
|
||
- 如果上面的没有价值成立，那正常项目所需的头脑风暴、prd、mrd 需求评审会议、kick-off meeting，开发、测试、发布、运维质量保证、线上数据运营分析，再次迭代发布新版本等一系列流程。都没意义了
|
||
- 显然这些动作是有价值，那么之前的假设就应该被推倒，同样问题的前提就不合理，也就是您所说的「需求都是产品给的方案，价值跟你有什么关系？」这个提法就不存在了
|
||
|
||
然后我们从正面聊聊这个问题。
|
||
|
||
## 工程师的差异在什么地方？
|
||
首先，优秀工程师和普通的工程师，差异主要存在2个方面：基础的技术知识、业务领域知识。那么优秀工程师的价值就体现在可以凭借扎实的业务领域知识，更好的理解业务问题、业务现状、准确的理解好业务问题，然后利用我自身的技术知识，设计面向未来、架构合理、具备可拓展性、维护清晰简单的技术架构，更好的赋能业务。
|
||
|
||
业务领域知识和技术如何结合？
|
||
举个例子，比如电商公司一个 App 有商品业务域、订单业务域名、营销业务域，商品业务域的核心功能是什么，展示不同的商品列表、商详信息。商品有多规格、无规格、多单位 等不同 SKU 信息，商品业务域和上下游链路的交互动作是什么，也就是商品业务域对外提供什么能力、接口。
|
||
低阶工程师只是会写代码，翻译需求成“只是能跑的业务代码”。那这个代码的拓展性、可测性、维护性、性能怎么样？线上问题多不多、用了一个可能会死锁的锁、会内存泄漏的代码，虽然简单的操作下 QA 没有发现问题，但是线上用户的使用环境千变万化，可能卡顿、crash、业务异常造成资损故障… 。
|
||
这里的陈述有些不那么聚焦，这么说吧，业务方面，业务领域知识扎实和不扎实的体现在，QA 在有限时间内的测试 case 并不能穷举所有代码分支路径，也就是每个 case 并不能走完，只能证明他给的测试用例走完了，那 QA 给的测试用例走完就可以保证所有的用户不会产生异常吗？显然不会。
|
||
所以如果开发自身业务知识稳定，写的代码一来可以 cover 一些 QA 没有列举到的业务 case，二来写的代码面向未来（比如目前有 n 种订单类型1、2、3、4、5，某次需求修改了类型2的字段 sku UI 样式，其中 sku 是基础属性，会影响到其他订单类型，如果没有测试好就会产生问题，low 的写法就是多个 if… else… 加测试了，好的实现就是工厂设计模式 + 单测了，测试覆盖率所保证，或者精准测试覆盖率）
|
||
|
||
## 换个前端来做有何不同？
|
||
第二个问题，换个前端来做有何不同？同样从2个方面出发（技术知识 + 业务知识）业务领域知识、业务 sense、更好的理解业务问题和梳理咱们公司业务未来可能的走向，看看业界其他公司的产品形态都是什么样的（比如淘宝就在做竞品分析的时候，实验室机房高速摄像机去录像，逐帧分析 App启动时长。可能有些人会问为什么不从技术手段分析启动时长？这是个技术问题，自身 App 可以去分析，但是对于竞品分析来说，不精确，所以为了统一分析标准，采用该方案），未来可能存在的业务 case 是什么，我会分析现状、疏离问题、主动去挖掘问题，拼接技术功底，挖掘技术问题、性能体验问题，不断去优化和体验，持续打造领先竞品的产品。抛开数据空谈理想类似耍流氓，我也会埋点统计线上性能数据，不断去量化定量分析问题，可能存在 n个 问题，我会根据业务现状和体验问题的严重性，衡量 ROI、PK 问题优先级，着重解决用户和业务中最痛、最有价值的事情，这也是优秀工程师和普通工程师的区别，不只是任务的执行者、需求的翻译者，而是业务的 owner、做有价值事情的挖掘者。
|
||
|
||
## 优秀工程师其他的软技能
|
||
1. 同时也会挑战一些不合理的业务需求。对于产品设计师的不合理需求勇于说不
|
||
2. 展示自己的可以体现软实力的东西。比如在某个项目中承担了一些 PM 的角色，然后某个项目有危险，通过自己什么样的有效动作（协调上下游资源、攻坚不属于自己的技术问题、私下个人时间推广跟进落地取得额外的价值等），做了几次技术分享等
|
||
|
||
核心逻辑：
|
||
1. 需要不丢面试官面子，合乎礼仪（以他的问题思路作为前提，来推导一些结论，再和大家认可的事实作为矛盾冲突，巧妙反驳他）
|
||
2. 凸显自己的价值，从技术 + 业务知识2个方面展开回答
|
||
|
||
千言万语：晋升的本质就是做了一些超越你当前职级能力边界的事情，并在业务上有价值 |