技术面试指南

面试流程

通常我们的面试分为一次电话面试和一次现场面试。在少数难以决定的时候会多增加一轮电话或现场面试。

面试中的沟通问题

尊重候选人,平等交流:让候选人自我介绍前,先介绍自己和公司;交流的时候双方处于平等的地位,耐心听完对方的话;在面试过程中不要有驳倒候选人的意图。无论是电话面试还是现场面试都应该做到守时。我们在考察别人的时候,别人也在考察我们。

把握好面试节奏:面试从双方的自我介绍开始,然后开始从候选人过去的职位和做过的项目开始谈起,这些都应该是候选人熟悉的内容,为后面更难的技术问题建立良好的沟通氛围。

不要只求答案正确,要本着一起讨论的方式让候选人充分说明解题思路;不要不断地变换问题,每个问题点到即止。对一个问题要一层层深入,直到候选人回答不了或完整解答为止,这样才能知道候选人思考达到的深度在哪里。

面试的重点是考察候选人解决办法的思路。可以从一个简单的问题开始,候选人给出回答后,在上一个问题基础上做些变化进一步加大难度,考察候选人思路是否灵活;也可以从一个困难的问题开始,考察候选人分解复杂问题的能力,在长时间没有进展时应该给出一些提示。同时也要注意考察候选人在遇到困难时是否会问合适的问题。

给候选人对你提问的机会:我们要通过面试了解候选人,候选人也需要在这个过程中了解我们。在面试结束前应该给候选人提出对我们的团队、产品、面试过程、职位需求等方面问题的机会。一来解答对方的疑问,二来也可以看出他对新工作的期待程度和热情高低。

每一次面试,并不仅仅是一次壮大团队的机会。哪怕最后没有招来新同事,也可以多让一个人知道我们的公司和产品。我们的用户群和我们招聘的目标人群是重叠的,我们接触的每个人都可能传播我们的形象和品牌。

面试中需要考察的问题

对不同的技术职位下面的几个方面有不同的权重,但都应该基本覆盖到:

  • 基础知识:基本的数据结构和算法;
  • 排序、二分查找等经典算法在现实中的应用;
  • 对概率的基本理解;
  • 对时间和空间复杂度的理解;
  • 所招聘职位相关的专业问题(iOS、Android、后端架构等)。

面试中应避免的问题

  • 与技术和实际工作无关的智力题,比如过去曾很流行的和海盗、金币、球相关的一类问题。因为在面试中能比较快回答出这类问题的通常是曾在网上看到过答案的人,并且这类问题对预测候选人在实际工作中的表现几乎没有参考价值。
  • 网上常见的所谓 Microsoft、Google 面试题等,原因同上。
  • 非技术的假设性问题:假如现在要赶活;假如有两件事情摆在你面前;假如老板故意刁难你;假如有一个不好合作的同事。

转自:http://open.leancloud.cn/tech-interview-guide.html

代码分支管理指南

介绍

这是我们团队的 Git 分支管理规范。每个人对工具的使用往往各有偏好,各种方法各有利弊,无所谓对错。但涉及团队协作的方面需要有一些一致的规范,所以请大家务必遵守。

除了一致性之外,这个规范的目的是以下几点:

  • 确保可以轻易确定特定时间发布或运行的版本。在新发布的程序存在重大缺陷时,可以尽快 rollback 到上一个稳定版本。
  • 在需要修复紧急 bug 并尽快发布时,可以只发布必要的 bugfix 而不同时发布还不应发布的其他改动。

branch 和 tag

每个官方的 repo(leancloud/ 下的都是官方 repo)有且仅有以下的 branch 和 tag。

Branch: master release。其中 master 对应目前的开发分支,所有的 pull request 都应该发到这个分支。release 是当前发布的分支,在这个分支只能增加从 master cherrypick 过来的 commit。详见本文后面的说明。

Tag: 对应每个发布版本的 tag。SDK 和应用程序的 tag 遵照 <major>.<minor>.<patch> 的命名,如 2.5.1;服务端程序的 tag 以发布的日期命名,如 2014.11.13,如果有 bugfix,则在后面增加小写字母,如 2014.11.13 后是 2014.11.13a,然后是 2014.11.13b

目前还有部分 repo 包含多个独立部署的项目(如 uluru-platform)。在这样的 repo 打 tag 时需要附上项目名做前缀,如 bigquery-2.5.1。但我们需要逐步把这些项目拆分到独立的 repo。

发布新版流程

  • 确保所有要发布的 pull request 都已经 merge 到 master
  • 使用 master branch 的代码进行测试,如果发现 bug,把对应的 bugfix merge 到 master
  • 删除旧的 release branch,并从当前的 master 创建新的 release branch;
  • 在 Jenkins 上从releasebranch 发起新的 build 并发布;
  • 发布完成后在当前的 release branch 打上对应版本的 tag。

Bugfix 流程

这里的 bugfix 指的是修复已经发布的程序(release branch)中的缺陷。master 里的 bug 请直接 merge bugfix 到 master

  • 如果此缺陷在master中还存在,请先 merge bugfix 到master ,否则跳到下一步;
  • releasebranch 从mastercherrypick 修复该缺陷的一个或多个 commit;
  • 在 Jenkins 上发布当前releasebranch;
  • 发布完成后在当前的releasebranch 打上递增的 tag。比如,如果上一个 tag 是2.5.1 ,这个 tag 应该是2.5.2 ;如果上一个是2014.11.13 ,这个就是2014.11.13a

其他

并不是每个 bug 都有专门发布 bugfix 版的必要,对于不紧急的 bug,可以在master里 fix 后随下一个版本发布。

在一个官方 repo 下只应该有以上说的 branch 和 tag,在开发过程中使用到的 feature branch 等请都放在个人的 fork,一律通过向master发 pull request 的方式给官方 repo 提交代码。

转自http://open.leancloud.cn/git-branch-guide.html

工作的评价和反馈机制

评价和反馈

我们在每个季度结束时会进行一次 performance review,即工作的评价和反馈。流程一定程度上借鉴了 Google 的 performance review, 但有不少简化和修改,以避免给大家造成额外的负担,毕竟我们的主要精力应该放在改进产品而不是处理内部流程上。

这个流程分为两部分。

自我评价及工作反馈

在季度结束时,每个同事会收到一个 Google Docs 表格,包含以下几个问题。除了第一个问题外,其他内容都会对其他同事保密,只有自己的主管和 HR 可以看到。

自我评价

  • 请列出过去一个季度你参与的工作、承担的职责、完成的具体内容,并陈述工作实际产生的价值。请尽可能详尽。如果有在自- 己日常职责之外的贡献,也请单独列出。(这部分内容将对所有人公开)
  • 针对以上列出的工作请给出对自己工作的评价。请总结得失以及原因。有哪些地方有改进的空间?
  • 针对上面的问题和需要做的改进,请列出在下个季度的具体改进计划。

工作反馈

  • 公司在哪些方面给你提供更多资源或支持可以让你工作得更好?
  • 对于你的主管或管理团队的工作有哪些反馈和建议?
  • 对于团队建设、公司文化有哪些反馈和建议?

主管评价

每个担任 people manager 的同事会收到下属的自我评价和工作反馈。每个 manager 会为每位下属写主管评价和反馈,同时打出本季度的绩效得分。绩效分数在 0.0 至 2.0 之间,其中 1.0 表示工作达到期望,低于 1.0 表示低于期望,高于 1.0 表示高于期望。这里的「期望」和每个人的职能、级别和薪酬相关。

对薪酬的影响

绩效分数对薪酬的影响体现在年终奖上。我们的年终奖计算公式为:

年终奖 = 本年度累计实际工资 * 15% * 年度个人绩效 * 年度公司绩效

其中的年度个人绩效即为个人各季度绩效分数的平均数。年度公司绩效由管理团队在年末评定。

结语

我们的 performance review 首要目的是为每个人提供一个总结工作并听取反馈,明确得失以便改进的机会;次要目的是通过浮动的年终奖让做出更多贡献的同事能得到更高回报,做到相对的公平。希望每个人都以坦诚、认真、实事求是的态度对待这项工作。

转自http://open.leancloud.cn/perf-review.html

休假制度

国家法定节假日

国家规定的法定休假日,公司将按国家的统一规定执行。

带薪休假

