今天很幸运的去了某公司面试前端开发，可是今天的面试表现却并不理想。面试来得很突然，知道了面试的消息后，整个人都很亢奋，在被问及何时可以去面试时，说立刻可以去面试更是其中的败笔。整个人并不是处于准备好的状态，而是一种慌慌张张，没有任何准备的状态，这真的是一场失败的面试。回家后自己一直在反思，晚上室友回来后也一起聊了聊这次面试，我想通过的希望大概很渺茫了，不过失败也是一种学习，对此次面试做一次总结反思还是很有必要的，要对下一次的面试起到积极的作用。

对于面试官的问题没有展开讲解

今天面试官看到我的简历上有golang的使用经历，因此要我介绍一下golang这门语言。也许是最近在看编译原理的关系，对语言这种东西看的很淡然，认为一门语言，本身只是一组语法，其本质不过是文本处理，虽然一门语言提供了什么功能很重要，但是一门语言真正的核心价值在于这个语言相关的库或者说生态，而这门语言能够做什么，基本是在于是否有相关的库来提供相应的功能。

所以，在面试时只是简单地讲述了一下golang主要特点是语法比较简洁，并且有goroutine，这种原生的并发支持，是的golang这门语言在写并发程序时负担更小。

然而，对于介绍一门语言其实还有不少可以展开的地方。首先是这门语言的设计目的，是否达到了效果。其次，可以介绍一下这门语言中的亮点，包括之前说的语法简洁，goroutine。之后可以介绍一些在使用这么语言中遇到的问题，例如，golang与C语言结合使用遇到的问题，goroutine遇到了什么问题。还可以讲述一下对这门语言设计上的看法，比如对interface的看法。

世间万物皆有因果，仅仅是一个结论并不能很好地让人理解，毕竟面试官不是学徒，你也不是禅师。结论更多的是对个人而言，只有有过类似经历的人才可能能够理解。我想在面试中最重要的是展示自己，如果在面试中能够将一个问题由因及果的展开的来讲一讲，一定能够更好的展示自己。

对于重难点的定义似乎过高

关于在工作中遇到的重难点问题，室友的一番话点醒了我，大概是自己对重难点的定义太高，认为如果没有做出什么突出的改善或者有重大价值的事情则不能被认为是重难点。

其实冷静的想一下，所谓的重难点，并不一定是要创造出惊人的价值，也许只是一次小小的技术突破，一次小小的改进或者是解决的一个个的坑，甚至是从写代码过程中学到了什么，都可以是一次不错的重难点。

在工作与非工作中都可能遇到各种各样的问题，结合问题，解决这些问题的过程以及最后如何解决这些问题做一次小小的总结，本身就可以是一次不错的对重难点面试问题的回答了。

以DDE相关的内容为例：如何解决Launcher中虚化显示图标的需求，中间尝试过什么解决方案。又比如实现Dock的底板时做了哪些尝试，遇到了哪些问题，最后是使用哪种方式解决问题。还有，给Launcher代码添加测试的工程中，学到了什么，如何学到这些东西。

小结

面试过程中，最重要的是展示自己。所以首先要做的是冷静，说话前停顿一下，给自己一点思考的时间。将问题由因及果的展开描述，而不是简单的抛出一个模糊的结论。必要时，或许可以通过纸和笔来举一些例子，更好的解释一些内容。

在面试前同样需要冷静的准备，这些准备可以提前完成。首先回忆一下以前项目的需求，然后看看这些需求是否遇到了某些坑，而这些坑正是这个项目的重难点。再回顾一下，在项目开发重构等过程中是否学到了什么东西。可以将这些记录下来，在面试前回顾一下。可能的话，模拟面试也是一个不错的选择。

同样，面试后，反思一下此次面试过程中的问题，然后总结一下，要在下次做到更好。