法律人到工程師,我的程式轉職之路(一):前言篇

kyo huang
kyo huang
Aug 9 · 9 min read
source: wallpaperscraft.com/catalog/art/

轉職,也就是職業轉換,從原來的工作、專長領域,放棄那些你已經駕輕就熟的事物,航向可能已知或未知的彼岸。

轉職是人生中至關重要的決定。一個人一生中實現轉職的機會大概不過一二,次數極少卻影響深遠。

所以,我們當然希望轉職是成功的、符合自身期待的。為了達到這個目標,我們要有方法,把心力用在對的地方。

這就是本系列文章的寫作目標:記錄我轉職過程的經歷與其中的心得和方法。好的,不好的,都會提到。好的方法可以參考,而不好的,則務必要小心避開。程式學習路上的坑非常多,有些錯誤,讓別人(包括我)去犯就好。

這是一個系列

如果你期待的是一篇3000–5000字的文章便總結完整個轉職的所有重點,顯然我沒有這個能力,所以我打算把它寫成一系列的數篇文章。

會這麼做的原因有幾個。首先,我的轉職過程確實比較長,為期1年4個月,而且是沒有工作的全職準備。前後經歷過幾個階段。過程和你看過的工程師轉職文相比,顯然更崎嶇、更不順遂一些,所以可以寫的東西也比較多。

其次,這系列文章偏重的部分可能也會和一般的轉職文略有差別,我並不打算一一詳細說明哪些技能最重要,怎麼學最好最有效率云云,不是不會提,只是不會花太多的篇幅。

相對的,在製作履歷和求職的部分,則預計會佔掉3–4成的文字量,我覺得這部分非常重要,但一般文章容易忽略或草草帶過。

有趣的是,在這次轉職之前,我既沒有寫過履歷,也沒有求職面試的經驗(打工不算),這部分的內容全靠自己學習和之後的實戰體會得來,或許有幾分說服力。

我也會分享一些理論和實際上的差距 — — 履歷求職教學文傳達的精神與內容有時接近理想,令人深表贊同,但現實往往相對骨感,勢必要做一些修正。

總之,這是一個系列文,能否完成它對我也是一項挑戰。

背景與自介

還是不免俗地先自介一下,雖然大部分並不重要,重要的部分我會特別強調。

我是法律系畢業生,退伍後和大多數有意繼續走這條路的法律人一樣,就是考試、考試、還是考試。耗費了不少時間全職準備,終於考上書記官,做了5年多,覺得自己無法堅持到退休,幾經考慮後決定辭職。

辭職歸辭職,仍舊跳不出法律的框架,繼續準備律師,過程就不提了,前面的文章也稍為講過。

從前年12月27日律師確定落榜開始,就是我廣義的轉職起算日,但原則上我還是會用進入資策會的第一天開始算,2018年1月22日。

最後是唯一重要的部分。準備書記官,花了近2年半,因為第二次才考上。準備律師,也足足花了半年。所以我和一般人最大的不同是,我有相當豐富的大學畢業後仍全職自學的經驗,這說起來也是法律系的特色與悲哀吧。

這樣的差別讓我在程式的「自學階段」,對於該怎麼做比較好、比較有效率,而且能持續,是相對有想法和具體做法的;一般人如果直接自學想轉職成功,難度可謂非常高。

我會從一般人的角度出發,探討全職自學常見的困境,而不會預設大家就是很有經驗的自學者,這點還請放心。

為什麼要聽我說?

比起自我介紹,讀者應該會更想知道為什麼我有資格寫這個主題,在此就不廢話,直接先講成果。今年5月求職為期2星期,總共投了約120家,收到15個面試邀請,推掉8家,面了7家,最後拿到3個offer。

乍看這些數字也沒什麼的過人之處,確實。不過就我目前看到的轉職文中,8成都是前端工程師,畢竟前端需求最大,轉職成功率也最高 — — 看看那些精美的前端補習班。而我是走後端、資料工程,轉職難度或許還是高一些些的(尤其是資料工程)。

