写本文的目的，大叔不是为了装逼（虽然说话的口气有时候也确实有点装逼，性格导致的，咳。。。我得改），其实大叔在公司也只是小罗罗，本文的目的主要是为了向大家展示如何通过各种软技能应对面试官，这个应对包括如何沟通，引导，展示技巧以及更多地让面试官跟着你的思路走，让面试官根据你的亮点挖掘你其它的优势，而不是一味地跟着面试官的思路走（这就有点危险了），也就是如何更多地展示你强的一面而尽量避免暴露自己的弱点，尤其是Senior和Lead在面试的时候需要注意这一点，当然，这确实需要下很多功夫，那就体会一下大叔在去年的一次面试经历吧。
起源事情起源于一个2010年11月12号（周五）的一个电话，下午刚吃晚饭被部门领导叫进一个小会议室说有事找我谈谈，大概事情是欧美一个大客户要在北京总公司建立第2个ODC（离岸研发中心）（第1个ODC已经在公司的另一个分公司建立了1年多了大约400人），这次面试很多高级开发工程师都已经面过了，但是客户就是不给签约ECA（个人另外和客户单独签的安全协议），原因是ODC的技术带头人一直没招到，公司提供了大批的架构师、Tech Lead、以及懂技术的项目经理去面试，都栽进去了，所以让我去试试，说一会公司的高级副总M先生马上就打电话过来。
在1万多人的公司工作，能让VP亲自打电话，其实心里还是蛮激动的，但其实大叔是不愿意去的，因为当时手头的项目也是很不错的，做亚洲最大的KTV连锁系统相关的东西（数据实时采集，商业智能分析，以及后期全新开发的WPF版的KTV点播系统），下面30多人，其实也挺不错的，主要是有了孩子，所以想先稳定2年。可是M先生打来电话了，大意就是客户面试比较严格，视频会议以及远程桌面现场编程，这就意味着，面试个过程中客户不仅可以看到你的表情和心里，还要通过远程桌面在你现场编程的时候看到你每敲的任何一个字母。很多人技术很强，但是印度式英语沟通上，或者代码编程细节上，甚至MSDN查询的细节上都有可能被客户challenge住，公司已经浪费了几个月时间，而且也浪费了大批的优秀候选人，客户给了deadline，如果没有满意的人，客户有可能就把这个ODC建立到欧洲那个公司了，所以希望我去试试。虽然我不情愿，但是在领导近于命令式的语言以及一大堆的憧憬中，大叔也没有办法，尝试着说先给我一周时间准备吧，因为我已经1年多没有进行编程了，但领导说，事情紧急，就下周一吧，给你两天准备时间。在坚决地拒绝以后（因为周一要去国贸客户现场讲解新项目的架构，所以没办法），面试终于选择在周二早上8点进行。
其实周一下午公司的人还是给予了一些面试指导，毕竟所有的人都很看重这个事情，尤其是和客户沟通方面需要注意的事情以及稍微了解了一下客户的脾气（因为之前有个人很坚持自己的方案牛逼，不愿意听从客户的方案解释，所以被fire）。
虽然之前有过和印度人共事的1年多经验，但是依然有点怯，连通视频我一瞬间，大叔惊愕了，面试官居然是Martin Fowler的翻版：
（Martin Fowler头像， 我的偶像啊！）
不过人还是挺友善的，在刚开始的5分钟，我主要是做个人介绍，大概介绍了一下最近2年做过的项目，和承担的职责，其实客户对这个不太感兴趣，他们感兴趣的是现场面试，so, 我说了一句：我准备好了，我们可是开始了么？客户来劲了，视频里说了一下题目，同时Live Meeting里也把英文题目发过来了（可能是怕听不懂吧），题目非常简单：找出第一个句子中有而第二个句子中没有的单词。
我很诧异，面试不会这么简单吧，就算我1年多没写过代码了，完成这个题目也是不成问题的吧，可是回过头来一想，我面的职位不是高级开发，也不是架构师，而是技术管理，于是我明白了。。。
客户：这时候客户直接问我要estimate估时了
大叔：这个时候我并没有告诉客户说，我需要时间先分析一下，问完问题才能给你时间，而是直接告诉他，我还没用细想，但是我觉得大概的乐观（optimistic）估时应该是1小时（其中包括，5分钟的思考，5分钟的问题确认，5分钟的设计，25分钟的编码，10分钟的code review以及10分钟的测试和bug fix），但悲观估时可能是1小时20分钟左右，因为冲突可能会出现无法预知的问题需要客户或者相关人的帮助。
客户表示Good。那就开始吧，滴答，滴答，滴答。。。。
在考虑了一系列的常见的和特殊的场景以后，我问了很多问题，但总时不超过5分钟，大概如下（记不太清楚了，就写这么多）
- 非英文下如何处理
- 数字等算不算单词
- 输入输出形式如何
然后又诚恳地问了一下，英文下除了逗号，句号，空格，问号，斜杠，感叹号以外，还有其它的语言符号么？（因为要用这些分割单词哦），客户比较开心这个问题，又告诉了我几个：反斜杠，引号，又特别提示了一下我，中划线不算分隔符。 中途也遇到了一点尴尬，就是对这些符号的英文单词，记得不是很清楚，所以老搞错，最后客户还是直接在live meeting上敲出才确认的，感谢IM。
编码正式开始了，其实中途的编码过程到时没什么问题，因为题目确实比较简单，但是代码总不能都在控制台的Program.cs吧，也不能只写一个简单的静态方法吧？题目虽然简单，不能体现什么架构，但是要展示点东西吧，于是一个有点搞笑的类文件InterviewEngine.cs出来了，但这时候，我并没用急于写代码，而是把我的代码处理逻辑的想法用英文写在这个类的summary里了，写了大概5分钟左右（这就姑且算我的设计吧），然后代码上，写了一个单例（有点不伦不类，后面会解释）（静态字段+静态构造函数的方式），当然在正式处理方法里也仔细考虑了很久，比如2个参数的空值判断，异常判断，以及分隔符的定义易修改等做了处理，当然中途我故意把字符的大小写没用区分（因为我想在后面的code review阶段来体现），当然该有的注释啥的也都有。
北京时间早上8:45（客户时间：下午4:45）代码结束，为了表明自己真的做了code review，自己还是硬着头皮把键盘提示符一行一行地走了一遍，以便让客户在编辑器里看到我真的是在做这件事，因为code review是项目里非常重要的一步，也为了证明我做了，我在这时候才把上面故意没用区分大小写的问题加上了。
由于不是按照TDD的方式来做的，所以单元测试是在基本的code review以后才开始做的，由于之前和客户确认了，不用使用MBUnit/NUnit之类的单元测试工具，所以只是手工写了一些case，做的case不仅包括了正常的，也包括了不正常的了，当然边界测试，空值测试，异常捕获等也都覆盖到了。（后面项目开始的时候，客户由于知道我熟悉MBUnit，所以在项目上让我们用了这个，而没有用其它人都推崇的NUnit）。
时间比我预想的提前了5分钟，暗自庆幸中，于是告诉客户，我已经写完了，当然也客气的说了一句：“你能帮我check一下，有没有其它的我没用想到的错误么？”。
"Okay, Tom...."，客户舒了一口气说，你再检查一下获取单词集合的时候有没有什么遗漏？我实在想不起来遗漏了哪个判断，参数判断，单词萃取，单词存储，查询性能等都考虑到，只有虚心而真诚地请教了客户：“I cann't find any problem now, could you give me some comments?”
客户这时候在IM上敲了一句话：Hello, tom, how are you？
OK, God，我明白了，原来是分隔符连续的问题，这时候分割出来的单词是空，所以这时候不需要在去判断集合里是否包含这个单词了，因为空根本就不需要添加到集合里。我对客户的提示表示感谢：“Oh, good catch, thanks R****.”，然后很快给予了修复，并且添加了相应的测试用例。
客户对题目表示满意，本意为面试就要结束了，但是客户这时候又给了一个需求变更，让我在现有控制台程序的基础上做一个方便测试代码，经过互相讨论，最终的理解是：做一个控制台的输入功能，让用户分别输入2段字符串，然后给出结果，在这一步，我差一点栽了，因为对Console.Read，Console.ReadLine以及Console.ReadKey的用法实在想不起来了，再试了很多次之后，才搞定的了，以至于客户问了我一句：你是不是这些知识已经忘记了，我只得遗憾地回答：“是的，长时间不写类似的程序，很多基本的东西都忘记了，看来需要经常来回顾一下用法。” 没想到，客户说了一句：“对，我也是经常忘！”
哈哈，看来没丢脸。
北京时间早上10:00（客户时间：下午6:00）客户又问了一下，我平时编码的时候是如何保证质量的？我会意的笑了一下，我说我有T氏法则，也就是我整理的Guideline，所有Team的人都要遵守，Guideline里囊括了开发过程中要预防的各种各样的问题，比如输入输出验证，编码，性能，加密解密，信息安全，客户端安全，多条件，多线程，异常处理，资源释放，代码覆盖率，单元测试等等，还顺便问了一句，你要看么？因为我现在用的是自己的机器，可以发给你一份。
客户表示想看，看了我发的英文版以后，客户表示：你在我们这里干的话，我想你的很多条规则都是可以用上的。
之后客户又突然回来，问我为什么面试的时候要用单例，我很诚实地回答，因为面试时间有限，所以我要想办法体现我的各种各样的能力，然后我们俩又针对单例讨论了很久钟，期间我讲我了解的单例模式，然后所有的实现都在VS2010里用代码展示给他了,最后，我连把单例的泛型版本都展示给他看了，他表示赞许，因为我在视频里看到他点头了。
面试持续了2个多小时了，因为很自信自己在设计模式方面的理解，所以为了抢占主动权，所以我豁出去地说了一句：你还想问我其它的设计模式么？
R先生：不用了，看你对单例研究这么深入，我觉得也没有必要再问其它的设计模式了，因为我相信你肯定也很熟悉了，而且你的职位又不是开发人员，而是要Manage他们，好了，你能再把你之前的工作经历详细地和我说一遍么？
有戏了，客户居然再次让我介绍之前的项目了，于是把自己之前的几个项目介绍了一下，由于之前的项目都不小（第一个项目，26人做了2.5年，第二个，16人做了1年，第三个34人做了半年），客户了解了我的职责以后，什么都没有说，只是说了一句，我们的项目和第一个差不多，你应该能够cover住的，技术面试这里就先结束了，1小时以后我们继续来聊非技术的吧，因为我要先回家吃饭（因为这时候已经是客户时间晚上7点了）。
什么？！！这才是上半场？下午我还要和我Team的人开会布置任务呢！！不过还是礼貌性地说了一句，感谢你的面试，我的准时上线的。
在这里，其实我自己感觉，技术面试这一关其实应该是八九不离十了，因为从和客户沟通的效果来看，基本上都是赞许，下半场还没开始，所以我在这里先总结一下我的面试体会：
1. 要有非常明确、规范、令人信服的整体结构。所以对代码分块很重要，同时这也是我们很容易疏忽的地方。各块代码的功能如下：
Block 1：描述性的注释。首先把题目放到注释里，让reviewer知道你现在做的是哪道题；其次是要对题目进行简短的分析，让reviewer了解你的思路，节省他阅读代码的时间；再次是提一下你将用到的关键技术以及你的concern。比如说你现在是按小文本的输入写出的最好的代码，但如果是大文本输入，需要更改逻辑。这主要体现出一个人的沟通能力。不管你自己知不知道该怎么做，首先要想到的是让对方知道哪些是你能够应付得来的，哪些是你的问题。忌讳按照自己的假设去答题。如果条件不明确，需要你自己提出来。客户很喜欢别人跟他讨论，这样可以明确需求，减少风险和不确定性。客户也很喜欢别人有问题时马上提出来。总体来说，他们很能容忍你有问题，但不能容忍你隐瞒问题。
Block 2：自动生成的代码。这里最重要的是注意命名规则。根据需要增加一些注释也是很好的习惯
Block 3：代码的主体部分。方法前面加注释是好习惯。变量最好集中声明，显得比较整洁有条理。一定不能遗漏的是数据的合法性验证，健壮性是代码的重要指标之一。Good test case 和 bad test case 至少各有一个。程序的可扩展性也很重要，少用hard code。
Block 4：异常处理。一定要有。
2. 尽可能多地去显示你的能力。从客户的角度来说，他们也很欢迎candidate全面地去展示自己
1. 多用OO的概念去思考问题
2. 替客户去想他们自己都没有想到的问题，但不要天马行空。例如，Scalability就能很好地展示自己思维的缜密
3. 适当展示自己design的能力，这一点很重要。即使是很小的问题，也是需要全局把控的。
3. 一个很重要的观念需要candidates转变过来。客户面试的根本目的不是为了难倒candidates，而是为了给candidates一个展示自己能力的平台。所以对于客户给出的题目，应该用工作的态度去应对，而不是用考试的态度去应付。很多优秀的候选人给我们的感觉是：让他实际工作，他可能会考虑得很全面，而答题的时候，他就显得比较马虎，完成要求就算结束。原因大概就在这里。这样的结果是，别人只能看到他考试的能力，看不到他工作的能力。
技术上半场是技术面试，没有问到管理的问题，但是我也想办法体现了自己的能力，比如告诉客户我还是比较了解软件开发过程的，从需求分析，需求确认，设计，编码，Code Review，测试以及需求变更方便的东西，在估时方便有悲观估时也有乐观估时，同时在自我介绍的时候也通过项目的实际经验向客户灌输一些其实你懂很多东西这个观点。
客户相对来说是个比较容易沟通的人，在需求确认的时候就能看出来了，没有趾高气扬的架势，以至于后来我反而去表扬了他一句“Good catch”，所以，在任何面试的场合，只要沟通做到位了，其实技术差一点也无所谓，就像前面，我连Console.Read的基本用法都不会了，也没有什么事。
下半场的面试是下午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个KTV门店上，后来实施部署的时候发现部分程序的门店使用的是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的人，我真的很希望能做你的项目和你一起共事。
非技术面试总结
这一块面试，主要考察的是2部分，一部分是项目管理方面的东西，看你是不是能很熟练地管理项目，确保项目质量按实提交交付物，同时也考察了你如何和客户进行沟通规避风险，最后要问了一些软技能的东西，比如发邮件的时候，什么时候该To，什么时候该C，而又什么时候该BCC，以及和同事相处及评价的态度等方面的问题。
另外还有一点，我觉得也是非常重要，那就是面试官花了很多时间在你身上，在结束的时候你应该多感谢一下他，这样他会很开心，即便不要你，以后说不定还有机会呢。
结果通过了，终于让VP Happy了一把，之前pending的一批已经通过面试但不让签ECA安全协议的人也都陆续开始和客户签协议了，当然我也从原来的部门调到了新成立的ODC，同时原部门把自由互联的兄弟NewSea挖了进来，以便能够继续之前的工作，1个月交接以后，我就飞往西雅图，去客户现场进行Domain Knowledge的培训去了。
以至于，后来还没用交接完，客户就让我自己去招聘下面的Senior人选了，估计也是为了向他的老板汇报一下吧，所以，在找到合适的人选后，我的第一份正式的邮件，就这样发出了（文中的H*，也是自由互联的一个大牛哦，目前和我一个组，有机会和大家介绍一下）：
Hi J*** and R***招聘
We are having the candidate H*** who qualify from our interview, we would like get your approval on the hire recommendation.
Below is my feedback after talk with H***, please let me know if you have any concerns.
Thanks.
General feeling in the interview:
H*** is proactive on communication, he has a good communication, also he would like to focus on .net development and passionate about the ODC project.he is talkative and introduce a lot aspects of himself and showing interests in ODC project on the project size, working method, etc.
Strength:
He show a good technical background especially on OOP Design/javascript/asp.net areas.
Deep understand on .NET CLR and OOP Design.
He is confident on the asp.net/JavaScript, and self-learning capabilities.
Weakness:
Limited oral English, however he shows potential as their reading/written English is good.
Hire recommendation: Hire
另外，我们最近也在招人，有兴趣的请联系我，基本条件如下：
- 6年以上C#开发经验，熟悉MVC
- 熟悉JavaScript，熟悉前端开发
- 能通英语口语进行简单的沟通
- 崇尚敏捷开发
本文已同步至目录索引：《大叔手记全集》
大叔手记：旨在记录日常工作中的各种小技巧与资料（包括但不限于技术），如对你有用，请推荐一把，给大叔写作的动力。
【文章转自：美国站群服务器 http://www.558idc.com/mgzq.html处的文章,转载请说明出处】