Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

學生心得:ahwei777 #39

Open
ahwei777 opened this issue Jun 6, 2021 · 1 comment
Open

學生心得:ahwei777 #39

ahwei777 opened this issue Jun 6, 2021 · 1 comment

Comments

@ahwei777
Copy link

ahwei777 commented Jun 6, 2021

關鍵字 - 行銷背景轉職、跨出學習舒適圈

哈囉我是 Ahwei ,因為相比其他同學較晚找到工作也幾乎無縫上班,利用上班後兩個月的空檔把欠了很久的心得補完。

-個人背景
-轉職原因
-選擇 Lidemy 原因
-學習過程
-求職準備
-求職總結建議
-課程建議

個人背景 - 一直找尋不到的「熱情」?

從高中開始一直沒有很確定自己的未來志向,如多數同學一樣只是被鼓吹努力考試的潮流推著走,對於自己的職涯規劃也沒什麼概念跟想像。企管系畢業後直接進了第一間錄取我的公司,從事某啤酒品牌在台灣的行銷及通路管理等。雖然運氣很好的,第一份工作薪資福利在業內已算不錯,但因為公司性質偏向傳產,有不少積累陋習以及在個人成長上有所侷限,待了四年後毅然決然轉換跑道,剛裸辭時花了不少時間重新面對自我,但老實說還是沒辦法找到一個能讓自己拋開一切投入的目標。這邊滿建議有相同煩惱的人可以看看 So Good They Can’t Ignore You 這本書,作者對於過去幾年鼓吹的「追隨熱情」做了一些反思,我相信許多傑出的運動選手或音樂家,除了天賦異稟外一定也具有相當的熱情去支持他們不斷前進成長。但如果你沒有在某方面明顯高人一等,也還沒找到某個可以燃燒生命的目標,那可能要思考一下「不停尋找熱情」是不是適合自己,因為熱情也能伴隨累積跟成就感產生。但當然要一直追尋熱情我也覺得沒有不好,但就是要把對應的成本考慮進去。我在仔細捫心自問後覺得更具體、更現實的去選擇一項工作,應該更適合我目前的人生階段。

下面提供一些我向自己提出的問題,網路上還有很多類似問題可以搜尋,主要都是希望轉職者可以充分、多面向思考後再做出決定,而非單純只憑衝動。

  1. 現在的工作是我想一輩子從事的嗎?
  2. 目前想轉職的推力是轉換產業可以解決的嗎?
  3. 我是一個需要從工作上取得成就感的人嗎?還是我可以從工作外實現個人目標呢?
  4. 如果我現在離開這個行業會有多少損失?跟不做選擇相比哪個會讓我未來感到後悔?
  5. 目前工作的優缺點是什麼?你評估後有興趣的目標工作/產業的優缺點是什麼?

轉職原因 - 工作與產業特性

我直接條列式,因為我覺得每個人的原因跟考量都不相同,我認為的優缺點不一定是你認為的優缺點,僅供參考:

  1. 想從事可在工作中取得成就感及不斷學習成長的職業。
  2. 想進入快速發展的產業,多看看新奇有趣的事物。
  3. 想擁可累積及移動的技能,容易彈性轉換公司或是去國外工作。
  4. 偏好年輕自主負責的企業文化,不喜歡辦公室政治還有傳產氛圍。
  5. 學生時代對於數學一直還算拿手,也學習了基礎程式語言,自認不會排斥。
  6. 目前軟體產業成長快速,薪資水平也較高。

選擇 Lidemy 原因 - 酷老師 & 自我挑戰

