1. 软件工程师的软技能指北（一）：总览篇
2. 软件工程师的软技能指北（二）：事业篇
3. 软件工程师的软技能指北（三）：高效交流篇
4. 软件工程师的软技能指北（四）：简历篇
5. 软件工程师的软技能指北（五）：面试篇(暂时跳过, 后面再填)
6. 软件工程师的软技能指北（六）：谈薪篇

2 前言

打了这么多年工，要说最后悔和最遗憾的是什么，「拿到 Offer 之后没有好好和 HR 谈薪资绝对算是（甚至没有之一）」。

如果说面试前的简历准备，刷题，面试中应付面试官的各种提问以及面试之外的学习与积累是一场马拉松比赛的话，那么拿到 Offer 就意味着你已经成功完成征程的前九十九步了，而商谈薪资待遇就是最后一步，亦是最关键的一步。

如果这一步没有做好，前面的九十九步无论多完美都等于白费了，可谓是令人痛惜。

谈得成功的话，可能一年工资就多了一辆车了（至于是五菱MINI 还是保时捷911就看实力了）。

3 认知

回想我之前曾经关于「谈薪资」的错误认知，可谓是非常经典，可惜当初没有师长可以为我指正。

3.1 学生思维

刚毕业时的「这是家大公司，我是来学东西的，开什么薪资都可以」, 这个可以算是典型的「学生思维」，甚至出发点就是错的。

工作的根本目的就是「为了赚钱养活自己，过上更好的生活」，而不是去企业里面学习，「学习新本领」也只是「打工赚钱」的副产品而已。

经历过各种残酷的「末位淘汰」后我就发现，企业招「应届生」进去也不是因为看中你潜力大啥的，而是需要你这个年龄段的员工， 企业也有各种政府下达的就业指标，而招你进去也不是让你学东西的，而是让你干活的。

最明显的佐证就是，我所经历过的大公司每年的「末位淘汰」会有很多的应届生被打低绩效， 毕竟刚出校门的学生在能力，经验等方面是肯定是不如老员工的。

「末位淘汰」从来都不是激励你学习的，而是让你多干活的。

既然公司招聘员工是为了公司利益的最大化，员工自然就要最大化自己的利益。

3.2 心理负担

不要把公司 拟人化 ，不要觉得和公司「谈判」不好，因此产生心理负担，公司只是众多利益相关的人组成的共同体而已。

3.3 不愿意承担风险

诚然, 现在整体就业大环境肯定不如2010-2020年的黄金十年，各种裁员降薪的消息层出不穷, 但如果持有「能找到个工作就不错了，还谈什么薪资」的认知，可能很难去HR谈薪资, 毕竟你潜意识就已经选择接受 Offer, 除非是 HR 的报价是远低于你的底线.

须知，收益永远是风险挂钩的，你永远不可能有高收益，零风险的投资标的。

3.4 默认公平幻想

「工资由能力决定，相信公司会公平对待，肯定可以拿到对应的薪资，不需要自己去谈」

我曾经也持有种这样的「幻想」，以为凭借面试的表现折服了面试官，他自己会帮我争取, 甚至给我一个好的薪资.

首先，在较大的公司，面试官都是无法决定或者甚至知道薪资的，会有专门的 HR 团队来和你的谈判薪资的；

其次，你也很难期望面试官能把技术面试的结果如实呈现给非技术出身的 HR.

总而言之，「有枣子没枣子打一棒就好了」，争取了不一定要有，但是不争取绝对不会有人给你加工资的.

4 风险收益分析

我用博弈论模型来简单分析下分析公司和求职者的策略互动过程中风险与收益, 用收益矩阵来表示双方的选择和收益。

假设公司有三种策略:

1. 接受谈薪（给更高薪资）
2. 拒绝谈薪（维持原 Offer）
3. 撤回 Offer

求职者也有三种策略:

1. 不谈
2. 温和谈判
3. 强硬谈判

分析策略:

• 不谈薪（保守策略）
  • 公司不会撤回 Offer，但求职者没有额外收益。
• 温和谈判（合理博弈）
  • 60% 机会加薪 5W，40% 机会薪资不变，公司很少会撤回 Offer（5%）。
• 强硬谈判（高风险高回报）
  • 50% 机会加薪 10W，30% 机会薪资不变，但 20% 可能失去 Offer。

收益矩阵:

纳什均衡:

• 如果求职者选择温和谈判，公司最优策略是接受或拒绝，而非撤回 Offer，因为撤回 Offer 也意味着公司损失招聘成本。
• 如果求职者选择强硬谈判，公司可能更倾向于撤回 Offer，因为不愿承担过高的薪资成本。
• 温和谈判是最优策略，因为它在风险和收益之间达到了较好的平衡, 既有提升空间，又降低 Offer 撤回风险.

也就是对于求职者来说，如果你选择谈判，谈判失败，你的结果大概率也是接受原 Offer而已，而一旦谈判成功，你将会获得额外的收益。

可以说在接 Offer 谈判时 风险低, 收益中, 甚至高 , 而不谈薪是最保守的策略，但也是收益最低的.

5 公司的策略

公司的终极目的肯定是为了创造营收，而在招聘中直接目的是希望可以招到想要的，能干活的员工。

每个职位肯定都是有级别，不同级别有不同的工资范围，但是级别只是定义了上下限，拿到上限和下限之间可谓有天渊之别。 而且，绝大部分职位，都不会给上限工资，人人都给上限，工资预算肯定超标了。

HR 给你 offer 数字之前，要考虑几个因素:

1. 公司招人有预算，能用低价招到的，就肯定不会出高价
2. 你可能会讨价还价，所以不能直接给上限，要留有提价的余地
3. 如果工资太低，你可能一怒之下就拒了。

6 求职者的手牌

虽然求职者与公司谈判过程中处于相对弱势地位，但是这并不意味着我们完全没有牌可打，所以我们要利用好手上的牌。

6.1 公司内部的助力

