技術強者不一定對公司加分,我該怎麼找到最適合的工程師?

從公司的角度講,面試的根本目的是找到「能夠做好工作」的人,而「高學歷」,「演算法好」,「基礎好」,「有經驗」這些都是表象而不是根本,它們並不能直接和「做好工作」劃上等號。
評論
評論

本文轉自中國工程師 Todd 部落格 〈 程序員面試什麼最重要?〉 一文,Inside 獲作者授權轉載。

工程師面試一直是社群樂於討論的熱門話題。我自己從 06 年實習以來,先後經歷了 4 家軟體公司,全部是外商,其中有世界 500 強的通訊公司,有從事期權期貨交易的歐洲中等規模的金融公司,也有為大型汽車製造商開發 Android 智慧汽車的新興公司。跨入資訊產業以來,我在求職過程中經歷過多次面試,近兩年也有過多次面試別人的經驗。我覺得現在差不多是我對這個問題發表自己看法的時候,這篇文章是我站在面試官角度對於工程師面試問題的一個階段性反思和經驗總結。

目標

相信和不少朋友一樣,有了幾年工作經驗成為 Senior 後就開始了面試別人的經歷。我在最初這個階段只是按照自己的想像把「找到基礎好的工程師」,「找到演算法能力優秀的工程師」,「找到有 Android 開發經驗的工程師」等作為面試的目標。

但是,實際的經歷告訴我,尤其是以「基礎好」,「演算法好」這些目標招到的人最終效果並不好。比如,有的應徵者基

礎知識和演算法掌握情況不錯,process、thread、記憶體等概念清晰,基本的 Hash,二元樹,快速排序等數據結構和演算法也比較熟悉,但是進公司後在實際工作中表現得很糟糕。後來,我才發現原來是我的面試目標出了問題,我原先的面試方法更像是大學的演算法或操作系統期末考試,按照這種方法讓許多並不合適的人通過了面試,同時也可能錯過了許多合適的人。

後來,我的反思是,從公司的角度講,面試的根本目的是找到「能夠做好工作」的人,而「高學歷」,「演算法好」,「基礎好」,「有經驗」這些都是表象而不是根本,它們並不能直接和「做好工作」劃上等號。

方法

目標明確了,但接下來的問題是假設應徵者是一個黑洞,「工作好」不是直接可觀測變量,你所能直接觀測的變量是基礎、演算法、經驗、學歷、性格、談吐、年齡等等。所以,實際上,你只能從「基礎好」,「學歷好」等可以直接觀測的量去推測「工作好」的機率,這就是一個在「X 好」條件下「工作好」的條件機率問題:P(工作好| X 好)。

根據這個模型,面試所應該考察哪些方面就很明顯了,那就是選擇那種最具有區分性的方面來考察。比如,考察面試者的體型特徵沒有太大意義,因為 P(工作好|高),P(工作好|矮),P(工作好|胖),P(工作好|瘦) 的機率都差不多;所以,體型特徵不具有區分性,這不是面試所應該關注的內容。

面試官應當結合職位的要求明確哪些因素具有比較好的區分性。比如,如果要找一名技術門檻比較高的 3D 遊戲引擎開發工程師,應徵者 A 具有 3D 遊戲引擎開發的經驗,但是在基礎知識和演算法面試方面表現一般;應徵者 B 相反,基礎知識和演算法面試表現很好,但沒有遊戲開發經驗,而你只能選擇其一。你選誰呢?

其實,這就是兩個條件機率問題 P(工作好|經驗好,基礎一般,演算法一般) 和 P(工作好|沒經驗,基礎好,演算法好)。這個問題就留給面試官來判斷了,就我個人而言,對於技術門檻較高需要技術積累的職位,經驗更加說明問題,因此,我更傾向於應徵者 A。

下面,我再結合自己的經驗談談對面試中常見方面的看法。

演算法

演算法是 Google 和微軟等大公司面試所重點考察的內容。我個人很喜歡演算法,曾經參加 ACM/ICPC 拿過北京賽區的 13 名。但是,就個人經驗來看,我所接觸過的絕大多數開發職位而言,演算法都不適合作為考察面試者優劣的主要因素。對於普通的非演算法性開發職位,考察應徵者的演算法就相當於考察他打乒乓球好不好一樣,與目標「工作好」的相關性太低。就我個人的經驗來看,差不多 P(工作好|演算法好)=50%,也就是演算法面試沒有太大的區分性。

