大家最近肯定看到了我司 PingCAP 大量放出的招聘信息，2.7 亿美刀 D 轮融资，众多优质客户，5.0 版本提升，等等。
如果对我司没什么了解的可以看看官网咱们的产品 TiDB，和 招聘列表（持续更新中）。
这里想以个人的角度来讲一下咱们的招聘。作为在 PingCAP 3 年半的菜鸟，我不会给你吹 PingCAP 多 NB，让你赶紧来。而是尽量把问题列出来，看有没有兴趣一起来解决（主要是技术和技术管理的突破），趟过这些坑，PingCAP 就成了。
一、先谈钱。
首先我要劝退短期内迫切需要大量现金的同学。
能通过面试进 PingCAP 的，肯定也能进 BAT、TMD 几个大厂。
薪酬结构上，PingCAP 的现金部分勉强能跟上几大厂，但大厂的股票是实实在在的，到了成熟期就是现金。
PingCAP 则是期权，你得等到上市或者被收购才能变现。
大厂的业务面、股价都相对稳定。PingCAP 期权则有较大的想象空间，如果业务发展顺利，从你进来后价值翻番翻番是没什么问题的，等到可兑现的时候，总收益就比大厂高。
在 2.7 亿刀之前，公司基本盘是靠一大批理想主义的天才少年撑住的。（和天才少女，是的咱们有漂亮妹子程序员）
拿到 2.7 亿刀前后，高级别的人才招聘占比增大了很多，海外也不少 FLAG 和传统数据库大厂的资深简历。做为一个基层我的感觉是虽然咱还是穷创业公司，但粮草是足的，支持得住这场硬仗。而且，如果你有 PingCAP 稀缺的技能（下面我展开讲），那么议价权更在你手上。
所以 PingCAP 属于优质价值投资，小几年内不急着大钱用，又看好 PingCAP、TiDB 的发展，那么可以投。
二、个人发展。
对于年轻的同学来讲，PingCAP 知名度和美誉度还不错，对履历来讲是有益的，不输大厂吧个人觉得。
然后从技术上来讲，代码是开源的水平大家都清楚，公司内强者无数，可以一起学习提升。
对于老鸟来说，PingCAP 当前在业务突破阶段（下面展开），处于临门一脚的时间点。早于这个时间的公司业务还没摸索清楚，风险太大；晚于这个点的公司主业务已经成熟，发挥空间小很多。
TiDB 是 ”分布式 + 数据库”，任何其一领域都是计算机科学王冠上的明珠。公司的目标市场的深度也可以让你安安心心做 20 年纯技术。
三、业务状况。
当前 PingCAP 的发力点有几个，一个个来。
A、社区用户：数量众多，包括美团、知乎、小米等不少大中厂，TiDB 是诸多技术团队的优先解决方案。但也要看到，用户对产品成熟度、性能期望比 TiDB 现状要高。（出于成本考虑大多都运行在较高压力下，也就对 TiDB 的要求更高）
各位客户爸爸的上线意愿挺强的，只要 TiDB 成熟度、性能做好（下面展开），那么 TiDB 大量接入核心业务，成为开源、互联网企业的事实标准是可以期待的，这条赛道上竞品不多。
B、国内金融客户：当前客户有浦发银行，光大银行、中国银联、北京银行等，金融客户是咱们商业健康发展的主要动力之一。国内还有大量金融客户在国产化转型，目前咱们和竞品处于有来有回的胶着战斗中，没有哪家明显领先。
当前挑战是性能，需要在延迟、稳定性等性能指标上拉开显著优势。咱们进场竞标的机会很多，如果性能能再上一个台阶，这波是可以吃好的。
C、上云：部署有两种方式，非托管的和托管（TiDB Cloud 服务，部署在 AWS / GCP）。
非托管不少海外大中厂如 PayPay（日本一家移动支付平台）、Square、Shopee，海外用户付费意愿较高，只要 TiDB 产品做好（还是成熟度、性能），顺利收钱是水到渠成的。
托管服务当前也已经上线，但比起竞品（Aurora 等）来说成本还没有拉开差距，所以业务量还小。
上云成本是咱们中长期的发力焦点，涉及包括存储层等很多方面的大幅度调整优化。个人相信成本下来之后，托管服务是明日之花。
总的看，PingCAP 已经在市场扎下了根，但上升空间还很大。在这几年的开拓下，客户已经准备好了，对 TiDB 是非常欢迎、开放的。咱们唯一需要做的，就是把产品打磨好，性能做上去。
只欠临门一脚，就等产品提升。
再唠叨一句，国内互联网、IT 业绝大部分以业务运营为主导，基础开发部门说到底还是为业务服务的。
而像 PingCAP 这样以技术推动业务的公司，几乎可以说绝无仅有。对于专注技术的同学可以把这点考虑进去。（招聘岗位覆盖技术和非技术，不要误会）
四、TiDB 产品现状。
TiDB 从 1.0 到马上要发布的 5.0，基本上每年稳步迭代一个大版本且进步飞速，有目共睹，众多客户爸爸也都用行动和钱包给咱们点了赞，不啰嗦，这里主要讲讲存在的问题。
归纳起来有三个方面：1、要的功能没有；2，功能不好用不稳定出漏子；3，性能不够优秀，包括线性扩展性、吞吐、延迟、性能稳定性、硬件成本等。
不爽的客户爸爸可以来论坛一起 吐槽，在内部重视程度很高，如果长时间没解决那就是太难搞、或者暂时没资源搞，毕竟咱们当前只是个不到 400 人的创业公司，看看这波招贤能不能把战斗力提上来。
第一个不算问题，没有就等吧，等不到那就...
第二个主要来源于过去对产品定位不够清晰，想要的太多，单个功能点投入资源、时间远远不够，以及工程管理有欠缺。
在这个问题上，有成熟项目管理经验的大佬如果愿意过来，会有很大的发展空间，得能上能下：能深入到一线挖掘问题（拿以往方案直接套估计是不行的）、分析原因，又能在更高层次对问题进行抽象归纳，然后给出靠谱的落地方案。
2020 下半年咱们就来了这样一位老师，指出了咱们不少问题，对功能进行了大规模精简，但之前铺太开了，要收回来逐个做精做细还需要时间。
但这样的大佬一位是远远不够的，要解决的问题很多，需要很多接地气的技术管理人才，也许就是你。
第三点性能问题，部分原因是和第二点相关（事情铺太开每项投入不够），部分原因是队伍的工程优化能力相对于产品要求来说还不足（大佬很多，但性能要求高，挑战也是巨大的，涉及性能的点很多，工作量也很大）。
瓶颈主要是存储层（计算层扩展容易，相对压力小一点），这是当前我负责的部分，下面会展开。
五、组织管理。
麻雀虽小，PingCAP 不仅只有技术团队，技术外的我不熟所以只聊技术团队。
PingCAP 做事要看结果，这个在哪里都一样，大家应该有共识，不啰嗦。
咱们这对出成果的期望时间点比较注重，如果需要较长时间才能出来的事情，那需要做好总规划，分解出执行计划，周期性（一般按周）披露进展避免走偏。
这里我本来想聊挺多事情，包括执行力的双刃剑、信息传递链长度等等，也算吐槽吧。但喝完两杯咖啡，仔细思考之后，我想所有的小吐槽在这个鲜明的特征下显得瑕不掩瑜：听取末端声音，持续变革。
也就是说在 PingCAP，不管你在什么位置，只要不是纯情绪发泄，把问题提出来，不管是技术方面还是管理方面还是其他，绝大部分时候问题都能得到研究，如果多数人（leader 层，也就是基层管理者）觉得必要的话，就会改进。
而只要有需要，这改进动作可以非常大（可以达到 CEO、创始人这级）、非常快。
还有个值得拿出来聊的，是工作边界不明晰，也是双刃剑。坏处是在强调执行、成果的环境下，你可能陷入涉及超出你能力范围的大坑出不来，而你和你上级都没察觉到。好处是可以百无禁忌地跨过组、职位的限制来做任何事情、出成果，并得到赞赏。
小结一下就是，不管是新秀还是老兵，如果你期望一个理想的环境，来了就有成熟体系带着飞，把份内事做精做透就行，那大厂更适合你。
PingCAP 是个不成熟，但有快速进化动力的地方，你需要和公司一起成长，把碰到的障碍挑出来（做起来其实挺难的，很多人就把问题憋着），一起寻找改进方案，推动变革。
六、加班问题。
首先没有 996。数据库这种项目不是靠蛮力能做好的，吃好喝好充分休息，才能高质量作战。
咱们提倡课余多读读 paper，关注下前沿，抬头看路，如果是焦点问题那就划入课内研究。
咱们有北上广深杭成、湾区等多地办公室，大家都习惯 remote、分布式的工作方式，卡考勤时间意义不大（当然开会要准时）。最重要的还是结果导向，从承诺到结果有清晰的自我追踪和密切沟通。
但咱们上线项目多，人力少，oncall 等需要紧急处理的事情工作量确实也很大，（在过去）给研发端的冲击不能忽视，也让小部分同学感觉疲惫。
在 2020 下半年咱们进行了改进，通过一个轮值小组来挡住这个冲击，有一定成效，应该还有提升空间。
小结一下：没 996，出活最重要。紧急事情还是会加班，改进中。
七、TiDB 存储层（TiKV）
这里专门讲讲我在的组，给咱拉点人。这里存储层包括 Raft、Raftstore、MVCC 模型、存储引擎，不包括上云特化的特性（有特攻小队专门负责）。
上面说过性能问题是咱们业务能上一台阶的关键点之一，而存储层是最大的瓶颈。
在上面列的吞吐、成本、稳定性等等一系列性能问题当中，延迟又是最突出的一项。
所以存储层在中近期（一两年）的目标就是性能，2021 年的核心是降延迟。至于给计算层、用户层的特性、接口，基本不会变动。
对于延迟问题，去年已经投入了比较大的精力，几个大的来源基本定位清楚了，一个是长尾放大（主要是”上层 一”对”下层多”引起，比如写操作过程涉及一个 TiDB 请求多个 TiKV，单 TiKV 内也有类似放大现象），一个是 消息派发模块 Batch-System 的调度问题，还有是 Raftstore 的 IO 模型比较低效。
Raftstore IO 的改进已经在做，但其它的还没人力开搞，所以这里很缺人，有兴趣尽快来一起。
在性能问题解决之后，咱们也有些脑洞想在存储层进行。（要比较久以后了，下面内容就先做做梦）
比如重构 Region 与Raft Group 一对一的模型，大幅降低 Raft Group 数量。
比如改进 MVCC 存储模型，3 个 CF 是不是过于低效？历史数据是不是可以分离存放？
比如上云的特化存储，利用低成本但延迟较高的存储（S3 等）降低成本。
比如把现在一大堆性能配置参数改成自适应（举例，IO 效率和 IO 请求体积作为 XY 是一个凸曲线，简单采样就可以定位到最佳体积），从而避免人工调参，以及当环境变化（负载、硬件）时可以快速自我调整。
比如自研存储引擎代替 RocksDB（对标 CockroachDB 的 Pebble），其实天才少年迟先生已经完成了一个初版 AgateDB，性能还不错。
我自己在新引擎上也有些想法，想通过匹配用户模式、惰性 compact 来降低资源消耗（这个文档 是一些我对引擎的理解，用于对齐思路再引出新设计的，里面公式没有仔细校验过肯定有错，发现了麻烦私下邮件我，脸皮薄公开处刑不好看 :P）
八、投简历来吧！
如果你想先摸摸情况，那发邮件，我加你微信聊（还在努力撸延迟问题，所以不一定顾得过来），觉得不需要尬聊的就直接邮件简历到 [email protected]，合适的我作为内推蹭点奶粉钱。（投存储层的我蹭不到 :D）
存储层我会参与面试，之前有同学说我这面试难过，这里澄清一下，我是真的菜，作为面官可能比你更虚更紧张。一般不会因为知识点没到位而刷人，重点看基础能力素质，看“在什么情况下，如何解决问题”，基本问法是“行为面试法”，不用特别准备。
期待你的投送，来共举大事！（邮件，切勿 APP 或网站内私信）
欢迎转发扩散。
PingCAP 刘聪
2021-02-07
如何找自己的职位：用以下职位名在 https://job.pingcap.com/alljob 中查找：
分布式存储系统研发工程师
分布式调度研发工程师
数据库内核开发（优化器）
数据库内核开发（Real-Time Analytics）
Cloud 研发工程师
Cloud 研发工程师（Operator）
资深数据库研发工程师 (General)
资深数据库研发工程师 (Optimizer)
资深数据库研发工程师 (Runtime)
Tools 研发工程师
资深分析引擎研发工程师
Web 研发工程师
后端研发工程师
Site Reliability Engineer
工程效率研发工程师
数据库测试工程师
数据库安全工程师
数据库产品经理
Application Team Leader
Chaos Engineer PM
IT 工程师
运维开发工程师
前端开发工程师
前端开发工程师（社区官网方向）
资深/高级/中级 TiDB DBA
资深互联网架构师
社区 BD 经理
开发者社区运营
资深社区运营
Community Marketing Specialist
行业高级架构师 (零售/物流/制造/电商方向)
行业高级架构师 (金融方向)
高级数据库架构师
高级应用架构师 (Java 方向)
资深/高级/中级 TiDB 交付 DBA
资深渠道合作总监
资深行业销售总监
资深售前技术总监
品牌经理
高级营销策划与运营
高级产品市场经理
Field Marketing Specialist
法务经理
高级项目经理
高级销售运营经理
渠道销售经理
PTC PM
Inside Sales
资深商务经理