確定學習程式想法時已經有做過功課比較各種實體/線上教學管道(資策會、聯X、六角、ALPHA Camp...),選擇主因如下:

  1. 課綱內容完整從基礎到相關面向皆有涵蓋,我不希望單純學會使用工具但不了解相關背景領域。
  2. 認同有關心得筆記、自學及搜尋能力對優秀工程師往後持續成長的必要性,而這是其他管道相對較欠缺的。
  3. 已嘗試並驗證過可以有自制力的線上學習,不僅節省大量通勤時間且可隨學習狀況調整進度。
  4. 導師同為自學背景較能以貼近語言解答並針對初學者可能障礙提供指引。
  5. 借用之前某前輩結訓心得:跟老師的相性很合,Huli 部落格內有關工程師的文章我全都看過,有關教學態度、拖延症(我自己也是一個重度患者)、工作價值觀等有很多共鳴,讓我感覺到這個老師是具有溫度跟能貼近學生的,而且除了專業知識外也會有很多可以交流學習的部份。

學習過程 - 自我妥協的拉扯

因為在二月底就從上份工作離職,在空窗期就有先透過網路資源學過一些 JavaScript 基礎語法,因此六月計畫正式開始時進度算是已經超前 1-2 週,但由於是人生第一次遠端自學,加上鑽牛角尖個性在每個挑戰題花了過多時間(手刻 Carousel 大概花了我快三天...),week 17~18 的後端部分因為不服輸也沒有跳過,因此到了尾聲時進度反而落後快 2 週,直接影響到了求職的時程,但過程中有些經驗可以分享給未來參加這個計畫的人做為參考:

  1. 作筆記的取捨

    如果有餘力我個人是很推薦作筆記,好的筆記除了幫助吸收也提高複習效率,尤其剛踏入一個新領域基本上同樣概念要看過好幾次才會比較有記憶度,加上有完整的筆記在求職複習前你會超感謝自己。但磨合出適合自己的筆記方式需要時間,因此在做筆記花費的時間上要做適當取捨,如果太執著在整理筆記一定會反而拖延到課程進度。

  2. 找到最適合自己學習的環境

    我在這半年基本上都是找外面的咖啡廳或圖書館學習,因為我是屬於很難在自己房間裡面專心的人,我需要一個空間營造感才能進入專心狀態,環境周遭的人也同樣在努力的話我會更有動力。另外也是因為全職學習的孤獨感相當強烈,如果還能跟社會有一些連結的話感覺會比較踏實一點。

  3. 不求甚解不一定不好

    這個我聽過某位程式界的前輩說過:「有些東西如果想很久還想不通就直接把他記起來,等到未來某個時間點你就會突然想通了」,這個概念對於我在學生時代都是打破砂鍋的方式算滿大衝擊,但對於有求職壓力的人來說不求甚解反而是不失為較有效率的學習方法。但提醒一下這邊只是希望不要在一個卡點執著太久,畢竟求職時還是會問你是不是真的對相關觀念理解透徹。

  4. 挑戰題沒做真的不會怎樣

    這個我也是直到事後才有感覺,因此我有聽說 Huli 打算之後的課程會直接做隱藏之類的處理,有時候長久的強迫症是很難一下子被糾正的 XDD

  5. 規律學習 + 規律放鬆

    每天白天學習完後我在晚上還是會固定去健身或是做一些運動,假日也會與朋友有些聚會,全職學習真的壓力頗大,只要制定適當的計畫後就不要把自己逼得太緊,另外轉職真的需要相當大的勇氣跟毅力,一定要適時的鼓勵自己。