甚至,還有一種很不好的情況特別多地出現在演算法好的面試者身上,我稱之為「只磨刀,不砍柴」。什麼意思呢?有類人只對什麼 A*演算法,異步編碼,JVM 類加載機制這種純技術問題感興趣,對實現使用者需求毫無興趣。這類人看起來有一定的技術能力,但是對公司來講貢獻十分有限,甚至不如技術一般但認真負責的人。所以,一旦遇到面試者演算法好,我就特別留意考察會不會是這種「只磨刀,不砍柴」的人。

另外,雖然我個人不了解 Google 和微軟,但我對於其特別重視考察演算法能力的面試策略是持懷疑態度的。即使在這樣的世界級大公司,演算法雖然重要,但可以想像在專案實施過程所遇到的各種各樣問題中,演算法問題絕大多數時候不會是主要瓶頸,沒有到那種需要每個人都是演算法高手的情況。實際上,絕大多數專案真正難點並不是一兩個演算法瓶頸,甚至也不是單點的技術瓶頸,而是系統性的組織、協調、設計、開發問題,有大量的看起來不是那麼有技術含量的苦工,也有許多問題是由於資訊不足,並不是技術能力強就能克服這些困難。一個團隊最好優劣互補,有人演算法強,有人業務分析能力強,有人擅長後端服務,有人擅長前端界面,有人聰明,有人踏實,這是最好的。如果全部按照「演算法好」的單一標準選材,必定會把許多優秀的人才拒之門外。

補充:在更多地了解了 Google 和 Facebook 等一流公司的面試細節之後,我對這個問題的認識有了一定的改變,實際上這些公司在面試過程中並不完全強調技巧性很強的演算法,而是更加注重編碼 (Coding) 能力,只是在進行編碼測試的過程中往往是通過一些簡單演算法題來進行的。我對於這種面試方法越來越欣賞,並且也把這作為了我們公司面試過程中的重點環節,因為編碼能力的測試是十分必要的,它有著知識性問題無法取代的作用,如果一個應徵者連「判斷一個字符串是否是另一個字符串的子串」這樣的題目都無法正確並快速地完成,那麼基本上可以直接排除了。我這裡所強調的是不必檢驗高難度的演算法問題,並非不重視編碼能力測試,請讀者不要誤解。

基礎

基礎面試是指考察諸如指針使用、process、thread 概念等基礎知識的面試,十分類似於大學期末考試題。我曾經以為基礎面試十分重要,但是現在不這麼看了。在工作

中基礎的確是重要的,但是在面試過程中,它必須具有區分性才有意義,也就是說 P(工作好|基礎好) 的機率要高,那麼考察指針使用,進程線程區別這樣的基礎題目才有它的意義。我的實際經驗是,基礎面試並不具有很好的區分性,和演算法一樣, 差不多 P(工作好|基礎好) = 50%。同時,基礎面試是最容易準備的,中國人有長期的應試教育經驗,要準備幾個把玩指針題目太容易了。

我曾經遇到過這樣的面試者,他的 C 語言基礎和編譯、連結等原理掌握得非常好,給我留下了深刻的印象,我給的面試結論是:領域面不寬,只會 C 語言,但基礎很紮實,建議錄用。後來的事情證明了那個結論的前半部分是對的,但是」建議錄用「錯了。他在實際工作中表現得一塌糊塗,不理解需求,不理解整體架構;同時,上班時間不是花在專案上,而是花在閱讀諸如《程序員的自我修養》之類的書籍上。最後,這位同事由於長期「沒成果」離開了公司。

基礎不是不重要,而是「基礎好」不足以說明面試者能做好工作,因為基礎是屬於局部性知識,而實際工作需要綜合性能力,二者有天壤之別。 C 語言、作業系統能考高分,但是不會寫程序的人在大學我們還見得少嗎?軟體開發就像蓋房子,綜合能力是設計和搭骨架,基礎知識是磚牆。張小龍原先 Foxmail 是 Delphi 開發的,他它不懂 C#,你如果要招募一個開發.NET Email 客戶端的人,你考察他對 CLR 掌握得好不好有意義嗎?讓張小龍來開發一個 C#版的 Foxmail 真的會有困難嗎?你招一個精通 C#但沒有 Email 客戶端開發經驗的人來真的比張小龍可靠嗎?

