标签：后端 路径 改变 hat 营销 思想 情况 遇到 task
一、你如何衡量软件工程师个人的工作表现？如何衡量整个工程师团队的工作表现？
主要从两方面：
任何绩效管理的最重要的前提就是针对这个人的合理期望达成共识，这里既包括显性期望和隐性期望。显性期望是指，要求对方在满足特定要求的情况下在规定时间内完成一个特定项目的交付。隐性期望是指，不管他们做什么项目，你对他们的表现所拥有的期待。
如果员工在负责开发一个功能，那么这里的“What”应该包括以下几个方面的内容：
这里的“How”应该包括以下几个方面：
你可以使用类似的方法来评估整个团队的表现。在评估团队的表现时，你可以问下面这两个问题：
二、你的工程团队成员的角色和职责分工是怎样的？你有指定专门的软件架构师或技术主管吗？
我首先需要说明的是，我不喜欢在团队中拥有指定的架构师角色或明确的架构师头衔。我认为，设计一个系统是所有工程师的责任，所有工程师都必须负责开发和维护这个系统，而不是让某一个个人或团队来专门负责并让他们在那光指挥别人做事而不自己亲自开发这个系统。
我知道这么说可能会得罪很多架构师领域的朋友，但是我还是要说。我之前在大公司里有过亲身体会。举个例子，Intuit 拥有一个非常强大的架构师团队，也拥有非常成熟的架构师职业发展通道，我知道这群人中有一些非常出色的人才，包括 Intuit 现在的首席架构师。然而，Amazon 是没有架构师这个职位头衔的，作为一个工程师，你可以走 IC 这个职业发展通道，或者技术管理的职业发展通道，不管你选择哪一种，你都需要能够负责设计非常庞大和复杂的系统。
我打造和运营的每一家公司和每一个团队采用的都是第二种方式。当然，任何时候都需要有人来负责架构方面的责任，但我希望这个人是工程团队的一名能自己亲自写代码的成员。
现在再说说技术主管。在我看来，“技术主管”应该是人们所应承担的一个职责，而不应该是一个具体的职位等级。
对于我自己而言，技术主管意味着需要在一个项目上领导其他工程师（而不是单纯的人员管理工作），既要在技术决策上发挥领导作用，也要在不同成员之间的分工协作上发挥领导作用。
我不认为必须要达到一定的职位级别才能成为一个项目的技术主管。例如，只要有能力，即使是一名只有一年工作经验的工程师也可以领导一个由一个或多个工程师/实习生参与的项目。我的团队中也有一些经验非常丰富的优秀工程师，他们是思想领袖和专业领域的专家，但是却不喜欢去领导其他人。因此，尽管技术主管中更多的是那些更资深的人员，但技术主管本身并不是一个职位等级。
在 LendingHome，我们在公司内确定了不同的职位级别，并定义了每个级别所要承担的角色和职责。在这方面，我们一直努力与行业的通常做法保持一致，这样我们公司的职位级别和头衔也能适用于其它优秀的科技公司。我们公司提供了两条职业发展路径：一种是 IC 职业发展通道，另一种是技术管理职业发展通道。这样你可以在不用做管理人员的情况下也能继续在公司得到成长和晋升。
如果走技术路线，我们公司的工程师等级分为工程师、资深工程师、高级工程师、首席工程师、高级首席工程师、杰出工程师、高级杰出工程师。在级别上，他们与经理、高级经理、总监、副总裁和高级副总裁是平行的。你在任何一个级别上都可以扮演一个首席架构师或技术主管的角色。实际上，我希望每一个技术主管都能负责他们手里项目的架构工作。
三、你用来确定产品优先级的流程是怎样的？
每一年，我们在公司层面只设定少数几个关键目标。然后根据公司的宏观目标，每个业务线为自己制定未来 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 来负责公司的所有产品工作的公司而言，下面是我的建议。在公司发展初期，CEO 自己通常是公司的首位产品经理。随着公司规模的发展壮大，其他一些人开始以兼职的形式分担部分产品工作。在创业公司，首先发展壮大的通常是工程师团队，CEO 会与工程师团队紧密协作。如果公司里没有一个技术联合创始人的话，这时公司首先招聘的通常是一个技术 VP。招到技术 VP 后，CEO 可能会招聘一个全职的产品经理来做一些产品战术方面的工作，比如制定产品说明书、与工程师协调等等，产品路线图和产品愿景还是由 CEO 亲自把控。在这个过程中可能会陆续加入几个产品经理，进而组成一个松散的产品团队，这个团队需要直接向 CEO 汇报。
这时，CEO 应该认识到，除了产品工作外，自己身上还要肩负起很多其他职责，这时他们必须认识到必须要招聘一个产品 VP 了。通常情况下，很多 CEO 都是被迫做出这个决定的，因为他们通常认为自己是会一直负责产品方面的工作的。
如果你是公司 CEO，面对需要招聘产品 VP 的情况时，你必须回答这样一个关键问题：新招聘的产品 VP 是只需负责执行 CEO 的指示、管理产品功能和产品经理团队？还是需要让他来整体负责产品愿景的把控和产品路线图的制定工作？
这是一个很难回答的问题，你对于这个问题的答案将决定需要招聘什么样的产品 VP。作为 CEO，你不应该自己独自做这个决策，你需要向你的董事会、投资者、团队中你信任的成员征求意见。让大家群策群力，看看究竟是什么样的产品 VP 才是真正满足公司的整体发展需要的。
八、你用来管理技术债的框架是什么？
在很长一段时间里，公司增长得非常快，也开始受到很多资源方面限制，因此，我们积累了大量的技术债务。所以我们已经重构了系统的几个部分。是否要对系统进行重构，从而偿还技术债，主要要看以下几个方面：
然而你还需要问自己下面这几个问题：
随着时间的推移，我们越来越擅长评估这些问题，但并不是总是有一种可行的方法。举个例子，我们现在正在重写一个项目，我想让团队并行地构建一个新系统去彻底替换旧的系统。因为如果对原有的系统进行循序渐进地改进，会花费太长时间，而且整个过程会让人感到非常痛苦。于此同时，我们还有一些正在进行的技术改进项目，循序渐进地改进一些现有的系统。
九、你是否曾在面试过程中使用过编码测试？如果有，具体是怎么测试的，为什么使用这种方法？
我们确实在面试过程中使用了编码测试。我们对编程语言没有限制，候选人可以选择任何语言编写代码。我们想要评估的是：
进行编码测试的时候，需要设置一个场景问题，这样我们就可以评估应聘者是否能有效地解决问题。
十、在一个技术经理招聘比他自己更有经验的人的时候，你有什么建议？
理想情况下，你雇佣的每一个人都应该在某些方面比你做得更好。这也适用于招聘比你经验更丰富的人。在招聘比你经验更丰富的人时，你需要考虑的主要问题是你如何为他们增加价值，以及你将如何从他们的经验中受益。
了解这个人在哪方面能够为你带来价值，以及他能从你这里得到什么帮助。例如，他们可能是在技术上比你更好的工程师，在设计和构建复杂系统时不需要你提供任何帮助。但是，他们可能没有你了解公司业务的相关背景、公司的客户等。你可以通过帮他们更快地熟悉所有这些东西来增加他们的价值，这样他们就能更好地完成工作。类似地，你也可以帮助他更好地了解公司的组织架构，从而更快地改善他们与其他团队的协作。
所有这些点在面试过程中就应该提到，而不是在他们接受了这份工作之后才告诉他们。当他们的这些需求和利益得到承认和满足时，说服他们加入就会更容易。
雇佣比你更有经验的人的最重要的方面在于你可以从他们那里学到东西。一定要保持一个开放的心态，并对能从他们身上学到知识表示感谢。相信我，当你向他们学习的时候，你仍然会给他们增加价值，所以不要担心这点。在我职业生涯中的很多时候，我总是不得不雇佣比我更有经验的人。我非常喜欢从他们那里学习，如果没有他们教给我的所有东西，就不会有今天的我。
标签：后端 路径 改变 hat 营销 思想 情况 遇到 task
原文地址：http://www.cnblogs.com/lurenjiashuo/p/7865370.html