说起来可能难以置信，虽然求职者可能与公司的人还毫无联系，但是求职者会在公司内有相当的助力，因为基本上你接触到的公司每个人都是想你接 offer 的.

对于公司来说，在你身上已经花费了相当的成本，HR 筛选简历，安排面试官面试，2-4轮的面试，都要花费面试官与HR时间的，公司付给员工工资，这些时间都是要算钱的。

而一旦你拒绝，这些花费的时间成本都会成为沉没成本。

对于 HR 来说，她们也是有考核指标的，招聘人数也是她们的考核指标，所以她们也有强烈的动机尽快招到人。

而对于招聘你的团队老板来说，肯定是希望赶紧招到人来干活的，工资多少他不关心，反正出的又不是他的钱。

所以这些人都是希望你能接 offer 的潜在助力。

6.2 多拿Offer

拿到多个的 offer，这个会成为你和 HR 谈判的最大底气，你就不会担心谈崩了，这家给不了，了不起去下家；如果多个公司愿意相互竞价，你就能渔翁得利，利益最大化。

对于公司来说，肯定是希望招到能力强，能干活的候选人，但是怎么去量化能力强呢，即便候选人通过了面试，也不能说明他们能力一定能胜任。

但是如果你能通过多个公司的面试，对于HR来说，相当你额外再通过了十几二十轮的面试， 从概率来说，你是没能力的候选人的机率大大降低，既然大家都说你好，那么他们就有更强烈的意愿与你洽谈。

6.3 薪资是底牌

上文提到，公司的策略是希望以尽量低的薪资来招到人，那么两个非常重要的参考标准：

一个就是别的公司给你开的工资，另外一个就是你现在的工资,

假如你现在的工资是20W 一年, 那我就只给你加个20%, 最多给加个30%, 既然你20W都愿意干，为什么我要开高价.

所以你现在的薪资就是你的底牌, 千万不要给人看到, 不然就定死上限了。

不然你拿了一次低工资，后面次次跳槽都要拿低工资，凭什么呢？真的是闻者伤心。

所以HR问你的时候，不要正面回答，尽量模糊化，以此争取最大利益。

比如HR换个问法，问你的预期薪资是多少？

这个问题非常坑，相当于给自己划定上限，如果你回答30W, 她就绝对不可能给你40W, 你可以回答说：我心里没个具体数字，但我对任何有竞争力的 offer 持开放态度.

一定要给的话，就给个模糊的范围, 比如阿里P7的水平吧。

7 谈判的手段

7.1 表达强烈的兴趣

“你想加入这家公司"这个前提是一切谈判的基础。

如果你表现出对加入这家公司兴趣寥廖, 那么即使你强如 Linus Torvalds, 也不会有HR会想和你谈薪资的，因为这个注定是不会有结果，她们当然也不会浪费时间。

所以你需要表示出对这家公司有强烈兴趣，无论是文化，工作方式，业务或者技术栈都与你非常契合，而你加入公司目前唯一的障碍就是没有拿到满意的薪资，这样HR才会非常乐意来为你争取。

你总要创造些条件给 HR, 她们才能为你争取更多。

所以无论你是否对这家公司感兴趣，起码你在谈薪资阶段都要表现出强烈的兴趣。

7.2 少说多听

求职者在谈薪资过程中是处于相对弱势的地位的，所以在谈判过程中要多听少说， 因为你的底牌不能被她们套出来，说得越多，不经意间漏出来的可能就越大。

而在电话中，当对方HR 试探性给出一个报价后，你都不要太快回应或者表达出来，因为对面的大概率也是谈判的老手，如果你表现得很欣喜, 那么她们就知道这个已经比你的底线要高了.

所以当听到报价之后，你可以适当地保持沉默，表示犹豫，然后让她们进一步加码, 即使她们不加码，你也用沉默表达了对报价的不满意.

7.3 多个公司竞价

如果只向一个公司谈 offer, 最多两轮，可能就到了摊牌的时刻了。

只有能让多个公司竞价，你才能让你的「未来雇主们」卷起来，实现利益最大化, 另外其他公司的报价也可以成为的谈薪资的底价.

比如你工资是20W, 你想要30W, 公司的HR就会挑战你，说你这30W 太高了，他们给不来, 其实也是换种说法说你不值30W.

但是如果A公司给了你30W, 那么你就有底气问 B 公司要高于30W 的薪资, 毕竟这是市场对你的认可.

假设B 公司给了你35W, 那么你就可以回头向A 公司说，你拿到个35W 的offer, 让A公司提高下标准, A 公司可能给到个37W,

然后你再回到 B 公司说:

我真的很想加入贵公司，和你们一起工作，只是A公司给了37W, 着实很为难，我真的很加入你们, 你们可以再匹配一下嘛?

B 如果能给到40W, 再把同样的话和A 说一次, 两家公司工作竞价两次, 就相当于谈了4次了.

如果手握两家以上公司的 offer, 那么这个可以再用到其他公司身上，所以这个就要求你要在差不多的时间拿到全部的 offer.

7.4 不要当场答应

无论 HR 给你的报价多么诱人，又或者这个是你梦寐以求的公司，都不要当场答应下来， 万一其他公司给你更好的报价呢，当场答应而后又反悔给人的印象太不好了, 要给自己留有余地。

如果 HR 要你马上给出答案，你也可以这样回应:

我非常珍惜贵公司提供的这个机会，我也非常希望加入贵公司，但是我意识到这个机会会对我的职业生涯产生重大影响， 我希望可以和家人商量之后再下决定。

8 总结

几轮谈薪之后, 你可能拿到满意或者仍然不满意的报价，你就可以根据自己的诉求选择公司了。

你不一定会选钱最多的，可能你还会考虑公司前景，职业前景，工作强度等因素，但是起码选择之后你不会因没有为争取更高的收入进行谈判而后悔。

此外，这个可能是你在这家公司最容易调薪的一次了。

一旦你加入公司之后，你就会受限于绩效，级别，部门业绩等各种限制，再也不会有打几通电话, 发几封邮件就能涨薪的美事了。

