@honeyCream
您好，我们是在合法合规的前提下开展「赛事结果有奖积分竞猜」的哈，。具体而言：

根据中华人民共和国的有关法律法规，我们持有网络文化经营许可证（琼网文[2019] 2669-225 号）、增值电信业务经营许可证（琼 B2-20190439 ）、广播电视节目制作经营许可证（琼字 00387 号）以作为我们合法开展相关经营活动的前置基础。
我们的竞猜娱乐游戏服务和竞猜积分兑换清算服务在拥有由海南省旅游和文化广电体育厅发布的正式批文（琼旅文便函〔 2019 〕 1295 号）的前提下基于 海南自贸区的政策 开展经营活动，并主动接受有关部门的监管、检查。所有赛事规则、积分兑换规则均向宣传部和网.信办报备。

@ddxx200 后端暂时只考虑 Ruby on Rails 背景的候选人哈

@hoyixi

感谢您和我们分享您的疑惑和观点。如果后续还有其他问题欢迎随时更贴，我们相信保持透明度是永远是消除公众疑虑的最佳手段。

首先特别说明的是 根据中国法律 《员工手册》属于《劳动合同》的附件文本是拥有律效力的。

以下段落摘录自我们的《员工手册》：

## 地点和时间
我们使用弹性制，只要你能按照约定的时间如期交付成果。但绝大多数人通常在上午 10 点到达办公室，并在晚上 7 点左右离开。如果可能的话，请尽量多地和这一时间段以便于展开各种协作。
和大多数的互联网公司一样，在每一个迭代正式发布之前的几天加班加点可能在所难免。但我们认为张弛有度的节奏感至关重要。如果你感觉自已因为长时间处于超负荷工作状态而身心疲惫，请不要犹豫和 @Boris Ding 谈谈会有助于解决这个问题。

## 方法论
基于目前的团队体量考虑，我们采用 魔改版的 Scrum 来管理迭代的生命周期。但我们会每 2 周举行一次回顾会议以便检视我们的交付成果和进行持续改进。通常来说这会在周五的下午举行。

## 我们的价值观

### 绝不重复你自己

> 有人说认为花大量的时间做自动化的工具，还不如人肉的效率高，比如，写自动化的脚本花 5 个小时，而重复做这件事 200 次只花 3 个小时。有这样的理解的人根本不懂工程。一方面，这个工具可以共享重用，更多的人可以受益，这次我花 5 个小时开发这个工具，下次只用 1 小时改一下就可以用在别的地方，这是着眼于未来而不是眼下的成本。更重要的是，这是一种文化，一种提高效率的文化，他会鼓励和激发出更多的这样的事情发生。
> 摘录自 什么是工程师文化？ - 陈皓

我们认为工程师文化的精髓并不在于无限量的零食或者有意思的文化衫，而在于「发现根本原因 彻底解决问题」。

具体而言我们：
残酷无情的推进自动化 你的时间必需花费在最具创造力的事务上。对我们而言，生产力工具与用户产品同等重要。
保持克制 复杂系统意味着更多的熵，我们倾向于优先考虑更简洁的解决方案。同时也意味着，在能满足需求的情况下理应优先考虑现有的 SaaS 产品或基于开源项目。
持续改善 我们极度重视回顾会议，并对所发现的问题寻求根本性的解决。

----


坦率的说，在当下的大环境下 通过构建强大的基础设施和不断优化方法论提升人效对绝大多数的互联网公司而言都是难的事情，通过加班、通过 996 反而是看起来更容易执行的解决方案。

但是**如果你想在商业竞争上获得成功，那么就要有勇气去建立一个足以让绝大多数平庸的公司所望而却步的壁垒**。当下我们只是一家不知名的初创公司，但我们也是一家拥有**市井雄心**的公司，我们拒绝平庸。

@redmoonisnil 没有

@redmoonisnil 您好，我们是在合法合规的前提下开展「赛事结果有奖积分竞猜」的哈，。具体而言：

根据中华人民共和国的有关法律法规，我们持有网络文化经营许可证（琼网文[2019] 2669-225 号）、增值电信业务经营许可证（琼 B2-20190439 ）、广播电视节目制作经营许可证（琼字 00387 号）以作为我们合法开展相关经营活动的前置基础。
我们的竞猜娱乐游戏服务和竞猜积分兑换清算服务在拥有由海南省旅游和文化广电体育厅发布的正式批文（琼旅文便函〔 2019 〕 1295 号）的前提下基于 海南自贸区的政策 开展经营活动，并主动接受有关部门的监管、检查。所有赛事规则、积分兑换规则均向宣传部和网.信办报备。

