面试.NET.doc

谈谈.Net技术面试 1、引子 最近一直在负责.net(B/S方向)技术面试相关的工作，前前后后面试了不少人，但是通过率较低，大概只有20%左右；有颇多感慨。最近也一直比较困惑，原因究竟是什么？是我们要求太高，应聘者本身的问题，还是是面试的内容本身的问题？2、我们的岗位要求 这是之前项目组整理的一个简单的岗位(.Net中高级职位)要求，贴一下： 必须技能： 有23年实际的项目经验（特别说明：工作经验不一定要进入实际的公司才能积累的） 思路比较清晰，有较强的独立解决问题的能力 熟悉b/s开发的各项基本知识（如css、javascript、html、），不要求全会，但至少能看懂别人写的东西，另外各项里面必须有一项较为突出； 对.net框架比较熟悉，熟悉多层模型，编码能力较强，编码规范，打字速度不能太慢（特别说明：这应该属于最最基本的技能，但是很让人不解的是面试过程中有不少的应聘者竟然尖着个手指头在那儿慢慢敲字!） 数据库知识比较扎实 优先考虑： 对web报表比较熟悉者 有过多种数据库开发经验，能够罗列出各种数据库之间的一些细微差别 有过一些c/s开发经验者 前端开发经验比较丰富者（如实际负责过ExtJS、JQuery、Dojo、YUI、AjaxPro相关工作的）3、使用的面试问题 面试过程中针对上面的岗位要求主要会涉及到以下几项内容 1）给10分钟左右的时间，做一个详细的自我介绍 2）C#、Asp.Net、前端、数据库等基础知识一般会问到以下一些问题 a) 下面三句代码有没有错，以inboxing或者unboxing为例，解释一下内存是怎么变化的 inti=10;objectobj=i;intj=obj; b) 编码题目， 如限定时间编码求菲波拉契数列第n项的值，求函数f(n)=1/1!+1/2!+1/3!+.+1/n!的值，求两个二维矩阵相乘的值等等； c) 谈谈对委托、事件的理解等等； d) 为什么控件能够保持住状态； button的客户端事件是如何映射成服务器端事件的；详细谈一下的管道模型； e) 下面css中“一段文字”最终在浏览器中显示什么颜色；如果用js原生脚本改变class为“xyz”该如何写，将“一段文字”替换成“其它文字”如何写等； .abccolor:red;#abccolor:blue;一段文字 f）谈谈ajax原理的了解程度以及目前业界流行的ajax框架的熟悉程度； g) 表结构： 成绩表（Grade），包含字段：GradeID（Int，自增）， SNO（int, 学号）， CNO（int, 课程号）， Score(float，分数） 查询每门课程的平均（最高/最低）分及课程号； 查询每门课程第1名的学生的学号； 查询每门课程中超过平均分的所有学生的学号等等；3) 设计方面的能力 a) 给出一些具体的应用场景，如多数据库支持、工资计算方式多样的情况，如何来设计； b) 谈谈对设计的理解； c) 偶尔还会让画画设计类型，写写代码实现常见设计模式（如单例模式等） 4) 解决问题的能力/学习习惯/个人特长等等 主要涉及到以下一些问题 让应聘者自己挑一个自己以往做过的他认为具有代表性的项目，详细聊一下，主要聊一下他/她在这个项目中的职责，这个项目曾经遇到过哪些问题，如何解决的，他/她在解决这些问题的过程中起到了什么作用等等。 给应聘者一个他目前不会的问题，让其解决一下； 课外时间都在干什么，常上的技术网站是什么，最近看的基本书（电子书当然也算）的名字还记得吗； 聊聊自己最擅长的方面；4、我期望得到的答案 当然上面这些问题不可能一次全部都问到，时间上也不允许，但是四部分的内容我会根据实际情况都会问到一些；时间一般在1个小时左右； 下面谈谈从项目组以及我个人角度出发希望得到的答案，希望能够给大家带来些许启示： 1) 首先是自我介绍部分 这部分的内容我本人之前被面试的时候也很是郁闷，认为：“我的简历都有了，你自己不会看吗，还让我再多说一遍，真实吃饱了撑的！”；这种想法真的是非常错误的，原因有以下几点： 简历是hr筛选的，技术面试官一般都比较忙，虽然hr可能会提前将简历发送给技术面试官，但是面试官一般都比较忙，面试之前未必会仔细看简历；所以通过自我介绍可以让面试官更好的了解你； 自我介绍可以看出你的语言组织能力、逻辑思维能力； 自我介绍可以引导面试官往应聘者自己熟悉方向上去发问，争取面试的主动权； 所以我所期望从应聘者的自我介绍中得到以下一些信息： 有组织、有条理的进行自我介绍； 自我介绍的内容包括简单介绍教育背景、工作经历、项目经历、自我评价（优缺点、特长【说明：重要，亮点，如果应聘者自己提到了的话我一般会接着这个话题继续聊下去】），个人的短/中/长期职业规划2) 基础方面 这部分的内容不一定要求全部精通，但是至少应该知其然，最好也能知其所以然，比如css的优先级，这里我举两个简单的例子： a) 编码题目，这个我一般都会让应聘者写一段代码，编码是开发人员最基本的功底；针对编码问题，我期望看到以下的结果： 编码之前先写思路，比如，第一步怎么怎么做，第二步怎么怎么做，体现出良好的思维习惯及逻辑思维能力，这样即使最终没有写出来也没有太大的关系； 良好的编码习惯（如命名规范、注释，在应聘者开始写之前我也会），这里我多说几句，常常听到有人说良好的命名就是最好的注释，强掉少些注释啥的；我面试过程中有一个原则，通篇代码没有一句注释的我直接不聊了；b) 引用类型/值类型，装箱/拆箱问题。 这个问题也比较典型，可能有人会说，这些东西又不会在工作中用到，问这种问题有什么意义！ 我要说的是，不是没用到，只是你没注意到而已。其它不多说了，我期望应聘者能把下面这张图画出来。 总之一句话就是，我希望应聘者能够对原理性的东西多了解一些。 3) 设计方面 设计知识其实也是作为高级开发职位必须具备的知识。 我期望应聘者能够对设计模式有比较深入的认识，通过我给出的经典场景能够立刻联想到应该使用的设计模式。 4) 解决问题的能力/学习习惯/个人特长等等 a) 解决问题的能力一直是我个人也好，还是项目组也好比较看重的，给一个不会的问题（写一个Windows服务小工具来搜集服务器的CPU、内存等信息），我期望得到的答案包含以下信息： 首先要制定一个计划（包含可能需要用到的资源、可能遇到的困难及解决思路，这个问题需要分几个步骤去做，制定大致的时间进度计划等等）； 按照规划好的步骤去做这些事情，遇到困难通过最快的方式/方法去解决，并及时修正计划； 解决完以后及时总结、汇报等等 b) 期望应聘者有良好的学习习惯，对新技术、新知识持续不断的学习； c) 在知识面上既要有一定的广度，同时也有自己的专长；5、总结与建议1) 总结 通过这段时间的面试，发现面试者主要有以下几点不能完全让然满意： 思路不够清晰，主要表现在：自我介绍的时候没有条理，比较乱；解决问题的能力有所欠缺； 比较浮躁，基础不扎实。 动不动就写精通XXX，对基础的问题（如装箱、拆箱）稍微聊得深入一点就清楚了； 不诚实：经常在简历或者自我介绍中提到：做过项目经理、技术经理，但是问到项目经理、技术经理的职责啥的却说不清楚； 知识面比较窄，学习习惯不够好； 职业目标不够清晰； 2)建议结合自己的一些真实感受，这里给出几点简单的建议吧： 给自己制定一个短/中/长期的职业目标，并为此不懈努力； 夯实基础，项目中用到的知识当然要学习，基础原理性的东西更要掌握； 多总结，把知识沉淀下来； 诚实。 培养良好的编码习惯；=希望本文能给各位求职者带来一些启发；如有不当之处，敬请批评指正。应该有很多人已经知道破窗效应【注1】这个社会学 （犯罪学）的词语，破窗效应最先由社会学家James Q. Wilson和George L. Kelling在一篇名为Broken Windows的文章中提出【注2】：“一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙地被人打破;一面墙，如果出现一些涂鸦没有被清洗掉，很快 的，墙上就布满了乱七八糟、不堪入目的东西;一个很干净的地方，人们不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑地抛，丝毫不觉羞愧。”我们一直在喊敏捷开发，其实敏捷开发的一个很重要的目的就是消除浪费，防止破窗效应的发生。事情太难，就让它简单，更简单。流程太重，就让它轻点，更轻点。尽量扫清开发的障 碍，消灭破窗形成的环境。下面我会从软件构建的很多方面来描述如何防止“软件开发中的破窗”。脏代码如果代码不整洁，后来人就很难看懂，人们往往会对难以看懂的代码失去耐心，不愿意进一步了解。如果不能进一步了解一部分代码，也就难以改进它，这样 带来的一个后果可能有两点：1、这段代码被抛弃，然后重新编写。2、直接复制这段代码在别的地方使用。对于第一点，会带来软件开发中的浪费，而且再次编写 也不可能就能一部到位的编写正确，可能会引入新的bug。对于第二点，大家都知道重复代码是设计走向腐化的根源之一。如果我们在编写代码时能不断的应用一些原则，确保我们的代码易懂，自描述。在开发新特性时还不断的使用重构手段，让我们的设计保持一个良好的状态。 我们就能防止窗户被继续打破。测试没有测试，或者混乱的测试代码都是破窗滋生的环境。没有测试没有测试时，当我们想对一块代码进行重构，我们就像没有带保险绳走钢丝，步履维艰，生怕一下子失去平衡，掉下悬崖。这样在我们的心中就产生了惧怕重 构的阴影，久而久之，我们就不去重构。最后带来的结果就跟上面一段说的一样，设计不断的腐化，然后就失去了控制。如果有了单元测试，有了验收测试，当我们每做一下重构时，我们都可以从测试快速获得反馈，每当红条亮起时，我们知道我们破坏了一些已有的功能，我们 停下来去修复，当绿条亮起时，我们知道现在处于安全状态，可以安心的继续重构。一切都在我们的掌控之中，我们会喜欢上重构。混乱的测试代码有很多人觉得测试代码不是交付给用户的产品代码，可以区别对待，我们不需要花那么多时间琢磨变量命名，方法命名，我们也不需要关注重复的代码。但 是混乱的测试代码跟没有测试是一样的，甚至比没有测试更糟糕。我们以为我们有测试，但测试却给我们虚假的报告，当我们发现我们的重构破坏如此之深时， 已经为时已晚。即使测试能给出真实的报告，但如果测试代码混乱，那么添加新的测试就非常困难，我们就会越来越惧怕添加新的测试。而且随着产品代码的演进， 测试代码也需要伴随着演进，测试代码越混乱，我们就越难以修改测试，让它反应出现在产品代码的状态。终于到了一天，大家决定抛弃测试，如是我们又回到了没 有测试作保障的日子。 实际上，从某种程度上测试代码的整洁程度比产品代码的整洁程度更重要，因为有了好的测试我们可以无忧无虑的重构我们的代码，即使现在我们的产品代码 很糟糕也不怕，因为有了测试的保证，我们知道我们可以重构过去，如果我们只有混乱的测试代码，我们那一线重构的希望都没有了。难以测试可测试性是衡量代码的一项准则。既然是准则一般都很难达到，如果代码难以添加测试，在尝试几次之后，我们一般都会放弃编写测试的想法。当我们尝试对 一段代码编写测试时发现，这块代码铁板一块，与太多的其他类耦合，需要传入很多重型对象的参数，比如与设备交互的代码，与数据库交互的代码相耦合，这些重 型对象很难模拟或插桩。没有办法，在进度的压力下我们只有放弃添加测试的想法了，那么如上面一样，代码就像草原上奔跑的野兽，失去了控制。编写可测试性的代码是困难的，要将糟糕的代码改进成可测的代码尤其困难。但有一个诀窍，我们可以先编写测试，用测试驱动出我们的产品代码，这样一开 始我们就获得了一个个测试套件，将我们的产品代码稳稳的固定在那里，就像走钢丝时的保险绳；不仅如此，我们还获得了可测试性的代码。测试运行太慢实际上测试运行太慢是一种信号，该信号告诉我们耦合的太紧了。运行一个测试，需要编译加载很多模块。如果运行一个测试需要20分钟，你希望频繁的运 行测试么？如果运行一套测试需要10个小时，你希望测试多久运行一次？测试运行太慢就是第一个被打破的窗户，如果不赶快修补，后面会有更多的窗户被打破。测试运行太慢，我们就不会频繁的运行测试，测试也就不能提供立即的反馈，这样测试的作用就大打折扣了。上面主要从代码实践方面来阐释编码中的破窗和如何防止破窗，其实在软件开发的很多方面都存在类似的情况。源代码管理有很多团队因为各种各样的原因采用了难以使用的源代码管理工具，或者完全因为厂商对管理层的广告宣传，采用了一个无比重型，好看但不中用的工具。在 经受一两次工具的折磨之后，团队成员就会产生惧怕的心理，尽量的推迟提交代码。提交代码需要足够的频繁，甚至一次有意义的重命名都可以作为一次提交，这样 在代码复查的时候光阅读提交代码的注释就能演示出代码的演化过程。而且，如果每一次成功都有保存，这样在犯错的时候我们有机会后悔，我们有机会回滚到一个 成功的状态。人的大脑虽然非常聪明，但也非常易于出错，特别是在疲劳的时候，如果我们小步前进，小步提交，我们就能停在任何地方。你还记不记得那种必须到 某个时候才能保存当前状态的电脑游戏？有的时候并不是工具难以使用，而是环境使然。在分布式的团队里，有可能网络不稳定，远程源代码仓库经常不可访问，或者在提交代码时需要连上VPN， 然后再提交，久而久之也会让团队成员懒于提交代码。这样我们就应该采用分布式的源代码管理工具，比如Git。难以集成代码写完了并不是开发任务的结束。你还记不记得多少次为了集成产品，解决几个模块之间的冲突而加班加点。敏捷强调及时的反馈，持续的交付。如果集成 一次产品需要几天时间，我们如何做到及时反馈呢？如果集成太困难，大家都会惧怕集成，就会尽量的避免集成，但产品最终是要集成的，所以到了最后期限的时 候，大家都在加班加点，但却不是写代码，而是为了集成。如果集成太困难，我们为什么不持续的集成呢？所有团队成员都工作在同样的分支上。持续集成服务器不断的签出最新的代码，运行各种各样的测试，最后构 建出可用的软件出来。只要需要，任何时候我们都可以提供可以工作的软件。可视化可视化是管理中的铁三角之一。很多管理人员喜欢使用各种各样绚丽的工具绘制出绚丽的图表。比如使用Project做出精确到天的人员计划，使用 PowerPoint做出产品的宏伟蓝图。好像将这些做出来，然后发给大家就有一种这个项目都在我的控制之内的感觉一样。其实不管怎么优秀的软件工具还是 比不上纸和笔。软件打开需要时间，随着软件更新换代，软件体积越来越大，打开一个庞大的Project文件甚至需要一两分钟的时间，而且文档埋藏在电脑文 件系统的深处。找到文档，打开，几分钟就已经过去了，别看这几分钟，久而久之我们就不想再去看这些东西了，我们以为这些东西都装在了我们的脑中，但实际却 没有。花了很多精力编写的需求文档，最后成了一纸空文，当发现与需求不符的时候已经晚了。要防止这种事情的发现，我们就不要打破第一扇窗。虽然到了二十一世纪，丰田公司还是在很多方面采用原始的看板。软件开发中也是一样，抛弃那些精美的软件吧，将计划，进度，用户故事用最简单的纸和笔 绘制，然后贴在开发人员抬头就可见的墙上。不需要画的多精美，因为越精美就越不想去修改，但软件开发中永恒不变的是变化，我们必须随需而变。笨重的流程有的公司给开发、测试、部署规定了严格的流程。开发人员想将产品功能部署到测试环境都需要与很多相关人员交互，提交申请单，然后才能由专人将刚刚修 改的一行代码部署到测试环境中，进行测试。首先不说这个过程中有多少等待，多少浪费。光这笨重的流程就让大家望而却步，进而导致惧怕修改，连好的改进都会 受到抵制。后记软件开发的方方面面就像一扇扇窗户，不要打破第一扇窗户，打破了也要