我說基礎知識不重要,和古人說的「不積窪步無以至千里」是不是矛盾呢?不矛盾!「窪步」與「千里」是一種可累加關係,但再多的「基礎知識」都累加不成「綜合能力」。學習軟體開發要像持續集成一樣,一開始就是一個完整的系統,雖然規模不大,問題很多,但它麻雀雖小五臟俱全,從小系統到大系統,從簡單系統到複雜系統逐步演化。

所以,基礎好本身不足以說明太多的問題,必須進一步考察綜合能力。對於基礎面試表現不好的面試者,如果時間允許也要進一步考察,有的面試者其實是有能力的,只是沒有進行充分的準備。最理想的狀態當然是基礎和綜合能力俱佳,若不能兼顧,應當綜合能力優先。

經驗

這裡所說的經驗不是通過工作了多少年來衡量的,而主要是指應徵者的經歷,比如,是否完整地寫出過一個軟體,或作為主要開發者完成過一個專案。經驗的重要性在於它能說明一個人的綜合能力。從專案的性質、規模和難度,面試官就可以大致判斷出應徵者的綜合能力。如果一個面試者一直在大公司負責一個小模塊的開發維護,那麼基本可以判斷他不具備獨立或作為主要開發者承擔一個專案的能力,只適合在另一家大公司做類似的事情。對於門檻較高需要長期技術積累的職位,相關經驗更顯得尤為重要,比如,Linux 核心開發,JVM 開發,遊戲引擎開發,資料庫實現,高級 UX 等。對於這類職位,沒有經驗的面試者即使綜合素質不錯也是需要長時間的學習和積累才能勝任。所以,基本上如果確定了你的職位屬於此類,那麼相關經驗毫無疑問應該成為首選因素,換句話說,P(工作好| 相關經驗好) 的機率是非常高的。

通過專案經驗判斷應徵者的優劣比通過基礎和演算法測試更加可靠,所以,面試過程中面試官應該花比較多的時間聽應徵者介紹專案經驗,並進行深入地探討交流,了解應徵者的知識面、思維能力、表達能力等。同時,可以結合專案提一些基礎知識和演算法的問題,比如,如果面試者做過 C++相關的專案,那就可以問他如何進行記憶體管理?是否熟悉智慧指標?如果面試者的回答不能令人滿意,那麼就基本上可以判斷他的專案做得不是很好。

要注意的是,經驗也是一個多維度的事物。比如,C++股票交易中間件系統,這就涉及 (C++,中間件,股票) 3 個維度。假如面試者 A 做過 C++股票交易客戶端,面試者 B 做過 C 的股票交易中間件。從語言角度看,A 最匹配,從專案性質看,B 最匹配,你如何選擇?這就是在多個維度中,哪個維度更重要的問題,就這個例子而言,我個人更傾向於 B,因為我認為中間件開發經驗是主要矛盾,而從 C 切換到 C++並不是問題。所以,面試官需要判斷哪一種經驗是主要的,而哪一種經驗是次要的。比如,我們招募 Android app 開發,這個職位的 Andr

oid 技術門檻並不高,它的真正難點在於做出好的使用者體驗 (UX)。所以,如果一個面試者沒有 Android 的經驗我們是可以接受的,但是我希望他在 UX 方面有經驗,至少做過其他平台的行動 app 開發。

性格

現在,我來談我認為最重要的因素:性格。這可能是許多初為面試官的朋友所難以想像的,怎麼會是性格最重要呢?說實話,當我意識到這一點時,我自己也很驚訝!說白了,還是 P(工作好|性格好) 的機率最高啊。我的實際經驗是,如果一個人的性格好,他能把工作做好的可能性是最高的,性格好遠比基礎好、演算法好要重要。

一個人如果技術上有缺陷,經驗上有不足,但性格好,在團隊中是很容易由其他人來補位的,他自己也很容易逐漸補起來;相反,如果一個人的性格不好,所有的技術優勢經驗優勢都發揮不出來,甚至還會起到反作用,而且性格缺點很難改變。我一直談到實際工作所需要的是綜合性的能力,這種綜合能力的發揮中性格是至關重要的。專案中不止會遇到技術問題,要涉及溝通、協調,不同的人不同的部門既有合作又有磨擦,如何處理這些事情都需要一個良好的性格。可以說,在開發團隊裡讓你與眾不同的不是你從哪個學校畢業,也不是你過去的經驗,而是你的性格。

當然,性格是一個複雜的東西,它包含了很多的方面,並非所有方面都是工程師面試所需要關注的。我的經驗是可以重點考察這些方面:

1) 態度積極還是消極