@Nasei 要真正建成一个能够「 1 个人做 3 个人的事情」的团队，显然不仅仅需要招到最好的人还需要拥有一整套非常强大的工程效率设施。所以我的理解是工程效率设施至少取代了「 3 个人」中「 1 个人」的工作量。

比如具体来说，我们现在拥有下述的工程效率设施：

* 我们买了 45 美元 每人每月的 Figma 企业版以便实现最高效的 Uikit 管理 和 视觉稿交互方式；
* 我们买了 21 美元 每人每月的 Github.com 企业版 以便使用静态代码安全扫描等高级功能和基于 Github Action 的 CI/CD;
* 我们在 Microsoft 365 E5 的基础上，自建了一整套高效的内部管理工具 包括 MDM 、BeyondCorp 等等；
* 我们在 Kubernetes 集群的基础上，通过使用了一系列 CNCF 生态的全家桶来提升整体交付效率；
* 我们使用 GitHub 的 HuBot 实现了一整套 ChatOps 体系;
* 还有一大堆基于 Github Webhooks 的各种 Bot 就不一一举例了

@vivili 只是打个比方。。。抱歉可能举的例子不太恰当

@lane1 我们目前暂时没有 Intern 的招聘计划，但预计下半年可能会有。欢迎保持关注

@Fontaine 感谢关注，我们还在持续看候选人哈

目测是对原文中

At the time, all of this was sorely needed. There weren't as many people working on Rust, and there wasn't that much documentation.

的误译

@encro 原有的运营团队在 海南大厦（新海航大厦旁），目前正在招聘的产品技术团队在全球贸易之窗。 都在国兴大道附近。

@holulu 感谢您的分享。

我大概在 2013 年左右开始使用 Ruby on Rails， 然后在此之后使用 Ruby 技术栈连续创业和帮助数家大厂组建了多个技术团队。我也很愿意很您分享下我的个人观点。

我的理解是 「小众语言和小团队」以及 「主流语言和大团队」其实都是相对适宜的取舍，而「小众语言的大团队」和「主流语言的小团队」这样的选择则可能不得不面对更多额外的挑战。招聘和做产品增长其实一样，本质上就是一个「漏斗模型」。 少量的高质量流量和高留存 与 大量的针对性不那么强的流量与低留存 实质上是完全等价的。

当我们考虑组建一个小而精英化的团队时，由于整个团队 headcount 相对有限。那么即便是选择通过猎头等成本相对较高的渠道，依然是具有高 ROI 的。 与此同时，精英化的小团队很多时候意味着「 1 个人拿 2 个人的钱」，而管理学的相关实践告诉我们「高薪资实际上是能够有效较低团队流动速度」的。


再就是关于 GraphQL 方面，我们的思考其实是这样的：

从本质上说架构是一种 Trade-off 的艺术。软件工程的诸多历史教训告诉我们「增加人手必然增加整个团队的沟通成本，沟通成本利滚利式的增长最终将抵消掉新人手所带来的工作量」。不同于劳动密集型行业，在智力密集型行业流水线式的分工很多时候将导致降低效率而非提升效率。在理想状况下「由若干名全栈工程师乃至于全干工程师*各自负责一部分产品模块」其效率必然远高于「由产品、前端、后端、运维、运营所组成的职能团队」。

但伴随着业务需求和技术复杂度的与日剧增，寻找既熟悉 iOS 和 Android 应用开发各自的难点，又熟悉如何使用消息队列解决高并发所带来的瓶颈，同时还拥有数据库容量规划经验的全能型 Web 开发者变得极其艰难。更多时候，全栈成为了「样样都懂」而非「样样精通」。

因此，全栈工程师主要活跃于需求相对简单的早期创业公司。绝大多数中大型互联网公司，不得不采用沟通成本相对高昂的职能型团队模式。仅有 Google 、Facebook 、Amazon 等少数科技巨头，另辟蹊径的在全栈与规模化之间找到了新的平衡点。

作为时下业界最为火热的术语，对于「中台」人人都有不同的解读。但正本清源，从更本价值上去看中台可以被理解为一种抽象层屏蔽后台复杂细节，促进前台迭代效率。

以 Google 、Facebook 、Amazon 为代表的科技巨头之所以能够建立全能型的工程团队，而不受由规模增长所带来的复杂度增长之影响，很大程度上要归功于它们极其完善的中台基础设施。

例如当 Google 将能够在全球范围内进行分布式部署同时可实现外部一致性事务的数据库（ Spanner ）构建为云服务时，Google 的「全栈工程师」（ SDE ）们无需成为分布式系统专家即可轻松完成复杂系统的全球化部署需求。又比如通过 React Native 技术，Facebook 的工程师们便有能力在仅具有网页开发经验的情况下完成绝大多数的移动 App 开发需求。

