下半场的面试是下午1点开始的（客户时间晚上8点），主要是问项目/Team管理和沟通方面的问题，主要问题如下：
- Give examples (include the documents in reply) of Architecture document/Design Document/Code Review feedback/Status report
客户要看我们日常项目里的文档，这个没什么问题，因为平时项目都是有的，我只是把Code review的文档做了一些详细讲解，比如两轮review+错误分级和优化分级，然后把平时发给客户用的日报和周报也都展示了一下，但是在后面展示给面试官看架构文档和设计文档的时候，我特地说了一句，这个文档我现在不能传给你，因为牵涉到之前的客户信息，由于我们公司不允许把每一个客户项目相关的任何内容公布，所以如果想看的话，我要把一些信息加工屏蔽处理以后，才能发给你一个大纲，客户表示满意，因为他说了句：恩，我们的项目也是需要保密的。
- How do you estimate work?
估时这个问题相对来说，比较宽泛，如果按照自己的绝对坚持的方式告诉客户，很有可能和客户的预期不一致，所以我的大体答复如下：
在真正做需求分析之前，估时的话，我一般是参考历史数据来估计，主要是包括之前是否做个相似的系统或者子模块，或者是公司是否有现成的系统或者子模块的解决方案可以直接利用，然后再参考一些特殊的要求给出一个预计。
在做需求分析之后估时，一般会按照up2down的方式，也就是将系统细分成子系统，子系统细分成子模块，子模块细分成子function，然后逐一估计，另外我也会让Senior（或者我的backup）给出自己的估时清单，最后会进行比较，然后对有较大差异的部分进行重新估计与讨论，以便最终达成相对的一致。
另外，我也列举了一般估时需要考虑的点：
1. 项目大小以及项目难易程度
2. 客户或公司的特殊限制约束
3. 每个Level的工程师数量以及Skill的能力
4. 开发步骤，每个步骤大概需要多少天（调研、分析、原型设计、架构、详细设计、编码、测试、bug修改、维护）
5. 交付物的数量（即客户需要什么样的交付物，因为不同的公司可能需要不同的交付物文档）
6. 会议、沟通、培训、Travel的时间
7. 有无任何可以重用的组件或者解决方案
8. 项目风险（CR，离职，换人等）以及Buffer
- What, in your opinion, are the roles and responsibilities of a tech lead?
我的答复：主要职责是项目和技术分析，方案决策，task assignment, schedule, scope, quality, technology and communication等，有时候，TL就是一个manager，因为他需要跟踪和控制项目的进度，找出项目风险然后避免这些风险，有时候又是一个BA，因为他需要有一个好的知识去完全理解客户的需求，所以说TL也是架构师和开发人员之间一座非常重要的桥梁，另外，TL也应该是一个技术决策者，在合适的时机做合理的决策，同时TL也在平时也应该负责整个Team的培训工作。
- What are your strengths? What are your weaknesses? List 3 of each.
在列举优势和劣势的时候，优势肯定要是优势，劣势也得时优势才行，当然你不能太明显了，我的答复如下：
优势：
1. 很强的IT背景和分析的能力
2. Team管理经验和项目交付方面有很多经验
3. 擅长沟通（从客户/公司到Team，从Team到公司/客户)
劣势：
1. 对项目成员要求非常严格（比如所有的文档必须用我指定的统一的模板，成员一般都喜欢flexible的风格）
2. 做Solution review的时候，太注重细节（经常在做决策的时候浪费不少时机）
3. 经常开会（但开发人员一把都讨厌开会太多的会）
- Describe the size and structure of your most recent team that has reported up through you.
主要还是想了解我最近的项目的结构和大小，以便确保我能否胜任他的工作，我按实际情况回答如下：
1. BA:2个
2. 架构师: 1个
3. C#开发组:9个（1个Lead，6个高级，2个中级）
4. BI开发组:8个（1个Lead，4个高级，3个中级）
5. C#测试组:7个(1个Lead，6个测试)
6. BI测试组:6个(1个Lead，5个测试)
- Give an example of how you’ve dealt with a conflict or issue and how it was resolved.
这个问题，刚开始还是以技术背景来理解的，后来想了想，应该是以管理背景来回答这个问题，首先，应该先找到问题的原因，然后列出关键点和对当前项目带来的风险，然后提供至少2个解决方案，同时给出每个解决方案的优缺点，最后会根据issue的重要程序和影响的大小来决定最终使用哪个方案。
给出的例子，就是上个项目里遇到的，当初客户要求用Windows服务+Access数据库的形式来部署到100个×××门店上，后来实施部署的时候发现部分程序的门店使用的是SQLite数据库或是Excel表。后来我们只用了4天就解决了支持多数据库源的问题，首先我们原因是发现了，然后列出了修改这些程序的风险和方案，后来结合客户的要求，先部署可以部署的程序，程序升级以后在通过我们的自动升级机制来升级成通用版本，当然这也得益于IOC这种技术的帮助，不过这个4天的时间依然在我们的Buffer之内，并且我们的代码也能很好的支持其它的数据源了。
- How do you assign work items to your team members and how do you track their progress?
由于很推崇敏捷，所以我们的开发一部都是按照2周为一个Sprint，所以每个Sprint我们都有明确的工作计划，明确了我们应该做什么，有什么样的交付物，另外分配任务的时候会根据不同的level的人给不同的任务，谁熟悉那一块就尽量做那一块，当然以便我们可以高效地利用时间，另外优先级比较低但是也比较重要的任务也会让middle的人去做，不过通常我都会指定一个Senior的人做他的mentor.
关于项目跟踪，我们一直使用的是DailyScrum的形式来监控进度，通过跟踪4个事情来确保项目处在合理的轨道：你今天做了啥？/你正在做啥？/有没有任何问题需要别人的帮助？/明天的计划是什么？，当然在问这些问题之前，他们还有一定的时间去做pair review的。
- How do you measure and monitor the quality of the code delivered by your team?
我的Team在质量控制方面一般分位2部分：
1. 任何设计和方案无论大小，在Coding之前必须经过review和approved以后才能开始，
2. 所有的task都要进行2轮的Code review，第一轮是编码中期，以确保方案理解是否正确，第二轮是编码结束以后。
同时，所以的bug都要进行逐一分析和总结教训，一般下一次不再犯类似的错误。
- When and how do you escalate design, technical implementation and quality issues to Onsite tech team?
答复如下：工作过程中，如果我们在设计，技术或者issue上做出决策的话，我们会发生邮件给Onsite寻求帮助，不过在寻求帮助之前，我们会至少提供2个方案，列出每个方案的优点和缺点，告诉我们比较倾向于哪个方案（以及为什么），方案包括分析结果、技术方案、估时、风险等，在offshore经过充分的讨论以后，会发给客户寻求帮助。（注：千万不要说，我们只要不懂，就发邮件问客户，因为客户出出钱让你干活的，不是来培训你的，充分提供资料给客户，让客户做决策是个好主意，因为客户了解的自己公司的东西远远比我们多）
- How do you transfer the knowledge to new team member?
在如何向新人transfer方面，一般刚开始会有一个high level的培训会议，然后show一些重要的PPT给他一个整体的讲解。然后每天会给新人提供很多文档用于学习，每个文档都会有一些key point一般他能否很快速的了解相应的业务知识，第一个月，我们有每周一次的check meeting来检查他的学习状态和学习结果，以便确保他能理解这些东西，当然也会回答他各种各样的问题，与此同时，如果我们发现有一些东西需要更新或者通过新人提问也让我们发现有些东西需要加进去的话，我们也会更新我们的文档。在学习结束以后，一般我们会分配1-3个简单的任务给新人，同时指定一个Mentor带着他做，以确保他能真正上手项目，并且熟悉我们的开发流程。
- How do you make sure members of your team are fully aware of functional and technical changes happening in your project?
如果让所有的人都知道需求变更，首先会把所有的CR发送给所有的项目组成员以确保所有的人都理解这个CR，然后所有的人都要对这个CR进行分析，以便确保这个CR到底和自己手头的活有没有关系或影响，如果有影响的话，自己的改动又会不会再次影响别的人；同时所有干系人都要提供针对这个CR的方案、估时和执行计划。
然后，我们会和onsite客户沟通我们的这些方案和计划，让他们来accept或者reject这个CR。
当然，我们也有自己的Traceability Matrix系统来跟着所有的需求变更，以便后期可以做分析总结，提示我们做分析、设计、架构、编码的能力，尽量在每个CR到来的时候不需要改动太多的代码。(其实还有一点作用，就是，万一出现问题，可以拿出来作为证据，因为这个系统里也记录了客户的邮件呢，嘿嘿，只不过这个一点没有告诉面试官)
- Do you support cross training your team members? Give us the reason why would you support or why you won’t.
交叉培训这一块，其实我本人是赞成的，因为每个人都有自己的强项和弱项，通过在项目过程中或者项目结束大家可以share各自的信息以便互相提高。
不过，对于交叉培训，我有2个理解，一个是同一项目组不同skills人的培训（比如CSS高手和JS高手互相培训），在这一个层面上，大家互相share的东西相对比较多，另外一个是不同项目组之间的交叉培训，比如DW BI Team可以向C#开发Team共享一些东西，C#也可以共享一些东西给他们，这个层面上，我本人不希望有太深入的培训，毕竟不是主业。
不管怎么说，交叉培训其实还是挺好的，因为可以让每个人或者每个项目组都有一些提升。
再回答完这些问题的时候，其实基本上已经过了3个小时了，因为冲突可能因为印度式英文的理解上耽误了一些实际，但总体效果上还是不错的，充分表达了我想说的内容。
后面又大概聊了半个多小时，主要是问我平时是如何发邮件的，邮件里的To/CC/BCC都是怎么用的，以及如何给项目组成员作评价，如果想领导要特殊的支持等方面的软技能了，平时怎么做的，我也就按实说了。
最后，估计R先生也觉得问个差不多了，而且他也困了（已经是他的夜里快12点了），所以就说我们到此为止吧，还说会尽快给答复的，当然最后我也花了很多词汇恭维他，因为他从下午4点一直到夜里12点一直花时间来面试我：我很appreciate你花了那么多时间来面我，对我来说这是一个很excited的面试，你真的是一个很Nice的人，我真的很希望能做你的项目和你一起共事。