求職準備 - 跳脫學習舒適圈、臉先洗先贏

  • 履歷整理

    原本打算用 html 手刻,但因為後來更動實在太頻繁,在同學建議下改用 figma,相比 Cakeresume 客製程度高且方便改動,也可以參考既有模板。初版完成後再請助教及業界前輩給予意見,前後大概花兩週完成比較滿意的初版,但後續都還是有持續微調。

  • Final Project 及作品整理

    期末有與兩位同學一起合作一個學習平台的 project ,另外也把課程作業中的 react blog 跟餐廳官網優化,加入一些新功能跟完成部署,然後把 Readme 盡量寫的完整。

  • 面試準備(技術/非技術)

    技術部分照 Huli 課程中提供的方向已經幾乎 cover 80% 遇到的問題,有餘力可以再去看其他題庫,但自己面試幾次下來覺得對於 junior 職位來說技術並不會問到太深,反而非技術題的部分還滿重要的,在自我介紹跟非技術題上要多用點心,讓面試官感受到跟你一起工作會是開心地而且你也是個對自我有要求負責的人,基本上就差不多了。

  • 轉換心態跳脫學習舒適圈

    雖然課程尾聲 Huli 佛心的開了面試衝刺群強迫自己每天練習,但我算是比預期花了更多時間才調整好心態跟建立信心,回頭來看我發現自己在課程後段有點陷入"學習的舒適圈",每週忙於追逐課程內容跟完成作業帶來的成就感,而這些小小的成就感成為這半年來支撐著全職學習且常常懷疑自我的我的養分,造成後來費了許多心力跟時間才將重心重新擺回"努力求職"上。找到工作最直接關鍵不在你私底下多努力學習,而是在你拿到了幾個面試機會還有實際面試中的表現。

  • 投履歷策略
    個人策略僅供參考,請選擇適合自己的方向:

    • 以前端為主但也有投一些後端。
    • 排除博弈跟轉型老公司。
    • 有穩定獲利產品與完整開發團隊。
    • 偏好扁平式自由管理,不用參與太多辦公室政治。
  • 總結投遞履歷成效
    從 2 月中開始初步投遞,先選擇比較沒興趣或條件較差的職缺,純粹練功跟逼迫自己進入面試狀態,但結果連這些雷缺的回覆率也低的可憐(不知道是競爭者太多或是遇到連續假期,當然也可能單純是履歷競爭力不足),於是乎就直接進入海投。

    • 104 銀行 121 家,Yourator:8 家,實際回覆率大概一成,最後拿到 3~4 個 offer 。

求職總結建議 - 徹底坦率

  1. final project 建議一定要設定時程進度及停止點,不然容易耗費太多時間或沒有做完的一天。
  2. 如果沒做 final project 建議還是要用心整理作品集,這些都是面試時的談資。
  3. 只要在履歷上有寫出來的都要假設會被問到,做球或被洗臉就看自己準備多少。
  4. "跨領域"轉職的必須好好想想怎麼把過去技能經驗"轉化"成讓對方感興趣的亮點。
  5. 無腦海投只是快速增加面試機會,但真的有興趣的夢想職缺建議還是稍微客製 cover letter ,也能讓 HR 感受到你的重視程度。
  6. 盡早開始安排面試,先挑幾家練功跟培養面試節奏後就可以投自己真的有興趣跟價碼可以接受的缺,然後不要把面試安排太密集把自己逼死。
  7. 面試時盡量坦誠相見,雖然很難不偽裝自己來討好對方,但找工作就如同找對象,之後的日常相處才重要,當下多互動跟感受面試官的個性、公司環境文化是不是自己喜歡的,避免進去才感覺磁場不合或是沒辦法做自己。
  8. 不要不要不要心急,公司需要一些時間消化履歷,寄出後過一到兩週才回覆都是非常正常的。
  9. 得失心真的真的真的不要太重,被洗臉代表是有哪些地方準備還不夠那就回家收拾好心情再接再厲,如果能有一群同時找工作的同學互相鼓勵講講幹話應該也不錯。
  10. 如果還不確定偏好前端或後端的同學,可以提早多了解工作實際差異或詢問前輩意見等,像我這次很幸運的前後端都各有拿到 offer ,反而造成選擇困難,最後是列出自己在意的一些優先次序比較來幫助選擇。

課程建議

這個計劃的特色就是真實透明,在這樣的環境下每一期學生都有給予真實的回饋,在前面幾期的修正之後我覺得已經相當完整,以課程設定的初衷來說是相當適合像我一樣完全無基礎轉職的同學,並且在過程中給予適當的學習痛苦讓你成長,以下是個人對於計畫的幾點小建議:

  1. 後端課程獨立為自由選修並加深

    這部分我看到許多同學也有反映過,我個人是認為兩週的時間對於剛接觸前端的人來說馬上要快速理解後端的架構真的稍微困難,因此是滿建議把後端的部分整個獨立出來,除了可以更完整的從基礎開始介紹外,也可以讓有興趣的同學自己決定是不是要額外花時間學習後端的知識,因為以我自己的經驗來說這兩週只是很快速的跟著 doc 跑過一遍,很多相關工具的使用也都是快速帶過,我相信老師當初是立意良善,但以整個「前端轉職」計畫安排來說可能反而不是很恰當,以我自己求職的經驗來看,後端怎麼實作大部分的面試官並不是很在意,反而前端要怎麼 call API 的流程跟可能遇到的問題會比較重要。

  2. 求職前的最後一哩路

    因為進入表定求職期時,我相比已經在求職的同學不僅進度稍晚,履歷、作品集也都還沒到位,自己也花了不少時間在調整心態,走出上面提到的"學習的舒適圈",當然這些總歸都是要自己負責的,但如果在結尾時能夠設計一些方法或機制的話,我覺得或許可以幫助到像我這樣欠缺自信的同學,像是後來透過助教有跟 Huli 一起做過一次模擬面試,我覺得就非常有幫助,撇除 Live coding 炸掉不談,當下給予的回饋真的給予我很大的勇氣跟信心,去面對真實面試官的洗臉。

  3. 關於 Live coding 的教學方式

    我自首自己也是後來 Huli 提到在模擬面試 Live coding 中整個卡住的面試者之一,當下其實超級緊張也算是滿震驚的,明明學過的東西但是當下要你馬上從 0 寫出來卻瞬間失去頭緒,回頭想想可能是課程中後端已經非常習慣片段式的跟著老師 coding,老師打一段我接著打一段,而沒有嘗試關掉影片並整個從頭到尾自己構思架構,雖然我記得老師有提到這方面的重要性,但後來進度延遲的時候只想著趕快交出可以符合標準的作業。如果之後作業可以增加像是不提供影片直接要求完成部分功能的話,應該會有助於改善這樣的狀況,或是可以在課程中穿插一些類似題目來訓練這方面的技能。

  4. Final Project 媒合以及由助教擔任 PM

    我個人覺得對於無經驗轉職加上你又沒有太多個人魅力或是豐功偉業的話,Final Project 還是有幫助的,但課程內其實算是滿自由放任的,如果有一個平台或機制協助想做的同學可以媒合同伴的話應該會更有效率一點,例如提供一個簡單的格式請發起人簡述一下自己的專案方向、需求人數、預計時程...等之類,然後如果能再分配一個助教擔任類似 PM 的角色,提醒大家關於題目方向的選擇,還有在團隊太發散時適度幫忙收斂,提醒專案時程等的,對於完成 Final Project 的效率跟質量應該會有一些幫助,像我自己知道的大多數組別其實完成 project 的時間都比原本預期的時程還要多出不少。

  5. 業界實際開發流程及進入職場前的準備

    這邊算是滿私心的啦,因為真的進來工作後才發現很多工具或是流程管理是之前碰都沒碰過的,包含 git 更複雜的指令、環境設置、docker 指令、好用的 VScode extension 等等,當然碰到當下都是要自己搜尋解決,但如果在開始工作之前能夠先預先接觸的話可以加快上手撞牆的速度,看是不是可以定時請學長姐或助教分享一些工作初期的小心得,應該會有一些幫助。

@aszx87410
Copy link
Member

這個我聽過某位程式界的前輩說過:「有些東西如果想很久還想不通就直接把他記起來,等到未來某個時間點你就會突然想通了」,這個概念對於我在學生時代都是打破砂鍋的方式算滿大衝擊,但對於有求職壓力的人來說不求甚解反而是不失為較有效率的學習方法。但提醒一下這邊只是希望不要在一個卡點執著太久,畢竟求職時還是會問你是不是真的對相關觀念理解透徹。

