《手把手教你改Resume》——描述篇(逻辑整理)

有一些人的Resume,看着很乱。如果仔细找,好像有好多内容,似乎把该写的东西都写的差不多,但是给人第一次看的时候,别人总是难以抓到重点。

这就是经历描述逻辑的问题。

在写Resume的时候要明确地意识到一点,看你Resume的人,极有可能对你的project完全不熟悉,是第一次了解你的project,并且这个人在你Resume上花的时间会非常有限。正因如此,如果你的project描述乱七八糟,毫无逻辑,就特别容易没有把该展示的东西展示出来,导致雇主对你的印象大打折扣。

比如说,有很多人喜欢按照时间顺序安排自己的bullet point。因为这是他们回忆的顺序,是很自然的一种表达方式。我先做了什么,再做了什么,看似逻辑通顺。

然而,一般情况下一个project刚开始做的事情都是比较无聊的,而雇主一般会对每个project的第一个bp进行阅读,再决定要不要继续看下去。于是,按照时间顺序写的项目,往往就把最无聊的内容,放到了最前面。

  • Learned about Flask framework, researched the requirements of the customers and made a detailed schedule to finish the project in three months.
  • XX
  • XX

看到第一个bp之后,后面的就懒得看了。最起码,后面的内容的第一印象就差了好多。看完感觉这项目啥有意义的东西也没做。

所以,我们第一个bp一般而言,都是概述一下我们整个project的情况,我大概做了个什么东西,让读者有一个基础概念,再去理解接下来的细节。

有人说,我的题目就包含了这个信息了,是不是就不用写了呢?当然不是,因为很多雇主是压根不太看题目的,直接从bp看起。更何况,一般而言题目应该就是个名字,或者是公司/职位,不应该包含大量的和项目相关的信息。

在有了一个概述之后,后面的若干个bp,一般是以平行或递进的关系描述的。也就是说,接下来的2~4个bp,要么是互相相对独立但是差不多同一级别的概念,要么应该是逐渐加强的关系。

  • Designed the data structure of ColorFight! to store the current game status in PSQL
  • Implemented the back-end API for both website and AI-client to access and control the game
  • Built the front-end web page to visualize the game in real-time

(以上是个细节上不怎么好的例子,但是逻辑比较清晰)

这就是一个比较平行的描述方式,每一个点的大小是差不多的,然后又是相对无关的,从多个层次支撑你这个project的内容。

  • Designed the data structure of ColorFight! to store the current game status in PSQL
  • Optimized back-end API so it would access the database only once instead of multiple times
  • Utilized a Redis cache layer for frequently-used contents to reduce the latency

(以上依然是个细节上比较差的例子,只是为了说逻辑)

这是一个比较递进的描述方式,从一个基础的版本开始,逐渐变得更好。

  • Designed the data structure of ColorFight! to store the current game status in PSQL
  • Smoothened the web page game display by speculating the game with keyframes
  • Implemented thread-safe attack function for the users to play the game with sending HTTP requests

(以上这个例子,就显得逻辑乱了)

逻辑哪儿有问题呢?首先,从后端跑到前端又跑回去。其次,这几个概念不太同级,有优化有实现,有大有小。这样出来进去的,就容易把人绕晕了。尤其是当你的bp相对比较长的时候。

如果你有一个方向的内容要写两个或多个bp,这几个bp一定要挨在一起,千万不要把他们分开。否则就会让人晃神,觉得哎这中间怎么夹了些东西?

总之,你的描述一定是要让人更容易看明白,而不是看着看着就糊涂了。把雇主看懵不是目的,让他们觉得你厉害才是水平。

所以,当你描述project的时候,千万不能想到哪儿写到哪儿,一定要先去整理一下逻辑,想想什么方式是最符合逻辑,最容易让一个完全不了解你project的人看明白你在干什么的。

那每一个project,尤其是重要的project的最后,一般都应该有一个结果。这是一个总结,也是一个展示。

这个结果可以是什么呢?比如这个东西最后被公司采用,进入了公司的代码库(这个对大公司好使)。比如这个项目最后发布到了某个平台,然后有了多少用户。或者说这个项目最后使得某个指标提升了(速度,用户数,精确率等等),从多少到多少。

为什么要说这个?因为不管你之前吹的多么愉快,你这东西最后扔到垃圾桶了,那立刻就让人觉得差了几分。我们都知道,上线的东西,尤其是被公司真正使用的东西,是要有一定的品质要求的。你一个project做的质量,从bp中有时候不那么容易体现出来,但是最后的结果是一个非常好的佐证。

除了描述的顺序之外,还有一个比较重要也有一定难度的注意事项,就是要构建一个完整的逻辑架构,让人能看明白你干了什么。

什么意思呢?有的人在一个大公司实习,做了一个小一些的模块,他就直接说他这个模块干啥了。然后描述凭空而降,没有前后文,描述中又出现了大量的公司内部专用术语和名词。对于描述者而言,这些可能都是理所当然的,他心中有一个非常明确的示意图,他做了什么,在哪个部分。但是对于雇主而言,他描述的东西是没有根基也没有关联的,因为雇主并不知道他「默认」的那些事情。

所以,当你写完了Resume之后,一定要去细细地读一下,看看自己有没有默认一些不是这个领域常识的事情。在描述的过程中出现的专有名词,把他们换成something,逻辑还是否成立,能不能看懂。你描述的这些事情本身,是否可以连成一个网络,每个点都以每种形式关联在一起。

如果你发现,你说的这些东西,没有了你「没写出来」的那些知识和背景,就不成章法,那就说明你的逻辑有问题了,你就需要增加一些必要的背景介绍,去让你做的事情合乎逻辑。否则当雇主看到之后脑海中只会有一个念头「这人到底干啥了?」

合理的逻辑在Resume中是非常重要的,一个合理的行文逻辑会让你的Resume更易懂,更具说服力,从而让雇主在短时间内可以收到更多有效地信息,对你产生更高的评价。

所以请千万不要看着自己的Resume说,我想写的东西好像都写上了,就这样吧。你写出来的东西,未必看的人就能读进去。

本文由EECSResume(www.eecsresume.com)发布,如需转载,必须复制本行。