招聘 【上海】薄荷科技诚聘 Ruby 工程师 2 名
职位概况：
公司：薄荷健康科技
坐标：上海浦东世纪大道地铁站附近
职位：中级 Ruby 工程师 2 名
职责：落地实施增长实验和模型，负责基础设施项目的开发
薪酬：15-20k
关于薄荷
薄荷 是一家在健康领域领先的互联网公司，主要应用包括“薄荷健康”和“食物库”。“薄荷健康”是中国减肥第一应用，长期位于 App Store 健康健美榜和各大 Android 应用市场健康或生活类应用前列，总用户已达数千万级别。“食物库”是中国食物营养第一应用，拥有中国最全的食物营养数据以及专业饮食营养指导工具和服务。
薄荷是国内较早使用 Ruby 的公司，从 2007 年开始所有的后端核心系统全部基于 Ruby 构建。随着系统规模不断增长，使用 Ruby 过程中遇到很多问题和挑战，但是我们没有放弃，迎难而上，经受住了考验。我们一直对 Ruby 充满了爱和信心，但我们也认为每一种语言和框架都有它的优势和劣势、擅长的应用场景，所以我们很早实施了微服务和容器化，积极、开放地引入其它语言，如 Go、Java 和 Python，目前薄荷后端技术栈的主要语言是 Ruby 和 Go。
关于团队
你将加入的是薄荷技术增长团队，我们负责用技术赋能增长，在薄荷 App 及外部渠道上，快速验证各种新奇的 idea，构建高质量的增长模型和产品，服务于用户增长和销售创高，团队由 CTO @vincent 直接带领，每周头脑风暴制定下周增长实验，复盘本周战果。
在这里，你可以得到：
- 宽阔的成长空间
薄荷的用户量级早已达到千万级，并且在很早就实现了全面的微服务化，因此一开始就要应对性能和并发的挑战，同时需要良好的代码质量以应对未来扩展要求，从薄荷毕业的每一位 Ruby 工程师都有独当一面的能力。
- 良好的技术氛围
我们有不错的技术氛围，崇尚极客精神，热情的参与 Ruby 社区各种活动，每周三会有内部技术分享，每年 RubyConf 也会踊跃报名参会，。
- 不错的薪酬回报
中级职位 15~20k，高级职位 20~35k。目前公司处于快速发展阶段，商业模式明确，营收稳健，并且已有顶尖风投基金加入（晨兴，SIG，DCM 和高通），未来发展前景可期。我们将视你为伙伴，希望通过一起努力，能够提供超出你预期的回报。
关于职位
薄荷从去年春季开始迎来了显著的增长，本次疫情期间，也始终保持着正向现金流，储备充分，在可预见的未来，薄荷会继续坚持着“高价值成长”，一些要求如下：
希望你有 1-3 年的 Ruby 实际开发经验
熟练掌握 Ruby 和 Rails，了解或掌握 golang，以及 Web 开发相关技术
扎实的后端基础，熟悉如 Redis，Rabbitmq，MySQL 等常用的中间件和数据库
热爱技术开发，擅长解决问题，有极客精神
加分项
- 较为广泛的技术了解，不局限于 Ruby 和后端的技术眼界
联系方式
投递简历到 zhangzhongnan(at)boohee.com，也可以直接添加微信聊 
，微信号：sidekiq
工作环境
作为一个日活百万的 App 开发团队，保障系统的正常运行是我们的职责，技术团队不承担 KPI，只约定 OKR，我分享一下我们关于 App 的 Key Result。
薄荷健康 App 产品和技术系统高质量开发和运行：
1）App 崩溃率万分之一以内
2）服务端系统高可用性达到 99.99%
3）快速响应，技术问题最迟 15 分钟（非工作日 30 分钟）内有人响应
就在最近，我们实现了 33 个微服务全面容器化，将 go 作为一级开发语言，在关键性能瓶颈点，新的技术系统上，我们都使用 go 进行改造和开发。在服务治理，架构设计，内部通信上都踏过了不少的坑，也积累了一些实践经验，如果大家在推进 go 的过程中遇到什么问题，欢迎一起交流。
sidekiq
回复
你这个还是 KPI，只是换了一个说法。
- OKR 是要暴露一个目标 Objective:
App 产品和技术系统高质量开发和运行 - 通过多个 KeyAction 拆解关键步骤和环节，以达到上面的 Objective，核心是要体现出思路、解决方案、关键途径等。
- keyAction 需要有多个有梯度的 KeyResult，KeyResult 是衡量 keyAction 的执行质量和目标水位，需要给出明确、有梯度、可循序渐进达到的标准，有些目标不是一下就能达到，要分步。
App 崩溃率万分之一以内
这个是一个 KeyResult，还应该有对应的梯度，比如 99% 是勉强及格，99.99 是及格，99.999 是超越预期等等。
可是 KeyAction 呢？如何达到这个目标呢？通过什么途径？用什么方法？ （建议补充出来，不要藏知识）
OKR 的精髓是一个思考框架，帮助组织将大的 Objective 拆成小 Objective，并往下层分发。Objective -> KeyAction -> KeyResult 这些点的落地、拉通、对齐、筛选就是在设定一整套体系、解决方案、解决途径、解决步骤。
通过提出一个目标，走一遍 OKR 流程，可以引导出解决方案，这是一个方法论，超越 KPI 的地方。
关于假期 30 分钟内必须回 dingding 消息的事情，晚上有点兴奋，我多几句嘴。
如果我是管理层，我会制定一个轮班机制：
- 每天有一个人轮班，有问题在 dingding@他，只有值班那天 Ta 才会注意群消息
- Ta 来判断事情是怎么回事，对客服等作出响应。如果是可以延后慢慢处理的，直接归档就行，如果紧急的，直接给对应模块负责人打电话
- 每个人不用每天下班都对手机消息一惊一乍的
- 很多时候所谓的”故障“是临时或无关紧要的，或者值班的人就可以简单解决
用大腿想一下，每个人都要在下班时盯着群消息，一惊一乍的。这个综合成本有多高，有多少无效劳动和心智消耗，需要加多少工资才能弥补上。
early
回复
目的就是要把你多余的注意力耗空，让你没有精力来学习提高，跳槽到其他单位。你节省下来的注意力，多半不会用在工作上面。且技术部门就是个工具，一个萝卜一个坑，只要有人干活就行，不需要太有创造力。
现实中往往不存在理想化的模型，高压式的管理可以降低对管理人员素质的要求。
严格的考勤和回复制度下，留下来的只会是一些服从性较好的员工，没有刺头，这样队伍比较好带。管理者不需要针对不同个性的员工来进行不同风格的沟通，也不需要为了粘合团队而做出努力。
其次，管理者往往承担了很大的压力（虽然报酬也更丰厚）。如果自身压力很大，看见手底下很舒服，人的天性会产生一种嫉妒心理。压榨下面的员工，可以让管理者找回一点掌控感。
好的管理者难找啊。技术要过关，又能够和各种各样的员工有效沟通。双商在线，能够在自身承受巨大压力的情况下依然鼓励他人，提升团队士气。要是真有这样的人，管个技术部分其实是屈才了。事实上很大一部分技术好的管理者，脾气暴躁，没有耐心，需要配上一套高压管理模式来帮助他们。
adamshen
回复
吼吼吼吼～真香啊～
我现在每天早上到公司先自己看一个小时的书，不干活，下班就开免打扰模式，而且跟项目经理坦白了。。。 有次部门经理路过问我看的啥，我回答了一个字：“书。”貌似我就是那种牵着不走打着倒退的员工，哎呀好丢脸。
不过，说真的，感觉如果在一个条条框框特别多的团队里，还是得以自己为主，要不得被公司拖死。
early
回复
非常同意你的观点，我们也在不断优化响应策略，后端是已经采用轮班制度了，也在推进和钉钉结合的工单系统的开发。
钉钉答疑群建立的初衷，是为了建立用户与研发沟通的桥梁，及早发现系统的隐藏问题和 BUG，能进入答疑群的问题，都是经过客服和产品经理两层，达到一定级别的。说起来，我们很多同事解决问题的能力，对项目的深入理解，就是从解决答疑群问题中磨练出来的，薄荷很早就实现了全面微服务化，平均一个工程师要承担 3 - 5 个系统的维护，除了必要的文档外，通过排查问题进行实操，也能快速的掌握一个项目。
去年下旬，通过排查一个用户数据不一致的问题，我们还发现了一个在项目中隐藏了长达一年半的深层 BUG，解决具体问题逐渐不再是我们的目的，通过这一步骤培养大家解决问题的能力，才是我们的期望。
好在我们的团队规模还比较小，遇到问题也都没有回避，能迅速的推进解决，也非常欢迎社区的意见和建议，帮助我们不断成长。
yfractal
回复
关于可用性的计算，我们是按照单个微服务不可用时间作为衡量的，当然也出现过系统整体不可用的情况，这时会按照整体不可用时间计算，99.99% 的 SLA 要求每年系统不可用时间不超过 52 分钟，分摊下来一个月不超过 4 分多钟，去年一季度因为凌晨整体停机上云，没能实现这个目标，其他时侯都是能顺利达成目标的。
薄荷系统没有想象的那么健壮，也存在一些不合理的设计和一些关键服务的强依赖，比如 Passport 账户系统，每日峰值调用能达到 5k qps，出现问题的话很容易造成后端抖动，从去年中旬开始，我们用 go 改造一些关键服务，顺利的降低了整体负载。
选择 go，是比较看好 go 的未来，和开放包融的社区，刚开始也是不太习惯的，随着在实践中的摸索，和对社区大量优质的内容学习借鉴，我们也形成了一套自己的开发方法论，使用 mono 仓库的方式组织代码，commit 即版本，也大胆的将 gem 实现直接放在 go 项目中，配合 nexus 私仓，做到只用维护一份 proto，go 与 ruby 使用 grpc 和 sneakers-packer 进行通信。
当然，我们并不是完全抛弃 ruby，ruby 还是有很大的优势的，这里分享去年 Vincent 写的一篇文章Ruby 在走下坡路吗？Ruby 程序员该何去何从，本着对大家负责的态度，希望每个从薄荷毕业的伙伴有更多的选择面，而不局限于 ruby 圈子。
sidekiq
回复
感谢
我大体明白你们怎么定义 SLA 了。是不是任何一个服务 crash 了，就是不可用？个别 API 500，不认为不可用？
每日峰值调用能达到 5k qps....我们用 go 改造一些关键服务，顺利的降低了整体负载。
那就是，使用 go 之后，可以更省内存和 cpu 吗？
那篇文章，简单扫了下，总结下来就是 ruby 不火了。技术热点转移了，再就是本身的问题。
本身问题有 3 点：
- 并发
- 不合适大规模工程开
- 不好招人
并发这个，目前主流还是机器换人力。
不合适大规模工程开发
你的回复，好像没有提工程的问题。比较好奇你们实践后得出的结论是什么？
“不合适大规模工程开发”这个本身是很模糊的概念。比如 java 被认为更容易大规模开发。但 java 的应用真的就 bug 少了吗？真的就更快了吗？似乎也不见得。
不好招人
中级的不好说，高级的感觉都不好招。还有一个问题，一个 ruby 开发可以解决的，用 go 可能要用 3 个。在这个假设下，那就是招 3 个 go 比招一个 ruby 容易。才能说 go 比 ruby 好招人。
可能整体来说，是更看好 go 的未来，所以想在 go 上多投入一些？
可能我是个假 Ruby
darren
回复
哎呀，教科书级的生产事故啊，招聘贴忘记留邮箱了，简历发给我就好了，zhangzhongnan(at)boohee.com，微信号和社区同名，sidekiq
只能说薄荷的团队氛围适合快速成长，不太适合养老，没有必要放大其管理上的不足。我于 15 年从薄荷离职，谈谈我的体验，不水也不黑。
加班
当时在薄荷的时候有项制度是绩效考核的时候会参考根据打卡记录得来的在司时长，一般这种事情老板私底下看看没啥，拿出来说确实让人很不爽。我的做法是下班没啥事的时候，就在公司刷刷时长，借加班的时间提升自己的技术。相信大多数技术 leader 对于你的自我提升是持鼓励态度的。#15 楼的观点，公司故意用加班消耗你的时间让你无法成长，我认为是有点阴谋论的。就算公司高层有这种出发点，你想提升自己是没有人能够阻拦你的。
技术氛围
薄荷的优点是技术部门会鼓励大家的成长，有两件事，我是从薄荷得到了很大受益的。
- 每周要求大家一篇技术博客；
- 每周二会组织大家做内部技术分享；
这两个举措，我在后面的每个团队都在照搬，效果很不错。会把不愿意成长的队员淘汰出去。不知道现在的薄荷还在执行这两个事情没。
技术 leader 的担当
有段时间我没事干了，我就自发的把薄荷的应用进行了 Rails 的大版本升级。在 dev 环境测试啥毛病没有，上了生产环境就把系统整挂了，薄荷的用户量很大，这个是个很大的事故，这个事故也超出了我当时的能力范围，不过 @vincent 没有半个怨字，还让我早早下班了，自己和运维的同事整了一整个通宵才恢复。这种不苛责的文化，我认为对于技术人员的成长是至关重要的，会让员工大胆的去干，不至于畏首畏尾。
综上，我觉得对于主动追求成长的程序员来说，不在意一些小节的话，去薄荷仍不失是个不错的选择。
补充一下，上面的回复，我不是说薄荷有什么管理不足。我不了解薄荷，不应该随便评论薄荷这个公司。只在某一年 ruby 活动去过薄荷一次，印象是办公室很漂亮，vincent 虽然不认识我，但是照面还是打了招呼，感觉人很温和。
我想说的是，技术员容易缺乏一种抽象现实中复杂问题的思维。因为对软件来说，人就是神，所有的软件都会按照既定的逻辑来处理。而现实中的问题是多维度的，是难以被精确建模的，不可能存在软件的那种统一性。一个公司不是一个简单的整体，许多看起来不合理的规定，实际上是有其内在道理的。那种软件运行时的理想化模型，很难套用到公司上面。
我们做技术的很容易认为现实中某一种制度，或流程不高效，为什么不能更好的运转。而实际上，存在即是合理。如果想要优化，先要搞明白它的复杂性。当然我那种略带阴谋论想法未必正确，这点我承认。
我们不要当一个空有方法的理想主义者，不能纯用解决技术问题的思维去解决现实问题。
哎，又是那一套说辞，说什么适合快速成长，难道快速成长就等同于鼓励加班？我按时下班然后做自己感兴趣的其他事情就不叫做成长了？说白了，还是 996 那一套逻辑。
不知道为啥，突然想起了学生时代的晚自习。。。 一个招聘帖，引起了大家这样活跃的讨论，好像不是很多见呀。其实我个人比较喜欢有什么就说什么的公司和人，本来就是一个双向选择的过程，就好比相亲一样，大家一开始都介绍一下自己的优点和不足，双方在了解了必要情况的前提下，再决定是否继续交往。其实提一下不足没什么的，毕竟大家看重的东西不同嘛，真正喜欢你的人是不会在意你的小缺点的。
我们反对的是 996，反对的是形式主义的加班，有些人完全是看到加班两个字就格外来劲。中国目前仍然处于被帝国主义薅羊毛的阶段，我辈唯有让我国在科技和创新性领域走到世界前沿，才能让我们的子孙后代不再加班。 国家还没强大，适当加班是没有办法的事情。
感谢大家对薄荷健康招聘的关注！我是薄荷的 Vincent，回帖里可能有一些对薄荷的误解，我尽量解释一下。
- 1、关于严格考勤制度 薄荷实行比较严格的考勤制度，上午 9:00 ~ 12:00，下午 13:30 ~ 18:30，8 小时制，周六周日休息。 大部分人在晚上 7 点或 7 点半左右下班，我想这个工作强度在互联网或创业公司里应该不算高。 薄荷是做健康的公司，我们也一直倡导健康的生活方式，我个人明确反对强制 996。
- 2、关于紧急问题响应 薄荷要求技术同学在发生紧急技术问题的时候需要尽快响应，我想这是任何一个重视用户体验的公司都应该做的。至于其中涉及的具体方法和评判标准，我们也一直在改进寻找更好的办法，但是出发点绝不是给员工压力。感谢 @early 一些提议，非常有价值。
- 3、关于团队成长 我认为薄荷提供了一个还算不错的成长环境，薄荷的技术系统有一定挑战性，薄荷一直坚持很好的内外技术交流分享的传统，这些年来从薄荷毕业的同学在外面大都是能够独挡一门的核心骨干了，象 stormzhang 已经成长为行业内很有影响力的技术大 V，象 @sidekiq 能短短一年多时间成长为整个开发部的主管，还有很多很多…… 我是为他们感到骄傲的。
最后说一下薄荷健康的用人原则，核心是 3 点：
- 1、成熟且保持年轻；
- 2、自主且高度自律；
- 3、目标远大且脚踏实地。
工作是一个双向选择的过程，如果认同我们，我们很欢迎，如果不认同，我们也尊重你的选择。
实锤下还能有这么精股东和义正严辞的一笔带过 难怪对韭当割......还抵制 996，996 的软硬条件你给的起吗.....还是欢迎萌新来做做梦挨下毒大，这里有背后打小报告狗腿子，当然也有一群默默无闻老带新的前辈
yiku
回复
哈哈..国家实力真不是靠咱们这些小老百姓加班抗起来的。大家被迫加班，是大环境变差的“果”，不是国家崛起的“因”。加班越多，行业越内卷。最后就像印度，你得跟洗衣机比拼性价比搏上位了，看老板愿意买洗衣机，还是招比洗衣机更卖力的劳工。加班 != 国家强大，也不会促使国家强大，只是行业内卷的一个现象而已。
工作本来就是个双向选择，不喜欢就换个工作就是了，到点就可以走的公司到处都是，你没有选择的能力还是没有选择的权力？
全世界都在喷华为加班，唯独华为自己的员工少有抱怨的，很多国人完全认不清楚形势（M 国人出钱请水军喷华为加班带节奏，很多人就跟着节奏走），加班不会让中国强大，喷子更不会让中国强大！
我在薄荷的时候有个同事，做数据分析的，大家都叫他博士，从来都是到点就走的，你也可以，谁都可以下班就走，绝对不会被开除也不会被孤立。我选择下班待在公司针对性的提升自己的技术，是因为当时的我还想能拿个稍微好点的绩效，当然我从来没有拿过奖，虽然领导很想照顾我们 ruby 小组一下。隔壁产品组的同事很拼（毕竟产品销售额是有提成的），奖大都是他们拿了。即便如此，我也不至于认为没有拿过好的绩效是因为公司有一批总是加班的“工贼”吧。
