马上要准备TW面试的小伙伴们,为你们奉上满满干货:
- 面试考核点
- 英文TW面试题集锦
- 中文TW面试题集锦
面试考核点
- 首先,作为TW,基本功一定得扎实。中英文写作理论与基础知识扎实,要讲得出平台遵照的写作原则与规范 (English Technical Writing Guidelines)。面试时要能讲得出来;笔试时,要充分运用。
- 其次,对各类文档的写作与评审流程有一个清晰的认识,能有条理地讲述出来。对平时工作中的痛点及个人思考心得,也要讲得出。
在《技术文档工程师6大必杀技》一文中,我根据自己的经验,给出了如何培养这些技能,可供大家参考借鉴。
- 另外,作为TW,与人沟通,团队合作意识,做事的主动性都很重要。准备一两个能体现你个人品质的案例。
- 最后,面试官会问你有没有问题--“你还想了解职位或是公司的什么信息?”。我个人觉得这一点能反映出应聘者思维活的跃度与深度。假使你不太善于现场提问,那不妨提前准备2个。
前几天,有位学文的TW进入二面技术面试,在网上问我:有点怵技术面试,该怎么准备?
我觉得这个问题提的很有代表性。的确,在技术面试环节,会有开发人员参与面试,目的是了解你对行业、技术的了解与熟悉程度。我想,即便是学理科的同学,也不一定专业对口,也一样会有忐忑。
我的建议:面试前,不用盲目地到网上去学基础知识,你要做的是到该公司的网站,充分了解该公司的产品,行业领域,在学习过程中,有些疑问,有时间的话,可以去追踪与学习。没有时间的话,就把这些问题记在心里,在面试时,也可能有机会与面试官就此进行交流。
不懂不可怕,怕的是不懂不爱学习。TW是一个要求不断学习的职位,学习能力/好奇心/探究能力是TW非常重要的素质--这是我作为面试官时很看中的品质。
English TW面试题集锦
先抛点干货。我不是个爱跳的人,所以前两家公司,一家九年,一家7年。其间也没有出去试试水。我在今年失业后,面试过几家公司,其中有两家文档外包公司是招English TW。我大致回忆一下,招聘需求以及试题。此外,我也会讲讲上家公司(Moody's Analytics (MA) 的面试试题)以及作为APAC TechComm组的深圳招聘官,我在招TW时会关注些什么。
某国外外包公司为瑞典电信设备商招外包TW (前同事内部推荐)
- JD:英文撰写深圳研发中心产品手册(网络通信中用到的软件加密认证软件,如果我没记错的话)。
- 电话面试:公司国内总经理英文面试,主要是介绍个人工作经历,由此发散随机问些问题,记得不清楚了,了解人的基本素质吧。
- 第1轮:外包公司总经理电话面试,英文聊经历、薪资要求,随机扩散发问。
- 笔试试题:
- 写一份打印机操作使用说明。(没有给出更多的提示)。-- 考查基本操作类手册的写作手法,写作规范功底。
- 给出一个房间3D布局图,要求给出房间布局描述。-- 考查作者的条理性,与语言文字的表达能力。
- 给出一份现在文档的前几章,要求你提出改进建议。-- 考查你的写作与编辑经验。
- 技术面试:
测试、项目经理、产口经理分别面试- 聊以往的工作经历。
- 最大的挑战是什么?
- 讲讲你以前所写产品的原理与工作流程。
- 面试结果:“新郎”发了喜帖了,但"新娘"不是我,是一位在中兴华为做过TW的前同事。
- 自我分析:与这是我七年来也是失业3个月来的第一次面试。我觉得电话面试时,太轻敌了,按招聘官头天晚上的电话:不用准备,顺便聊聊。我连个人的简历都没看。英文自述时,有些磕巴,这点自我感觉不太好。所以现在面试前,我都把英文简历多读几遍,自我做个rehearsal。任何面试机会,都要全力以赴,做足准备。
港交所离岸开发中心招外包TW (HR主动联系)
- JD: 英文撰写研发文档(港交所内部为英文工作环境)、中译英、英译中,写英文宣传文稿.
- 线下笔试--给出一遍18页的中文稿(讲Block Chain原理),翻译至少3页。这个我准备了一周交稿,因为,我认为要翻译得 准确到位,一定要对这个领域有一定认识,技术术语也要专业、准确。所以工作日的晚上,我在上网学习英文相关知识,并没有做翻译。周六日抽空翻译了大约5页,翻到一个概念完结处打住。
- 面试--只有一个开发总监面试,聊对职位及该公司的看法,过往工作经历,聊对股市的认识。
- 现场笔试--还是翻译,翻译一份Block Chain技术实现的个人心得。基于我前一周的学习以及自己的网络通信基础,做得不错,还指出了里面的描述性错误(或者是原作者的笔误吧)。
感觉招聘官/接待人员在招聘礼节上做得不专业,一杯水都没倒给我。 - 面试结果:总监反馈:Joy's Performance is Pretty Good. 但在与外包公司谈薪资时,一开始同意,后面就一直拖着说在讨论。
(11.17. 外包HR又给我打电话,问我近况,说要给我个交待:仍没有招到合适的人,每周都在讨论如何处理我的情况。我当时在大巴上,实话实说,拖太久了,我决定还是安心做我的大数据。专心做事,才会有所收获。)
英国软件startup公司的邮件面试
A fictional scenario for a technical writing exercise
- It's up to you to decide how long it needs to be, but conciseness is in general a virtue.
- Present some notes on how you went about the writing task:
-
- what your process was
-
- why you made any decisions you did
-
- any assumptions you made
-
- anything else you think we should know
-
某软件公司面试问卷
- An explanation outlining how you feel you meet the requirements of this role.
- A 250 - 500 word essay explaining what you feel are the biggest challenges in being a technical writer and the strategies you have developed to overcome them. Please provide specific examples from previous jobs. Focus on 3-5 challenges in your answer.
My answer for your reference:
As a technical writer, what are the pain points you ever get? The following I list a few I ever encountered in different writing phases and share how I handle them.
Planning -- > Writing -- > Review --> Publishing- Planning
How to draft an outline for a guide?
Solutions: Gain an overview on the product by reading feature proposals and attending feature-related meetings.
How to have a clear understanding of my audience?
Study user persona, and put myself into users' place, and talk with product managers. - Writing
How to present the document in a clear, concise and professional language?
When I entered Moodys Analytics in 2011, I stepped into the Financial Technology domain from the previous Telecom domain. One of my work is to co-author RiskOrigins User Guide for staff in financial institutions. I did the following to get myself up to the speed, and completed my first document in this company with very position feedback from my manager:
Get familiar with the company's writing style. I read Moodys Style Guide in details. Plus, I asked my manager to recommend a similar User Guide from other product lines and saw how these writing rules are applied. I discussed constantly with my manager and colleagues to get to know the reasons behind these rules.
Getting familiar with the product. I read through feature proposals, specifications, user stories for the product. Attended daily scrum, feature proposal review meetings, and show-and-tell meetings to get myself submerged into this product. I talked to product managers about features to dig out why users need a feature and how important it is to users.
Gather terminology used in this industry. I asked my manager for our competitors' names and famous industry journals and wiki links. In this way, I was getting familiar with the terminology used this industry. - Review
How to have the review parties review my documents in time and with quality?
This is really a headache for writers. It time permits, I can write a long article to talk about the ways that I have ever used and its effectiveness.
The following I'd like to share two stories:
Thumb of rules is to gain support from the upper manager.
For guides targeted at technical audience, review comments from QAs and sometimes Developers are valuable. But at the project planning stage, project managers often neglect the review efforts in QAs and Developers' workload. What I (my team) did is to come up with a documentation development plan at the project planning phase where we list all guides to be released for this release, required review parties, input that we need, and the timeframe for the review. We have this plan reviewed and approved at the project planning meeting, and the product owner authorized the project management to assign review efforts (manpower) to each user story in the Rally system. This really helps improve the review efficiency.
To give a workable review schedule to book reviewers' time
RiskOrigins customers complained about the usability about the User Guide. They wanted to see more real-life examples for operation tasks not the step-by-step procedures. Based on this requirement, we need to have the SMEs to review each chapter in the guide and provide samples where there is a need.
SMEs are based in London and normally not reviewers to user documents. As the lead writer of this guide, I need to work out a new way. SME manager is also the owner of this product and I talked to her when she was in Shenzhen on business trip, and she was very supportive to this idea and gave me the name list for each module. I came up with a detailed review schedule for each chapter (module) including when the chapter will be ready for review and when we expect the review comments and examples to be back. Then I sent this schedule to SMEs for confirmation respectively and made adjustment based on their feedback.
Meanwhile, I created a wiki page on our Confluence platform for the cooperation. I put the confirmed schedule there and created a table to track the writing progress and review status.
- Planning
- More information on the more significant technical documentation that you have written – for each, please include size of the document, total effort, your specific responsibility (for example: author, reviewer, editor, and so on), complexity of the document, your approach to planning the content, and how you ensured quality of the final result.
MA当年在深圳招TW:
- JD:为基于workflow的风控软件产品招TW,用英文撰写各类产品用户手册。英文、计算机、经济类专业皆可。
- 第1轮英文电话面试--SG与SF TechComm Director与Manager分别英文面试,决定是否move onto现场面试环节。
- 第2轮现场面试与笔试
- 现场面试--APAC TW组英文群面。介绍职位需求,公司,开始提问,考核点:了解你对英文写作规范的认识与经验,你以往的文档写作流程,团队合作能力,文档工作中的难点及你的解决办法。聊得开心的话,会找到不少共鸣点。
- 现场笔试--1. 给出了一节操作说明(半页),进行优化。2. 给出一段描述类产品描述,进行优化。3. 给出一份现有其它产品线的用户手册,让你给出修改建议。
中文TW面试题集锦
异地某金融云平台中文TW面试 (TW圈内部推荐)
- JD: 推荐人给的JD与HR的JD有些出入,HR的版本:各种产品的文档、教程、最佳实践 等形式的完整内容体系,为用户快速上手使用产品提供完整的支撑。要求:信息类毕业(计算机,信息工程,软件,自动化,电子工程,通信,数学等)或者有IT从业经验3年以上
- 第1轮电话面试--由TC组文档工程师面试,简述工作经历,了解日常文档写作版本管理、TW写作与人员管理心得。聊得很投机,从一开始的小紧张中放松下来,侃侃而谈。在这样一个小众行业,有人能懂你,认同你的做法,顿时有惺惺相惜之感。
- 第2轮晚间邮件笔试--收到邮件笔试试题,晚上收到花了近3小时做完(要求2小时,可是TW的职业习惯和这个岗位的高匹配度,让我认真应对)。试题分几大部分:
- 选择题:考查基本英文文法
- 改错题:考查英文技术写作与编辑技能
- 中译英翻译题--英文翻译技能
- 中文编辑试题
考题出得挺不错,方方面面都有,难度于我不大。唯一觉得做得不太理想之处是:英文翻译。我历来阅读比翻译做得多,所以,在翻译上,我通常要花较长时间去推敲才出得了精品。
- 第3轮下午电话面试--我觉得是TC组Manager角色吧。简述工作经历,聊文档写作流程,文档组角色设置、概述目前所做产品,TW职业发展经历与考虑、如何面对年青我二十岁的开发相处。展开聊了一个半小时。结合第1与3轮面试,两位TW同行都很nice。回过头来看,我可能在某些问题的回答上,没有换位站在面试官的角度体会出问题的用意,一聊high就一股脑什么都倒 切记:面试的目的是找工,要谨记这是找工谈话呢!但也要时刻保持稳重与谦和,Don't jump the gun,尽最大能力展现自己对这份工作的热忱与投入 。
- 面试结果:HR发来邮件拒了我。评语是:您的学识和资历给我们留下了良好的印象。 遗憾的是,您所应聘职位的要求与您的实际情况不太符合,因此暂时没有机会与您合作。我们已经将您的资料列入人才储备档案,希望我们今后有共事的机会。
- 自我分析:能进入第三轮,起码说明我的写作基础得到了认同,增加一次笔、面试体验,个人信心与应试能力都得到了提高,又多了一份体验收获,虽说是以失利结尾,不过,也算是一次很有意义的体验!
对于失利,我觉得:优质公司职位候选人一定不会少,从HR角度考量,如果是一个较为junior的职位+异地就职+中年女性,我是没有优势的。高处不胜寒,起舞弄清影,何似在人间
某云平台中间件中文TW笔试
JD: 云平台中间件产品的文档。要求:信息类毕业(计算机,信息工程,软件,自动化,电子工程,通信,数学等)或者有IT从业经验3年以上
-
邮件笔试:约定时间收到邮件笔试试题,要求在2小时内提交。试题分以下三大部分:
- 文档优化改写 (如果没有相关产品背景,做起来会找不到北。)
- 撰写指定平面几何图形的绘制步骤
- 翻译几段平台相关的Marketing资料
-
笔试结果:因为互联网公司只招35岁以下的员工,本次笔试是我通过争取,打动了文档组经理,特别给我的一次笔试机会。但笔试过后两周,文档组经理遗憾地告诉我:她没能说服她的boss(不是TW出身)。
本来憧憬满满,笔试自我感觉也很好。但国内互联网公司对年龄设的这道坎,让我心塞,本以为TW岗位更看重经验。退而思之,也只能说明自己还不够优秀,不足以让雇主动心放弃年龄的顾虑。那就继续努力完善自我吧!!
每次面试都是一次修行!都是自己了解自己缺点,发现不足,重新认识自己,改善提高的机会!每一次面试又是一次缘分,我们可以静静的听对方的故事和建议,思考对比自己的人生,不断修正,学习借鉴!自我鞭策! --摘自微信文章《43岁,2017我的第15次面试-1中年海归的下岗再就业自救宝典》,说出我的心理话!
相关话题
深圳文档工程师-市场需求与薪资分析
各大招聘网站 (APP) 适用性评测
技术文档工程师六大必杀技