之前在 studyabroad 板有试着把我写的关於求职的文章整理出来 [1] ，但那些 旧文都是在「讨论」，所以比较零碎、发散。是故，开始试着有系统地整理一些观 念，集合成单篇的文章。 有任何意见、建议、问题，请不吝指教，谢谢 :) * 网页版 http://www.30abysses.com/TWY/2017/01/26/resume-tone.html * GitHub Issue 版 https://github.com/teach-and-learn/write-resume/issues/2 [1]: https://webptt.com/cn.aspx?n=bbs/studyabroad/M.1478510359.A.EFF.html #1O84SNx_ (studyabroad) ======================================================================== # 职涯、英语，写，美式履历表，语气 有作过功课的人大概都知道「[美式履历表][1]」 与台、日常见的履历表（格） 不一样。美式履历表从一张白纸开始，虽然有由经验归纳出的常见样版，但并没有 严格统一规格，多半由求职者自由发挥。 [1]: https://en.wikipedia.org/wiki/R%C3%A9sum%C3%A9 关於「美式履历表写作」，网路上有许多英语资料，但中文（公开）资料仍偏少， 且多半只限於讲解美式履历表的基本格式，少有对写作风格多作着墨（尤其是写作 语气的案例解析），是故，在此整理我这几年来发布的文章，以作参考。这篇从最 重要的「语气」谈起。 **声明：我的经验来自於我对北美软体科技业的认识，不见得适用於所有行业。** # 所谓「语气」为何？ 履历表是求职申请的敲门砖，最常见的错误语气，就是把它当作 「[起居注][2] 、流水帐」来写，也就是错误地把焦点放在： > 在某时某地，我以某方法作了某事，句点。 [2]: https://zh.wikipedia.org/zh-tw/%E8%B5%B7%E5%B1%85%E6%B3%A8 这种写作语气的错误在於：这就像是把 iPhone 秤斤论两，照着金属原料、物料的 单位价格来卖，而无视 iPhone 的整体价值。 易言之，比较以下两句话： 1. 我以Ｎ牛顿的力量施加於该质量Ｍ的小孩产生Ａ的加速度让他在Ｔ时间作出 Ｓ距离的位移。 2. 我奋不顾身将该小孩从失控的卡车前拉开，使他免成车下亡魂。 `(1)` 与 `(2)` 说的是同一件事；虽然 `(1)` 在技术上完全正确，但 `(2)` 才能突显「救了一条人命的价值」。 这就是所谓的「语气」；并不只是从网路上的 "action verb" 清单里挑动词 填填看，而是要从读者的角度去想，如何坚守诚信但又清楚展示你的价值。 # 三段连续技：成果 → 实例 → 细节 所谓三段连续技，即是成果(result)、实例(example)、细节(specifics)。先从一 实际案例来看（以下所有案例皆有略为修改，以保护当事人隐私）： > Created Bash scripts and custom Eclipse plugins in Java for automatic > code generation > > 建立 Bash 脚本、以 Java 客制化 Eclipse 插件来自动产生源码。 这给出了实例与细节，但後继无力；是故，稍作修改订正，变成： > Automated _X%_ _component_ code generation with Bash scripts and > custom Eclipse plugins (Java). > > 以 Bash 脚本、 Java 客制 Eclipse 插件，将 _某元件_ _X%_ 的源码生成 > 自动化。 这就是由「成果」起手（ "X%" ）、说明实例（ "automated code generation" ），点出价值（由自动化节省人工，而人工就是成本），最後补充细节（ "Bash scripts", "Eclipse plugins (Java)" ）。 除了点出你创造的价值，也为接下来的对话布局，不管是由读者发问，或是自己 导入以下这类这些话题都可以，例如 * 这个 _X%_ 是怎麽算出来的？这种算法有多精确？ * 为什麽 _component_ 需要 automated code generation ？ * 若能重来，会如何改进这个作法？ 易言之，先以连续技作出有效打击，再掌握节奏，进可攻，退可守，会比原本的 被动语气（只丢实例与细节，等待读者来猜测、推敲你做的事的价值）来得有利（ 因为你的读者很少会愿意花那时间来解读你的「言外之意」、也多半没那个心力来 为你探索你自己都说不明白的成果价值）。 --- 另一个案例 > Implemented automation E2E tests with xUnit and Moq from scratch; > integrated with CI to send test report. > > 从头以 xUnit 及 Moq 实作自动 E2E 测试，并与 CI 整合、送出测试报告。 与该履历表作者沟通之後，了解到该团队之前完全没有自动测试，是故这东西作 出来後，是从顶头上司到 CTO 都点赞的大功，是故，重点在那句 "from scratch" ；订正之後拆成三句： > Reduced average testing efforts per build from _X_ man minutes to _Y_ > machine minutes. > > 100% automated CI E2E tests plus test result reporting, analysis, > visualization. > > Designed and implemented full CI E2E test suite from scratch with > xUnit and Moq. > > 将平均测试成本从 _X_ 分钟（手动）降至 _Y_ 分钟（自动）。 > > 100% 完全自动化 CI E2E 测试，且自动化汇报测试结果、分析、并以视觉化 > 图表呈现。 > > 从零开始设计整个 CI E2E 测试库；以 xUnit, Moq 实作。 同样一件事，换个说法就铿锵有力掷地有声；可惜该履历表作者手上没有 code coverage, branch coverage 等资料，不然这一段的打击火力可以更强大。 # 「成果」的重要性 「成果」是整个连续技的开始，以格斗游戏来比喻的话，这三段连续技就是： > 浮空 → 连击 → 追打 （概念影片支援： [https://youtu.be/qcnrq7G6nag?t=36s][3] ） [3]: https://youtu.be/qcnrq7G6nag?t=36s 对应到成果、实例、细节就是： > 成果（浮空） → 实例（连击） → 细节（追打） 「成果」代表你创造出来的价值，同时展现你作事的态度（你如何量化你的成果？ 如何导入最基本的 [Build-Measure-Learn][4] ？）；「成果」不一定要是什麽 丰功伟业，只要把你的职务作到 *卓越* ，就一定有拿得上台面的「成果」。有了 成果，就能抓住履历表读者／雇主的注意力，掌握节奏，主控（面试）场面。 [4]: https://en.wikipedia.org/wiki/Lean_startup#Build.E2.80.93Measure.E2.80.93Learn # 结论 如果是没有特定目的而写的履历表（例如，就放一份在自己网站上，给猎头人参考 用的），那稍微偏向流水帐的语气是无妨（工作经历、学历、证照、技能）。如果 是为了特定职位而写的，就要以 sales pitch 的心态去写，也就是这整篇文章 一直强调的「成果、价值」。 「实例、细节」与左手一样，只是辅助；如果一味纠结於「实例、细节」而忘了 「成果、价值」，那就像是把 iPhone 如废五金秤斤论两卖，本末倒置。 -- 个人 杂谈、学习、英语、软体 https://www.facebook.com/tw.yang.30 https://www.facebook.com/30abysses/ https://twitter.com/twy30 http://www.30abysses.com/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 72.211.194.61 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Oversea_Job/M.1485568512.A.37B.html ※ AmosYang:转录至看板 Soft_Job 01/28 09:55 这很难用是否题的方式来回答 :) 我在上面原文中提出这个主张： > 「成果」不一定要是什麽丰功伟业，只要把你的职务作到 *卓越* ，就一定有拿 > 得上台面的「成果」 例如网路前阵子在刷的「因为自动饮料机而延毕的那一年」 [1] 系列文。 [1]: http://opass.logdown.com/posts/1273243-the-story-of-auto-beverage-machine-1 以「商转」论成败的话，最後是失败的，但其中还是可以挖出很多成果与价值，尤 其是「解决问题」的过程；放杯、加冰、加水、加糖…都是从无到有，作出解决方 案。从这个角度切入去写的话，仍可以显出作者的毅力与研究能力。 有的时候，的确会发生当局者迷、旁观者清的现象；有些事当事人会觉得不值一提 ，但旁人听了会听出其中可用之处。 例如，今天下午才与一位网友讨论他的履历，他列出来一条，大意是 > 维护既有产品，修正臭虫 与他聊了聊才发现，他所谓「维护既有产品」时，为了增设一个新功能，必须开发 框架里本来没有的功能，才让这新功能得以运作。 那这就可以写成 > 研发扩充商转产品关键技术： _某技术_ 原本听起来无特别之处的「维护既有产品」，换个角度，还是可以挖出价值。易言 之，在遵守诚信的前提下，嘴炮不犯法，不炮白不炮 :D 结论: 在下「没有那麽吸引人」的定论前，最好与人讨论一下，看看能否从不同的 角度切入；在不违反诚信的原则下，突显你的价值。 如果扪心自问有好好把事作好的话，通常很难会真的没有东西可以挖出来写 :) ※ 编辑: AmosYang (72.211.194.61), 01/28/2017 12:41:58 这也是无法以是非题来回答 :D 是我的话，我还是会放上去，但重点自然就不是「相关专业技能」，而是作事基本 态度。例如学生参加社团就是一个例子，社团不见得与专业技能直接相关，但若是 担任干部作出实绩，也是可以写。去担任社区义工也是一个例子，例如，想出什麽 办法让义工队伍作事流程改善，都是「作事能力」。 如上面的讨论一样，只要扪心自问有「把事作好」，那就应该一定有东西可以挖出 来写（因为，要「把事作好」，不外乎就是认真负责仔细，懂得思考轻重缓急，有 执行力、统率领导能力；是故，一定有某个角度可以看到你的成果与价值） 反过来想，这也是检视自己行事处世态度的机会，如果真的完全找不到好事来写， 那就得想想是为什麽。 :) ※ 编辑: AmosYang (72.211.194.61), 01/28/2017 12:58:43 若满足以下条件 1. 北美软体业（其他产业我不熟，不敢妄言） 2. 时间上能配合 3. 很明显有作过功课 我多半会帮忙看；收费就 pay-it-forward 就好，以後看到有别人很明显有作过功 课但差临门一脚的，就去踹他一脚 XD 把这一脚传下去 :D 反之，则无兴趣；网路上另有许多收费承包这类润笔业务的商家，可找他们 :) ※ 编辑: AmosYang (72.211.194.61), 01/28/2017 14:25:46 :) 如果觉得这是有帮助、经得起考证的正理，就帮忙散布吧 :) 好问题 :) 其实履历表写作与一般写作并没有差很多，就是从大量的思绪粗料中萃取出意念的 精华。易言之，可从「自由写作」开始，不管三七二十一就写下任何你能想到关於 该 course project 的任何事，用写的，用画的，都无所谓，重点是搜集材料。例 如: * 最後拿了几分／哪里被扣分／同学们平均表现如何 * 哪里觉得不太确定，後来证实是错的／对的／无关紧要的 * 哪里花了特别多的时间／试了好几次 * 遇到了什麽样的难关／如何解开 * 与人合作时发生的事情／沟通上的问题／行事效率 ...... 有了这些材料後，可以帮助自己看到，有哪些方向、特点是对你来说特别有趣、值 得回忆，特别有成就感（就像多隆对韦大人的景仰，有如滔滔江水连绵不绝），再 试着从那些角度切入。 反过来说，如果该 course project 完全让你「没感觉」（例如，就只是作了交差 了事），那…神仙难救 XD （你自己都无法相信、投入的事，在不违背诚信原则的 前提下，要如何令别人相信／感受到你的热情／作事能力／动力？ :D ） Ref: wikipedia 上对「自由写作」的说明 * https://zh.wikipedia.org/zh-tw/%E8%87%AA%E7%94%B1%E5%AF%AB%E4%BD%9C * https://en.wikipedia.org/wiki/Free_writing :) 新年快乐 :D ※ 编辑: AmosYang (72.211.194.61), 01/29/2017 00:35:50 是有听过有人主张不要写 summary, objective ，但我个人还是会写，但写的内容 会是求职信(cover letter)的两行浓缩版，而不是履历摘要。也就是用一、两行话 解释为什麽我是最适合这职缺的人（我的价值），而不是我的技能细节。 如上面原文里主张的，美式履历表比较像是一出纸上的舞台剧，是有一些「基本规 距」，但给作者很大的发挥空间，最後看你觉得要如何突显自己(self-promotion) ，你就照着你想要呈现出的戏剧效果去编剧，诉说你的故事。反过来说，台、日的 履历表「格」就像是食品成份表，讲究标准化；视文化、产业不同，这两种方法并 没有绝对的好坏，就看想招来什麽样的人材。 这也让我想到很久一阵子前，在这版上的笔战，我主张「只要不出格，在 ethical, professional, legal 的前提下，我不在乎求职者如何表现他自己；这 是他的舞台，我只是观众」，但另一方的意见则是主张「标准化、公平、量化」， 意指每个求职者都应在客观条件相等的测试方法下被评量。这两种方法也是没有绝 对的好坏，就看自己喜欢哪种文化。 结论: 应该不至於说有写没写 summary/objective 就是成败关键，最後还是看你 想为自己如何编剧。但如果要写的话，我建议以写 cover letter 的心态去 写，用一、两行话点出你最大的价值。 又，求职用的 resume 与 cover letter 的目的本来就是 self-promotion :D 那 就完完全全 100.00% 是在「老王卖瓜」；在守诚信的前提下，「自夸」就完全是 这类文案要达成的目的 :) （不然何必花那麽多精神去写 XD ） ※ 编辑: AmosYang (72.211.194.61), 01/29/2017 13:11:27 这取决於你打算如何写这出戏的剧本来诉说你的故事。易言之，如果你指的 「条列」是指像食品成分表一样的条列，那我不会如此去条列。与之前讨论过的 summary/objective 类似，我会这麽作： 1. 细读该职缺的叙述。 2. 归纳出三至五项该职缺最重视的特点／技能／经验。 3. 以两行左右的文字，描述我如何符合 (2) 所指出的特点，并以粗体字标出。 4. 在 Experience 里提到 (2) 所指出的特点时，也以粗体字标出。 （又，从另一方面来说，除了要标出最重要的重点，我个人会尽量避免使用粗体字 ；把粗体字保留给最重要的七至十个重点，减少视觉噪音。） 例如，假设一个软体业职缺一整页的叙述读下来，最後归纳为： * 任务：协助团队打造 _某系统功能Ｘ_ * 要三年专业经验 * 要会 .NET/C# * 要会 Git 版本控制 * 要熟悉敏捷开发 * 如果熟悉 ASP.NET/JavaScript/HTML/CSS 更好 再假设求职者是 * 作过 _某系统功能Ｙ_ ，与 _Ｘ_ 扯得上边 * 有四年 .NET/C# 经验 * 会 SVN * 有待过跑敏捷开发的团队 * 但对 ASP.NET/JavaScript/HTML/CSS 只有基础知识，实战经验少 那我个人会把以下这样一段话放在履历表的开头： * 4-year .NET/C# mid-level developer seeking opportunity to contribute lessons learned from _Y_ to project _X_; familiar with SVN version control and Agile development; intermediate knowledge in ASP.NET. 上粗体字 * 4-year .NET/C# mid-level developer seeking opportunity to contribute lessons learned from _Y_ to project _X_; familiar with SVN version control and Agile development; intermediate knowledge in ASP.NET. 看，很简单吧 XD （概念图片支援： https://upload.wikimedia.org/wikipedia/en/7/70/Bob_at_Easel.jpg ） 结论：基本上，如果读者看完这段仍无兴趣的话，那接下来写什麽大概都没有用了 ；反之，如果这段能引起读者的兴趣，他接着仔细读接下来的资料的机会应该会高 些。这也就是为什麽我主张「切忌一稿多投」；「多投」本身没有问题，问题在 「一稿」。除非你个人品牌响亮，不然求职时最好还是针对每个职缺微调优化你的 履历表与求职信。而这微调优化的过程，对接下来的面试准备也会有相当的助益。 ※ 编辑: AmosYang (72.211.194.61), 01/31/2017 07:14:29 ※ 编辑: AmosYang (72.211.194.61), 01/31/2017 07:31:15 ※ 编辑: AmosYang (72.211.194.61), 01/31/2017 08:10:08 ## 更正启事 在上段中的假设例子，本意是想把求职者的经历假设为「有四年 .NET/C# 经验」 ，但却写成了 > * 有四年经验 > * 会 C# 经 [Jimin Hsieh][11] 指出，这会让人误解， > Jimin.Hsieh > > 这样说，四年经验和会C#，并不等於，4-year .NET/C# mid-level developer， > 实际上是，两年C#和两年C++，这样说，一个人可能是Polyglot的， > 这样写可以吗？XD 是故，将原文修正为 > * 有四年 .NET/C# 经验 感谢 Jimin Hsieh 的指正。 [11]: https://www.facebook.com/Jimin.Hsieh ※ 编辑: AmosYang (72.211.194.61), 01/31/2017 09:41:16