面試心得: 台積電TSMC technical writer

面試時間: 2022年12月底

難度: 2/5

推薦度: 3/5

過去TSMC曾經徵才的對象比較類似特助或翻譯,PR writer,但2022年底的這次是真的technical writer,專門為軟體和內部IT單位寫api文件網站。TSMC的IT單位(ICSD)有用jira和Confluence,和一般的軟體公司比較接近,與晶圓半導體產線端的沒有什麼直接關聯。

面試前會填寫不少資料,而且都是留在它們HR資料庫裏面的,建議把自己重寫好的履歷和taleo的帳號密碼都存起來。面試主管就一個人,他解釋TSMC 的IT專案是一群又一群的工程師輪流改動台積電內部的IT系統,也已經上雲。所以並不是如一般的公司固定和一群或幾個單位的後端工程師合作。每次都和不同的人合作,這會增加technical writer的心智負擔,按照這個規模,差不多每個月都是不同的一大群人在做系統。這幾乎等於是每個月都在換公司的程度了吧?

透過Teams面試很快,大約不用20分鐘。對方特別注意的部分是"有沒有架站或寫網頁的能力",這部分我很老實說沒有,對方看來也沒有培養或利用現成網站做邊雇用邊學的意思。對方強調這個缺必須在新竹工作,目前沒有遠端,我的面試大概就在這附近結束。 

我面試完才想到,其實他要的東西比較接近slate或市面上已經有的readme.io。研究一下slate必須靠doc as code來完成,也就是在每一個開發者的repo裡面引入slate,並且透過開發團隊的git來持繼作保存版控,而不是另外分別存著。

比如gitlab的網站和教學,完全是以git去存MD語法的內容 https://about.gitlab.com/company/culture/all-remote/people/  。這很類似MD化的維基百科。這種方法在實際撰寫時也必須考量到怎麼分工,對於會馬上過時的小資訊,就不能這樣隨便更新。要怎麼確定每次變動的內容會在一個範圍內,比較好做文件維護。畢竟merge conflict在這邊會更明顯,雖然說開發者能夠自己用MD語法來寫,但以我對開發者的認識,它們心中的目標和實際去做的一定有不小落差,只是MD語法字串組成的文件要怎麼符合隊此時api的設計理念,才是實際的挑戰,這個api的設計如果依據開單系統上的規劃那倒好辦,就怕是跟規劃的行為完全不同。

 

雖然我沒試過,但具體的做法這邊有影片。過程中會需要JsonPlaceHolder來生成暫時的假api,如果你目前沒有api可以做實驗的話(最好也是別用正式的來練習)

TSMC想要的api documentation應比較接近上面這種。簡單的說,是利用template engine能夠產生每次的api文件,最好能有簡單的語法,所以是MD語法。

Postman推出了另一種方式,但經過了一年多的觀察,我覺得似乎還不是很受歡迎。因為大眾對於文件的想像是,寫在那邊的東西不會有錯,至少版本對了就沒問題,不用擔心還會被偷改或不承認。不會沒有版本號或混在一起忘了更新版號。postman好像沒想這些問題,單純執意想繼續擴大自己工具的生態系。


我雖然不是開發者,但會在這段時間自己試試看這兩種方法,並把成果給大家看看。希望能有滿意的效果,這對大家的技能提升或解決開發團隊的眼前文件流程難題也有幫助。



留言