Try   HackMD

「0 到 100 的軟體工程師面試之路」摘要

我該刷題嗎? / 在面試之前 / 追尋自己想要的人生是一輩子的功課 / 刷題只是一種選擇

在問 “我該刷題嗎?” 這個問題之前其實應該要先問的是:

  1. 對現在的工作滿意嗎?想換工作嗎?

    人生就是在 optimize 整體的開心指數。

    因素
    ​​​​​​​ - 想要追求更高的薪資:是基於錢可以買到很多開心、錢可以解決房租/房貸壓力,帶來安心感讓人開心、讓女友老婆/投資在教育讓小孩以後開心
    ​​​​​​​     (很多人換工作完全一昧追尋Total Package,可能三年一跳就是薪資的Optimal solution,但是薪資只是影響你開不開心的其中一個因素)
    ​​​​​​​ - 公司文化
    ​​​​​​​ - 組上環境氣氛
    ​​​​​​​ - 同事個性/能力
    ​​​​​​​ - 工作內容 (新奇與否/對社會是不是有貢獻)
    ​​​​​​​ - 工時/Oncall與否 (花太多時間工作沒時間做該做的事 ex陪家人 顧健康長久下來造成的不開心可能遠高於高薪)
    ​​​​​​​ - 工作地點
    ​​​​​​​ - 工作上的心理壓力、責任、風險
    ​​​​​​​ - 工作Title
    ​​​​​​​ - 公司名氣(像是長輩聽到在某股價穩到不行的公司工作就會很高興,但是真的在內部工作的工程師卻痛苦得不得了)
    ​​​​​​​ - 公司旅遊點心午餐等其他福利
    ​​​​​​​ - 自我成長方面
    
    ​​​​​​​ 等等因素也都應該列入考量
    

    早點看清楚自己現在開不開心、目前哪裡讓你覺得無聊/或是覺得不滿、以及同一間公司未來會不會有機會變得更開心,也許就是要不要/需不需要換工作的答案。

  2. 想換去的公司面試需要刷題嗎?

    養成刷題習慣很重要的原因之一是:基本上大公司的軟體工程師職缺都會考,就算滿意現職或是想去的不考,可能有天會變得不滿意或是有一些其他改變,有刷題習慣的話就可以去其他公司拿個 offer 跟自己現職公司談條件。

  3. 花很多時間精力刷題順利換了工作,會比現在開心嗎?

    • 如果發現其實其他公司/或是其他公司做的事,也沒有很喜歡但現職又有些不滿:

      • 一是很多人會忽略或是羞於主動主管談談看有沒有改善空間,或其他比較滿意的運行模式可以work
      • 二是也是可以嘗試跟大主管說談談看換Team換主管之類的

      (胡立的這篇文章也是相當推薦的工程師職涯隨意聊:改變環境,而不是讓環境改變你)

    • 在不確定其他選擇的內容是什麼之前,一昧地為了追求高薪水而刷題換工作,也是有點過於極端,附上筆者很喜歡的一個小寓言故事,你用一輩子努力賺錢成為百萬富翁,然後呢?

    刷題只是一種選擇。

    很多優秀的工程師確實沒必要花大把的時間和精力刷題換工作:

    • 可能是超級滿意自己現在的公司
    • 可能是想把時間花在追劇打電動上山下海旅遊帶娃陪家人
    • 或是對刷題就是嗤之以鼻覺得工作上根本用不到刷題仔就是背答案仔
    • 或是自己的專業技能早就凌駕在leetcode之上根本沒必要當苦命刷題仔 e.x. 前端/後端/ML/Linux Kernel很熟/影像演算法/Android/IOS/割韭菜等等等等…

    不知道自己想要什麼是一件很正常的事情。

在你面試前一定要做的事

首先有一個不錯的文章可以先看一下(這篇是通用文章,不是針對軟體工程師的)
[心得] 面試時你應該知道的事

要準備開始丟履歷了,那必做的事情有:

好好研究JD(Job Description)

研究好JD是非常非常必要的一件事情,雖然很多JD的需求寫的很籠統,但把JD裡要做的事情的關鍵字搜一搜,就可以大致上猜出入職後要做哪些事情,另外,JD上的關鍵字如果有好好搜尋,在問面試官問題的環節也是非常加分的。