我覺得最後一句講得很棒,只是希望不要卡太久,但還是要對原理有一定的理解,之所以不希望卡太久是因為有些知識需要時間來消化,硬要在短時間內吞下去真的沒什麼用,不過有時候那個界線很難抓就是了

這個我也是直到事後才有感覺,因此我有聽說 Huli 打算之後的課程會直接做隱藏之類的處理,有時候長久的強迫症是很難一下子被糾正的 XDD

這期有做了,不過我也不確定有沒有用,好像還是有些同學有挑戰題強迫症XD 再做更絕一點可能就是進度落後就把挑戰題關掉,但這樣就有點限縮學習方式就是了

期末有與兩位同學一起合作一個學習平台的 project ,另外也把課程作業中的 react blog 跟餐廳官網優化,加入一些新功能跟完成部署,然後把 Readme 盡量寫的完整。

readme 寫完整是我覺得最重要的,因為 readme 如果寫不好,我連專案在幹嘛都不會想看

找到工作最直接關鍵不在你私底下多努力學習,而是在你拿到了幾個面試機會還有實際面試中的表現。

沒錯,面試官不會看到你多努力,只會看到你表現的怎麼樣,就算你背後很努力但表現差也沒有什麼用

最後面這些對計劃的建議非常實用!

這部分我看到許多同學也有反映過,我個人是認為兩週的時間對於剛接觸前端的人來說馬上要快速理解後端的架構真的稍微困難,因此是滿建議把後端的部分整個獨立出來,除了可以更完整的從基礎開始介紹外,也可以讓有興趣的同學自己決定是不是要額外花時間學習後端的知識,因為以我自己的經驗來說這兩週只是很快速的跟著 doc 跑過一遍,很多相關工具的使用也都是快速帶過,我相信老師當初是立意良善,但以整個「前端轉職」計畫安排來說可能反而不是很恰當,以我自己求職的經驗來看,後端怎麼實作大部分的面試官並不是很在意,反而前端要怎麼 call API 的流程跟可能遇到的問題會比較重要。

當初加這些確實是希望能讓大家熟悉一下後端的流程跟架構,但如同你說的,我想教的跟學生學到的可能不一樣,而加上後端的另一個目的是希望所有人都能有自己寫基礎後端的能力。總之後端這個主題絕對不會在這個計畫中消失,絕對是必修項目之一,但確實是有改進空間,例如說比例可能可以變小,或是融入得更自然。

因為進入表定求職期時,我相比已經在求職的同學不僅進度稍晚,履歷、作品集也都還沒到位,自己也花了不少時間在調整心態,走出上面提到的"學習的舒適圈",當然這些總歸都是要自己負責的,但如果在結尾時能夠設計一些方法或機制的話,我覺得或許可以幫助到像我這樣欠缺自信的同學,像是後來透過助教有跟 Huli 一起做過一次模擬面試,我覺得就非常有幫助,撇除 Live coding 炸掉不談,當下給予的回饋真的給予我很大的勇氣跟信心,去面對真實面試官的洗臉。

這聽起來滿不錯的,來個模擬面試的話似乎是不錯的選項

如果之後作業可以增加像是不提供影片直接要求完成部分功能的話,應該會有助於改善這樣的狀況,或是可以在課程中穿插一些類似題目來訓練這方面的技能。

第五期多了期中考,應該也算是一個試著改善的方案XD

如果有一個平台或機制協助想做的同學可以媒合同伴的話應該會更有效率一點,例如提供一個簡單的格式請發起人簡述一下自己的專案方向、需求人數、預計時程...等之類,然後如果能再分配一個助教擔任類似 PM 的角色,提醒大家關於題目方向的選擇,還有在團隊太發散時適度幫忙收斂,提醒專案時程等的,對於完成 Final Project 的效率跟質量應該會有一些幫助,像我自己知道的大多數組別其實完成 project 的時間都比

第五期會有這個,會幫助大家來媒合同伴,這樣子應該會比較好一點,至於助教要不要當 PM 這個可以再看看,但我認同規模跟時程應該要有個人來盯一下

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants