小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金。

废话只说一句：码字不易求个，收藏 === 学会,快行动起来吧！评论区走起‍‍‍。

在面试时，经过简单寒暄后，面试官一般先从让候选人自我介绍开始，紧接着就是问候选人简历中所列的项目，让介绍下项目经验。常见的问法是，说下你最近的（或感觉不错的）一个项目。面试中很多人忽视对这一个环节的准备，不仅回答不了面试官的追问，甚至连自己的项目都讲不清楚，说起来磕磕巴巴，甚至有的人说出的项目经验从时间段或技术等方面和简历上的不匹配，这样无疑会让面试官对面试者的能力产生怀疑。

面试时7份靠能力，3份靠技能，本文将从“前期准备”和“面试技巧”两大层面告诉大家如何准备面试时的项目介绍，当然，这只是一家之言，没有最好的方式，只有更适合的方法，仁者见仁智者见智。

前期分析

知己知彼百战不殆。如果想打动面试官，那么你就必须得了解他到底想要从你口中了解到什么，哪些信息是他所想要的。

在面试前准备项目描述时，别害怕，因为面试官什么都不知道，最了解你项目的还是你自己。

面试官是人，不是神，拿到你的简历的时候，只能根据你所描述的项目去推测你的工作经历，是没法核实你的项目细节的（一般公司会到录用后，通过背景调查的方式来核实）。

更何况，你做的项目是以月或以年为单位算的，而面试官最多用30分钟来从你的简历上了解你的项目经验，所以你对项目的熟悉程度要远远超过面试官，所以你一点也不用紧张。而面试官想了解更多他想知道的你的工作方式及项目中所负责的内容、所用到的技术栈，就不得不从你的介绍中去深挖技术点，以期了解你对项目及技术的了解的深度。

首先从气势上就要告诉面试官，这项目就是你参与的，有你所负责的功能模块，让面试官不容置疑。

心态上准备好了，那么就要分析面试官想要考察什么呢？

熟能生巧，对答自如。

首先是需要有个充足的准备，写项目经验一定要写自己熟悉的，因为面试官就会根据你写的项目经验提问。在面试前，就要在脑子里过一遍这个项目，准备好说辞，面试的时候自信点。讲清楚这个项目是满足什么需求的，开发过程中遇到哪些困难，自己怎么解决这些困难的。如果你经过充分准备，面试中也能答的很好，那面试官好感度就会增加，相反，如果面试中说的磕磕绊绊，那么可信度就会低了。

明确目标，控盘引导。

在面试前，你需要明确自己的面试目的，就是通过面试，争取拿到 Offer 。

最保守的方式就是在自己介绍项目的时候要么就是以面试官为主导，回答很简单，就是面试官问你一句你答一句。这会让面试官失去想了解你的信心，其次也会让自己错失表现自己，凸显重点思想的机会。做好防守虽然也是一种取胜的方式，但并非上策，很容易丢分。

讲自己简历中所列的项目一定要很清晰明了有逻辑，埋下后续可能会提问到的技术点，也给面试官留下一个好印象。如果项目经验介绍的好，有逻辑和引导力，那么就会给自己带来以下两点明显的好处：

给面试官带来的第一印象好，会让面试官感觉该候选人表述能力较强。一般来说，面试官会根据候选人介绍的项目背景来提问题，假设面试时会问10个问题，那么至少有5个问题会根据候选人所介绍的项目背景来问，候选人如果说的好，那么就可以很好地引导面试官去问后继问题，这就相当于把提问权完全交由自己控制了。

如果你的工作经验比面试官还丰富的话，甚至还可以控制整个面试流程，甚至遇到 Nice 的面试官的话会以讨论的方式进行沟通。

应聘者面试官

对项目及技能了解程度

很了解

只能听你说，只能根据你说的内容做出判断

面试过程中的职责

在很短的时间内防守成功即可

如果不能全面了解，找不到你薄弱的地方就代表你做过