就得到offer的「質」來說,我個人覺得滿意。後端和資料工程都有不錯的選擇,所以面完7個就止步了,待遇也和我離職書記官時差不多,以無經驗轉職的新人而言,已經滿足。

畢竟軟體業也存在大量的「免洗工程師」,即乙方專案公司的工程師,作為資訊人員駐點到甲方,做一些重複性很高的事務,比如銀行的資訊系統維護。這些工作通常薪資和技術要求都不高,我相信那不會是你轉職的目標。而我們所謂的轉職成功,顯然也不是指得到這樣的結果。

不過話說回來,我想可以自己寫這個主題的最大理由還是:我的轉職過程並不順利,既曲折又費時(全職準備也很花錢),所幸最後堅持了下來。這些錯誤與痛苦才是比較值得一提、能對讀者有幫助的。我會在回顧時一併呈現我的看法與價值觀。

普通讀者與目標讀者

寫這個系列文章,出發點固然源於對文字的練習與經驗分享。但在讀者的辨識與選定上,我有非常明確的考量,基本區分為兩種。

第一種,普通讀者。看文章主要出於好奇與消遣,覺得寫得好就看,沒有立即的幫助也無所謂,主要重視心靈層面上的獲得與滿足感。在大部分的時候,我也是屬於這種讀者,

第二種,目標讀者。是本系列文章所圍繞的重心,可以說,這些文章在最終評價上的高低良窳,就是由這群目標讀者所決定的。

之所以要特別提出來講,原因很簡單,就是要明白表示,這系列文章真正關注的就是目標讀者們的疑惑、困境,與需求,接下來的所有內容也都會是如此。所以,如果對程式毫無興趣,也沒有轉職的打算,或許看完這篇前言就足夠了。

目標讀者描述

符合目標讀者的描述,這些文章對你才真正有價值。

本系列鎖定的目標讀者大致分成兩種,不過兩者差別不大。第一種就是以我自己為典型:非資訊科系出身,也已經在非資訊領域工作多年,基於對職涯的規畫而決定轉職,並選擇投入軟體工程的懷抱。

第二種則是非資訊科系的大學畢業生、準畢業生,或大學畢業一、兩年,顯然對就讀科系的領域沒有熱忱,已確定不繼續走下去,而對程式有興趣,考慮改行當軟體工程師的人。

誠如前面所言,兩者的差別不大,真要說的話,差別只在「時間」對前者 — — 也就是30歲以後才決定轉職工程師的人 — — 難免相對嚴苛。我認為需要更慎重的衡量,與更仔細地規劃。以免轉職雖然成功,卻發現後續走得比想像中辛苦,屆時再想「二轉」就十分費力了。

而剛畢業的新鮮人,在職涯方向的選擇上可以犯錯的餘地總是比較多,這對每一個人都一樣公平,差別只在於自己有沒有好好把握過這些「試誤的機會」而已…恩…我承認我沒有。

最低限度條件要求

無論是哪一種目標讀者,對於「成功轉職」這個總目標,我希望你願意拿出來的交換條件都是差不多的,那就是:時間。

足夠的時間。

具體而言,至少需要6個月的時間,最好是完全空白、可以自由運用的6個月。

6個月這個數字究竟是怎麼得來的,大概有三個參考。其一,資策會各類程式的轉職養成班,幾乎都是以5–6個月為期,時數大概是500–600小時左右。

其次,縱觀各篇轉職心得文,大概也都需要半年以上的時間,這幾乎是一個最小公約數。而且別忘了,會發心得文的,也意味作者正是成功轉職的那一小部分倖存者。一樣花了半年但失敗的,並不會告訴你。

最後是我個人的看法:真的就是需要這麼多時間。如果讓我重來,時光倒流並清除所有關於程式的記憶,我推估需要6–8個月的時間才能回到目前的水平,這是在不走彎路的情況下。

時間與牠們的產地:如果我無法全職學習

到此常見的問題可能是:那我無法拿出完全自由運用的6個月該怎麼辦?因為我要工作啊!我一邊工作一邊準備可以嗎?

這是一個不容易回答的問題,因為每個人的狀況各不相同。不過有一個化繁為簡的評估方式,就是用時數來計算。

你需要600–800個小時。

咦,前面不是說資策會的課程通常就500–600小時嗎?那怎麼不是這個時數?沒錯,但那是「密集全職學習」需要的時數。當你的時間相對零碎,還有生活上的瑣事會不斷介入、干涉時,你的學習效率會不可避免地下降,所以整體用時只會上升。

最殘酷的不是用時的上升,而是整個過程需要面對持續且漫長的意志力消磨,這對任何人而言都是十分嚴峻的要求。換句話說,如果全職轉職的成功率是50%,那麼兼職轉職的成功率大概只剩5%。

附帶一提,若你必須一邊工作一邊準備,這段轉職過渡期,最好也不要超過兩年。換句話說,如果接下來的兩年內無法拿出至少600小時學程式,那工程師轉職計畫建議還是先擱置比較好。因為這樣真的太辛苦了,絕對還有別的選擇,程式的門檻終究是相對高的,這和智力無關,投入大量時間是硬條件,就像考律師一樣。


花了兩大段來告訴你至少需要6個月或600小時,不知道你是否覺得有點囉嗦了,確實如此。不過這個前提真的很重要,有足夠的時間才會有良好的產出,在時間允許的前提之下,你才能夠好好發揮你的耐心與堅持。

主論述的層級

如前所述,這個系列不會詳細地告訴你什麼技能具體該怎麼學,有哪些技術上的重點等等,這畢竟是技術教學文在做的事,而我們只是轉職分享文。

所以整個論述上的層級是:比技術學習再高一層,專注在轉職具體怎麼「進行」:大概要做些什麼、有什麼樣的手段、工具選擇、抱持怎麼樣的心態會比較好、以及怎麼堅持。

工程師,什麼樣的工程師?

這裡指的工程師,自然是軟體工程師,簡單講就是你要寫程式啦!

雖然對一般人而言,程式只有一種,就是亂碼;寫程式也都是在做同一件事,就是製造亂碼。但事實是軟體工程師還是有相當多樣的分類。

所幸,作為一個轉職者,我們尚且不需要知道太多。基本上只要知道前端、後端這兩個大方向就足夠了。至於全端,就是前後端的綜合體,聽起來很厲害,但一般認為還是從前後端先選擇一項專精會比較好,除非你一開始就打算當一個接案soho工程師。

前、後端的具體差別與需要的技能樹,隨便Google一下就有了。在踏入這個領域之前,我想你也只能就這兩者選擇其中一個切入,作為轉職的出發點。其餘什麼DevOps啦、系統底層開發啦,暫時都與我們無緣。

我如何選擇?你如何選擇?

前面有稍為提過,前端工程師是非本科系轉職的大宗,因為需求最大,所以轉職成功率最高,以致於坊間的單一主題補習班幾乎都是前端補習班。

但單從成功率來選擇恐怕是悲劇的開始,我們還是要考慮到自身的特性與偏好。想當前端工程師最好對使用者界面呈現方式與美感有一定程度的追求(偏執?);後端則適合著重「實現功能」的人 — — 或是對前端興趣不大的人。

究竟該怎麼選擇,我也無法給一個明確的標準,恐怕也不存在這樣的一個標準。但我覺得選擇並不真的那麼難,因為走前端也不可能完全不碰後端。走後端也偶爾需要做做界面;而作為轉職學習者的我們,本來就應該全部都接觸到,你完全可以在學習的時候問問自己的對這些事物的感受,之後再決定方向就可以了。

而我畢竟選擇了後端、資料工程,在經驗與論述上難免會有所偏向,對想轉前端的讀者或許會打一些折扣,雖然我覺得影響不大。畢竟這系列還是以轉職「軟體工程師」為主軸。

系列基本架構

  • 前言篇
  • 資策會篇
  • 自學篇
  • 履歷篇
  • 求職篇

好,廢話不多說,我們可以開始了。

kyo huang

Written by

kyo huang

法律人,現在是熱愛Python的小書僮

Code and Me

我的程式與學習探索

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade