一份有说服力的初级开发者简历,在还没有带薪工作经验的情况下,应该以你真正能展示的东西开头,而不是把一个空洞的工作经验部分硬撑长。个人项目、课程作业、训练营的毕业项目,或是对某个代码库的任何真实贡献,都可以取代原本的工作经验部分,并按照工作经历条目的方式来写:清晰的名称、时间、使用的技术栈,以及一段简短的成果说明。教育背景可以进一步支撑这些内容,而顶部的简短总结应该清楚说明你目前的水平和你想应聘的岗位类型,而不是用含糊的措辞来掩饰没有带薪工作这件事。
把项目经历放在通常由工作经验占据的位置
对于没有带薪工作经验的初级开发者简历来说,一个不错的结构调整是让项目经历部分获得通常属于工作经历的分量和位置:先是标题和简短总结,然后是项目经历,接着是教育背景,再是技能部分,最后才是课外活动。招聘人员浏览简历时通常是从上到下快速扫描,所以最有力、最与岗位相关的内容应该排在最前面,而对于一个最大优势是自己做过的东西的人来说,这就是项目经历,而不是实习或与开发无关的兼职工作。两到三个项目,按照与目标岗位的相关性而不是完成时间来挑选,会比硬塞五六个项目效果更好。为大学课程做的项目、训练营的毕业项目和个人小工具都可以放进来,只要每一个都得到同样的处理:名称、简短描述、技术栈,以及它实际做了什么,而不只是一份课程名称清单。
把每个项目条目写得像一份工作,而不是一个爱好
每个项目条目最好包含工作经历条目会有的相同字段:名称、时间段、使用的技术,以及一到三行描述项目做了什么、如果是团队项目你具体负责的部分,以及由此带来的任何变化或成果。写清具体的技术栈,一门语言、一个框架、一个数据库、一个部署平台,在这里比在工作经历条目中更重要,因为这往往是读者判断你实际能力最清晰的证据。如果项目是和其他人一起完成的,要说明你具体负责的部分,而不是笼统描述整个项目让自己的贡献变得含糊;一个只列出团队整体成果的共同项目读起来会更模糊,而不是更令人印象深刻。一个还在进行中的项目,如果已经进展到可以具体描述的程度,也值得写进去,但一个从未超出想法阶段的项目最好完全不写,因为简历条目需要有实际做出来的东西可说。
对别人代码库的贡献同样算数,而且往往比独立项目读起来更可信,因为它说明你能在不是自己写的代码里工作。如果你为某个开源项目修复过一个缺陷、加过一个小功能或改进过文档,写出项目名称,用一行描述具体改动,并说明让改动被合并需要做什么,比如理解一套已有的测试代码,或者第一次按照贡献流程操作。这样的条目,哪怕很小,也能展示一个周末独立项目无法展示的东西:在别人设定的约束里工作,而不是在自己设定的约束里。
示例说明:把一句含糊的项目描述改写成完整条目
改写前:"和几个朋友一起做了个网站,作为课堂作业。"
改写后:"任务追踪应用,团队项目,大学课程,[年份]三月至五月。用 Node.js 和 Express 构建了后端 API,负责一个四人团队的身份验证和任务分配;前端由另外两名队友用 React 完成。部署在免费主机方案上,用于课程结课演示。"
改写后的版本保留了同样的基本事实,一个课堂上的小型团队项目,但现在写清了技术栈、具体负责的部分、团队规模以及最终的结果,给读者一些具体的东西来判断,而不是一句空泛的话。
技能与教育背景,保持诚实
按类别对技能分组,编程语言、框架、工具、云服务,而不是堆成一长串没有分类的清单,就像CVBuilderKit开发者模板中技能部分可以分组呈现的方式一样。只保留那些你能在面试中有一定深度地谈论的内容;一份塞满只在教程里接触过一次的工具的长清单,造成的伤害比一份简短但准确的清单更大,因为面试官一旦针对某个夸大的条目追问,就会很快发现其中的空洞。教育背景应保留,写明学位、院校和预期或实际的毕业日期,如果这部分内容仍显单薄,可以加上与目标岗位直接相关的课程。
发送第一版之前
结构确定之后,像招聘人员那样把整份简历读一遍:第一条项目经历说的内容是否足以让人愿意再看一眼,总结句是否给出了一个真实的目标而不是泛泛而谈。也值得单独读一遍总结句,脱离文档其余部分,问问自己它是否说明了一个具体的岗位方向,比如"初级后端开发者"或"专注 React 的前端开发者",而不是像"积极进取、正在寻找机会的开发者"这种几乎可以描述任何人的泛泛之词。如果单靠项目经历部分分量还不够,以应届毕业生身份撰写几乎没有工作经验的简历从更广的角度讨论了同样的问题,尤其是在教育背景和实习的呈现方式上。结构确定后就可以开始搭建简历,并随着每加入一个新项目调整措辞;用这种方式搭建的简历,等第一份带薪工作终于可以写进去时也很容易扩展,因为项目经历部分只需要往下移,而不需要从头重建。