准备时间

面试前你有充足的时间准备

一般在面试前用30分钟阅读你的简历

沟通过程

你可以出错，但别出关键性的错误

不会太为难你，除非你太差

技巧

表达要有逻辑性，引导面试官提问，也可以从网上找其实就问些通用的有规律的问

足够多的面试题

既然面试官无法了解你的底细，那么他们怎么来验证你的项目经验和技术？下面总结了一些常用的提问方式。

提问方式目的

让你描述工作经验和项目（极有可能是最近的），说的是否和简历上一致

看看你看你是否真的做过这些项目

看你简历上项目里用到的技术，比如框架、数据库，然后针对这些技术提些基本问题

还是验证你是否做过项目，同时看你是否了解这些技术，为进一步提问做准备

针对某个项目，不断深入地问一些技术上的问题，或者从不同侧面问一些技术实现，看你前后回答里面是否有矛盾

深入核实你的项目细节

针对某技术，问些项目里一定会遇到的问题，比如候选人说做过数据库，那么就会问索引方面的问题

通过这类问题，核实候选人是否真的有过项目经验（或者还仅仅是学习经验）

面试技巧

内容上要对项目进行以下拆分，思考并进行总结，并试着口语化讲出来。

项目描述。用通俗易懂且简洁的方式简述项目，阐述整个项目及其背景、规模，不要有太多的技术词汇。项目模块。2-3分钟的流程介绍，详细的列出项目实现的功能，各个模块，整个过程，大概思路。项目技术栈。说出项目实现的技术栈和架构，能说出项目的不寻常之处，比如采用了某项新技术，采用了某个架框等，简要说明技术选型。候选人的角色及责任。说出你在项目中的责任，所涉及的功能模块，运用的技术，碰到的难题、代码细节，技术点、应对措施。项目总结，待优化点。

方法上可以使用万能的STAR原则

Situation（背景）：做这个项目的背景是什么，比如这是个人项目还是团队项目，为什么需要做这个项目，你的角色是什么，等等。

Target（目标）：该项目要达成的目标是什么？为了完成这个目标有哪些困难？

Action（行动）：针对所要完成目标，你做了哪些工作？如何克服了其中一些困难？

Result（结果）：项目最终结果如何？有哪些成就？有哪些不足之处可以改进？

除了项目所取得的成绩之外，候选人还可以说明自己做完项目的感受，包括项目中哪些环节做的不错，哪些环节有提高的空间，自己在做这个项目中有何收获等。

无论是介绍自己的IT产品开发经历，还是在其他公司的实习项目经历，候选人都可以运用STAR法则来具体说明，轻松表现出自己分析阐述问题的清晰性、条理性和逻辑性。

但面试前如下的一些情况还是需要多加注意的。

回答很简单。问什么答什么，往往就一句话回答。如果你日常回答别人的问题或者之前面试中出现过类似情况就要有所改善了。这里应该将你知道的说出来，重点突出跟问题相关的思想、框架或技术点等。

扯闲篇，大忌。说少了太过于简短没有互动不好，自来熟，回答问题没有重点，没有逻辑，乱说一通也是大忌。会让面试官感觉你思路混乱，抓不到重点，只是拿其他方面的东西东拼西凑。

说的太过流利，也未必就是好事。虽然面试有所准备在面试官看来是好事，但是机械的准备好答案去背诵，主观上给人一种你并没有理解这个问题，只是靠记忆知道答案，后续面试官的问题也会相应的加大难度。这方面改善建议是适当停顿，做思考状，边思考边说，过程中同面试官有个眼神上的互动。

有的放矢的介绍技术细节。不要一次性过多的介绍技术细节，技术面点到为止，等面试官来问。因为面试官通常都有自己的面试节奏。所以技术点等着问的时候再多聊，可以先事先埋下技术点引导着面试官继续追问。

