[心得] PHP/node.js工程師面試心得

看板Soft_Job作者 (芸)時間8年前 (2015/10/01 14:36), 8年前編輯推噓21(21推 0噓 68→)
留言89則, 22人參與, 最新討論串1/1
我是工作約一年的PHP工程師，晚上會自修node.js， 處理過售票系統、人力資源管理系統，都是收爛攤子就是了。 想跳槽因為公司(資Ｘ、Ｘ通）規定太多（上班要穿西裝、坐姿要端正、不可以聽音樂）， 且公司沒有具有前瞻性的計畫，工作沒有挑戰性， 反應一些安全上的問題也沒用(都買windows server了，幹嘛不用IIS當伺服器 ，硬要用apache，還用2.2版的) 1.CHOCOLABS(node.js) 我先說結論，這家是好公司，這是我面試到目前為止最滿意的一家。 我們一共談了3HR，我從那邊收穫到很多，DevOps真的是花時間來陪我的。 一開始Chief system Architect進來感覺還好，問了我一些作品的基本問題，就出去了。 之後進來了以後換DevOps各種被電，而且他才學三個月ＯＲＺ。 他問了很多有趣的問題，比如： 如果你要開發一個DB要如何開發他的index功能? 如何調查全台有幾家加油站 你贊不贊成clean code(附帶一提，我是反對派的) 當然一些javascript的基本概念他也有問，但是那些我都答不好ORZ。 最有趣的是最後一小時他說別談技術了，但是話題還常常偏到技術去ＸＤ。 很久沒有面試感覺很充實了 結果：經驗不足，以後再聯絡 2.Omusic(PHP) 我不想談，我事後覺得我不夠成熟，所以才吵了一架。 3.PCHOME支付連(PHP) 最近很火紅的第三方支付，所以所以我有投。 基本上就把我售票系統如何做講了很多，這是我唯一一家有開到薪水的，我開50K。 他有暗示我說把薪水降低一點，不過我覺得沒必要去降，所以沒理他。 結果：說預算不夠，不錄用 4.台灣自由行(PHP) 我講了很久他才坦白跟我說他是PM，他跟我說現在程式部分是外包給中國， 他希望有人可以優化介面。 我很耐心聽他說完，確定他要找的是前端不是後端，但顯然他搞不太清楚差別，我花了一點時間跟他講解（雖然我自己也不是很懂） 結果：他開45K，但我拒絕，因為我不想害人。 5.麻吉波波(node.js) 最近很火紅的17APP，雖然我是面試後才知道的。 面試的空間很小，很有壓迫感，我不太喜歡。 來面試我的人口音有點奇妙，不過可以聽得懂。 當我講解完我的履歷跟網站以後，被劈頭說一句你這個網站好像也沒什麼特別的功能。雖然這是事實，但我還是有點不爽，因為我的網站是純靠我自己一個人架起來的。 最後他展示給我看他們的APP，說有機會會通知。 結果：無聲卡 題外話：我大概把104、板上、66k的用node.js的公司全投過一遍了，但是有邀我去面試的還是很少。 看來只能寫PHP寫個3年再跳槽到node.js吧。 徵一下node.js gitbook協作者，有意者站內信。 https://y2468101216.gitbooks.io/node-wiki-book/content/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.30.31 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1443681404.A.07C.html ※ 編輯: y2468101216 (118.163.30.31), 10/01/2015 14:40:03
推
10/01 14:49, , 1F
去的不在裡面？
10/01 14:49, 1F
我全部fail歐。 ※ 編輯: y2468101216 (118.163.30.31), 10/01/2015 14:58:29
→
10/01 15:10, , 2F
想聽關於 clean code 部分的細節
10/01 15:10, 2F
其實談的不多，我先假設大家對clean code認知是一致的 （即完美的程式是不需要註解的。） 我談到我說我要求自己寫程式都要寫註解，DevOP就說那你知道clean code嗎？ 我那時大概是說我覺得沒有任何code是完美的，所以我永遠都不支持clean code。 我的看法就是趨近於一但永遠不等於一。
推
10/01 15:15, , 3F
想聽吵架
10/01 15:15, 3F
推
10/01 15:19, , 4F
吵架+1
10/01 15:19, 4F
推
10/01 15:24, , 5F
XD 我對吵架也有興趣
10/01 15:24, 5F
→
10/01 15:24, , 6F
還有坐姿要端正，現在很多公司有要求這個嗎 好奇問問
10/01 15:24, 6F
推
10/01 15:27, , 7F
想聽吵架 (認真
10/01 15:27, 7F
可以翻閱之前我對於面試要考試的心得，是因為那個吵起來的。 ※ 編輯: y2468101216 (118.163.30.31), 10/01/2015 15:35:07
推
10/01 15:55, , 8F
clean code 並不是極端的不要註解
10/01 15:55, 8F
→
10/01 15:56, , 9F
而是良好的命名 易懂的function名稱 簡潔的function 功能
10/01 15:56, 9F
→
10/01 15:56, , 10F
如果註解可以融入code中，那和必須要處處擺註解?
10/01 15:56, 10F
→
10/01 15:57, , 11F
int a;//Age <-- 那就直接寫int age;
10/01 15:57, 11F
→
10/01 15:57, , 12F
另外註解到後來會跟程式脫勾，程式一直改，註解不會改
10/01 15:57, 12F
→
10/01 15:58, , 13F
或是程式看的懂，但是他媽的註解看不懂！
10/01 15:58, 13F
→
10/01 15:58, , 14F
clean code是一本書（我想你應該知道）大便的時候可以看
10/01 15:58, 14F
→
10/01 15:59, , 15F
另外node.js穩紅的！ 趁你已經在船上，請多往這方面求職
10/01 15:59, 15F
謝謝，我會找時間來看看的。註解即code，要達到這樣的境界很困難， 可是寫註解卻不需要太多的技術，有時看到開頭就知道trace到錯誤的code 而不用再看下去，我認為的註解是這樣，我的看法拉。 ※ 編輯: y2468101216 (118.163.30.31), 10/01/2015 16:03:34
→
10/01 16:00, , 16F
我覺得這問題有點像廢話，應該要問你認為什麼是clean code?
10/01 16:00, 16F
→
10/01 16:02, , 17F
omusic不去不是你的損失，這貨註定就這樣了 是他們的筍絲
10/01 16:02, 17F
→
10/01 16:04, , 18F
clean code 中文版 第8~13 頁，是各大師談什麼是clean code
10/01 16:04, 18F
※ 編輯: y2468101216 (118.163.30.31), 10/01/2015 16:07:48
→
10/01 16:11, , 19F
『我喜歡我的程式優雅又有效率，邏輯直截了當，使得錯誤
10/01 16:11, 19F
→
10/01 16:11, , 20F
無處可躲，盡量降低程式的相依性，以減輕維護上的功夫..』
10/01 16:11, 20F
→
10/01 16:12, , 21F
『Clean Code簡單又直接明瞭，讀起來就像一篇優美的散文.』
10/01 16:12, 21F
→
10/01 16:13, , 22F
另外那個啥，DevOps你文中指的像是開發人員？ 但它的意思..
10/01 16:13, 22F
DevOPs Architect我沒打全名。 ※ 編輯: y2468101216 (118.163.30.31), 10/01/2015 16:23:21
推
10/01 17:23, , 23F
先假設你沒有寫Testing的話
10/01 17:23, 23F
→
10/01 17:23, , 24F
像我註解會寫這樣耶
10/01 17:23, 24F
→
10/01 17:24, , 25F
//1.初始化計算用變數
10/01 17:24, 25F
→
10/01 17:24, , 26F
//2.丟入Sum function進行計算
10/01 17:24, 26F
→
10/01 17:24, , 27F
//3.取得結果，存入資料庫 .
10/01 17:24, 27F
→
10/01 17:24, , 28F
自已覺得這種註解也不錯呀！XD
10/01 17:24, 28F
→
10/01 17:48, , 29F
其實樓上這註解很...咳
10/01 17:48, 29F
推
10/01 18:16, , 30F
其實clean code並沒有說完全不準註解 而是追求code本身
10/01 18:16, 30F
→
10/01 18:16, , 31F
表達一切所有註解很多餘
10/01 18:16, 31F
→
10/01 18:17, , 32F
如果什麼都註解 其實看的人會很辛苦
10/01 18:17, 32F
推
10/01 18:18, , 33F
註解感覺只是寫給不在同一個水平的人看得
10/01 18:18, 33F
推
10/01 18:21, , 34F
看完註解還是得看code才可以準確明白coder的邏輯，如果
10/01 18:21, 34F
→
10/01 18:21, , 35F
什麼也註解就變成同樣的內容要看兩遍...
10/01 18:21, 35F
→
10/01 18:23, , 36F
我認為唯一有價值的註解是 // It's a trap!
10/01 18:23, 36F
→
10/01 18:25, , 37F
Clean code提出很多建議原則 雖然我也沒100%贊同但我覺
10/01 18:25, 37F
→
10/01 18:25, , 38F
得80%很值得參考，像是控制每行的長度，每個method的行
10/01 18:25, 38F
→
10/01 18:25, , 39F
數使之維持在1/2左右可以一次呈現
10/01 18:25, 39F
→
10/01 18:26, , 40F
有助於一個螢幕至少可以顯示兩個method(左跟右）
10/01 18:26, 40F
推
10/01 18:29, , 41F
坐姿端正 XD
10/01 18:29, 41F
→
10/01 18:30, , 42F
唉 穿西裝是怎麽回事
10/01 18:30, 42F
→
10/01 18:55, , 43F
我覺得clean code和完美是兩回事
10/01 18:55, 43F
→
10/01 18:58, , 44F
每個人心中都有最愛的小說 但不會有一本是所有人都愛
10/01 18:58, 44F
推
10/01 19:14, , 45F
看產業吧，除非你有信心一次記熟20種以上代碼，爬幾千
10/01 19:14, 45F
→
10/01 19:14, , 46F
行程式也不會搞混，那的確不需要註解
10/01 19:14, 46F
推
10/01 19:17, , 47F
不知道西裝是不是等於正式服裝 像玉山就得穿正式的
10/01 19:17, 47F
→
10/01 19:18, , 48F
某些產業有一堆系統，畫面20個按鈕，每種按鈕根據3、4
10/01 19:18, 48F
→
10/01 19:18, , 49F
個狀態代碼判斷開啟或隱藏或disable, 我會希望註解 越
10/01 19:18, 49F
→
10/01 19:18, , 50F
多越好
10/01 19:18, 50F
→
10/01 19:20, , 51F
樓上，金融業幾乎都會要求至少襯衫加西裝褲
10/01 19:20, 51F
→
10/01 19:39, , 52F
所以那不知道算不算西裝 XD
10/01 19:39, 52F
推
10/01 20:04, , 53F
吵架的那間真的是頗呵 我之前也有去那裡interview過
10/01 20:04, 53F
→
10/01 20:05, , 54F
完全是雷到爆炸的地方 但是沒像原PO一樣吵架啦XD
10/01 20:05, 54F
推
10/01 21:49, , 55F
當你的同事根本還沒體會「可讀性」的藝術、英文程度也爛
10/01 21:49, 55F
→
10/01 21:50, , 56F
到爆時，只有順手多寫一點中文註解，可以減少他們來煩你
10/01 21:50, 56F
→
10/01 21:50, , 57F
的機會....
10/01 21:50, 57F
推
10/01 21:54, , 58F
別寫中文...看過太多匯入變亂碼的...
10/01 21:54, 58F
→
10/01 23:01, , 59F
我是舉例啦T_T 我個人是不會寫中文，雖然UTF8很好用.
10/01 23:01, 59F
→
10/01 23:01, , 60F
deray這是我自已開發的習慣@@ 所以你覺得這樣很差嗎XDD
10/01 23:01, 60F
→
10/01 23:03, , 61F
我是因為如果邏輯複雜，這樣寫下來才知道自已做到那裡:D
10/01 23:03, 61F
推
10/01 23:23, , 62F
//2.丟入Sum function進行計算
10/01 23:23, 62F
→
10/01 23:23, , 63F
int sum = GetSum();
10/01 23:23, 63F
→
10/01 23:23, , 64F
那註解何必呢...
10/01 23:23, 64F
→
10/01 23:34, , 65F
註解拿來寫每段大概的功能很好用，而且有區隔的作用...
10/01 23:34, 65F
→
10/01 23:36, , 66F
畢竟讓程式碼自己解釋自己是一種理想的狀況。
10/01 23:36, 66F
→
10/01 23:37, , 67F
不過沒有維護的註解不如不要寫，因為會變成一種誤導！
10/01 23:37, 67F
→
10/02 00:10, , 68F
每段功能不一樣 那不同功能拆不同function不是更好嗎
10/02 00:10, 68F
→
10/02 02:48, , 69F
註解就和看書一樣~並不會所有人都能清楚你的明白~所以雙
10/02 02:48, 69F
→
10/02 02:49, , 70F
管齊下會是比較好的~如果註解和code都看不懂~其實代表的
10/02 02:49, 70F
→
10/02 02:50, , 71F
是雙方都有問題...
10/02 02:50, 71F
→
10/02 09:54, , 72F
可能我的比較偏向提醒用的 功能拆不同fn是要的。
10/02 09:54, 72F
→
10/02 09:55, , 73F
就見人見智囉XD我是覺得把每行記錄的事做完，你功能也做完了
10/02 09:55, 73F
→
10/02 09:56, , 74F
反正我是舉例啦 可能例子不好GoalBased才覺得好像多此一舉
10/02 09:56, 74F
→
10/02 09:56, , 75F
分享一下而已 :D
10/02 09:56, 75F
推
10/02 10:27, , 76F
分享一下註解我大多用在兩個地方，1. method開始最上方
10/02 10:27, 76F
→
10/02 10:27, , 77F
，但理由為的不是分段，而是因為會用自動產生說明文件
10/02 10:27, 77F
→
10/02 10:27, , 78F
的工具跟給ide自動補字時帶出的。所以整個team註解風格
10/02 10:27, 78F
→
10/02 10:27, , 79F
也一樣。2.是做標記，todo之類的，方便管理技術債...跟
10/02 10:27, 79F
推
10/02 10:29, , 80F
附帶ㄧ提，因為team有限定code style所以比較少註解，
10/02 10:29, 80F
→
10/02 10:29, , 81F
及註解看不懂的狀況。
10/02 10:29, 81F
→
10/02 10:42, , 82F
m大你的第2點就是我現在的用法 XDD .fn的說明我也是因應文件
10/02 10:42, 82F
→
10/02 10:42, , 83F
(握手) :D
10/02 10:42, 83F
→
10/02 10:44, , 84F
我是覺得久了大概就跟你在寫文章一樣吧！ 要言簡易賅呀~~
10/02 10:44, 84F
→
10/02 11:16, , 85F
推Ｍ大
10/02 11:16, 85F
推
10/03 19:25, , 86F
如果自以為自己的程式碼很簡潔易懂 但其實沒有 又不願意
10/03 19:25, 86F
→
10/03 19:25, , 87F
寫註解時 那就換成是別人的惡夢了
10/03 19:25, 87F
推
10/03 19:27, , 88F
在成為clean code大師的路上 總少不了一些同事當祭品 哈
10/03 19:27, 88F
→
10/03 19:27, , 89F
哈哈
10/03 19:27, 89F
‣ 更多 y2468101216 的文章
文章代碼(AID): #1M3DHy1y (Soft_Job)