《面试.NET.doc》由会员分享，可在线阅读，更多相关《面试.NET.doc（10页珍藏版）》请在金锄头文库上搜索。
1、谈谈.Net技术面试 1、引子 最近一直在负责.net(B/S方向)技术面试相关的工作，前前后后面试了不少人，但是通过率较低，大概只有20%左右；有颇多感慨。最近也一直比较困惑，原因究竟是什么？是我们要求太高，应聘者本身的问题，还是是面试的内容本身的问题？2、我们的岗位要求 这是之前项目组整理的一个简单的岗位(.Net中高级职位)要求，贴一下： 必须技能： 有23年实际的项目经验（特别说明：工作经验不一定要进入实际的公司才能积累的） 思路比较清晰，有较强的独立解决问题的能力 熟悉b/s开发的各项基本知识（如css、javascript、html、），不要求全会，但至少能看懂别人写的东西，另外各
2、项里面必须有一项较为突出； 对.net框架比较熟悉，熟悉多层模型，编码能力较强，编码规范，打字速度不能太慢（特别说明：这应该属于最最基本的技能，但是很让人不解的是面试过程中有不少的应聘者竟然尖着个手指头在那儿慢慢敲字!） 数据库知识比较扎实 优先考虑： 对web报表比较熟悉者 有过多种数据库开发经验，能够罗列出各种数据库之间的一些细微差别 有过一些c/s开发经验者 前端开发经验比较丰富者（如实际负责过ExtJS、JQuery、Dojo、YUI、AjaxPro相关工作的）3、使用的面试问题 面试过程中针对上面的岗位要求主要会涉及到以下几项内容 1）给10分钟左右的时间，做一个详细的自我介绍 2）
3、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原生脚本
4、改变class为“xyz”该如何写，将“一段文字”替换成“其它文字”如何写等； .abccolor:red;#abccolor:blue;一段文字 f）谈谈ajax原理的了解程度以及目前业界流行的ajax框架的熟悉程度； g) 表结构： 成绩表（Grade），包含字段：GradeID（Int，自增）， SNO（int, 学号）， CNO（int, 课程号）， Score(float，分数） 查询每门课程的平均（最高/最低）分及课程号； 查询每门课程第1名的学生的学号； 查询每门课程中超过平均分的所有学生的学号等等；3) 设计方面的能力 a) 给出一些具体的应用场景，如多数据库支持、工资计算方式
5、多样的情况，如何来设计； b) 谈谈对设计的理解； c) 偶尔还会让画画设计类型，写写代码实现常见设计模式（如单例模式等） 4) 解决问题的能力/学习习惯/个人特长等等 主要涉及到以下一些问题 让应聘者自己挑一个自己以往做过的他认为具有代表性的项目，详细聊一下，主要聊一下他/她在这个项目中的职责，这个项目曾经遇到过哪些问题，如何解决的，他/她在解决这些问题的过程中起到了什么作用等等。 给应聘者一个他目前不会的问题，让其解决一下； 课外时间都在干什么，常上的技术网站是什么，最近看的基本书（电子书当然也算）的名字还记得吗； 聊聊自己最擅长的方面；4、我期望得到的答案 当然上面这些问题不可能一次全部
6、都问到，时间上也不允许，但是四部分的内容我会根据实际情况都会问到一些；时间一般在1个小时左右； 下面谈谈从项目组以及我个人角度出发希望得到的答案，希望能够给大家带来些许启示： 1) 首先是自我介绍部分 这部分的内容我本人之前被面试的时候也很是郁闷，认为：“我的简历都有了，你自己不会看吗，还让我再多说一遍，真实吃饱了撑的！”；这种想法真的是非常错误的，原因有以下几点： 简历是hr筛选的，技术面试官一般都比较忙，虽然hr可能会提前将简历发送给技术面试官，但是面试官一般都比较忙，面试之前未必会仔细看简历；所以通过自我介绍可以让面试官更好的了解你； 自我介绍可以看出你的语言组织能力、逻辑思维能力； 自
7、我介绍可以引导面试官往应聘者自己熟悉方向上去发问，争取面试的主动权； 所以我所期望从应聘者的自我介绍中得到以下一些信息： 有组织、有条理的进行自我介绍； 自我介绍的内容包括简单介绍教育背景、工作经历、项目经历、自我评价（优缺点、特长【说明：重要，亮点，如果应聘者自己提到了的话我一般会接着这个话题继续聊下去】），个人的短/中/长期职业规划2) 基础方面 这部分的内容不一定要求全部精通，但是至少应该知其然，最好也能知其所以然，比如css的优先级，这里我举两个简单的例子： a) 编码题目，这个我一般都会让应聘者写一段代码，编码是开发人员最基本的功底；针对编码问题，我期望看到以下的结果： 编码之前先写
8、思路，比如，第一步怎么怎么做，第二步怎么怎么做，体现出良好的思维习惯及逻辑思维能力，这样即使最终没有写出来也没有太大的关系； 良好的编码习惯（如命名规范、注释，在应聘者开始写之前我也会），这里我多说几句，常常听到有人说良好的命名就是最好的注释，强掉少些注释啥的；我面试过程中有一个原则，通篇代码没有一句注释的我直接不聊了；b) 引用类型/值类型，装箱/拆箱问题。 这个问题也比较典型，可能有人会说，这些东西又不会在工作中用到，问这种问题有什么意义！ 我要说的是，不是没用到，只是你没注意到而已。其它不多说了，我期望应聘者能把下面这张图画出来。 总之一句话就是，我希望应聘者能够对原理性的东西多了解一些
9、。 3) 设计方面 设计知识其实也是作为高级开发职位必须具备的知识。 我期望应聘者能够对设计模式有比较深入的认识，通过我给出的经典场景能够立刻联想到应该使用的设计模式。 4) 解决问题的能力/学习习惯/个人特长等等 a) 解决问题的能力一直是我个人也好，还是项目组也好比较看重的，给一个不会的问题（写一个Windows服务小工具来搜集服务器的CPU、内存等信息），我期望得到的答案包含以下信息： 首先要制定一个计划（包含可能需要用到的资源、可能遇到的困难及解决思路，这个问题需要分几个步骤去做，制定大致的时间进度计划等等）； 按照规划好的步骤去做这些事情，遇到困难通过最快的方式/方法去解决，并及时修
10、正计划； 解决完以后及时总结、汇报等等 b) 期望应聘者有良好的学习习惯，对新技术、新知识持续不断的学习； c) 在知识面上既要有一定的广度，同时也有自己的专长；5、总结与建议1) 总结 通过这段时间的面试，发现面试者主要有以下几点不能完全让然满意： 思路不够清晰，主要表现在：自我介绍的时候没有条理，比较乱；解决问题的能力有所欠缺； 比较浮躁，基础不扎实。 动不动就写精通XXX，对基础的问题（如装箱、拆箱）稍微聊得深入一点就清楚了； 不诚实：经常在简历或者自我介绍中提到：做过项目经理、技术经理，但是问到项目经理、技术经理的职责啥的却说不清楚； 知识面比较窄，学习习惯不够好； 职业目标不够清晰；
11、 2)建议结合自己的一些真实感受，这里给出几点简单的建议吧： 给自己制定一个短/中/长期的职业目标，并为此不懈努力； 夯实基础，项目中用到的知识当然要学习，基础原理性的东西更要掌握； 多总结，把知识沉淀下来； 诚实。 培养良好的编码习惯；=希望本文能给各位求职者带来一些启发；如有不当之处，敬请批评指正。应该有很多人已经知道破窗效应【注1】这个社会学 （犯罪学）的词语，破窗效应最先由社会学家James Q. Wilson和George L. Kelling在一篇名为Broken Windows的文章中提出【注2】：“一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙地被人打破;一
12、面墙，如果出现一些涂鸦没有被清洗掉，很快 的，墙上就布满了乱七八糟、不堪入目的东西;一个很干净的地方，人们不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑地抛，丝毫不觉羞愧。”我们一直在喊敏捷开发，其实敏捷开发的一个很重要的目的就是消除浪费，防止破窗效应的发生。事情太难，就让它简单，更简单。流程太重，就让它轻点，更轻点。尽量扫清开发的障 碍，消灭破窗形成的环境。下面我会从软件构建的很多方面来描述如何防止“软件开发中的破窗”。脏代码如果代码不整洁，后来人就很难看懂，人们往往会对难以看懂的代码失去耐心，不愿意进一步了解。如果不能进一步了解一部分代码，也就难以改进它，这样 带来的一个后果可
13、能有两点：1、这段代码被抛弃，然后重新编写。2、直接复制这段代码在别的地方使用。对于第一点，会带来软件开发中的浪费，而且再次编写 也不可能就能一部到位的编写正确，可能会引入新的bug。对于第二点，大家都知道重复代码是设计走向腐化的根源之一。如果我们在编写代码时能不断的应用一些原则，确保我们的代码易懂，自描述。在开发新特性时还不断的使用重构手段，让我们的设计保持一个良好的状态。 我们就能防止窗户被继续打破。测试没有测试，或者混乱的测试代码都是破窗滋生的环境。没有测试没有测试时，当我们想对一块代码进行重构，我们就像没有带保险绳走钢丝，步履维艰，生怕一下子失去平衡，掉下悬崖。这样在我们的心中就产生了
14、惧怕重 构的阴影，久而久之，我们就不去重构。最后带来的结果就跟上面一段说的一样，设计不断的腐化，然后就失去了控制。如果有了单元测试，有了验收测试，当我们每做一下重构时，我们都可以从测试快速获得反馈，每当红条亮起时，我们知道我们破坏了一些已有的功能，我们 停下来去修复，当绿条亮起时，我们知道现在处于安全状态，可以安心的继续重构。一切都在我们的掌控之中，我们会喜欢上重构。混乱的测试代码有很多人觉得测试代码不是交付给用户的产品代码，可以区别对待，我们不需要花那么多时间琢磨变量命名，方法命名，我们也不需要关注重复的代码。但 是混乱的测试代码跟没有测试是一样的，甚至比没有测试更糟糕。我们以为我们有测试，但测试却给我们虚假的报告，当我们发现我们的重构破坏如此之深时， 已经为时已晚。即使测试能给出真实的报告，但如果测试代码混乱，那么添加新的测试就非常困难，我们就会越来越惧怕添加新的测试。而且随着产品代码的演进， 测试代码也需要伴随着演进，测试代码越混乱，我们就越难以修改测试，让它反应出现在产品代码的状态。终于到了一天，大家决定抛弃测试，如是我们又回到了没 有测试作保障的日子。 实际上，从某种程度上测试代码的整洁程度比产品代码的整洁程度更重要，因为有了好的测试我们可以无忧无虑的重构我们的代码，即使现在我们的产品代码 很糟糕也不怕，因为有了测试的保证