有的面試者在談吐中就會自然給你一種積極上進的感覺,或者你可以在他的經歷中發現他積極的因素,這些都不是太難看出來的。相反,有的面試者你能明顯感覺到他的消極情緒。積極性在工作中是十分重要的,積極的人能給團隊帶來朝氣,也更易於合作。基本上,如果確定面試者屬於態度積極的,他通過我這一關的可能性就會大大增加;相反,如果確定屬於態度消極的,即使技術能力不錯我也會十分謹慎。

2) IQ

我的經驗是,總體來看,聰明的人在工作中的表現更為優秀。在面試中要考察一個人是否聰明並不一定要像 Google 和微軟那樣找些專門測試 IQ 的智力題,其實,你只需要看他討論問題是不是很有邏輯性,思考和說話是不是反應敏捷就可以做出大致的判斷。另外,眼睛是人心靈的窗戶,一個人聰明與否,眼睛是會說話的。不過,聰明也不完全是優點,比如,當公司或專案遇到困難時,往往是聰明人先跑掉了,堅守的往往是 IQ 一般的人。

3) 語言表達能力

語言表達能力也是工程師十分重要的一項素質,它關係到專案中的溝通是否順暢。面試官可以看看應徵者能否用簡明的語言介紹清楚曾經做過的專案,能否抓住要點,能否考慮到聽者的相關背景。一般來講,語言表達能力強的人綜合能力都不會太差。

4) 是否具有使用者意識

有人說工程師是做研發的,哪來什麼使用者?只有行銷、市場人員才會和使用者打交道。其實,這是完完全全的錯誤認
知。你寫一個模組,甚至一個 API,只要有別人用,他就是你的使用者。有的工程師設計一個模組或是一個軟體總是習慣於從使用者的角度來考慮,盡量地方便使用者,這就是一種良好的使用者意識。具有良好的使用者意識的人更能考慮別人的感受和整體的需要,而不是單純地從自己和局部來思考問題。當應徵者談及過去的專案經驗時,面試官可以常常站在使用者的角度對其進行提問,從這個過程中觀察其是否具有良好的使用者意識。

5) 如何應對質疑和壓力

面試官應該對應徵者的回答以及以往專案進行合理的質疑,看看他如何應對。曾經有一位面試者談到做遊戲登錄伺服器的經歷,我就問:「如果伺服服務器掛了,怎麼辦呢」?他說原先雖然沒有考慮這個問題,但是可以怎麼怎麼改進。其實,大家都理解專案中有各種不完美,這裡面原因很多,只要面對質疑和壓力能從容應對努力

往好的方向思考解決就可以了,不需要掩飾缺陷,更不應該有情緒。我遇到過有的應徵者,一旦你對其專案提出質疑,他馬上產生反抗情緒,或不高興,或不承認有問題,這很容易一下子看出來他在工作中容不得質疑和批評,這種人要想合作就很困難。

6) 個性特點

許多面試者喜歡在簡歷上寫「精通 C++/Linux「,這些字眼看得人麻木,如果有人寫」喜歡 C++/Linux「,我就會有一種眼前一亮的感覺。「精通」是沒有感情色彩的敘述,而「喜歡」包含了應徵者的個性,我更願意看到應徵者的個性。我相信對某樣東西真正的熱情遠比你當前對它的掌握程度更為重要。其實,N 年的經歷告訴我們,同一個班的同學,同一個專案組的同事,雖然每天所學的知識,所接觸的工作都是相同的,但其實每個人的成績和表現差異是十分明顯的。那麼,到底本質的差異是什麼呢?其實,就是每個人的個性。是個性使得有的人業餘時間去打球,有的人業餘時間去看書,有的人喜歡 Linux,有的人喜歡 Mac。一個人在團隊中扮演的角色也和他的個性有很大的關係。面試官應該引導應徵者展現自己的個性,並判斷其是否有益於團隊。

總結

最後總結起來,我的經驗是:

  1. 面試官的目標是找到」工作好「的人,一定要圍繞這個目標來進行面試,如果把面試當成了演算法或作業系統期末考試這就走入了誤區;
  2. 面試過程是通過學歷、性格、基礎、經驗、演算法等可以測試的因素去綜合判斷面試者「工作好」的機率;
  3. 在各種因素中,性格> 經驗> 基礎> 演算法。性格是最重要的,如果性格不好,所有技術能力都會大打折扣,而且技術缺陷容易彌補,性格缺陷很難改變;經驗體現了一個人的綜合能力,你可以從面試者過去的經歷中判斷他能從事哪種工作,不能從事哪種工作;基礎和演算法則主要起到輔助參考的作用,基礎好的程序員一般適應性比較強,學新技術更快,但是切忌單純從基礎來判斷一個人的能力。

