# BQ ## 自我介紹 各位面試官好，我是劉冠廷，畢業於中山大學金融創新產業碩士專班，藉由財務接觸資料科學，再從資料科學決定踏入軟體工程師的職涯。 由於嚮往親手打造方便易用的數位產品，也希望藉由科技的力量對社會有所幫助，所以決定以前端工程，作做為我的起點 在 2022 的 下半年，我加入火箭隊培訓營進行全職學習，在教練引導之下，規劃學習目標，成為獨當一面的工程師。 在最後的結訓專案中，我和另一位夥伴，選定以電子名片作為核心主題，這個專案有完整的名片編輯器，以及方便的名片管理功能，使用 React、Redux 還有 Next.js 進行前端開發，其中也涵蓋貴司的職務需求 同時我也兼任了後端開發的角色，使用 Express.js 和 MongoDB，開發共 39 支 API 身為具備後端知識的前端工程師，我認為自己能換位思考，在考慮可行性、合理性之下，與後端夥伴溝通協作，再加上先前有擔任過數據分析師的經驗，對於資料處理跟分析過程，具備一定的掌握度，這些跨領域的思維，都是對跨部門合作非常有幫助的 最後，在個性方面，我喜歡學習新知、分享知識，除了架設自己的技術部落格，也曾在火箭隊進行短講，我認為自己適合組織扁平、快速迭代的公司，希望和同事互助合作、一起成長 希望可以成為 以沛的一份子 謝謝 ## 自介一分版 您好，我是劉冠廷，畢業於中山大學金融創新產業碩士專班，由於嚮往親手打造方便易用的數位產品，也希望藉由科技的力量對社會有所幫助，所以決定從資料科學轉換到前端工程師的職涯。 在 2022 的 下半年，我加入火箭隊培訓營進行全職學習，在最後的結訓專案中，我和另一位夥伴選定以電子名片作為核心主題，使用 React、Redux 還有 Next.js 進行前端開發，同時我也兼任了後端開發的角色，使用 Express.js 和 MongoDB，開發共 39 支 API 身為具備後端知識的前端工程師，我認為自己能換位思考，在考慮可行性、合理性之下，與後端夥伴溝通協作，再加上先前有擔任過數據分析師的經驗，對於資料處理跟模型建置，具備一定的掌握度，這些跨領域的思維，都是對跨部門合作非常有幫助的 最後，在個性方面，我喜歡學習新知、分享知識，除了架設自己的技術部落格，也曾在火箭隊進行短講，我認為自己適合組織扁平、快速迭代的公司，希望和同事互助合作、一起成長 ## 為什麼想從資料科學轉職前端工程師？ 資料科學是一門很有趣的領域，需要集結統計學和程式的能力，將資料挖掘出 insight，那時候在公司的業務上有使用 Python 的地圖套件，畫出銀行分行在地圖上的分布，還有一些重要地標，比如說科學園區、競行分佈，來看哪裡適合設立新分行，那時就覺得能做出前端互動的功能是一件很酷的事 所以從那時起，下班閒暇的時候，我開始從 udemy 自學 web 開發，發現自己真正喜歡的是，實際親手打造一個功能或是產品，再加上軟體工程師的領域，風氣比較多元自由，很適合我的理想，於是在兩年期滿決定加入火箭隊培訓營全職學習 經歷過培訓營跟結訓專題，我更加確定自己想要走這一條路，因為除了感受到自己一直在成長之外，實際做出一個功能或產品，也讓我感到十分有成就感 ## 你不打算繼續做資料科學了嗎？ 目前還是以深入前端跟web開發為主，經歷過培訓營跟結訓專題，我更加確定自己想要走這一條路，因為除了感受到自己一直在成長之外，實際做出一個功能或產品，也讓我感到十分有成就感 但資料科學方面的知識，還是對我很受用，例如統計學的知識，在人生各個情境的決策上面，都能以機率跟風險的角度進行思考，擔任數據分析師期間，養成對資料處理的敏感度，在軟體工程的職涯也有一定幫助 ## 你為什麼想加入我們？ 因為我自己有數據分析的背景，再加上也有後端 node.js 的知識，覺得和貴司的向性跟 tech stack 十分契合，希望可以貢獻自己跨領域經驗的價值 再來是嚮往彈性自由、又可以快速成長的公司，所以想加入以沛 ## 你覺得你的優缺點是什麼 ### 優點 : 熱愛學習，喜歡分享 學習新技術，都是為了解決某些痛點 一開始學原生 js，覺得直接更改 DOM 會很難維護，邏輯也不連貫，學了 react 後，發現這種資料驅動畫面的思路真是新天地 再來寫原生 css 的時候，常常煩惱命名要怎麼取，tailwind 就能以原子化 css 的概念解決這個痛點，團隊協作也能達到統一 所以我很喜歡這種一步一步練功成長、破關的感覺 接著，我喜歡分享，因為我認為，如果我自己的努力，可以幫助一些人，甚至是一大群人解決他們的問題，節省他們的時間，這是一件很酷又很棒的一件事情 所以我有一個技術部落格，撰寫技術文章，除了可以幫助別人之外，也可以藉由這個過程更鞏固自己的知識 ### 缺點 : 一開始就會想一步做到位、過早最佳化 一開始在學習程式的時候，容易把 scope 開得太大，會想要一步就做完美 例如一開始在學 css 的時候，其實切版還不是那麼熟，就開始研究 css 設計模式，結果到後來也很少用到 或是一開始學後端的時候，就想把架構拆得很齊全 但是我逐漸發現，這樣容易讓我停在構想與計畫階段，而不去實際實踐 後來我的哲學是，先求有，再求好，一開始可以先構想好重要的架構，但不要規劃過多，在實踐的就會從經驗慢慢理解怎麼優化 ## 你克服過最大的困難是什麼 那時候在銀行擔任資料分析師，剛到職的時候，對很多資料庫的架構十分不熟悉，銀行的資料庫又十分龐大、又有許多業務邏輯，又迫於時程又不熟悉，所以有時資料嚴謹性不是很好，常常會有疏漏或是錯誤的地方，那時業務單位有一些小抱怨，我很怕這樣會打壞我們分析單位的名聲，被人覺得我們的資料很不可靠，所以當時滿緊繃的 我的解決辦法是，建立自己的知識體系，把常用的資料撈取邏輯全部分門別類整理好，例如：想撈換匯相關資料、想撈理財產品新申購金額，就建立許多示範程式碼筆記，這樣慢慢去統整起來， SQL 開發時程快了很多 再來就是依照不同任務去建立 SOP check list 例如製作定期報表有哪些前置動作，幫業務端撈取數據的時候有哪些絕對要特別留意的地方，有這個check list 都讓我及時發現許多錯誤 ## 過去專案所遇到的問題？如何解決 主要是碰到時程限制和技術卡關的取捨 對於每個功能，我們都會有很多理想的想像， 但現實上，我們很難做到技術一步到位，又要時程來得及 首先，時程限制，我們可以先去制定優先順序 1. 這個是不是核心功能？ 2. 這個功能如果沒有完成，會不會嚴重影響其他地方？ 我覺得只要符合這兩個條件，就非常值得花心力好好解決，排在優先，例如我們這次專案為例： 1. 要怎麼把編輯器套件，介接在 react 上？ 2. 要怎麼把 Next.js 跟 redux 作結合？ 3. 最後的程式碼，怎麼佈署上線？ 這些功能像是專案的基礎建設，會牽一髮動全身，我們就會將最大的心力放在這裡，行有餘力再來完善其他功能 再來，是技術碰到卡關該如何透過一些決策過程，來循序解決 例如我們前端網站的佈署，是採用一個叫 Vercel 的服務，因為 Vercel 本身就是 Next.js 的開發團隊，所以當然做為首選 但是當初在本地端 build 完之後都沒有問題，但是佈署的時候發生錯誤 我們碰到兩個連環問題 1. 名片編輯器所使用的套件，跟 Vercel 向性不太好，這個問題很多人碰到，在 github issue 有詳細的討論，看著裡面討論不斷反覆嘗試，先初步解決了 2. 接著馬上碰到第二個問題，編輯器所使用的套件，底層程式碼太過於龐大，超出了佈署服務的程式碼容量限制 - 作了研究發現並且看 vercel 官方文件發現，而這個限制，是佈署環境底層 AWS Lambda 本身的限制 - 不能透過加購升級方案來解決 - 總而言之，就是訂死那，花錢也沒用 這是我們就有兩個決策 1. 套件瘦身 2. 換一個佈署服務試試看 兩個都可行，但是我們需要分析這些替代方案有哪些優缺點 1. 套件瘦身 - 優點：套件的容量問題是所有佈署問題的最後一塊拼圖，若這個解決了，其他都沒問題 - 缺點：可能根本沒有瘦身空間，或是瘦身後，原程式需要大幅重構 1. 換一個佈署服務試試看 - 優點：其他佈署服務是以 docker 化處理，比較沒有其他限制 - 缺點：換一個佈署服務，又衍生其他非預期錯誤 在時程考量下，我們的決策是，先以套件瘦身優先，因為這是最後一里路，並以更換佈署服務當做備案 所幸，在 github 搜尋了許多 issue 才發現，有人做出原套件的瘦身版，而且架構跟程式一模一樣都可以直接沿用，後來就解決這個佈署問題了 但是，有一點很重要的是，在後來時程充裕的時候，我們也去嘗試在其他服務佈署，發現也行得通，後續碰到這個問題也能有更多的解決方案了 1. 若時間足夠，對必要的相關底層技術知識進行研究，有時其他問題會迎刃而解 2. 思考有沒有替代方案，替代方案之前有什麼優缺點，哪個比較符合現行狀況 3. 先選擇最具可行性的進行研究，在時間充裕時可以去研究備案，增加自己的手牌 4. 在社群發問，尋求方向上的解答，或許有不同的火花 ## 你覺得你在團隊裡大多扮演什麼樣的角色 經過結訓專案的過程，我覺得自己在團隊也具備設計架構與規劃的能力 我的夥伴專注在最核心也最複雜的功能，名片編輯器，而我則是負責後端、 Next.js 、redux 的規劃與研究，所以需要以比較全面的觀點來思考一個產品，例如 1. 這個專案需要的功能有哪些？該開什麼 API？ 2. 後端的資料庫，要怎麼設計比較適合功能開發？ 3. 再來就是技術選行的問題： 4. 為什麼要選用 redux 而非 useReducer ? 1. 因為 redux 可以把多個獨立的reducer 合併在一起，並且可以使用 thunk 來進行 非同步請求，不論是結構的清晰度，還是協作的方便性，都很不錯 5. 為什麼要選用 next.js ? 1. 因為這個 side project 有為每個名片制定公開入口網頁，顯示名片跟個人資訊，這個時候用 next.js 的 ssr 渲染，會有利於 seo ![[Pasted image 20230104210833.png]] 總之，我們可以擁抱新技術，但每個技術導入並不是為了新潮，而是為了解決問題 ## 跟後端是什麼配合，或是用什麼方式溝通的 因為在這次專案當中，我也兼任後端的角色，當然身為前端工程師的我，能夠以前端的角度來思考，如何配合畫面和需求，開發出方便的 API 在專案初期，我們團隊根據 wireframe ，模擬使用者的流程，先把 api route 跟功能，以 notion 列表出來，再來思考 schema 如何設計，預想好前端可能會需要什麼 response，我認為如果前端工程師如果具備這樣的知識基礎，跟後端協作會更加順暢 其實在前後端分離的基礎下，雙方只要對 RESTful API 的串接達成一致的共識， 把 model 跟 controller 等內部商業邏輯運算交給後端，前端專心處理後端回傳的資料，渲染成正確的畫面，就能協作無礙 我們一開始有使用 swagger ，但是一開始採用的 jsDoc 寫法會超級多行註解，後來為了後端程式碼的簡潔性拿掉了，採用共同 postman 的 workspace 進行對焦 ## 除了目前學的框架之外，未來還有想研究什麼嗎 TypeScript、測試 (繼續接下一個回答) ## 平常會怎麼精進自己的能力？ 轉職的初期會覺得知識焦慮，畢竟前端有太多新技術不斷冒出來，覺得學也學不完，逐漸領悟到，學一個新技術不是為了學而學，而是為了解決問題或是某些痛點而去學： 例如： 1. 需要配合 CI/CD、或是將環境佈署在雲端，可能需要懂 docker 的知識 2. 希望對 react props 或是 state 有格式和資料型態的規範，所以需要 TypeScript + Zod 所以一開始我會先思考為何需要這個技術、這個技術能解決什麼，使用的情境有多少，再來決定研究的深度，我的學習管道主要有三個 1. 線上影片：前端是一個分享風氣十分旺盛的領域，youtube 上有很多人講得很好，udemy 上也有很棒的課程作為參考，我覺得有一些操作性或是展示性比較強的知識，甚至是邏輯比較網狀、非線性的，就特別以線上影片學習，例如 css 屬性跟動畫，這種就特別需要實際操作給你看 2. 官方文件：其實現在官方文件都寫得十分不錯，如果用心一點的，還會特別帶到需要注意的觀念，例如我一開始學 React 就是跟著官方 react doc beta 跟著學的，裡面講到 render 的觀念也會特別著墨，不過官方文件幾乎是最正確，但資訊最繁複，想要追根究底知道詳細參數跟用法，看文件的能力還是很重要 3. 社群、與人交流：有一些核心觀念的問題，總是要與人討論才有激盪的火花，例如一開始我不是很瞭解 next.js 的 Hydrate 到底是什麼，也以為 next 的 sever 處理階段只存在 getServerProps，透過跟學長姊討論才發現，next page 第一次的渲染都預設會是 server 處理，最後才 Hydrate 交還 client 端，回復完整互動功能，懂了這個以後，後面很多坑都迎面而解 ## 你在未來 3~5 年有什麼樣的職涯規劃 第三年 - 從情景挑選最適合的工具 - 乾淨俐落的程式碼 - 學習廣泛核心知識，資料結構、演算法 - 注重資安、網頁效能等議題 第五年 - 技術內化到自己平常的開發習慣裡，達到信手捻來的境界 - 拆解問題、獨立思考與商業思維，理解每個功能跟需求要解決的問題究竟是什麼 - 有能力帶領一個小型團隊 3~5 人，藉由分享與交流，讓團隊成長 - 能規劃出整體專案流程架構 ## 你進入公司後會想學到什麼？ 1. 學習進行大型的團隊程式協作、產品團隊的開發流程，例如敏捷開發 2. 前端同時需要和後端還有設計協作，學習更好的溝通技巧 3. React 寫法其實很自由，想在這裡看看實務上怎麼往 best pratice 或 clean code 前進 4. 學習如何寫測試，讓程式可靠度更好 ## 火箭隊是怎麼運作的 我覺得火箭隊是一個很棒的地方，教練不是一直上課，直接把所有知識丟給我們，而是引導我們設定目標，達到自己希望的高度 一開始會從切版開始練習，有很多的作業，並且要在期限內繳交作業 有些夥伴很厲害會提早交，這就激勵我們其他人想要更努力跟上他的腳步，這種良性競爭很棒 這些作業通常是，要切出一個完整的 Landing Page，或用 react 作一個 todolist，甚至是一個小型的 agoda，所以在過程中，我們必須不斷自己找出解法，並且和周圍的人進行討論，自主解決問題的能力從這裡開始培養 而在最終兩個月的專案，可以說是最重要的環節了，我們從題目發想、wireframe 制訂、時程規劃、實際開發，都要自己一手包辦，所以這是很珍貴的經驗。 ## 你怎麼處理主管的交辦的任務 如果在不了解方向、時程、人力的狀態下直接開工，有很大的機率最後的成果與主管心中的答案不符，所以在收到任務時，我會先確認自己的思路是否與主管一致，跟主管討論，對焦彼此的共識 ## 意見衝突如何處置 發生衝突的時候，我會先放鬆全身，不要讓自己那麼緊繃，讓自己跟緊張還有怒氣保持距離，這樣能冷靜處理問題 再來就是專心聆聽，對方的需求、跟在意的事情是什麼，耐著性子好好溝通，如果兩方都隨著情緒起舞，更不能解決問題 ## 可以談談你先前工作經驗負責什麼嗎？ 大部分的時間是和業務單位對齊需求和欄位，撰寫 SQL 整合複雜的 table，提供他們需要的資料 但同時間，我們也需要去 開發跟維護定期報表，每個人手上也要負責維護 data mart，這是比較 summary 性質的 table，會給分析單位其他同仁使用 再來，因應技術的創新，我們也需要去建立一些機器學習的模型 優點就是，很多數據領域的工作都會碰到，簡直像是一條龍，缺點就是比較沒辦法 deep in 給出 insight 但我喜歡很喜歡技術的部分，從那時起就有努力嘗試用很多不一樣的作法來突破 - 例如當時候把每個客戶的帳戶總額，弄成像股票折線圖的資料格式進行分群，會發現有穩定上升、穩定下降、資金大進大出、靜止，這幾種形式十分有趣 - 這時候就可以搭配行銷活動名單，以此作為輔助條件進行輔助篩選 - 這個困難點在於，有一百多萬個客戶，再加上每一筆客戶可能又有好幾千筆資料，資料整理起來很繁複