招聘 【上海】薄荷科技诚聘 Ruby 工程师 2 名

sidekiq · 2020年03月23日 · 最后由 darksky 回复于 2020年04月02日 · 2921 次阅读

职位概况:

  • 公司:薄荷健康科技

  • 坐标:上海浦东世纪大道地铁站附近

  • 职位:中级 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

工作环境

工作环境技术氛围一级棒,欢迎新同学加入😀

技术氛围很赞哦, 同时公司也有很多项目在用 Go, 对此感兴趣的欢迎交流

环境氛围非常不错,公司业务持续高涨,非常有前景,欢迎大家加入~~~

强大的技术团队,一流的工作环境,总之是很棒的公司,蒸蒸日上。

从知乎上的评价似乎公司氛围最近几年冷冰冰的, 想了解一下

yiku 回复

看样子是过来人呀, 不过你这新建小号就回复这一个帖子吗。难道还在职

kevinyu 回复

号小不小不重要,每个公司都会有各种问题,也都能理解,但我讲的都是客观存在的奇葩,如果招聘时候告知连简历都不会投

作为一个日活百万的 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 的地方。

early 回复

万分同意。

sidekiq 回复

请教下 可用性 具体是怎么计算的?

还比较好奇为什么换到 go?收益是什么呢?

我只能说外边诱人,内在复杂

early 回复

目的就是要把你多余的注意力耗空,让你没有精力来学习提高,跳槽到其他单位。你节省下来的注意力,多半不会用在工作上面。且技术部门就是个工具,一个萝卜一个坑,只要有人干活就行,不需要太有创造力。

现实中往往不存在理想化的模型,高压式的管理可以降低对管理人员素质的要求。

严格的考勤和回复制度下,留下来的只会是一些服从性较好的员工,没有刺头,这样队伍比较好带。管理者不需要针对不同个性的员工来进行不同风格的沟通,也不需要为了粘合团队而做出努力。

其次,管理者往往承担了很大的压力(虽然报酬也更丰厚)。如果自身压力很大,看见手底下很舒服,人的天性会产生一种嫉妒心理。压榨下面的员工,可以让管理者找回一点掌控感。

好的管理者难找啊。技术要过关,又能够和各种各样的员工有效沟通。双商在线,能够在自身承受巨大压力的情况下依然鼓励他人,提升团队士气。要是真有这样的人,管个技术部分其实是屈才了。事实上很大一部分技术好的管理者,脾气暴躁,没有耐心,需要配上一套高压管理模式来帮助他们。

adamshen 回复

吼吼吼吼~真香啊~

我现在每天早上到公司先自己看一个小时的书,不干活,下班就开免打扰模式,而且跟项目经理坦白了。。。 有次部门经理路过问我看的啥,我回答了一个字:“书。” 貌似我就是那种牵着不走打着倒退的员工,哎呀好丢脸。

不过,说真的,感觉如果在一个条条框框特别多的团队里,还是得以自己为主,要不得被公司拖死。

oatw 回复

哈哈 老兄加油 自己的出路当然只能靠自己去找

我感觉自己这两年没啥提升,差不多快废了,不过是我自己的能力问题,不怪公司

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 圈子。

darksky 回复

哈哈,感谢老哥顶贴,少了你的出现,这就不是一篇完整的招聘贴。

easonlovewan 回复

暂未开放远程岗位,不过经历疫情的洗礼,大家对远程都有了更深刻的认识,将来一定会拥抱远程开发的😀

sidekiq 回复

感谢😀

我大体明白你们怎么定义 SLA 了。是不是任何一个服务 crash 了,就是不可用?个别 API 500,不认为不可用?

每日峰值调用能达到 5k qps....我们用 go 改造一些关键服务,顺利的降低了整体负载。

那就是,使用 go 之后,可以更省内存和 cpu 吗?

那篇文章,简单扫了下,总结下来就是 ruby 不火了。技术热点转移了,再就是本身的问题。

本身问题有 3 点:

  1. 并发
  2. 不合适大规模工程开
  3. 不好招人

并发这个,目前主流还是机器换人力。

不合适大规模工程开发

你的回复,好像没有提工程的问题。比较好奇你们实践后得出的结论是什么?

“不合适大规模工程开发” 这个本身是很模糊的概念。比如 java 被认为更容易大规模开发。但 java 的应用真的就 bug 少了吗?真的就更快了吗?似乎也不见得。

不好招人

中级的不好说,高级的感觉都不好招。还有一个问题,一个 ruby 开发可以解决的,用 go 可能要用 3 个。在这个假设下,那就是招 3 个 go 比招一个 ruby 容易。才能说 go 比 ruby 好招人。

可能整体来说,是更看好 go 的未来,所以想在 go 上多投入一些?

难道只有我一个人觉得微服务还是 Java 香吗?😂 可能我是个假 Ruby

sidekiq 回复

期待着😀

JiangYongKang 回复

Spring Cloud 全家桶真香。比 k8s,istio 好用多了。

sidekiq 回复

大佬能留个微信么,或者邮箱,我要投简历,我的微信 15220220554

JiangYongKang 回复

我也觉得 java 更香

darren 回复

哎呀,教科书级的生产事故啊,招聘贴忘记留邮箱了,简历发给我就好了,zhangzhongnan(at) boohee.com,微信号和社区同名,sidekiq

mingyuan0715 回复

佩服 你太厉害了 向你学习

adamshen 回复

大佬你好~😁

补充一下,上面的回复,我不是说薄荷有什么管理不足。我不了解薄荷,不应该随便评论薄荷这个公司。只在某一年 ruby 活动去过薄荷一次,印象是办公室很漂亮,vincent 虽然不认识我,但是照面还是打了招呼,感觉人很温和。

我想说的是,技术员容易缺乏一种抽象现实中复杂问题的思维。因为对软件来说,人就是神,所有的软件都会按照既定的逻辑来处理。而现实中的问题是多维度的,是难以被精确建模的,不可能存在软件的那种统一性。一个公司不是一个简单的整体,许多看起来不合理的规定,实际上是有其内在道理的。那种软件运行时的理想化模型,很难套用到公司上面。

我们做技术的很容易认为现实中某一种制度,或流程不高效,为什么不能更好的运转。而实际上,存在即是合理。如果想要优化,先要搞明白它的复杂性。当然我那种略带阴谋论想法未必正确,这点我承认。

我们不要当一个空有方法的理想主义者,不能纯用解决技术问题的思维去解决现实问题。

adamshen 回复

我们不要当一个空有方法的理想主义者,不能纯用解决技术问题的思维去解决现实问题。 👍

适合年轻人...这种公司,成长的方式有很多,不一定非要去通宵啊...昨天看到业内一个大佬去世,才 36,一时有感而发。。。

“适合年轻人”,所以不负责任地猜测人员流动有点大?

哎,又是那一套说辞,说什么适合快速成长,难道快速成长就等同于鼓励加班?我按时下班然后做自己感兴趣的其他事情就不叫做成长了?说白了,还是 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、目标远大且脚踏实地。

工作是一个双向选择的过程,如果认同我们,我们很欢迎,如果不认同,我们也尊重你的选择。

stormzhang 是不是技术大 v 不知道,但是确实是个割韭菜高手,哈哈,祝贵公司能招到合适的人才,祝好。。。

richard1230 回复

hhh

割韭菜好说法,好像每个公司老板都会这样

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册