显然通过抽象包装屏蔽技术细节，才是应用开发进行精细化分工的正确打开方式。

以 Docker 和 Kubernetes 为代表的 Cloud Native 技术的出现，使得构建完善的工程效率基础设施已非 Google 等科技巨头的专利。以中国互联网公司为例，从 阿里、腾讯 到 头条、美团、滴滴 再到 绝大多数的 A 轮以后初创公司，Kubernetes 已经成为了行业的事实标准。在此基础之上 Serverless 、Service Mesh 等新技术亦逐渐升温，构建 PaaS 乃至于 BaaS （后台即服务）已经成为了业界所共同预期的未来。

RPA （机器人流程自动化）、低代码&零代码平台等概念也在近期广受追捧，很大程度上也可以被视作源于这一预期的进一步传导。

基于此，我们相信未来将这样到来：传统意义上的程序员或将不复存在，取而代之的将是两类人产品设计师（兼具当下的产品经理和全栈工程师的职能，广度优于深度）和计算机科学家（某个特定细分领域的行业专家，深度优于广度）。

@wukong1024 您好，我这个月月初刚刚到海口。「二三线城市的物价水平」是基于我个人到海口后主观认知，以及和我之前在帝都时的生活经验的对比。可能确实不够全面和有代表性，如有过于主观的偏颇之处，欢迎您帮忙补充。

我个人的主观经验是：

住： 我在北京金台夕照附近租住两居室的价格是 18K/月，更早些时候在大望路百子湾附近租住大开间的价格是 6k 元 /月。 而我和我的其他同事现在在海口类似地段所租住的小区（国兴大道附近），一居室的价格在 3-4k 左右。

食：同样是在国兴大道附近，我在饿了么上点外卖的均价大概在 30 元左右。 但之前在北京金台夕照附近，如果我在饿了么上点相同质量的食物，大概需要 50 元左右。

行： 我在海口使用滴滴快车做为通勤工具，2 公里距离的价格是 10 元。 作为参考，在北京 2 公里的价格是 16 元。

宽带：有在帝都生活经验的同学，应该都感受过「运营商垄断」的痛苦。在北京有大量的小区只能提供诸如「长城宽带」、「方正宽带」等价高质劣的二级运营商的小区宽带服务。 而在海口，至少我和我同事当下选择的这几个小区都可以直接办理 电信 500M 家宽。

@huoguozhang 感谢你的关注，原则上我们只考虑有 React 技术栈经验的候选人。 但如果您对 RxJS 和 GraphQL （ Apollo ） 有一定的使用经验的话，也欢迎投简历试试。

@satoru 主要还是综合考虑到生态的问题，以 Ruby 在湾区的流行度而言 至少 GEM 生态（类似 NPM Package ）是非常丰富的，能够满足业务上的绝大多数需求。特别是在 GraphQL Server 方面，Ruby 社区会拥有相对成熟的开源实现。Github 的 GraphQL API 就是基于 http://graphql-ruby.org/ 实现的。 同时 Ruby 2.7 引入了 Compaction GC 在性能上也有非常大的改观。

@najiawang 是这样的 中海国投（盈动电子竞技（海南自贸区）有限公司 和 动动电子竞技（海南自贸区）有限公司 的母公司）在 2019 年获得了相关的牌照和试点许可，涵盖运营、客服和研发等部门差不多有 100 人左右。但基本都是在海南本地招聘的团队，相对来说距离一线互联网公司有非常大的差距，导致产品体验相对不那么理想。

所以现在我们和中海国投进行战略合作，成立了一家新的公司（海南思行科技有限公司）来从 0 到 1 组建一个能匹配一线互联网公司水准的精英化小团队来重新研发产品。目前还在早期招聘阶段，当前计划维持整个产品技术团队在 10 人左右的规模。

@najiawang 作为精英化的小团队 我们只招「潭雅」不招「动员兵」（红警梗） XD

@Rwing Ruby 其实也有可选的类型标准系统（ https://sorbet.org/）

另外我们相信对于一个足够精英化的小团队而言，ruby 的元编程等特性实质上是可以提升可维护性而非降低可维护性的。架构的本质是 tradeoff，而我们的 tradeoff 哲学是 Rails Doctrine （ https://ruby-china.org/wiki/the-rails-doctrine ）


其实在语言学上有一个假说 认为你使用的语言会反过来影响你的思维模式（「所说即所想」），我们认为这以假说在编程语言范围内同样适用。 尽管大多数编程语言都是图灵等价的，但显然不同的范式和语法风格会导致你以不同的思路去设计程序。