《延伸閱讀》

 

 

歡迎加入"Inside" Line 官方帳號,關注最新創業、科技、網路、工作訊息

 


【社會數位轉型】連假出門不塞車、推動漁港再生,經濟部打造永續交通生態圈

智慧運輸時代來臨,全球競相投入無人載具與數位交通研發,希望在未來行動力的佈局搶得先機。從陸地、海洋到空中,無人機以整合 AI、5G 技術為核心,應用場域超乎想像,不僅能帶動產業升級與經濟成長,在解決社會問題上也有許多可能性。
評論
Photo Credit:Pexels
評論

聯合國預估,2030 年全球將出現 43 個人口超過千萬的巨型城市,而 2050 年將有 7 成人口居住於都市。城市人口密度持續增加,為交通帶來更大考驗,需要用更有效率的方式來管理。而在臺灣常見因車流量過大造成塞車、事故頻傳,以及偏鄉交通不便、公共運輸使用吸引不足、燃油車輛帶來環境污染等問題,也可望透過發展智慧交通迎刃而解。雖然短時間內還無法真正落地、普及,但種種想像已顯現出智慧運輸系統(Intelligent Transport System,ITS)的重要性。

智慧運輸科技是一門跨領域的技術,包括 7 大關鍵新興科技 iABCDEF 中的i(IoT,物聯網)、A(AI,人工智慧)、D(數據科技,DataTech)、E(邊緣運算,Edge Computing),並涵蓋資通訊、能源與電子等產業。面對接踵而來的挑戰,經濟部技術處與工業局合作,配合交通部、科技部、工研院、資策會等跨部會單位,關注企業與民眾的需求缺口,擴大各項交通科技創新服務的實驗場域。希望加速資通訊及智慧交通應用落地,推動產業轉型與數位經濟發展,更處理公共議題,建立更好的居住環境。

交通車載設備一站式整合 為國內實現物物相聯

未來在 5G 環境下,物聯網能讓各種設備、軟體、網路服務等更快速的相互連結,透過虛實整合應用與民眾進行深度互動,達成高速運算、低延遲通訊、萬物聯網的目標,這也是目前持續發展如智慧交通、自駕車所必備的條件。

當交通與運輸更加智慧化,將為國內業者帶來新商機,相關產業鏈例如雲端軟體服務、影像辨識與人工智慧分析、路側設備業、道路安全警示以及周邊的系統整合、工程顧問、二輪車安全聯網等,都是發展智慧交通智慧系統重要的環節,而智慧交通控制服務也是相當重要的一環,當交通號誌的紅綠燈控制做最有效的安排時,將可使路網中的車流運行更加順暢,也能減少更多的廢氣與碳排放的產生。

資策會智慧系統研究所(系統所)組長黃暉慈指出,發展一站式整合的關鍵之一在於道路上的路側設備(Roadside Unit,RSU)與安裝在車內的車載裝置(On Board Unit,OBU)兩者間的跨設備溝通,過去常因各家技術及介面規格不一、各類型設備分屬不同廠商維護、跨部門協調等原因難以整合,若要產生對民眾更具價值的應用相對是一大難題。

以建立永續智慧交通環境為目標,經濟部技術處匯集各法人能量,致力於運輸資源、資訊的整合共享,提升協作效能。

「比方說像各縣市智慧公車站牌就都長得不一樣,以及路側設備分屬不同部門管理:如交通局的號誌、工務局路燈管理處的路燈、警察局的 CCTV 等等,設備跟服務多為各單位獨立運作,資源無法進行有效的整合」黃暉慈表示。因此,為提升協作效率最佳化,經濟部技術處與資策會系統所合作,發展多元資訊的智慧交通作業系統,以建立共通平台之概念,打破廠商之間的資訊串接藩籬並能協同合作,減少資料使用者、管理者必須面對不同格式資料的困擾,以達成資訊交流的通透性與共享目的。