凡公司全职的正式员工都享有带薪休假(在本节简称休假)。

  • 员工加入公司每工作满 1 个月,即可累积 1 个工作日的带薪休假。在本公司每工作满一年额外增加一天休假。每年内累计新增休假以 20 个工作日为上限。在入职本公司之时,工龄已经累计 20 年以上的员工,入职时即每年有三天额外休假(也就是工作满一年时一共有 15 天休假)。
  • 员工由于非工作原因,实际出勤天数不足当月正常工作日的 50% 时,当月不增加可休假天数。
  • 员工可根据个人情况以及工作需要安排休假,选择一次休完或分散休完,最小单元不小于半天。休假申请需通过内部请假系统提前至少三个工作日提交,请假系统会自动发送邮件通知给全公司。时间较长的休假请尽早提交。
  • 通过试用期的正式员工可提前预支休假,但在任何时候预支休假总天数不超过 6 天。
  • 员工当年度的休假未休息的天数可跨年度累计,但累计未休的休假总天数不能超过 20 个工作日,超出天数作废。
  • 员工离职时,如果有剩余休假,员工需要先将剩余休假一次性休完,再回公司办理离职手续。
  • 员工离职时,实际休假天数多于应休假天数的,公司会在离职当月的工资中扣除多于应休假天数的工资。

病假

员工患病或者非因工负伤而不能工作时需请病假,休病假须在可能的最早时间通过请假系统提交。连续 2 个工作日以上的病假,应持有医院开具的有效病假证明,并在病假结束上班后,将病假证明交人力资源部。

员工病假期间,公司按以下标准支付工资。

  • 当月的第 1 天病假工资照常发放。
  • 当月的第 2、3 天病假,日薪按 70% 发放。
  • 当月的第 4、5 天病假,日薪按 50% 发放。

事假

员工有私事需要办理而不能工作时,并且无可用带薪假时须请事假,休事假须提前在请假系统申请并得到主管的批准。

事假为无薪休假。工资扣款额=固定工资/月计薪天数(21.75)× 事假天数

婚假

婚假包括公休假和法定假,需在领取结婚证一年内休假,逾期未休视作主动放弃,不可拆分休假。在入职日期以后领取结婚证的员工才享有婚假。根据《婚姻法》以及《北京市人口与计划生育条例》的规定,依法办理结婚登记的夫妻,除享受国家规定的 3 天婚假外,增加假期 7 天。再婚者可享受国家规定的 3 天婚假。

产检假

国家规定在职女员工怀孕后享有产检假,在规定的范围内,孕妇去医院进行产检,算正常出勤对待,具体的时长与计算方法如下:

  • 怀孕第 1-6 个月,每月可享受 1 天产检假,用于妊娠确认以及健康培训等;
  • 怀孕第 6-7 个月,每个月可享受 1 天产检假;
  • 怀孕第 8 个月,每月可享受 2 天产检假;
  • 怀孕 9 个月以上,每月可享受 4 天产检假,但其中 2 天已包括在预产假中。

产假

是指在职女员工在分娩前后一段时间内的特殊休假待遇。产假是包括双休日和法定假日的,不可拆分休假。

  • 单胎顺产者,给予产假 98 天,北京市女职工生育后享受的假期,除国家规定的 98 天产假外,还享受 30 天生育奖励假;
  • 难产者,增加产假 15 天;
  • 多胞胎生育者,每多生育一个婴儿,增加产假 15 天。

流产假期

  • 12 周以上 16 周(含)以内流产的产假为 15 天;
  • 16 周以上流产的产假为 42 天。

二胎产假

只要符合计划生育政策,均可依法享受相应的产假等福利待遇。

陪产假

符合法律法规规定生育的夫妻,男方享受配偶陪产假 15 个自然日。

转自http://open.leancloud.cn/vacation.html

薪酬体系

##简介

