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

sidekiq · March 23, 2020 · Last by zzz6519003 replied at April 21, 2020 · 10433 hits

职位概况:

  • 公司:薄荷健康科技

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

  • 职位:中级 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,对此感兴趣的欢迎交流

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

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

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

Reply to yiku

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

Reply to kevinyu

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

作为一个日活百万的 App 开发团队,保障系统的正常运行是我们的职责,技术团队不承担 KPI,只约定 OKR,我分享一下我们关于 App 的 Key Result。

薄荷健康 App 产品和技术系统高质量开发和运行:

  • 1)App 崩溃率万分之一以内

  • 2)服务端系统高可用性达到 99.99%

  • 3)快速响应,技术问题最迟 15 分钟(非工作日 30 分钟)内有人响应

就在最近,我们实现了 33 个微服务全面容器化,将 go 作为一级开发语言,在关键性能瓶颈点,新的技术系统上,我们都使用 go 进行改造和开发。在服务治理,架构设计,内部通信上都踏过了不少的坑,也积累了一些实践经验,如果大家在推进 go 的过程中遇到什么问题,欢迎一起交流。

Reply to 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 的地方。

Reply to early

万分同意。

Reply to sidekiq

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

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

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

Reply to early

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

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

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

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

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

Reply to adamshen

吼吼吼吼~真香啊~

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

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

Reply to oatw

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

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

Reply to early

非常同意你的观点,我们也在不断优化响应策略,后端是已经采用轮班制度了,也在推进和钉钉结合的工单系统的开发。

钉钉答疑群建立的初衷,是为了建立用户与研发沟通的桥梁,及早发现系统的隐藏问题和 BUG,能进入答疑群的问题,都是经过客服和产品经理两层,达到一定级别的。说起来,我们很多同事解决问题的能力,对项目的深入理解,就是从解决答疑群问题中磨练出来的,薄荷很早就实现了全面微服务化,平均一个工程师要承担 3 - 5 个系统的维护,除了必要的文档外,通过排查问题进行实操,也能快速的掌握一个项目。

去年下旬,通过排查一个用户数据不一致的问题,我们还发现了一个在项目中隐藏了长达一年半的深层 BUG,解决具体问题逐渐不再是我们的目的,通过这一步骤培养大家解决问题的能力,才是我们的期望。

好在我们的团队规模还比较小,遇到问题也都没有回避,能迅速的推进解决,也非常欢迎社区的意见和建议,帮助我们不断成长。

招远程吗

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

Reply to darksky

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

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

Reply to 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

Reply to sidekiq

期待着😀

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

Reply to sidekiq

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

我也觉得 java 更香

Reply to darren

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

佩服 你太厉害了 向你学习

Reply to adamshen

大佬你好~😁

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

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

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

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

Reply to adamshen

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

35 Floor has deleted

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

哎,又是那一套说辞,说什么适合快速成长,难道快速成长就等同于鼓励加班?我按时下班然后做自己感兴趣的其他事情就不叫做成长了?说白了,还是 996 那一套逻辑。

不知道为啥,突然想起了学生时代的晚自习。。。 一个招聘帖,引起了大家这样活跃的讨论,好像不是很多见呀。其实我个人比较喜欢有什么就说什么的公司和人,本来就是一个双向选择的过程,就好比相亲一样,大家一开始都介绍一下自己的优点和不足,双方在了解了必要情况的前提下,再决定是否继续交往。其实提一下不足没什么的,毕竟大家看重的东西不同嘛,真正喜欢你的人是不会在意你的小缺点的。

我们反对的是 996,反对的是形式主义的加班,有些人完全是看到加班两个字就格外来劲。中国目前仍然处于被帝国主义薅羊毛的阶段,我辈唯有让我国在科技和创新性领域走到世界前沿,才能让我们的子孙后代不再加班。 国家还没强大,适当加班是没有办法的事情。

41 Floor has deleted

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

也只有薄荷的招聘才能这么热闹

实锤下还能有这么精股东和义正严辞的一笔带过 难怪对韭当割......还抵制 996,996 的软硬条件你给的起吗.....还是欢迎萌新来做做梦挨下毒大,这里有背后打小报告狗腿子,当然也有一群默默无闻老带新的前辈

要是真为了天下苍生还真愿意加班,你在这给私企当免费劳动力莫不是让老板天天换法拉利喷你尾气

Reply to yiku

哈哈..国家实力真不是靠咱们这些小老百姓加班抗起来的。大家被迫加班,是大环境变差的“果”,不是国家崛起的“因”。加班越多,行业越内卷。最后就像印度,你得跟洗衣机比拼性价比搏上位了,看老板愿意买洗衣机,还是招比洗衣机更卖力的劳工。加班 != 国家强大,也不会促使国家强大,只是行业内卷的一个现象而已。

工作本来就是个双向选择,不喜欢就换个工作就是了,到点就可以走的公司到处都是,你没有选择的能力还是没有选择的权力?

全世界都在喷华为加班,唯独华为自己的员工少有抱怨的,很多国人完全认不清楚形势(M 国人出钱请水军喷华为加班带节奏,很多人就跟着节奏走),加班不会让中国强大,喷子更不会让中国强大!

我在薄荷的时候有个同事,做数据分析的,大家都叫他博士,从来都是到点就走的,你也可以,谁都可以下班就走,绝对不会被开除也不会被孤立。我选择下班待在公司针对性的提升自己的技术,是因为当时的我还想能拿个稍微好点的绩效,当然我从来没有拿过奖,虽然领导很想照顾我们 ruby 小组一下。隔壁产品组的同事很拼(毕竟产品销售额是有提成的),奖大都是他们拿了。即便如此,我也不至于认为没有拿过好的绩效是因为公司有一批总是加班的“工贼”吧。

有一说一,华为毕竟给的钱足够多。喷和抱怨也是个人权利啊,可以不赞同,但捍卫评论的权利。

博士此刻的心情应该比较复杂

Reply to nate_yu

博士一般懒得刷论坛吧 ^_^,博士应该看得出我是在侧面烘托他的牛逼

Reply to vincent

ceo 换了?

You need to Sign in before reply, if you don't have an account, please Sign up first.