【經驗談】中英文文檔工程師面試集錦 (更新于2021-03)

馬上要準備TW面試的小伙伴們,為你們奉上滿滿干貨:

  • 面試考核點
  • 英文TW面試題集錦
  • 中文TW面試題集錦

面試考核點

  1. 首先,作為TW,基本功一定得扎實。中英文寫作理論與基礎知識扎實,要講得出平臺遵照的寫作原則與規范 (English Technical Writing Guidelines)。面試時要能講得出來;筆試時,要充分運用。
  2. 其次,對各類文檔的寫作與評審流程有一個清晰的認識,能有條理地講述出來。對平時工作中的痛點及個人思考心得,也要講得出。

    《技術文檔工程師6大必殺技》一文中,我根據自己的經驗,給出了如何培養這些技能,可供大家參考借鑒。

  3. 對于以往工作中寫過的產品,要至少能有條理地講出它的功能與特點、面向的讀者群、最好還能講出你對產品技術的理解。
  4. 作為TW,與人溝通,團隊合作意識,做事的主動性都很重要。準備一兩個能體現你個人品質的案例。
  5. 最后,面試官會問你有沒有問題--“你還想了解職位或是公司的什么信息?”。我個人覺得這一點能反映出應聘者思維活的躍度與深度。假使你不太善于現場提問,那不妨提前準備2個。

前幾天,有位學文的TW進入二面技術面試,在網上問我:有點怵技術面試,該怎么準備?
我覺得這個問題提的很有代表性。的確,在技術面試環節,會有開發人員參與面試,目的是了解你對行業、技術的了解與熟悉程度。我想,即便是學理科的同學,也不一定專業對口,也一樣會有忐忑。
我的建議:面試前,不用盲目地到網上去學基礎知識,你要做的是到該公司的網站,充分了解該公司的產品,行業領域,在學習過程中,有些疑問,有時間的話,可以去追蹤與學習。沒有時間的話,就把這些問題記在心里,在面試時,也可能有機會與面試官就此進行交流。
不懂不可怕,怕的是不懂不愛學習。TW是一個要求不斷學習的職位,學習能力/好奇心/探究能力是TW非常重要的素質--這是我作為面試官時很看中的品質。

English TW面試題集錦

先拋點干貨。我不是個愛跳的人,所以前兩家公司,一家九年,一家7年。其間也沒有出去試試水。我在今年失業后,面試過幾家公司,其中有兩家文檔外包公司是招English TW。我大致回憶一下,招聘需求以及試題。此外,我也會講講上家公司(Moody's Analytics (MA) 的面試試題)以及作為APAC TechComm組的深圳招聘官,我在招TW時會關注些什么。

* 某國外外包公司為瑞典電信設備商招外包TW

  • JD:英文撰寫深圳研發中心產品手冊(網絡通信中用到的軟件加密認證軟件,如果我沒記錯的話)。
  • 電話面試:公司國內總經理英文面試,主要是介紹個人工作經歷,由此發散隨機問些問題,記得不清楚了,了解人的基本素質吧。
  • 第1輪:外包公司總經理電話面試,英文聊經歷、薪資要求,隨機擴散發問。
  • 筆試試題:
    • 寫一份打印機操作使用說明。(沒有給出更多的提示)。-- 考查基本操作類手冊的寫作手法,寫作規范功底。
    • 給出一個房間3D布局圖,要求給出房間布局描述。-- 考查作者的條理性,與語言文字的表達能力。
    • 給出一份現在文檔的前幾章,要求你提出改進建議。-- 考查你的寫作與編輯經驗。
  • 技術面試:
    測試、項目經理、產口經理分別面試
    • 聊以往的工作經歷。
    • 最大的挑戰是什么?
    • 講講你以前所寫產品的原理與工作流程。

* 港交所離岸開發中心招外包TW

  • JD: 英文撰寫研發文檔(港交所內部為英文工作環境)、中譯英、英譯中,寫英文宣傳文稿.
  • 線下筆試--給出一遍18頁的中文稿(講Block Chain原理),翻譯至少3頁。這個我準備了一周交稿,因為,我認為要翻譯得 準確到位,一定要對這個領域有一定認識,技術術語也要專業、準確。所以工作日的晚上,我在上網學習英文相關知識,并沒有做翻譯。周六日抽空翻譯了大約5頁,翻到一個概念完結處打住。
  • 面試--只有一個開發總監面試,聊對職位及該公司的看法,過往工作經歷,聊對股市的認識。
  • 現場筆試--還是翻譯,翻譯一份Block Chain技術實現的個人心得。基于我前一周的學習以及自己的網絡通信基礎,做得不錯,還指出了里面的描述性錯誤(或者是原作者的筆誤吧)。

* 英國軟件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 positive 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 have the product owner authorize 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 request, what we need is 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 of 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.
  • 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. 給出一份現有其它產品線的用戶手冊,讓你給出修改建議。

* Philips Healthcare ECR products在深圳招TW (非本人親歷,朋友轉述)

  • JD: Researching, interpreting, analyzing and writing, by interpreting technical source information and determining approporateness for inclusion into documentation and other content development. Collaborating with cross-functional teams, including Localization, Product Management, Engineering, Quality and Regulartory, to produce high quality and accurate customer documentation that ensures compliance with regulatory requirements. ... requirements: 技術寫作或相關專業。 5年以上產品技術文檔寫作經驗..
    1. HR二輪面試 2. 美國TWs電話群面 3. 美國TW Manager面試 4. 筆試
  • 筆試題為:寫一段英文文檔,介紹如何在Outlook中用Calendar發起會議邀請

中文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資料

      本來憧憬滿滿,筆試自我感覺也很好。但國內互聯網公司對年齡設的這道坎,讓我心塞,本以為TW崗位更看重經驗。退而思之,也只能說明自己還不夠優秀,不足以讓雇主動心放棄年齡的顧慮。那就繼續努力完善自我吧!!

每次面試都是一次修行!都是自己了解自己缺點,發現不足,重新認識自己,改善提高的機會!每一次面試又是一次緣分,我們可以靜靜的聽對方的故事和建議,思考對比自己的人生,不斷修正,學習借鑒!自我鞭策! --摘自微信文章《43歲,2017我的第15次面試-1中年海歸的下崗再就業自救寶典》,說出我的心理話!

相關話題
深圳文檔工程師-市場需求與薪資分析
各大招聘網站 (APP) 適用性評測
技術文檔工程師六大必殺技

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容