我们相信公平和透明的薪酬机制很有益于公司的长期健康发展。我们在设计薪酬体系时重点考虑了几个问题:

  • 避免薪酬倒挂:很多公司,尤其是大的互联网公司在人才竞争激烈的年份给出较高的入职薪水,而老员工的薪水因为惯性没有相应提高,所以造成了新员工入职薪酬高于老员工的不公平现象。
  • 消除薪酬谈判带来的不公:在招聘时,很多公司往往会根据候选人之前的薪酬以及他/她的期望值在可接受的范围内确定 offer。这样的方式事实上惩罚了之前薪酬偏低的人和不善于薪酬谈判的人,而有利于之前薪酬偏高或者善于薪酬谈判的人,造成了能力和贡献相似的人薪酬产生较大差别,也就导致了组织内部的不公平。所以我们决定从机制上保证给出的 offer 完全取决于我们自己对候选人的独立评判,与其他因素无关。做到这一点,自然也就不应有任何因素导致我们对 offer 进行调整,就可以把薪酬谈判从招聘中去掉。
  • 简单透明:作为一个精简的创业公司,我们需要一个透明、自动化的机制来保证在薪酬这样的敏感问题上尽可能的公平。当人为因素越少,机制越透明时,大家就越不需要把注意力放在这些方面,日常运作也更简单高效。
  • 保持灵活性,避免线性等级:专业领域的专家和承担管理角色的同事对团队都很重要,这需要在薪酬体系中体现。

##月薪的计算

每位同事的月薪由下面的公式得出:

Salary = Function × Experience + Impact + Choice + Adjustment

其中 Function 是不同职位类型的月薪基数, 会随公司发展的情况进行调整。当前各类型的基数如下:

Function Base Amount
工程师9000
设计9000
项目经理12000
行政管理6000
商务8000
市场7000
Chief Officers13000
顾问0

以上是我们现有的职位类型,将来会根据需要增加新的类型。

Experience 是不同经验和能力等级。对于新加入的成员这个等级会根据面试情况确定。对于在职的同事,会根据实际工作情况进行定期 review 和调整。这是一个团队内部的标准,和外部的通常标准或其他公司的职称标准完全无关。Experience 所对应的数值如下表所示:

Experience Level Experience Amount
E0 0.8
E1 0.9
E2 1.0
E3 1.2
E4 1.4
E5 1.8
E6 2.0
E7 3.0

Impact 指的是在团队中的影响力和贡献,对应的数值如下图所示:

Impact Level Impact Amount
I0 0
I1 2,000
I2 4,000
I3 6,000

由于在面试中无法衡量将来在团队中的实际贡献,我们在新的 offer 中通常会把 impact 定为 I0 留待将来调整。

Choice 除联合创始人月薪的 Choice 部分为 0 外,其他同事在入职时默认 Choice 部分为月薪其他部分的 10%。我们会按期权激励计划授予每位同事期权。新同事在入职的第二个月底前可以在期权和月薪间做一个倾向性选择。选择期权的同事可以放弃月薪的 Choice 部分而在原定期权基础上多获得 20% 的期权。

Adjustment 这是一个对所有人固定的调整,目前为 1000 元。

##例子

假设某个 function 的基数是 13000,那么这个 function 的 experience level 为 E3、impact level 为 I1 的同事,她的 Function × Experience + Impact 部分就是 13000 × 1.4 + 5000 = 23200。如果她选择更多期权,那么她的月薪就是 23200 + 1000 = 24200。如果她选择更多月薪,那么她的月薪就是 23200 × 110% + 1000 = 26520。

##奖金

目前我们周期性的奖金是每年的年终奖。年终奖的金额是浮动的,规则详见 工作的评价和反馈机制。

##结语

以上的机制借鉴了 Buffer 的 Open Salaries,具体的公式按照我们的情况做了调整, 希望让每个人都能清楚自己薪酬的由来以及未来的空间,也让潜在的应聘者一目了然了解可能的薪酬范围。

所有同事的薪酬以及发给候选人的 offer 都严格遵照这个标准。我们有可能不定期地调整各类职位的基数以适应公司发展的不同阶段并保持竞争力。由于这样的调整是整体的,所以不会导致倒挂等问题。另外由于影响最大的因素是 function 和 experience,这个公式也保留了足够的灵活性。比如一个很资深并作为项目负责人的工程师薪酬完全可能达到或超过 VP 和 C-Level 级别的管理者。

任何制度都会经历在实践中完善的过程,我们会根据反馈在发展中不断地完善这个薪酬体系。

转自http://open.leancloud.cn/salary.html