技术面试指南

面试流程

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

面试中的沟通问题

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

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

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

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

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

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

面试中需要考察的问题

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

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

面试中应避免的问题

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

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

代码分支管理指南

介绍

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

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

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

branch 和 tag

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

Branch: masterrelease。其中 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
  • 删除旧的 releasebranch,并从当前的 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

Hadoop集群安装配置

最近需要做大数据的分析,研究了一下HADOOP,作为第一步,配置HADOOP集群是最基础的工作。这里简单记录一下流程。

一、配置每台机器的网络。包括修改hostname,hosts

二、配置每台机器之间的SSH免密码认证(注意.ssh文件夹和其内文件的权限)

三、配置防火墙

四、安装JAVA环境并配置环境变量

1
2
export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk
source ~/.bashrc

五、安装HADOOP并配置环境变量

1
2
3
4
5
6
7
8
9
# Hadoop Environment Variables
export HADOOP_HOME=/usr/local/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin
1
source ~/.bashrc

六、配置PATH变量(hadoop/bin和hadoop/sbin)

七、配置文件slaves、core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml

1、slaves内为slaves机器名

2、core-site.xml为

1
2
3
4
5
6
7
8
9
10
11
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://Master:9000</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>file:/usr/local/hadoop/tmp</value>
<description>Abase for other temporary directories.</description>
</property>
</configuration>

3、hdfs-site.xml,dfs.replication 为datanode个数,一般设为 3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<configuration>
<property>
<name>dfs.namenode.secondary.http-address</name>
<value>Master:50090</value>
</property>
<property>
<name>dfs.replication</name>
<value>3</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/usr/local/hadoop/tmp/dfs/name</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:/usr/local/hadoop/tmp/dfs/data</value>
</property>
</configuration>

4、mapred-site.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<configuration>
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
<property>
<name>mapreduce.jobhistory.address</name>
<value>Master:10020</value>
</property>
<property>
<name>mapreduce.jobhistory.webapp.address</name>
<value>Master:19888</value>
</property>
</configuration>

5、yarn-site.xml

1
2
3
4
5
6
7
8
9
10
<configuration>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>Master</value>
</property>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
</configuration>

八、复制主节点hadoop及配置文件到所有节点

九、初始化namenode

1
hdfs namenode -format

十、启动或关闭hadoop集群

1
2
3
start-dfs.sh
start-yarn.sh
mr-jobhistory-daemon.sh start historyserver
1
2
3
stop-yarn.sh
stop-dfs.sh
mr-jobhistory-daemon.sh stop historyserver

JPS 查看进程
hdfs dfsadmin -report 查看报告