[請益] 新鮮人 Offer 選擇(Google/AWS/Tiktok

  • 只想去某家公司

    如果說你就是只想去某家公司(比如說谷歌),而且不太想離開台灣,但是又對最最純軟的東西才有興趣那很可惜的,仔細研究過台灣谷歌(目前的)職缺之後,可能會發現台灣沒有那些YouTube, Ad, Search, Map, 之類的Team的職缺。

    就筆者目前所知道的,台灣谷歌是Silicon (Pixel, Nest), Chrome OS, Cloud等等為大宗,這些Team有沒有開最最純軟的缺?也有!但是比日本的壓縮機還要稀少

    筆者最近就認識一位大神要做Silicon內部要用的網頁系統(缺如果稀少競爭就特別激烈,而且也比較可遇不可求)。

  • 你不開心你的主管也不開心HR也不開心的三輸局面

    如果沒有好好先看過履歷的JD,很有可能跟HR溝通要去面試哪個組的時候,HR也不能100%了解那些技術專有名詞,他們可能就會把你放到你沒興趣的組裡面,這樣就算錄取了,可能做了一下下就又想轉組,變成你不開心你的主管也不開心HR也不開心的三輸局面。

職缺這種東西時不時都在變化,各位讀者請自己好好打開職缺網站研究JD。

整理履歷

快樂社畜路:畢業後的後端開發求職準備

履歷如果能稍微針對要去的公司客製化一下是會比較好的。

Mock Interview:3-4遍以上

Mock interview 是在面試之前最最最重要的事情,必做!

如果是考刷題的外商公司的話一定要用英文mock過,面試前應該最少最少要mock過3-4遍以上,而且一定要找有實際面試經驗的朋友做 mock。

準備Behavioral Questions

就是在測試一個人「多有熱情想加入Google」、「和技術能力無關」、「是公司面試流程policy中的一個硬規定」,因為Google面試會刷題這就是一個大家都知道的事實了,所以他們可以很容易的透過一個人刷了多少題、刷得多熟練,來定量的了解到一個人他對加入這間公司的熱情有多少,透過這個衡量方式, 這間公司就能夠了解這個人是有多願意為了公司妥協自身的。

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

  1. 如果有要面Amazon,就專心準備Amazon的14 LP的BQ就好,其他公司都一定能用到,尤其對Amazon的話真的要好好花時間準備好故事,仔細想好以前在公司有哪些案例可以拿來回答那些很棘手的問題(像是處理衝突,跟主管意見不合,dive deep,hard decision,show initiative,ownership,customer focus之類的)
  2. 如果沒有要面Amazon,那還是專心準備Amazon的14 LP的BQ,只是故事不用準備的那麼多(也只要準備那些常常被問到的問題就好,像是最大的缺點/最大的失敗之類的)

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

了解面試流程

  • HR Phone Check → Online Assessment/Phone Interview → Virtual Onsite Interview → Result → Negotiate → Offer Letter
  • 大公司從跟HR打完電話到VO應該差不多都還會有一個月的時間。

分項目介紹:

  • HR Phone Check:通常兩三個禮拜之內HR就會打電話過來

    • 確認「組」和「grade level」
      HR會跟你聊天,確認你現在做的工作/會的技能,然後確認你想要以面試哪一個組和哪一個grade Level為主,在這個階段一定要看清楚要面試的組和 grade level (也先上 levels.fyi 查好 package)。

    • HR 一定是把你丟到最缺人 aka 最容易上的組
      HR 他們把你分流到哪裡也是有一點壓力在的,那種純軟或是更研發一點的Team肯定是比較搶手又比較競爭,可能面試cycle早就排滿了,所以相對來說變成其他 Team 機會就比較多。

    • HR 這關也有直接問一些基本的技術問題甚至考一些簡單的程式題的

  • Online Assessment/Phone Interview

    • Online Assessment 常見的平台是 hackrank/codility
    • 就是刷題
  • Virtual Onsite Interview:面試的重頭戲

    • Google:四關 3DSA+1BQ,一樣 L4 以下不考 system design(初級工程師從L3 開始)

    • Amazon:總共四關,每關都是一個小時,有15分鐘以上都在問14 LP(請見BQ篇文章)。

      剩下的技術時間也不一定全部都是考刷題:

      • 跟要去的team的主管聊天
      • 考專業知識跟一些比較像Design tag的 leetcode 題目,寫code的sytle、trade off考量、edge case考慮等等等等都很容易從這類的題目看出來
  • Result

    • Google TW

      • HC (Hiring Committee):

        一群獨立於面試官、想要你的主管、接手的HR「之外」的資深員工(不確定要多資深還是要是主管才能去當)組成的 Committee。

        HC可以拿到每個candidate每一關的所有表現(甚至聽說還有每個面試官過往的評價,這個人是不是本來就比較嚴格,常常給出比較低的分數之類的),去綜合評價這一輪所有的面試者,決定要收誰,降低因為某一關表現不好造成的bias。

        確保給 Approval 的 quality,決定 reject 或是 加面 或是 給 down/up level offer 或是 offer。

        好像是Google才有,Meta/Apple沒面過不確定。

    • Amazon TW(Ring)

      • VO 四關都由「你要去的組的人 + Hire你的主管 + 一些相關組的人 + 一個完全跟你不相關的Bar raiser」一起當面試官,沒有什麼HC之類的,大部分面試者都面完之後這幾個人會直接開會討論要發誰 offer 就發誰
        • Bar Raiser:Amazon面試的一個特點,他們會派一位和你的工作完全不相關的人來面試,目的是為了從旁觀者的角度來觀察候選人有沒有符合亞馬遜的公司文化、確保候選人可以提高團隊整體水平、並且防止因為太急著徵人而雇用不適任的員工。

      少掉了 team match 跟 hc 的過程,跟 Google 比起來速度非常快,先發offer贏一半

  • Negotiate

    • 後面文章會打的比較詳細,大家可以直接接著看
  • Offer Letter

    • 這部分好像沒什麼特別好分享的,後面文章會再提,有問題可以留言~

On board之後才是挑戰的開始

常常人們談論 FAANG 的風氣就好像 “人生在畢業之後一面就上FAANG然後就能一帆風順高枕無憂”希望讀者們也同時不要對外商大公司的生活抱持著太美好的幻想。

(就跟所有的考試一樣)就算常常會聽到那種抱怨是:誰誰誰沒刷題就上了、誰誰誰只刷幾個題什麼都不會還是進去了、誰誰誰工作能力不好只會刷題就錄取了⋯⋯等等等,以為誰都可以拿到好公司的offer以後就能開始輕鬆的美好生活。

隨著時間的推進,每個人終究都會被放在最適合自己的位子上

可能會發現大部分那些面試錄取的人,幾乎看不到他們工作的心得文,一方面其實是都蠻忙的,一方面是FAANG的生活可能沒有像youtube裡、辦公室導覽時介紹的那麼光鮮亮麗。同事產出可能都會超級高,不管是來自升等還是自我要求/職涯發展的壓力都是蠻大的,尤其是在矽谷景氣不好的時候砍人真的是沒在手軟,在今/明年這兩年實在是沒那麼好混。

筆者也是有蠻多在美國Google的同學每週的工時是遠超過40小時的

因為人才過剩,聽過更誇張的故事是同一個產品,交給好幾個不同的組一起做,看誰做的最好才能deliver,其他人等於白做工等等。

  • 軟實力才是硬實力

    筆者就稍微列舉一些自己覺得重要的項目,自己也沒有每項都能做到完美,希望能與讀者共同努力。

    • 溝通:不會溝通的工程師是糟糕的工程師,只剩下溝通的技能就是個FYI接線生也不太行
    • 野心:一點野心也沒有會是糟糕的工程師,充滿太多的野心會是不切實際的工程師
    • 向上管理/推銷自己:默默的做一堆事情但是沒有適時的推銷自己十分可惜,整天事情不做向上管理/推銷自己一定會搞的大家都很不爽
    • 把鳥事適時丟給別人的能力:把鳥事都默默扛下來顯然是不健康的行為,整天把鳥事丟給別人更是對團隊不健康的行為
    • 積極爭取薪資:做得很好不敢談加薪 vs 沒做什麼事整天覺得自己拿太少
    • 遇到挫折的調整:覺得自己都沒有錯 vs 一受傷就玻璃心
    • Adaptability:發現苗頭不對趕快閃人的能力 vs 讓自己忍受並適應環境的能力

    還有一些不太能量化的能力

    • 同理心
    • GRIT / 恆毅力
      • 意志力(grit):是追求長期目標的熱情(passion)與毅力(perseverance);不只是努力1周或1個月,而是持續長達幾年的努力,直到目標實現為止。
    • 找到好題目/值得做的題目的能力
    • 防潑屎能力
    • 解決衝突的能力
    • 人際關係/親和力
  • 工程師與刷題面試的安全感

    筆者從和電資本科系學弟聊天中聽到,他常常聽說那種從來沒念過相關科系的、其他甚至非理工學院的畢業生,刷刷題就能進大公司的故事,覺得去做軟體工程師可取代性很高沒什麼安全感。

    另一方面,筆者也在跟沒念過相關科系但是正在當工程師的同學聊天過程中,聽到他們覺得自己不是電資相關科系的,就算去刷了題面了試,感覺就是少了某些底子和自信在當工程師的過程中覺得很沒有安全感。

    這其實是非常弔詭的一個現象。不管本科系還是非本科系,都在覺得寫code很容易被取代很沒安全感

    臺灣的人才其實沒有自己想像的那麼差,只要能確定自己是用對的方法,往對的方向,和別人一樣地努力,等到回過頭來,其實和世界頂尖也不會相差太遠的。

    • 可以看看Huli和Dan Abramov的這系列文章

      從 Redux 作者 Dan Abramov 的文章談前端學習路線圖- Huli

      如何看待React 核心成员Dan Abramov 自曝年薪13W 美金? - 知乎

      大神沒有你想像中厲害:大神只是個稱號,終究還是個人,他們在那些擅長的領域很厲害沒有錯,可是不用把他們想成什麼都會。

      結論

      1. 所有領域本來就都學不完,這很正常
      2. 挑自己有興趣的部分學,然後成為專家
      3. 不要因為自己不會的部份而失去自信,而是要為了自己會的部分產生自信

      huli 文章節錄

      節錄自 Dan Abramov 寫的文章:

      People often assume that I know far more than I actually do.

      大家常以為我會的東西很多,但其實沒那麼多

      In this post I’ll offer an incomplete list of programming topics that people often wrongly assume that I know. I’m not saying you don’t need to learn them — or that I don’t know other useful things.

      這篇文章會列出一些大家以為我會但其實我不會的東西,但我不是說這些東西不需要學,也不是說我不知道其他有用的東西

      First, there is often an unrealistic expectation that an experienced engineer knows every technology in their field. Have you seen a “learning roadmap” that consists of a hundred libraries and tools? It’s useful — but intimidating.

      首先,大家對大神們總有一些不切實際的幻想,認為他們在各自的領域中什麼都會。你有看過那些列出一大堆工具跟函式庫的學習路線圖嗎?那很有用沒錯,但也很嚇人

      他列了一大堆自己不會的東西:

      1. 完全不會用 docker
      2. 對網路的理解知道有 IP 位置、DNS 以及有個通訊協定叫做 TCP/IP,就這樣了
      3. 不知道 Flexbox 跟 Grid
      4. 從來沒學過 SCSS/Sass
      5. 從沒設定過 HTTPS / SSL,只知道跟公鑰與私鑰有關

      他舉了二十幾個他不會的東西,有些其實跟後端比較有關,所以我挑幾個跟前端比較有關的(除了 docker)出來而已。

      舉了這些他不會或是不熟悉的技能,他希望大家看完文章後能理解的事情是:

      Even your favorite developers may not know many things that you know.

      儘管是你很崇拜的開發者,知道的可能還沒有你多(這邊原文 favorite 應該比較像喜愛?但我直覺翻崇拜比較貼近)

      Regardless of your knowledge level, your confidence can vary greatly.

      (這句不知道怎麼翻比較好)

      Experienced developers have valuable expertise despite knowledge gaps.

      有經驗的開發者儘管還是有很多不懂的,但至少他在某些領域上是專家

      老實說一開始看到那篇文章我有點嚇到,想說:「哇,原來我會的居然比 Dan 多,至少我用過 docker、我會用 SCSS,我也知道 TCP 的三次握手」,但仔細想想之後發現這句話只對了一半。

      對,在 Dan 提出的這些「不擅長」的領域中,我的確懂的比他多,可是這沒辦法推出:「我懂的比他多」,因為在那些他擅長的領域裡面,他有的知識一定屌打我。

      例如說對 React 的理解、對開源專案的理解、對 Redux 的理解以及對種種 UI 常見問題的理解,這些絕對都遠遠超過我。

      所以結論就是:有什麼好比的呢?

      除了一個人在幾乎所有的領域都比另外一個人厲害以外,似乎也很難說誰懂的比較多。儘管我們把範圍侷限在前端,前端還是包山包海包郵包了一大堆東西,為什麼一定要分出個高下?

      你如果讓 Dan 去做那種需要一堆華麗動畫跟特效的網站,還要加上複雜的排版,他可能會做得很差;可是你今天把他放到他擅長的 UI Engineering 的職位,他就能夠做得很出色。

      不需要因為自己懂的不多而沒有自信,相反地,你要為了你懂的那些部份而變得有自信。


    自信也是重要的軟實力之一,共勉之。

  • 關於「On board之後才是挑戰的開始」不錯的文章

    終於成功留下來,然後呢?──那些在「美國舒適圈」裏的台灣人,下一步去了哪裡?

    Re: [討論] 理工工程師轉職請益- 看板Soft_Job - PTT網頁版

    矽谷工程師=人生勝利組?光鮮故事的「真實下半場」

    軟體工程師的修煉與成長(7) — 如何突破資深工程師的天花板

    Google工程師的鄙視鏈

References