https://github.com/jorgef/engineeringladders

- Technology: knowledge of the tech stack and tools
- System: level of ownership of the system(s)
- People: relationship with the team(s)
- Process: level of engagement with the development process
- Influence: scope of influence of the position

---
如果非要凑够六个维度，也许可以加一项个人成长向的，比如自驱力？

@lamls #11
@orangy #12

我碰到过几次冬天早上无法唤醒的情况。原装电池，晚上室温大概 0~5°。
要充电几分钟才能开机，开机进系统显示电量 0%。

所以我怀疑「天冷掉电」是电脑锂电池的通病，不是第三方电池的锅。

我的处理方法：冬天夜里把 MBP 放卧室里（室温 > 10°）。

同 15’ MBP 2015 ，三年前通过苹果官方的电池召回计划换过一次。
https://support.apple.com/zh-cn/15-inch-macbook-pro-battery-recall

今年 8 月份发现又开始鼓包了。
苹果不支持再次召回了：「 您输入的序列号不符合这项计划条件。记录显示，您的设备已通过这项计划进行了维修。」

现在机器除了发热厉害点儿，日常使用需求都能满足。迫于穷，还想再让它继续服役一两年。

想问一下 OP 换的是什么品牌的电池，什么价位？
后继使用过程中如果有啥问题也希望 OP 能持续更新。
谢谢。

建议参考头部玩家的技术选型，比如 Discord 的数据库迁移历程：MongoDB → Cassandra → ScyllaDB

《 How Discord Stores Billions of Messages 》
> In July, we announced 40 million messages a day, in December we announced 100 million, and as of this blog post we are well past 120 million.
> The messages were stored in a MongoDB ……, we reached 100 million stored messages and…… see the expected issues appearing: the data and the index could no longer fit in RAM and latencies started to become unpredictable.
https://discord.com/blog/how-discord-stores-billions-of-messages

《 Discord Chooses ScyllaDB as Its Core Storage Layer 》
https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/

> 重点来了，这次面试一开始面试官看完简历，就告知我他们做渲染图形方向的，好像不太匹配，问我要不要继续，我直接就拒了。全程持续 2 分钟。

一方面，面试官在面试开始前竟然不读候选人简历不针对性预设讨论内容场景，极不专业；
另一方面，方向不匹配 HR 也要联系面试，极不专业。

感觉字节（或者该部门？）的招聘流程极其混乱与傲慢，浪费人才时间精力。

感觉 Kotlin 是我用过的最舒服的语言。最喜欢的几点：
1. 语法糖: null-safety, lambda, `val`, standard library
2. coroutines
3. 设计好 DSL ，写代码犹如写文章
4. 全端开发

我最近一次写 kotlin 代码大概是两年前，印象中有这么一些劣势／限制：
1. 语法过于灵活很容易放飞自我， 普通开发者难以消化大量的 let/apply/run/also 和 filter/flatMap/associate/groupBy
2. 除 Android 和 backend 外，其它端的工具／生态／社区还是不够完善，能用但不够好用
3. 编译速度慢

基于以上因素，我建议只在独行侠项目中使用 Kotlin 。
如果能在团队中成功应用，也许需要是业界 top 10% 精英组成的超级团队。

@vczyh #37

> 情况 1：查询用户，带出对应的订单（造成 User 依赖 Order.getListByUserId(long userId)接口）
> 情况 2：查询订单，带出用户的某些信息（造成 Order 依赖 User.getSomeInfo(long userId)）

用户模块属于最基础的模块，不应依赖于其它业务模块。考虑两种情况：
1. 如果用户模块依赖于订单模块，那么添加支付功能就会依赖支付模块，添加消息功能就要依赖消息模块，最后用户模块就会成为一个「巨无霸类」，无法维护；
2. 如果把用户模块和订单模块拆分为独立的微服务，那么用户微服务里不应保存订单信息，所以用户模块也不应依赖订单模块。

回到「情况 1：查询用户，带出对应的订单」的问题。
从产品业务分析，我觉得这是标准的「基于用户 ID 查询订单」功能，应该由订单模块独立提供 API 接口和服务。
web/app 端拿到用户 ID 后调用这个 API 接口即可。

@20015jjw #12
@janus77 #22

似乎二位没有读完「 TL;DR 」的内容。

为了避嫌「躲闪回应关键问题」，我还是回复一下吧。
----

> 说白了就是没面满意 他就觉得你值这么多 你以为大家都闲着喜欢面着玩 浪费钱吗

没面满意就直接告知「本轮面试没通过，是否考虑我们的 xxx 职位？」，应该不难吧。
何必继续走完招聘流程浪费彼此时间精力呢。

> 至于压价，哪家不压价？段子上面写的“面试 10-20k ，实际就 10k”你以为仅仅是个段子吗？

我的情况是「面试 10-20k ，实际就 5k 」。
这已经不是压价的问题，说严重点叫招聘欺诈。
如果能以沟通职位的薪资下限发 offer （虽然竞争力不大，我不会接受），我也不至于对 HR 意见这么大。
----

如果两位觉得「未及职位要求，不告知应聘者，以低职级岗位完成面试及薪资调查流程」是合理的行为，那就好吧「您说的都对」。

@kenl6 #13

> 请问楼主，低职级面试高职级会有什么坑

如我文中所述：低职级面试官，可能无法客观准确全面地评价高职级候选人的能力水平。

客观性：面试官可能持「为啥他能应聘这个职位却不让我晋升」的心态进行刁难。

准确性：候选人描述的高阶技术及场景案例，可能超出面试官的能力和视野，导致其无法准确评判。

全面性：面试官可能过多关注自己擅长的领域，而非招聘职位的工作内容与关键技术。
----

早些年我也曾经尝试过几次「低职级面试高职级」的机会，但是面下来体验极差。

大概有几种情况：
1. 面试官认为候选人不过尔尔，他说的技术我们大多听说过（同样的问题我们也存在，只是没时间 /机制 /资源去处理）。
2. 面试官带着固定答案问八股文，不认可候选人在类比场景下的解决思路。
3. 企业不重视技术，都找不出一个技术水平相当的员工或顾问。

当然，也可能是因为我的能力没有达到举重若轻、授道妇孺的境界。

@mara1 #14
@ioriwong #9
@xtx #15

因为蔚来汽车发布的职位 title 就是这个格式的（虚拟举例：「互联网摸鱼专家 150 - 200k・14 薪」）。
为了尊重事实，我保留了这个格式来表达薪资，只是隐去了具体薪资数字。

这种表达确实不好理解，所以我 append 了解释。

感谢诸位的讨论与信息补充，修正了我对网约车平台及长途打车的认知。
本帖标题也许可以改成：「高德跨城打车体验：平台傲慢模型下，司机内卷黑车化」

从人文关怀的角度，网约车跑长途确实性价比不高，要求加价的心理可以理解。
只不过他们要求加价的对象应该是网约车平台，而非乘客。

从社会进步的角度，我仍然坚持既然选择了网约车平台提供服务，就应该遵守平台规则。
如果不认同平台规则，就应该用行动投票，与平台 /市场 /官府博弈，鼓励与促进精细化运营的市场参与者。
而不是加剧内卷的同时，试图靠破坏规则侵害乘客权益，来获取本应合法合理的收入。

@Jooooooooo #3

> 换句话说, 无法标准定价, 也就会造成随便定价的问题
高德／携华对远途订单是有标准化定价的：起步费 11 + 远途费 184 + 分段里程费 228 + 分段时长费 22

> 从你的描述来看, 我感觉滴滴把当前定价直接乘以 2 更合理点.
215 公里收费 1000 ，要达到高德的「商务型」标准了

@cxh116 #2

如果觉得跑长途不值当，完全可以选择不接单嘛。

上车后再绕过平台要加价，这不就是妥妥的黑车行为么。

@shot #35

呃……算错了。

1.5 Gbit ÷ 8 byte / bit ≈ 2 × 10⁸，相当于全中国人民每十秒钟都刷一次百度首页。

@lawler #29

> 百度大部分时刻首页流量每秒在 1T~2T 。在已经极端压缩优化 js ，css 的前提下。又删减了一个字符，流量下降 1.5G~3G/s 。

姑且不考虑 gzip 压缩传输，一个 UTF-8 字符 1 byte ，1.5 Gbit ÷ 8 byte / bit = 7.5 × 10⁸。
10 亿量级的 QPS ，相当于全中国人民每一秒钟都刷一次百度首页。这不太客观吧。