黃暉慈說明,智慧交通作業系統(Transport OS,TOS)是一套能整合各項遠端設備的管理平台,透過 TOS 函式庫讓程式介接、遠端佈署與應用開發都變得更簡單。「我們希望藉由一套共通的標準格式進行資料的收集,協助業者在設備管理、資料管理、資料分析上都能更加簡易有效率。」經由系統的整合,能自動化遠端監控路側設備的運行狀態,偵測錯誤並通知管理者,並以AI感測蒐集車輛、事故等應用數據。「省下開發系統和串接的功夫,業者能專注在設備功能的強化。」經濟部計畫透過整合性資訊服務,改善當今運輸走廊壅塞問題,未來國內車廠在技術發展上也能突破國外母廠的限制,打造出門無縫、用路安全、交通順暢的智慧運輸系統。

黃暉慈舉例,假如 CCTV 的監控影像出現雜訊、模糊、被遮蔽或鏡頭偏移,或工業電腦網路斷線等異常發生,系統都能即時發現問題,發出警示,「本系統具備彈性擴充功能,可協助業者介接提供更多加值應用,例如接入 RTSP 串流影像也能做到如智慧化判斷車輛是否違停的科技執法應用。」此外,TOS 的另一特色就是會將蒐集到的數據生成可視化圖表,有效地傳遞資訊,以利使用者能迅速評估狀況、做出因應。

Photo Credit:資策會

提升船舶監測效率 給予閒置港岸新生命

除了陸地的交通,海洋也是智慧運輸科技的發展重點。資策會系統所蔡政鴻組長分析,臺灣四面環海、海岸線長達 1,000 多公里,每年海洋經濟產值高達近 6 千億,「物流、漁業之外,還有觀光娛樂,光是用漁船載客出海磯釣每年就可賺超過百億,把安全性做好會很有市場。」

資策會系統所在經濟部技術處科技專案的支持下,採納百家以上產官學研機構與專家的建議,以海港數位轉型需求的高可靠邊霧協作物聯網技術為主,規劃「近岸船舶監測系統」,與相關業者、海巡隊合作,加強港岸船舶的管理效率。

蔡政鴻說,過去在智慧漁港常常做的是智慧照明,當然智慧照明在節能與管理上有很多好處,但除了漁港好像放在其他地方也很好,對於漁港的特色比較沒有凸顯出來。現在漁港面臨的問題是利用度不高,漁港資產閒置,最主要原因是來自過度捕撈,導致海裡無魚可抓,因此產生閒置問題,海洋資源的永續是主要的解決方法,除了生態保育,另一個是漁業漁港的轉型,從過去過度捕撈的抓來吃,轉型到生態體驗的旅遊價值,傳統漁業要轉型到娛樂漁業,發揮觀光旅遊的價值,從中帶來收入,魚就不用補那麼多,海洋資源才可永續。美國的漁業統計,休閒釣魚的經濟效益是商業捕魚的九倍,因此休閒釣魚的發展,其實是可以取代商業捕魚的部分經濟能量,進而減少捕撈。

以基隆市政府為例,2017 年便率先制定娛樂漁業島礁磯釣自治條例,管理認證核發與收費標準,並陸續導入科技管理工具,以船舶自動識別系統(Automatic Identification System,AIS)對磯釣船舶實施監測,採用邊霧運算技術,藉由與鄰近船舶、衛星等設備交換資料,當磯釣船訊號消失或離岸太遠,就會發出警示,建立數位治理機制,確保磯釣活動的安全戒護工作落實,保障業者與釣客的活動安全。另外磯釣證申辦,過去都要上班時間臨櫃申辦,造成不便。現在將磯釣證上網申辦,結合磯釣船出船單,送到漁港的海巡安檢流程,到磯釣船舶的海上航跡訊號勾稽,完成一套完整的服務鏈路,讓安全與方便形成基隆磯釣發展的重要後盾。使過去出海捕魚轉變成載客釣魚,減少捕撈,生態得以生息,漁民也有生計,還帶動釣具產業的發展。

其實智慧交通早已悄悄融入在日常生活,我們對數位票證的依賴度不斷增加,新零售時代的物流配送越來越快速。然而各種進步將可能衝擊原有的就業市場,該如何引導人才轉型也是重要的社會課題。

且讓我們試著想像,在交通的流動中,有出門運動、買菜的銀髮族,有通勤的白領上班族,有趕著上學的學生與接送孩子的父母,每個人的移動需求都能被滿足。經濟部技術處期望從技術專業角度,協助打造更人性化、友善的交通環境;同時,企業也能從競爭轉為合作,共同為產業創新轉型與減少污染的社會企業責任努力,創造更多就業機會;政府也能減少治理、管理的成本,持續優化交通運輸系統,形成社會美好的循環。