所以，从这个角度来说，谈薪资的电话可能是你最应该打，且性价比最高的电话(大概率也没有之一)

9 参考

• https://www.healthyhacker.com/2019/07/13/more-money-please/ (一个我很喜欢的播客的主持人分享他自己谈薪资的过程)
• https://www.1point3acres.com/bbs/thread-286214-1-1.html (一亩三分地版主分享求职如何跟公司讨价还价)
• https://podcasts.apple.com/us/podcast/no-477-%E6%88%91%E8%AE%A4%E8%AF%86%E7%9A%84%E6%9C%80%E5%8E%89%E5%AE%B3%E7%9A%84%E5%88%9D%E4%B8%AD%E6%AF%95%E4%B8%9A%E7%94%9F-%E5%8A%AA%E5%8A%9B%E5%B7%A5%E4%BD%9C-%E5%AD%98%E9%92%B1-%E7%95%99%E5%AD%A6-%E8%AF%BB%E4%B9%A6-%E7%BB%A7%E7%BB%AD%E5%8A%AA%E5%8A%9B%E5%B7%A5%E4%BD%9C/id1147186605?i=1000676154793(忽软忽硬电台采访，这位同行在下家要求出具薪资证明的时候，请财务吃饭，直接将工资x2再打印出来，叹为观止)

1. 软件工程师的软技能指北（一）：总览篇
   
2. 软件工程师的软技能指北（二）：事业篇
   
3. 软件工程师的软技能指北（三）：高效交流篇
   
4. 软件工程师的软技能指北（四）：简历篇
   
5. 软件工程师的软技能指北（五）：面试篇(暂时跳过, 后面再填)
   
6. 软件工程师的软技能指北（六）：谈薪篇
   

2 前言

我在高三的时候，每周有五节的语文课，我的语文老师陆老师总是会拿一节语文课，当作书法课，让我们练字。

陆老师认为，写作文能言之有物，切中要点很重要，但是答卷的字体也很重要。

可能同样的答案内容，字体写得好的试卷会比字体一般的试卷高5到10分。

而陆老师自身的软硬笔书法水平都很过硬，黑板板书相当漂亮。

明清两朝，有专门用于科举考试的通用字体，特点是：以乌黑、方正、光洁而大小齐平。

明朝称之为「台阁体」，清朝称之为「馆阁体」：

人终归是视觉动物，内涵固然重要，门面也不可或缺。

如果把工程师的职业当作事业的话，那么简历就是门面和敲门砖。

如果有足够的亮点的经历的话，再配上优秀的简历，可谓如虎添翼；
纵然经历不够亮点，一份得体的简历就如考试时的一手好字，同样可以让人眼前一亮。

3 要点

所谓的简历，本质上和街边的宣传单，以及电视上的广告没有什么区别，都是希望可以引起潜在客户的注意，把「商品」销售出去。

只是他们销售的是商品，你销售的是自己的「劳动力」。

而你的目标是在诸多的同行竞争中脱颖而出，你需要做的是「扬长避短」，把自己的长处和优势展示给潜在客户。

根据社会心理学的研究，人总是会对先看到的词产生先入为主的认知。

如果形容一个人：

勤劳，勇敢，善良，温柔，俊美，卑鄙，下流，肮脏，贪婪，邋遢。

你对他的印象是好是坏呢？

那下面这个人呢？

卑鄙，下流，肮脏，贪婪，邋遢，勤劳，勇敢，善良，温柔，俊美。

你对他的印象是坏是好呢？

同样的内容，调换了顺序，给人的认知就完全不一样了。

所以你需要做的，就是把你最引以为傲的内容（比如你的经历，学历），放在简历的前面；
再把你觉得弱势的内容（比如学历，经历），放到简历的后面。

4 结构

我个人习惯是会在简历中呈现五部分内容：「联系方式(Contact)」, 「职业经历(Employment)」, 「项目(Project)」, 「教育(Education)」, 「总结(Summary)」。

放在最前方的，毫无疑问是联系方式，不然潜在客户对你再感兴趣，找不到你的联系方式，也是抓瞎。

其次就是教育，职业经历，总结的顺序。

我个人的学历不占优势，只有本科学历，又非名校，根据「扬长避短」原则，「教育」就被我放最后了。

因为我自己在三家所谓的大厂打过工，所以职业经历更有优势，所以「职业经历」放在前面。

而「项目」大多时候与「职业经历」挂钩，逻辑顺序上，在职业经历之后，所以结构就变成：

• 联系方式
  
• 职业经历
  
• 项目
  
• 总结
  
• 教育
  

结构推荐是这五项，顺序就根据个人自身情况进行调整了。

5 格式

联系方式与教育没有太多值得说道的点，可谓千篇一律。

主要聚焦点还是在项目和职业经历上。

5.1 职业经历

职业经历的格式也相对固定：

「公司」，「地点」，「担任的角色」，「工作时间」

「在公司中负责或参与过的项目，一句话概括」：

1. 参与xxx 项目，负责xxx 的开发，达成了什么成果
   
2. 负责xxx 项目, 设计，开发xxx, 取得了什么项目成果
   
3. 负责xxx 项目，…
   

在职业经历中一句带过项目经历，进而引出下文提到的项目经历，相当于承上启下。

当然，如果项目太多，也需要作相应的增减。

5.2 项目

可能会有朋友觉得项目和经历着实没有什么好写的，或者写出来的内容类似：

服务编码，前后端对接，测试

功能开发并上线

每个项目和经历总是有东西可以写的，成功的项目有可写的内容，失败的项目也有可写的内容，只要有思考，总是有输出的。

那么思考的方式是什么呢？

5.2.1 STAR method

就是之前在《软件工程师的软技能指北（三）：高效交流篇》提到的 STAR method 这种结构化的思考和沟通方式。

所谓的STAR method, 是四个单词的首字母缩写，分别是: Situation(场景), Task(任务), Action(行动)，Result(结果)。即：

• situation: 描述问题的背景，这个问题是什么，以及你为什么需要做这个事情
  
• task: 你具体的任务是什么，你需要做什么，你的角色是什么？
  
• action: 你做了什么事情？ 你的行动是什么?
  
• result: 项目结果如何？ 最好用 可量化 的指标来呈现.
  

通过STAR method, 以结构化的方式来思考，并呈现你的项目，描述你的职责与成果。

xx 公司/xx 项目, 时间: 2020.03-2020.xx

1. 项目背景一句话、
   
2. 自己在项目里负责的工作
   
3. 用到的技能/思考的过程或者难点攻克的过程
   
4. 项目的结果或者我的成绩
   

例如：

服务编码，前后端对接，测试

就可以修改成:

负责xxx项目开发与设计，主导前后端契约设计，前后端并行解耦开发工作，项目用时1个半月成功上线，日访问用户20w, 页面浏览量100w, 峰值访问1000/秒，服务平稳无故障。

这不比平铺直述更有感染力嘛。

5.2.2 量化指标

量化的数字让人更有印象，会让你的经历更有说服力，也更能突出你自己的成绩：

如非量化的指标表述：

项目重构之后，服务性能与可用性都得到了显著提高

难免让人觉得说明力不足

项目重构之后，压测TPS从100/秒增长到1000/秒，系统的不可用总时长从上线前的2小时下降到20分钟，系统可用性从99.9% 增长到99.99%

这个又可以呼应《软技能指北（三）：高效交流篇>》》的「云雨伞」模型，通过数据来表述「云」，增加说明力。

6 排版

所谓亮眼的简历，无非是「优秀的内容」+ 「简洁耐看的排版」。

「内容」值得每个工程师花心思去构思，但花时间去「排版」却大可不必。

所以写简历，我只推荐使用 LaTex, Word 还是算了吧。

有朋友可能不熟悉 LaTex, LaTex 是美国计算机科学家Leslie Lamport(就是那个发明 Paxos 共识算法的大神) 在20世纪80年代开发的排版系统，遵循「展示与内容分离（separating presentation from content）的原则」, 顺便说一下, HTML 和 CSS也是依照「展示与内容」这样的思路。

即使用户没有排版和写代码的经验，只需要根据模板填入内容，就可以生成精美的出版刊物。

想熟练掌握Latex, 需要花费相当长的时间, 但是如果只是用来写简历，只需要掌握几个简单的宏即可, 难度只比Markdown高一点.

本地安装和使用LaTex 相当麻烦，所以强烈建议使用网页版本的LaTex 服务，如 Overleaf: https://www.overleaf.com/, 所见即所得, 非常简观，对类似我这种Latex 新手非常友好.

至于简历模板, Overleaf 本身有很多的简历模板分享，Github上也有许多类似的项目，如 https://github.com/billryan/resume, 只要把在 Overleaf 上把内容填入到模板中，即可生成一份好看的简历：

如果是应届生，推荐简历在一页内，在职的工程师，简历最好也不要超过两页，太长的简历没有人会去细看的.

6.1 照片

是否要放照片，这个取决于行业和自身特点，遵循「扬长避短」原则即可，如果形象得体，大可把照片也放在简历中。

6.2 文件格式

只推荐pdf，因为这是一种通用的文件格式，相当多的工具都能打开pdf.

我既不推荐使用word 写简历，更不推荐发送word 格式的简历。

因为并非人人电脑都有装office 办公软件，不一定能打开；此外，版本不正确，或者相应字体没有安装，可能就会导致精心排版的简历乱掉了。

简历文件命名: 姓名_[公司/学校]_联系方式.pdf, 对于毕业生而言, 就把「学校」后缀带上, 对于已经工作的打工人，就把「公司」带上.

切记不要以「简历.pdf」这样的文件来命名，HR可能一天收到几百封简历，
她完全有可能不记得自己是否打开过「简历.pdf」这个没有辨识度的文件.

7 投递渠道

写完简历之后，免不了要向潜在客户推销简历，就我个人所知的几个渠道: 内推，官网，第三方招聘网站，猎头，优先级分别是：

内推>>官网~=猎头>>>第三方招聘网站。

无论是找相熟或者不认识的朋友，内推总是投递简历的最优推荐，因为有人可以帮忙跟进处理进度。

无论过与不过，都可以马上知道结果，可以最大限度地避免石沉大海

如果心仪公司没有相熟朋友，也可以在脉脉或者Linkedin上找人内推。

别人一般都很乐意的，部分公司还对内推有奖励。

如果实在是找不到人内推，官网也是一个备选项，一般公司的简历系统都会对处理时间有规定，简历起码都会被处理到，但有可能渺无音讯。

2022年时曾经去 Indeed 官网投递，几天后直接收到拒信了.

比较有趣的是，在收到拒信之后, Indeed的招聘人员却在Linkedin 上面加我了.

像「Boss某聘」这类的第三方招聘网站，一般是投递没有「官网」或者内部招聘系统的公司的选择。

毕竟HR连官网的简历都有可能处理不过来，着实不大可能去第三方网站上捞简历，只有在要应付指标的时候，才会上去捞一下。

当然，把简历直接给到「Linkedin」,「脉脉」之类的三方招聘网站的HR, 那就是属于选项一的「内推」。

最后才聊到「猎头」，「猎头」本质上是把你的职业当作商品，你自己的「职业」规划和未来与他们关系着实不大，
所以他们给你推的不一定是满足你规划和兴趣的公司。

但「猎头」比第三方网站要强的地方在于，他要把「你」这件商品成功销售给他的客户，也就是你入职成功才能获利，所以我们作为求职者与「猎头」是有共同利益的.

关于筛选无用的猎头和招聘消息，我有个简单的小技巧:

我在「Linkedin」上，把我的First Name 设为「啤酒的Emoji」，Last Name 才是「我的姓与名」。

所以那些没有看过我信息，直接私聊发送招聘信息的，就会变成这个样子：

连我名字都没有写对的人，还能指望什么呢。

8 抛砖引玉

我按照上文提到的技巧，结构与格式来整理了一下自己拙劣的履历：

9 趣事

之前，在博客和公众号上发了一个内网看到的 Amazon的国内专场招聘，给有兴趣去加国血汗工厂打工的朋友分享了这个信息。

然后，过了一周后，我的个人邮箱收到了这个专场招聘的另外一位recruiter 的邮件，推荐我去参加这个专场招聘，因为我曾经用自己的个人邮箱给 Amazon 投递过简历。

只是这位recruiter 不知道我入职，并且与她同组的另外一位同事沟通过这个专场招聘的事。

就变成了我这个帮忙发专场招聘信息的人，最后究竟也收到了这个专场招聘的邀请。

10 总结

一份优秀的简历就好比一份宣传册子，可以更好地向我们的潜在客户推销自己。

但功夫在平时，简历的内容最终也是日常积累的呈现。

扎实做好日常工作，成为一个靠谱的人

金玉其外固然好，内有乾坤两相宜。

按照一位长者的话说：「两手抓，两手都要硬」

11 参考

• https://en.wikipedia.org/wiki/LaTeX
  

1. 软件工程师的软技能指北（一）：总览篇
   
2. 软件工程师的软技能指北（二）：事业篇
   
3. 软件工程师的软技能指北（三）：高效交流篇
   
4. 软件工程师的软技能指北（四）：简历篇
   
5. 软件工程师的软技能指北（五）：面试篇(暂时跳过, 后面再填)
   
6. 软件工程师的软技能指北（六）：谈薪篇
   

2 前言

让我静静，我只想写代码

化用《我的团长我的团》里面，孟烦了父亲的一句话：

为何诺大的公司，放不下一张能安静写代码的书桌？

在我此前的固有认知里，所谓的软件工程师就应该安安静静地写代码，但为何我总是求而不得呢？

但事实是，在软件开发的大部分时间里，我们都是在与「人」交流，而非与「计算机」交流。

即使我们编写代码，首先也是让「人」去理解，其次才是让机器来执行，否则直接写二进制代码即可。

而在程序优化中，有一条金科玉律：「针对热点代码进行优化」，因为那是性价比最高的优化策略。

既然软件开发中，大部分时间都是与人交流，那么如果能提高与人交流的效率，那么我们的开发效率也会相应地大幅提高。

3 原则

3.1 尊重

与人相处时，最重要的概念之一（可能没有之一），就是尊重他人，每个人心底都是渴望被尊重的。

所谓的尊重体现在各种的细节里面，例如：

尊重他人的观点和言论，留意倾听，眼神放在对方身上，不随意打断别人。

尊重他人的时间，不迟到。

尊重他人的成果和工作，引用时注意作者与链接等。

尊重别人的空间，不在工位附近大声开会，尽量找个会议室。

被尊重是每个人最基本的需要，也是很容易忽略的地方。

我自己也会在心急时，直接把别人的话打断掉，所以自己在这方面还有很大的改善空间。

3.2 不随意批评

因为国内普遍存在的各种上下级等级关系和官本位思想。

遇到阻碍或者问题时，很容易通过「批评」来推动和开展工作，甚至很容易出现所谓的「PUA」话术：

其实，我对你是有一些失望的。当初给你定级px，是高于你面试时的水平的。

我是希望进来后，你能够拼一把，快速成长起来的。

px这个层级，不是把事情做好就可以的

你的产出，和同层级比，是有些单薄的，马上要到年底了，加把劲儿。

什么，这个事情排期要2周，1周就可以了，没有多少工作的。

我自己也亲耳听过类似的话，心情着实是难受。

事实上，如果真的把「尊重」这个基本原则考虑在内，鼓励与赞扬是比批评更有用的工具。

我现在的 manager 是个白人，他就很喜欢夸人，我私下喊他做「夸夸群群主」。

我和组员刚来的时候，可能他担心我们不适宜，或者是不干活，我们做了一些工作之后，总是在换着法子在夸我们：

Thanks you for help to our team, your work makes a great difference.

You are doing a great job, I am impressed by the way you tackled the problems.

You will be successful in Amazon, I am pretty confident about that.

虽然知道老板目的还是想让我们干活，但是被人夸的感觉肯定比被人用鞭子抽打的感觉要好。

见贤思其焉，所以我也学老板多夸人。

有一次和舍友去一家韩餐餐馆吃饭，炸鸡很好吃，其他菜也不错。

上完菜后，韩国小姐姐过来问我们还有需要，我就说，「all foods are delicious, especially the fried chinken」。

小姐姐开心得拍起了小手。

身为中国人，可能从小被教育要内敛和矜持，但我们大可不必太高冷，不要吝啬自己的溢美之词。

3.3 换位思考

高效沟通的另外一个要点就是换位思考，从别人的角度，而不是自己的角度来思考问题。

在沟通对话中，什么对于他们来说是重要的？他们想要的是什么？

最好的方案是一个共赢的方案，可以把多方的诉求都包括在内。

一个非常有效的技巧就是，在开始你自己的观点，先重复一次别人的观点，这样就给对方一个明确的信号，我是真的考虑过你的观点的。

举个例子，前段时间发了一个 Amazon Canada 招聘的文章，有朋友闻讯而来，给我发简历，让我内推到系统中。

只是他没有预料到的是，发送完简历后，马上就收到一封笔试邮件，要求在一周内完成笔试。

朋友觉得时间太紧，没有准备好，于是邮件告知我准备放弃。

我思索片刻之后，决定与recruiter 沟通下，询问能否推迟笔试截止时间。

因为对于朋友而言，他的诉求肯定是有充足的时间来准备；

而对于recruiter 而言，她们办这个event ，也是希望有尽量多的候选人参加，有尽量多的候选人通过。

所以推迟笔试时间，以便朋友参与笔试，是一个符合多方诉求的方案，最后recruiter 的回复也是可以推迟时间：

3.4 充分的上下文

高效沟通和决策的前提是，提供足够的，充分的信息。

也就是说，在你提问题或者沟通的时候，把问题的上下文信息给提供清楚。

以前经常会遇到的一种情形是，在企业微信被人拉到一个群里，然后被@, 「xx哥，帮忙看下这个问题」。

我也很想帮忙，但是我连问题是什么都不清楚，我是没有办法解决的。

一个群几十上百条信息，我是没有精力去逐条翻聊天纪录的。

然后，很快就会有人打电话过来，让我解决这个xx问题。

如果想要我快速解决问题的话，麻烦首先要给出定义，问题是什么？然后再给出问题的上下文，这样我才能方便排查问题。

但这还不是最佳的咨询姿势，我推崇的咨询方式是所谓的 STAR 方法或者叫「Search before Asking」。

4 STAR 方法：高效提问

所谓的STAR method, 是四个单词的首字母缩写，分别是: Situation(场景), Task(任务), Action(行动)，Result(结果)。即：

• situation: 描述问题的背景，这个问题是什么，以及你为什么需要做这个事情
  
• task: 你具体的任务是什么，你需要做什么
  
• action: 你做了什么事情？你的行动是什么.
  
• result: 结果如何，你得出的结论是什么?
  

前面提到过，尊重是与人交流的基本原则, 尊重自然包括尊重别人的时间，不做伸手党。

在咨询别人问题的时候，不仅要把问题说清楚，还需要把自己的调查和排查结果告诉别人，即所谓的「search before asking」，这样给人的印象是我尝试自己来解决，但解决无果才来请教你。

既表现出对别人能力的尊重，也显示出自己是经过调查才发问的，避免询问一些低级，Google 就能找到答案的问题。

没有人喜欢伸手党，你直接拿个问题，不经自己思考去询问别人，这就不是交流沟通，是「空手套方案」了。

别人没有这样的义务来给你提供解决方案。

所以我向别人求助，无论是企业微信，邮件，还是当面求教，流程一般是：

1. 我现在尝试解决xx问题，我要去解决这个问题的原因是yyy
   
2. 我尝试了解法1, 解法2，都无法解决，这是我的日志
   
3. 尝试这几种解法都不能解决问题，不能你能否根据你的经验，给我提供点思路呢？或者是我漏了什么关键步骤么?
   

或者是.

1. 我现在尝试解决xx问题，我要去解决这个问题的原因是yyy
   
2. 我尝试了方案a xxxx, 得出的结果是xx, 然后我再尝试了方案b xxx, 得出的结果是xxx.
   
3. 我个人感觉这两种方案各有优劣，分别是xxx, 我倾向方案a, 原因是xxx.
   
4. 想请教下，你的看法是觉得哪个方案更优，或者你有什么建议么？
   

提供足够的信息和选项给别人做选择题，让不是提供个空白问卷让别人做主观题。

毕竟大多数人都喜欢做选择题，省时省力。

—
<2023-05-29 Mon>

关于如何提问，《How to ask questions the smart way》一文已经把要点给掰碎讲清楚了，推荐阅读。

5 云雨伞: 有效提建议

来源于日本知名咨询师大石哲之的著作《靠谱：顶尖咨询师教你的工作基本功》，简单有效，原理概括起来就一句话：

天上出现乌云，眼看要下雨，带上伞比较好。

其中的「云」代表通过观察得到的客观事实；「快要下雨」，是从客观事实得出的分析；「带上伞」这个是根据分析给出的建议。

这就所谓的「云雨伞」模型的来源，运用「云雨伞」模型提建议，有理有据有方案，能让对方更愿意接受。

青史留名，给老板提建议（画饼）的名篇《隆中对》，也运用了「云雨伞」模型：

亮答曰：“自董卓以来，豪杰并起，跨州连郡者不可胜数。

…

荆州北据汉、沔，利尽南海，东连吴会，西通巴、蜀，（描述「云」，表达事实）

此用武之国，而其主不能守，此殆天所以资将军，（推测「雨」，即分析利弊）

将军岂有意乎？（带上「伞」，即提出建议）

益州险塞，沃野千里，天府之土，高祖因之以成帝业。（描述「云」，表达事实）

刘璋暗弱，张鲁在北，民殷国富而不知存恤，智能之士思得明君。

将军既帝室之胄，信义著于四海，总揽英雄，思贤如渴，若跨有荆、益，保其岩阻，西和诸戎，南抚夷越，外结好孙权，内修政理；
（推测「雨」，即分析利弊）

天下有变，则命一上将将荆州之军以向宛、洛，将军身率益州之众出于秦川，百姓孰敢不箪食壶浆以迎将军者乎？
诚如是，则霸业可成，汉室可兴矣。（带上「伞」，即提出建议）

这一番结合「云雨伞」的建议（画饼），让老板直呼，「孤之有孔明，犹鱼之有水也」

6 总结

所谓的「Skill = knowledge + practice」，知道一项知识，如果不运用，没有办法修炼成技能的。

毕竟「纸上得来终觉浅，绝知此事要躬行」。

要多实践才能提高沟通能力。

推荐几本读过的，关于沟通，心理学与咨询的好书，推荐度由高至低：

1. 《非暴力沟通》, 豆瓣评分：8.7(当然，评分只是一个参考项)
   
2. 《社会性动物》，豆瓣评分：9.0
   
3. 《靠谱》：豆瓣评分：7.6
   
4. 《QBQ!問題背後的問題》，豆瓣评分：7.4
   

软技能系列的下一篇是：

• 软件工程师的软技能指北（四）：简历篇
  

1. 软件工程师的软技能指北（一）：总览篇
   
2. 软件工程师的软技能指北（二）：事业篇
   
3. 软件工程师的软技能指北（三）：高效交流篇
   
4. 软件工程师的软技能指北（四）：简历篇
   
5. 软件工程师的软技能指北（五）：面试篇(暂时跳过, 后面再填)
   
6. 软件工程师的软技能指北（六）：谈薪篇
   

2 前言

打工是不可能打工的，这辈子都不可能打工的。

3 心态转变

很多软件工程师容易把自己定义成「写代码的」，或者是「码农」，就是以写软件为生的人。

也只愿意接受写代码相关的任务，什么文档，设计，需求分析，是一概不想理的，我就是一把唆。

也有工程师觉得，反正我把事情做好也只有这么点工资，摆烂收入也不一定会下降，那不如就躺平，反正我的收入是固定。

也不能说毫无道理，只是把自己定位成「需求翻译机」，着实和「流水线的工人」区别不大。

随着自动化技术的进步，「流水线工人」很容易就被机器人所取代，它们只要能源充足，就可以24小时不停地产出

但是踏实干活的工程师，也难免容易有与以上类似的疑惑。

那不如换个思路：

把你的工作当成是你自己的生意（business），那你眼中的一切都会变得截然不同。

3.1 客户

既然是生意，自然要找对目标客户。

如果把工作当成生意，那么你的客户就是你的雇主，虽然你的客户大多数情况下只有一个。

但是很多的公司，都是靠给某一个大客户供货而做大做强的。

3.1.1 客户（customer）与用户（user）

谈起business, 我就想聊一下个人对于客户与用户的浅薄见解。

归纳起来，就是两点：

商业公司总是客户第一

用户不等于客户

简而言之，用户是使用某项服务或者产品的人，而客户是为某项服务或者产品付费的人。

举个例子，经常有人说，微信不注重用户体验，微信不倾听用户的声音，微信有着地球上第二傲慢的产品经理团队（第一可能是苹果）。

就我在微信的开发经历而言，的确如此。

没有见过哪个产品经理提的需求是改善用户体验的，
腾讯内网上都是挂着各种反馈微信用户体验的帖子，最后都是以「这个问题，楼主可以私聊我们讨论」结束的。

因为，对于微信而言，微信用户只是使用微信这个软件的人，而不是为微信付费的人，不是微信收入的来源。

对于微信支付而言，客户是各种接入微信支付的商户，因为每笔交易，他们要交约等于交易金额 0.0021%或者更多的手续费，属于躺着赚钱的模式；

对于微信朋友圈，公众号而言，客户是各种广告主；

在微信用户面前，微信就是个爹，教育你们怎么使用微信；但是在微信客户面前，比如美团，快手这些微信支付的大客户，微信就是孙子。

要做什么需求，产品经理根本没有办法推；要什么时候上线，就什么时候上线，即使不合理，也只能回来压榨工程师的时间。

毕竟客户说了，你们不做我们就切到支付宝去。

所以微信用户本质上只是微信收入来源的耗材和燃料，反正用户离不开微信这口灶，产品经理为什么还要听燃料的心声呢。

当然，背后的商业逻辑是这样，用户体验又是另外一回事了。

3.2 产品

既然是生意，那么自然要有可以营利的产品或服务，对于大部分工程师而言，他们能提供的产品，就是生产软件的服务。

那和「写代码的」也没有什么差别嘛？

稍安勿躁，这只是第一步嘛。

如果我们提供的生产软件的服务是生意的话，那么要想营利，产生更大的利润，就需要我们考虑一个问题：

如何大家都是生产软件的生意，你的产品又如何从同质化严重的同行中脱颖而出。

3.3 竞争优势

搞低价倾销（加班巻死他们）？

这也是个可行但不能持久的法子：

1. 毕竟你搞低价倾销，即使把生意都抢到，你产能有限，客户的单不一定都能接过来；
   
2. 另外低价倾销，只会把市场搞坏，降低了利润空间，只会让客户单方面受益
   
3. 强中自有强中手，一山还有一山高，万一遇到比你还能搞低价倾销的同行，那不是哑巴吃黄莲，有苦说不出嘛。
   

所以最优解应该是你提供更优质的服务，将优质服务作为自己的竞争优势。

既然要提供优势的服务，就需要

1. 学会与客户沟通交流，先明确客户的需求，
   
2. 然后分析需求，明确这服务是否客户想要的，
   
3. 再动工建设，保证最终成品贴近客户的诉求。
   

或者是成为某个领域的专家，提供差异化的服务。

所谓人无我有，人有我优。

看到这里，有朋友可能会质疑：即使我做了这么多，做得这么好，但是工资（产品的售价）还是不涨阿，那还有什么意思？

如果把这个当作自己的生意，提供优质服务之后，自然是需要和客户重新谈合同的嘛（加薪）。

如果谈不拢，那就换家客户就好了，反正我只要产品够好，自然不缺客户，我还可以拿现有的供货合同和未来的客户谈。

生意是自己，服务做优质之后，最终受益的还是自己（当然，需要些时间和策略）

3.4 大厂光环

所谓的大厂光环，和偶像光环类似，就觉得个人会因为进去某个公司，把平台优势当作自己的成就，从而骄傲了起来。

坦白讲，以前我也有大厂光环，在自己去了某家大厂之后。

走路的时候，头抬得更高了，背挺得更直了，以便于胸前的工牌更加醒目。

如果把自己的职业生涯比作一门生意后，我想我应该不会再为与某个客户合作而沾沾自喜，毕竟客户的商业成就，与我关系不大。

客户可以有很多个，没有必要为别人的成就而自得不已。

最近新读到一首诗，唐代孟郊的《劝学》：

击石乃有火，不击元无烟。

人学始知道，不学非自然。

万事须己运，他得非我贤。

青春须早为，岂能长少年。

万事须己运，他得非我贤。

4 十项全能

既然是要做生意，那么只会写代码，注定是不可行。

毕竟没有见过哪家成功的商业公司，只在车间生产产品即可，不需要一系列配套的商业运作流程：

1. 营销与广告，打造个人品牌，写博客或者做Up主
   
2. 持续学习，没有什么生意是一成不变，就能从爷爷辈做到孙子辈的
   
3. 如何提升个人效率，以更少的投入获取更多的产出
   
4. 如何理财，管理你生意的营收与支出
   
5. 如何健身，管理你自己的身材
   
6. 旋转720度，落地无水花
   

诸如此类，这些技能要求也就变成理所当然。

5 总结

把工作当作生意的思路转变，只是第一步。

套用《霸王别姬》的一句台词：

今儿个是破题儿

文章还在后头呢