主动介绍项目亮点。因为面试官没有义务挖掘你的亮点，所以这就需要自己主动提。遇到不会的问题，就如实说这个技术点不会。或者半懂也可以直接说。甚至可以谈谈自己的见解。把自己了解的说说。

项目准备

一般来说，在面试前，大家应当准备项目描述的说辞，自信些，因为这部分你说了算，流利些，因为你经过充分准备后，可以知道你要说些什么。而且这些是你实际的项目经验（不是学习经验，也不是培训经验），那么一旦让面试官感觉你都说不上来，那么可信度就很低了。

不少人是拘泥于“项目里做了什么业务，以及代码实现的细节”，这就相当于把后继提问权直接交给面试官。下表列出了一些不好的回答方式。

回答方式后果

我在XX软件公司做了XX门户网站项目，这个项目做到了XX功能，具体是XX和XX模块，各模块做了XX功能，客户是XX，最后这个项目挣了XX钱

直接打断，因为业务需求我不需要了解，我会直接问他项目里的技术

（需要招聘一个前端开发，会 React）最近一个项目我是用JQuery实现的，实现了....或者我最近做的不是开发，而是测试....或者我最近的项目没有用到 React

提问，你最近用到React技术的项目是什么时候，然后在评语上写：最近XX时间没接触过 React

在毕业设计的时候（或者在读书的时候，在学习的时候，在XX培训学校，在XX实训课程中）

直接打断，提问你这个是否是商业项目，如果不是，你有没有其他的商业经验。如果没商业项目经验，除非是校招，否则就直接结束面试

描述项目时，一些关键要素（比如公司、时间、所用技术等）和简历上的不匹配

我们会深究这个不一致的情况，如果是简历造假，那么可能直接中断面试，如果真的是笔误，那么就需要提供合理的解释

在避免上述不好的回答的同时，大家可以按下表所给出的要素准备项目介绍。如果可以，也请大家准备一下用英语描述。

要素样式

控制在1分钟里面，讲出项目基本情况，比如项目名称，背景，给哪个客户做，完成了基本的事情，做了多久，项目规模多大，用到哪些技术，数据库用什么，然后酌情简单说一下模块。重点突出背景，技术，数据库和其他和技术有关的信息。

我在XX公司做了XX外汇保证金交易平台，客户是XX银行，主要完成了挂盘，实盘成交，保证金杠杆成交等功能，数据库是Oracle，前台用到JS等技术，后台用到Java的SSH，几个人做了X个月。不需要详细描述各功能模块，不需要说太多和业务有关但和技术无关的。如果面试官感兴趣，等他问。

要主动说出你做了哪些事情，这部分的描述一定需要和你的技术背景一致。

我做了外汇实盘交易系统，挂单成交系统，XXX模块，做了X个月

描述你在项目里的角色

我主要是做了开发，但在开发前，我在项目经理的带领下参与了业务调研，数据库设计等工作，后期我参与了测试和部署工作。

可以描述用到的技术细节，特别是你用到的技术细节，这部分尤其要注意，你说出口的，一定要知道，因为面试官后面就根据这个问的。你如果做了5个模块，宁可只说你能熟练说上口的2个。

用到了Java里面的集合，JDBC...等技术，用到了Spring MVC等框架，用技术连接数据库。

这部分你风险自己承担，如果可以，不露声色说出一些热门的要素，比如Linux，大数据，大访问压力等。但一旦你说了，面试官就会直接问细节。

这个系统里，部署在Linux上，每天要处理的数据量是XX，要求是在4小时，1G内存是的情况下处理完5千万条数据。平均访客是每分钟XXX。

不露痕迹地说出面试官爱听的话

在项目介绍的时候（当然包括后继的面试），面试官其实很想要听一些关键点，只要你说出来，而且回答相关问题比较好，这绝对是加分项。我在面试别人的时候，一旦这些关键点得到确认，我是绝对会在评语上加上一笔的。

下面列些面试官爱听的关键点和对应的说辞。

一旦有低级错误，可能会直接出局

面试过程中有些方面你是绝对不能出错，所以你在准备过程中需要尤其注意如下的因素。下面列了些会导致你直接出局的错误回答。

面试场景题

举一个例子，比如考察候选人是否聪明，star 法则会这样询问：

1.在刚才的项目中，你提到了公司业务发展很快，人手不够，你是如何应对的呢？2.在你的项目里面解决了什么样的难题3.在你的项目里面如何做的登录4.前端的项目如何进行优化，移动端呢？5.图片加载失败要做啥6.让你带领一个小团队完成一个项目，你会怎么做？7.项目的同源处理，跨域相关8.如果再做这个项目，你会在哪些方面进行改善？面试中，如果面试官让你描述一个自己比较得意的项目的时候，一定记得要遵循 STAR 法则进行回答。比如

为了整合 xxx 业务(S)，我承担 xxx 角色，具体负责 xxx (T)。做了 xxx 事情(A)，最后产生了 xxx 结果

然后在描述项目亮点的时候也一样，比如

由于项目 xxx 原因(S)，我需要进行 xxx 改进(T)，然后进行了 xxx 处理(A)，最后产出了 xxx 结果，数据对比为 xxx

整体这样下来，会显得你很有思考力，且具有行动力，可以给企业创造出价值，这也是面试官评定候选人最关键的指标之一。

面试官的套路

面试时所问的问题基本分为两种：具象的问题和开放性的问题。

具象的问题基本都会参考工作经验按照 STAR 法则来进行，主要是了解基本的素养，技术深度和潜力。

开放性的问题基本是考察思维发散能力，考察在某个领域的深度和广度，基本上会结合技术问题来问，或者是结合工作内容来问。

比如：实现某种技术的 n 种方法？某种技术的实现原理？和什么什么相比有哪些优缺点？你对这项技术的思考是什么？

面试者的应对

1.就实际情况做回答，提前准备的时候多发散，多思考，多总结。这一块是可以自己准备的加分项。

2.发散性问题主要是看自己平时积累。首先基础知识要牢固，同时也要了解最新技术动态。面对这类问题切记也不能答非所问而跑题了。

注意：

1.避免拿别人的项目直接用

很多初级阶段的同学们，可能并没有实际的商业项目，或者所做过的项目类型有限，就直接从网上找项目当做自己的项目，直接使用是断不可取的，但是如果你仿造别人的项目自己去尝试着将功能实现，有自己的新得体验，这样在做的过程中也可以对项目中的功能点和技术栈有进一步的了解，不至于在面试的时候，磕磕巴巴，甚至将项目时间都搞错。

2.避免低级错误

很多基础相关的低级错误一定要杜绝，如果被问到熟悉知识点就多答，不熟悉就直接说不熟悉。每个人都有自己擅长的点也有不擅长的。

另外就是可以引导一些话题，不要自说自话。很多人会一直很激进的表达自己，反而显得强势。有的面试者被问到数据库相关内容，他不仅回答数据库，还会把大数据处理技术全部都说出来。其实点到为止最好，面试官感兴趣会继续问，但是你一直主导话题，会减分。

这里要说的是，不要把不是自己做的项目说成是自己做的，自己不是核心负责人说成是负责人，即使你对项目很熟悉了解，像我们一线起来的面试官，问几个问题就很清楚你实际参与了多少了，只是大部分不会明说而已，反而起到反效果。

总结

首先我要劝大家，认真对待每一次面试。既然知道自己要参加面试，就在家自己模拟一下面试。自己提前准备一下自己的项目描述，不要到了面试的时候去打磕巴。但是如果你参加面试的时候实在紧张了，磕巴了不要慌。深呼吸尝试让自己放松，一般面试官也会给些提示帮助你回答的。

两句话，第一，面试前一定要准备，第二，本文给出是的方法，不是教条，大家可以按本文给出的方向结合自己的项目背景做准备，而不是死记硬背本文给出的一些说辞。

部分内容整理自网络