1. How do you measure the job performance of individual software engineers? How to measure the performance of the entire engineering team?
Mainly from two aspects:
- Is the employee doing the work he agreed to do or should do? (What)
- How do they do their job? (How)
The most important prerequisite for any performance management is to reach a consensus on the person's reasonable expectations, both explicit and implicit. Explicit expectation refers to requiring the other party to complete the delivery of a specific project within the specified time under the condition of meeting specific requirements. Implicit expectations are the expectations you have for their performance no matter what project they are working on.
If an employee is responsible for developing a feature, then the "What" here should include the following aspects:
- Is this feature performing well in production?
- Is this function developed according to the specification?
- Was this feature released on time?
- Can this function meet the needs of future scale expansion?
The "How" here should include the following aspects:
- Are they working well with other members of the team?
- Have they developed a system that is difficult to maintain by taking shortcuts?
- Have they followed all the right steps and developed a durable product that scales?
- Did they break other people's systems in the course of their work?
- Did they mentor others in doing their work?
- Did they learn something new in the process?
- Are they innovative and able to solve problems in an innovative way?
- Are they forcing previous solutions to be applied to new, completely different problems?
You can use a similar method to evaluate the performance of the entire team. Here are two questions you can ask when evaluating your team's performance:
- Did the team deliver the work they were supposed to deliver?
- Would you like to have them do similar work in the same way in the future?
2. What are the roles and responsibilities of your engineering team members? Do you have a dedicated software architect or technical lead?
Let me start by stating that I don't like having a designated architect role or explicit architect title on a team. I believe that designing a system is the responsibility of all engineers, and all engineers must be responsible for developing and maintaining this system, rather than assigning a certain individual or team to be responsible and let them just direct others to do things without developing the system themselves.
I know that saying this may offend many friends in the architect field, but I still have to say it. I have experienced it firsthand in large companies before. For example, Intuit has a very strong team of architects and a very mature career path for architects, and I know some very good people in this group, including Intuit's current chief architect. However, Amazon does not have the title of architect. As an engineer, you can take the career development path of IC, or the career development path of technology management. No matter which one you choose, you need to be able to design very large and complex systems.
Every company and every team I've built and run has taken the second approach. Of course, someone needs to be responsible for the architecture at any given time, but I want that person to be a member of the engineering team who can write the code himself.
Now let's talk about the technical lead. In my opinion, "technical lead" should be a responsibility that people should assume, not a specific job level.
For me, being a technical supervisor means leading other engineers on a project (rather than simply managing people), playing a leading role in both technical decision-making and the division of labor among different members.
I don't think you have to be a certain job level to be a tech lead on a project. For example, even an engineer with only a year of experience can lead a project with one or more engineers/interns, given the ability. I also have some very experienced engineers on my team who are thought leaders and experts in their field, but don't like to lead other people. So tech lead is not a job grade per se, although tech leads are more likely to be those who are more senior.
At LendingHome, we identify different job levels within the company and define the roles and responsibilities at each level. In this regard, we have worked hard to align with common practice in the industry, so that our company's job levels and titles can also be applied to other outstanding technology companies. Our company provides two career development paths: one is the IC career development channel, and the other is the technology management career development channel. This way you can continue to grow and advance in the company without being a manager.
如果走技术路线，我们公司的工程师等级分为工程师、资深工程师、高级工程师、首席工程师、高级首席工程师、杰出工程师、高级杰出工程师。在级别上，他们与经理、高级经理、总监、副总裁和高级副总裁是平行的。你在任何一个级别上都可以扮演一个首席架构师或技术主管的角色。实际上，我希望每一个技术主管都能负责他们手里项目的架构工作。
三、你用来确定产品优先级的流程是怎样的？
每一年，我们在公司层面只设定少数几个关键目标。然后根据公司的宏观目标，每个业务线为自己制定未来 6 个月的阶段性目标。然后，我们再制定符合半年目标的季度目标路线图。这些路线图就是我们定期冲刺的参照标准。就这样，公司整年的宏观目标被分解成一个个短期的目标。
制定路线图总是从每个产品经理开始，产品经理负责制定一个需要与跨职能合作伙伴一起协作完成的优先任务清单。我们将所有这些优先任务清单整合到一起，并创建一个我们希望在下个季度完成的整体优先任务清单。这个任务清单列表也包括我们上个季度延续下来的任务。
一旦我们就这些优先任务清单达成一致之后，产品经理与工程技术部门合作，对各个项目做大概的评估。工程技术部门也需要提供一个本季度的明确的工作目标。利用这种方法，团队可以进行有效的权衡，并制定该季度最终的产品工作优先级清单。这不是一个项目计划，而是一个我们想要完成的任务清单。
我们就从这个优先任务列表中选择任务分别进行冲刺，并在整个季度持续执行。我们努力在这里做足前期调研工作，这样我们就不需要在季度中途改变这个优先任务清单。但是，如果出现了需要修改的东西，那么我们就强迫自己对优先任务列表中的任务进行权衡取舍，而不是直接在列表中添加更多的任务条目。这说起来容易做起来难，但却是至关重要的。
四、如何让设计师完美地适应产品开发流程？如果能在项目早期就让设计师参与其中、同时又不会浪费设计师的时间？
在理想状态下，在公司业务的各项不同的产品工作中都应该有设计主管或指定的设计人员参与其中。这个设计主管应该在项目早期阶段就参与其中，这样他们就可以在整个项目进行的过程中从设计团队中为该项目获取所需的其它资源。
我们过去遇到的挑战是我们的设计团队中没有足够多的人员来肩负起这样的角色。我们的目标是建立起这样一种架构，让设计团队能尽早参与到所有项目中去。但是这也要看项目的性质，例如，我们不希望让设计师参与到一些专注于纯粹的后端服务和基础设施的项目中。但是另一方面，对于那些直接面向客户的项目，尤其是那些与品牌、营销和应用流程直接相关的项目，我们应该在项目刚开始的时候就让设计师参与其中，而且通常情况下都会有多个设计人员同时参与其中。
如果你已经将项目人员数量降到了最低，你就不应该担心浪费设计师的时间。
这里需要着重强调的一点是，我不认为设计是纯粹的外观和视觉设计。如果是纯粹的外观和视觉设计，完全可以等到项目后期阶段、在所有其它重要工作都完成之后再做设计方面的工作。对我而言，设计是一项非常宏观的工作，它涉及到几个方面的工作：交互、调研、视觉等等。要想不浪费设计师的时间，最好的方式就是在每一个阶段让合适的人员加入进来，而不是在每一个阶段让所有人都参与进来。例如，当需求还没有确定的时候，我是不会让视觉设计师参与进来的。但是，我会尽早地让交互设计师参与进来，因为他们可以在早期定义需求和解决方案的时候发挥很大的作用。
五、在打造工程技术团队的过程中，有哪些常见的错误想法？
常见的错误想法有很多，我这里主要强调以下三个常见的错误想法：
1、招聘最聪明的人，把他们放在一起，你就能组建一支高效的团队。
你应该始终努力招聘比你自己更聪明的人加入团队。但是，把一群聪明人放在一起不一定就能组成一支高效牛逼的团队。要想打造一支真正高效的团队，你需要一群真的愿意在一个团队中共事合作的聪明人，而且这些人需要关心团队的成功胜过自己的成功。
解决后面这个问题比招到聪明人要困难得多，而这也是决定你的团队能否成功的关键因素。因此光招聘一群聪明人是不够的。为了确保加入团队中的人都是具有团队合作意识的人，你可以在面试中使用 STAR 法则(Situation-情形、Task-任务、Action-行动、Result-结果)，因为你可以通过根据应聘者过去的行为表现来预测他未来的表现。如果一个应聘者在之前的工作中并没有表现出能够和团队成员很好协作的一面，或者没有表现出团队的利益和成功是高于个人的利益和成功的，这时，如果你招他进来，他在未来的工作中很有可能会有类似的表现。
2、只招聘那些与你自己或团队中其他人员很像的人员。
我曾经非常希望能够多克隆几个我团队中的一些非常出色的人员。幸运的是，对于我来说这个选项是不存在的。
因为，如果我真的克隆了很多团队中最出色的人，让团队中的所有人都差不多，这只会让团队丧失想法的多样性，最终丧失了所有的创新能力。经验和思想的多样性是激发新的、创造性的解决方案的源动力。从长远来看，一个多元化的团队将会变成一个更好、更强大的团队。
3、将一群聪明人放在一起，他们就能解决任何问题。
很抱歉又强调了一遍这个问题，但是在某种程度上，这确实是事实。聪明的人喜欢解决富有挑战性的问题，他们往往会能够想出一个非常不错的解决方案。但这并不是打造一个强大团队的基础。其中的关键不仅仅在于找到一群聪明的人，同时要确保这些人是真正有激情去解决你要解决的问题的。如果这些人对要做的工作缺乏真正的兴趣和热情，你可能在早期阶段还能将工作完成的不错，但是从长远来看，你最终面对的将是一个个无法全身心投入工作的员工和一个表现不佳的团队。
六、你面试工程师的流程步骤是怎样的？你为什么认为这样的流程步骤很重要？
我们在 LendingHome 采用的工程师面试流程是非常直接的。第一步，面试官可能会对候选人人做一次电话面试。是否进行电话面试取决于：是我们在积极挖一个比较被动的候选人，还是候选人在积极地申请应聘我们的岗位？如果是前面这种情况，我们就不会进行电话面试了。如果是后面这种情况，我们可能要做一轮电话面试。
最开始要进行一轮电话面试筛选，主要有两个目的：
- 为候选人提供有关我们公司和相应招聘岗位的相关信息。
- 评估候选人的解决问题能力和编码能力。
通过电话面试的候选人将会被邀请参加最后的现场面试。现场面试有有几轮，要持续一整天时间，需要和 6 个面试官面试——3 个工程师、2 个技术经理(我们会从总监、经理、VP、我自己和首席技术官中选取两个人)和 1 个产品经理。我希望每一个工程师招聘小组里都能有一个非工程师人员，这样我们在招聘中就能获得一个完全不同的看待候选人的视角。
在现场面试中，我们要考察的内容包括专业能力、领导能力和行为技能。专业能力考察内容包括架构、系统设计、解决问题的能力和编码能力。我自己非常喜欢使用 STAR 法则来评估候选人的非技术方面的能力。
每一位面试官在面试结束后都需要在面试追踪系统 Greenhouse 中填写对应聘者的详细评价和反馈。采用的是匿名评价的方式，这意味着你在评价之前是看不到其他面试官对应聘者的评价的。然后，我们会在应聘者现场面试结束后的当天，对每一位候选人进行 30 分钟的总结评估，并决定是否给该候选人发 Offer。如果决定给 Offer，我们就会尽快给候选人发出 Offer。
七、什么时候招聘产品 VP 合适？招聘什么样的产品 VP 合适？
这个问题主要看公司的发展阶段，以及你想通过招聘一个产品 VP 来解决什么样的问题。根据公司和技术团队规模的不同，产品 VP 的职责也会有所不同：
- 在一家大公司，产品 VP 可能只负责一个特定业务线的产品工作。
- 在一家小公司，产品 VP 可能会负责整个公司的产品工作。
要问答上面这个问题，需要根据各个公司的不同情况。对于那些想招聘一个产品 VP 来负责公司的所有产品工作的公司而言，下面是我的建议。在公司发展初期，CEO 自己通常是公司的首位产品经理。随着公司规模的发展壮大，其他一些人开始以兼职的形式分担部分产品工作。在创业公司，首先发展壮大的通常是工程师团队，CEO 会与工程师团队紧密协作。如果公司里没有一个技术联合创始人的话，这时公司首先招聘的通常是一个技术 VP。招到技术 VP 后，CEO 可能会招聘一个全职的产品经理来做一些产品战术方面的工作，比如制定产品说明书、与工程师协调等等，产品路线图和产品愿景还是由 CEO 亲自把控。在这个过程中可能会陆续加入几个产品经理，进而组成一个松散的产品团队，这个团队需要直接向 CEO 汇报。
这时，CEO 应该认识到，除了产品工作外，自己身上还要肩负起很多其他职责，这时他们必须认识到必须要招聘一个产品 VP 了。通常情况下，很多 CEO 都是被迫做出这个决定的，因为他们通常认为自己是会一直负责产品方面的工作的。
如果你是公司 CEO，面对需要招聘产品 VP 的情况时，你必须回答这样一个关键问题：新招聘的产品 VP 是只需负责执行 CEO 的指示、管理产品功能和产品经理团队？还是需要让他来整体负责产品愿景的把控和产品路线图的制定工作？
这是一个很难回答的问题，你对于这个问题的答案将决定需要招聘什么样的产品 VP。作为 CEO，你不应该自己独自做这个决策，你需要向你的董事会、投资者、团队中你信任的成员征求意见。让大家群策群力，看看究竟是什么样的产品 VP 才是真正满足公司的整体发展需要的。
八、你用来管理技术债的框架是什么？
在很长一段时间里，公司增长得非常快，也开始受到很多资源方面限制，因此，我们积累了大量的技术债务。所以我们已经重构了系统的几个部分。是否要对系统进行重构，从而偿还技术债，主要要看以下几个方面：
- 在系统不断规模化扩展的过程中出现的问题数量。
- 维护这个系统的复杂性。
- 需要将这个系统分解成独立的、更易于管理的服务或系统。
- 由于系统中存在太多的相互依赖的地方，因此无法快速开发系统中的某个部分。
- 现有系统无法满足日益增加的业务复杂性。
然而你还需要问自己下面这几个问题：
- 如何平衡好“为了使业务向前发展而需要开发新的功能” 与 ”对可能不会立刻带来明显效益的系统进行重构“这两者的关系？
- 你在这两个方面投入的资源占比分别是多少？
- 你是会在不影响系统正常工作的情况下对其进行循序渐进地改进，还是会重写系统并彻底替换原有系统？
随着时间的推移，我们越来越擅长评估这些问题，但并不是总是有一种可行的方法。举个例子，我们现在正在重写一个项目，我想让团队并行地构建一个新系统去彻底替换旧的系统。因为如果对原有的系统进行循序渐进地改进，会花费太长时间，而且整个过程会让人感到非常痛苦。于此同时，我们还有一些正在进行的技术改进项目，循序渐进地改进一些现有的系统。
九、你是否曾在面试过程中使用过编码测试？如果有，具体是怎么测试的，为什么使用这种方法？
我们确实在面试过程中使用了编码测试。我们对编程语言没有限制，候选人可以选择任何语言编写代码。我们想要评估的是：
- 他们是否能写良好可行的代码？
- 他们是否能正确地解决手里的问题？
- 他们是否能进行良好的测试？
- 如果代码中有问题，他们是否会接受反馈？
进行编码测试的时候，需要设置一个场景问题，这样我们就可以评估应聘者是否能有效地解决问题。
十、在一个技术经理招聘比他自己更有经验的人的时候，你有什么建议？
理想情况下，你雇佣的每一个人都应该在某些方面比你做得更好。这也适用于招聘比你经验更丰富的人。在招聘比你经验更丰富的人时，你需要考虑的主要问题是你如何为他们增加价值，以及你将如何从他们的经验中受益。
了解这个人在哪方面能够为你带来价值，以及他能从你这里得到什么帮助。例如，他们可能是在技术上比你更好的工程师，在设计和构建复杂系统时不需要你提供任何帮助。但是，他们可能没有你了解公司业务的相关背景、公司的客户等。你可以通过帮他们更快地熟悉所有这些东西来增加他们的价值，这样他们就能更好地完成工作。类似地，你也可以帮助他更好地了解公司的组织架构，从而更快地改善他们与其他团队的协作。
所有这些点在面试过程中就应该提到，而不是在他们接受了这份工作之后才告诉他们。当他们的这些需求和利益得到承认和满足时，说服他们加入就会更容易。
雇佣比你更有经验的人的最重要的方面在于你可以从他们那里学到东西。一定要保持一个开放的心态，并对能从他们身上学到知识表示感谢。相信我，当你向他们学习的时候，你仍然会给他们增加价值，所以不要担心这点。在我职业生涯中的很多时候，我总是不得不雇佣比我更有经验的人。我非常喜欢从他们那里学习，如果没有他们教给我的所有东西，就不会有今天的我。