客户或公司是一个抽象的概念，实际也是由形形色色的人组成。

与客户合作，实际是与各种人打交道，如何高效沟通和交流就是一个非常有用的技能。

但对于曾经社恐的我来说，跨出第一步却是非常艰难。

所以软技能系统的下一篇是：

软件工程师的软技能指北（三）：高效交流篇

对于后续的篇章，呼应上文，我有了大概腹稿，分别是：

• 软件工程师的软技能指北（四）：简历篇
  
• 软件工程师的软技能指北（五）：面试篇
  
• 软件工程师的软技能指北（六）：谈薪篇
  

为了方便阅读，把本系列的文章的目录整理如下：

1. 软件工程师的软技能指北（一）：总览篇
2. 软件工程师的软技能指北（二）：事业篇
3. 软件工程师的软技能指北（三）：高效交流篇
4. 软件工程师的软技能指北（四）：简历篇
5. 软件工程师的软技能指北（五）：面试篇(暂时跳过, 后面再填)
6. 软件工程师的软技能指北（六）：谈薪篇

2 背景

上大学时，曾经看过一本书《软技能，代码之外的生存指南》，主要介绍程序员要想取得成功的职业生涯，所必需的软技能。

所谓的软技能，是区别与使用C++或Java 编写业务逻辑和单元测试代码，使用Docker 部署等「硬技能」，而是注重职场，心态，身体与理财等各方面提升的「软技能」。

大学时候的我还沉迷于编写各种很cool 的代码，学各种编程语言，觉得此书不过是面向程序员的「鸡汤」一本。

2.1 再读

工作第三年时，换了一份工作，对职业充满了迷茫与困惑，然后再读了一次这本书，得出的结论是书挺不错的， 但是不符合中国程序员的国情。

比如理财方面，建议程序员在低房价时买房，我也想买，但是在深圳只能是望楼兴叹；

健身方面，下班后多运动，自己做饭，控制饮食以增肌减脂，着实没有时间自己做饭。

但里面的思路和哲学很有参考意义。

2.2 三读

最近突然想起了这本书，搜索之后发现，英文原版在2020能出了第二版，而中文版本也在2022年翻译出版了；

因为书再版了，所以又重读了一次这本书，英文书名会更正常一些：Soft Skills: The Software Developer’s Life Manual

得出的结论还是与之前一致：「书中的思路和哲学很有参考意义，做法却不一定适用」。

但区别在于，我这次打算把我自己的做法与行动也总结下来，「用他的旧瓶子，装我的新酒」。

就成功的标准而言，我的职业生涯还远谈不上成功，甚至可以说还有很多失败之处，这也算是我自己反思的心得。

毕竟也不只有别人优秀的经历，我这种潦倒的经历也是可以参考的。

见贤思齐焉，见不贤而内自省也。

这让我想起了Netflix 的高分纪录片《我心永随桑德兰》，别人拍纪录片是记录成功，这部豆瓣9.2分的片子却是在记录失败：

英超保级劲旅桑德兰，在2017年终于花光自己在英超的保级运气，从顶级联赛英超跌入二级联赛英冠。

然后俱乐部高层想拍一部纪录片，记录自己奋发图强，卧薪尝胆杀回英超的经历，以此吸引投资者，最后却是二连跳， 跌入到三级联赛英甲的神剧情。

把我不开心的事说出来，拿出来给大家一起开心下嘛。

3 软技能

就软技能而言，绝不止「软件工程师」这个职业需要这个技能，而是绝大部分职业都需要的。

因为绝大部分的工作都是与人打交道，而软技能就是如果更高效与人沟通的关键技能。

如果有「软件工程师」认为自己只要写代码就可以了（我曾经就是这么认为的）；或者觉得，写代码才是最有趣的部分（我现在也是这么认为的），我不想理这么多事情；

那么你的可替代性就非常高，当代码生成工具足够成熟之后，你就可以被裁掉了。

之前办信用卡时候，我说的职业是Software Engineer，银行客户经理问我， 你们是不是只要埋头对着电脑敲键盘即可，不需要和人说话的？

（我心想，你是美剧看多了吧）

而事实恰恰与直觉相反，软件工程师大部分时间都在与人打交道：

1. 拿到需求时，需要分析需求的可行性，与产品经理扯皮，理清模糊之处
2. 撰写设计文档，和组员及老板介绍方案，比较方案优劣，选择最优解
3. 与上下游团队扯皮，求下游团队帮忙干活，给上游团队表演太极
4. 和老板画饼，只要再给我些时间，定然能做得成绩斐然。

哪项不是与人打交道呢？项项都是我缺乏的技能阿，我就只会接活，干活，然后再接再干。

老黄牛听到我这境况，估计都得叫我一声兄弟；流水线见我这际遇，也会直呼一声「内行」

所以「软技能」真的是不可或缺。

或许是我给银行客户经理的答案不合他意，我信用卡申请被拒了；

或许我「软技能」再强大一些就能通过了.

4 主旨

原书把主旨分成七部分，分别是:

1. 事业(Career): 像经营企业一样，打磨自己的职业生涯
2. 自我营销(Marketing Yourself): 通过高质量文章和视频，打造自己的个人品牌
3. 学习(Learning): 终身学习，自我学习
4. 生产力（Productivity）：提高生产力的方式
5. 理财（Finanacial）：如何复利，创造被动收入
6. 健身（Fitness）：健康，有型的体魄
7. 心态（Mindset）：培养积极的心态，To be a better man(woman).

我就不会按照作者的主旨来阐述我自己的想法，毕竟「他瓶装我酒」，想怎么「装」就是我自己的选择了。

感触多些的主旨，就拆分开多几篇文章，没有太多感慨的部分，可能就选择性省略了。

5 总结

所以要「软硬都抓，内外兼修」，才能成长为一个优秀的软件工程师。

只会写代码的软件工程师，真的是注定吃亏，酒香也怕巷子深。 这是多次吃亏之后得出的经验总结。

其他的职业与岗位也大抵如此。

公号同步更新，欢迎关注👻