如果考虑 gzip ，压缩之后更不应该会有显著区别了。

读下来感觉楼主对低学历的怨念有点儿魔怔了，下意识把所有的难以克服的困难都归结到学历上。

相亲谈恋爱，还是要看缘分碰到合适的人，不要因为个别人生过客否定自己的价值和追求。

---

> 1.工作性质

java 10 年，年入 60w 。说明你已经在高科技的 IT 领域站稳了脚。可见学历并没有影响你的工作性质。

> 2.兴趣爱好生活情调:比如学历高的人可能比较倾向于高雅艺术比如读书 /听音乐 /去美术馆 业余生活爱好等
> 3.三观 世界观人生观价值观等都会有点距离 眼界宽一点 关注点可能不一样 对生活要求不同 过什么质量的生活 精神生活可能不一样

这些内容不是大学的必修课。
只不过好大学里能接触的这些内容的机会和人群比社会多一些而已。

我接触过的 985/211 毕业生，绝大部分对这些方面也说不上有啥追求。
顶尖高校的教授们，也有他们市侩的一面。

你要想在这方面突破自己，有的是渠道和方法去努力。
选择追求别的人生目标，也无可厚非。

同意 @root8080 #10 的观点，合作者的素质非常重要。

补充一下「组织合作」视角的观点：
既然「口头沟通」存在障碍，那你们能否尝试把沟通的内容以文字的形式整理出来，相互完善以便达成共识呢？

文字的组织过程，其实也是对自己思路的整理、提炼和推敲。
表现形式也很灵活多样：需求文档、产品设计、技术方案、jira ticket 、思维导图、……
可以是领导牵头完成，也可以是团队成员先根据自己的认知完成初稿找相关方确认。

团队沟通有障碍，如果只是个别成员的素质问题，就先帮助提高他的工作素质；
如果是团队普遍问题，那就需要从团队合作机制上去解决它。

要是直接就放弃沟通，看起来非常缺乏共同目标和合作意愿。
你们这个组织更像是「乌合之众」（ crowd ），而非「团队」（ team ）。

从 leader 角度说说我的经验和看法吧。

楼主引用的言论，我和团队成员交流时经常提及。
谈论这些内容的对象有两个前提：
1. ta 明确向我表示过，希望得到职级的晋升，但 ta 目前的能力经验知识储备仍有较大差距；
2. 或者 ta 的简历与面试时声称承担过哪些职责获得过哪些成绩，但是入职后发现工作结果远低于预期。

如果是故步自封不思进取的人，那根本没必要请 ta 进步，ta 会在团队里逐渐边缘化自己离开。
如果是实力与 title 相符的人，ta 对自己的能力和成长路径有很清晰的认识，很多时候 ta 会主动请教如何进步。
----

如果抛开「领导 vs 员工」的对立身份，假设说这些话的人不是「领导」，而是一个关系非常亲密的朋友，而且阅历比你丰富知识储备比你多，你还会觉得他是在 PUA 你吗？

更进一步的观点，如果你确实希望自己进步，你自己就应该有意识地主动分析工作中的得失，个人的优势不足，补强的方法路径时间节点，需要上级团队客户给予的支持等等。
这些操作可以认为是成为行业精英的普遍选择和必然路径。
----

> 自己如何成长是自己的事情，成长方向也应该是自己选择的

同意。只要你确实问过自己这些问题，已经有明确的答案，并且正在按照计划努力成长。
那你又何妨与领导真诚直接地沟通这些内容。也许他可以给你一些改善的小建议呢。或者调整你的工作内容让你学到的新知识能直接付诸实践。

> 不断的要求总结你的缺点实际上是一种 pua 行为，通过不断打压你让你丧失工作上的自信心。

不同意。
除非对方只是指出你的缺点，却完全不给时间机会解决方案去补强；或者给你错误的指引（比如明明是系统 bug 却让你请客户喝酒解决）。

> 不断的要求你成长一个方面只是让你不断的努力加班

从个人的经验来说，当工作内容和自己的成长规划一致时，我会主动加班。但这只能是对自己的要求。
对团队成员，我的建议是：
八小时内兢兢业业，八小时外海阔天空；
八小时内求生存，八小时外谋发展。