[面試] AMI面試主管真是佛心來著

看板Tech_Job作者 (800IM)時間11年前 (2013/01/11 18:32), 編輯推噓32(46推 14噓 96→)
留言156則, 66人參與, 最新討論串1/7 (看更多)
今天去面試的時候，公司先拿了一張C語言考卷給我寫， 先承認，我不是每題都會寫，而且還不小心用到VB的語法 (% 用 Mod) 主管看了我寫的那幾題，問我：「你寫的是C語言嗎?」「是阿,請問有哪個語法錯了嗎?」 他先告訴我C沒有 Mod,才發現自己用錯 (我當助教教了整學期VB,有時候會在VB行末打";") 不過他說，他知道這是取餘數 但是下面這行又讓他更疑惑 (N Mod 2)&&(敘述式1,敘述式2);　/*誤用Mod前面已經解釋過*/ 　　　　　　　　　　　 我解釋，如果N是奇數，就執行敘述式1,2， 敘述式1,2都是在做幾何運算，幾何運算的結果最後要return出去 「&&是在做邏輯判斷啊，你怎麼會拿來計算？」 「我沒看過這種寫法，你是第一個這樣寫的!」 然後我一直跟主管解釋左右括號的運算順位不同，IDE會最佳化可以不用if等等的 「你這是C++的語法吧！C complier不會過」 我又解釋，我都把這樣的東西寫到8051裡面，這一定是C的語法 已經不知道怎麼解釋了，當下真的很難堪 「這個逗號是什麼? C有這樣寫的嗎?」 我又說那是把兩個不同敘述式隔開，不用換行，而且都會執行 以前去面試我為了Demo專題都會帶NB，一定當場拿出來跑給主管看， 這次是騎單車去，加上又是美商， 所以我只帶專題報告和大學成績單，結果根本連拿出來的機會都沒有 「如果"&&"compiler會過，我再叫你來」 然後我灰頭土臉的回來了 我想可能真的是自己的問題，所以回來第一件事情就是打開 keil 3 寫了51測試程式 RI&&(('L'==SBUF)&&(P1=~P1,RI=0)); 結果這行compiling竟然過，而且MCU能按照UART收到的指令執行 我想精明的外商主管絕對不可能弄錯的，一定有堅強的程式實力和經驗才能幹到這個位子 這一定是： 1. 我的51都從實驗室的垃圾堆裡面撿來用的，可能被之前的學長燒壞了 2. 全華圖書的光碟有問題，竟然給我盜版的keil 3. AMI臨時人事凍結，主管不好意思直接叫我滾回家，讓我演一場知難而退的戲 AMI 真是一家為人著想的好公司呢! -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.122.165.222 ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 18:41)
推
01/11 18:41, , 1F
寫Code 要寫得讓人看得懂,可維護性也很重要
01/11 18:41, 1F
→
01/11 18:42, , 2F
除非是要調效能,不然用太刁鑽或冷門的寫法會被當垃圾= =
01/11 18:42, 2F
我有解釋，以前做專題曾遇到速度瓶頸，我找了很多最佳化的方式來解決問題 ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 18:47)
推
01/11 19:19, , 3F
你沒反問主管C的&&要怎寫
01/11 19:19, 3F
他說那只能做邏輯運算，不接受我說的短路運算子概念 ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 19:21)
推
01/11 19:26, , 4F
主管回去發現真的會過 就再叫你來啦 不要太悲觀了 囧
01/11 19:26, 4F
要是真的有這個心確認，就會當場coding了吧 ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 19:28)
→
01/11 19:29, , 5F
你不應該回嘴的,有些只是看你的心態而已,就算真的會過,
01/11 19:29, 5F
→
01/11 19:30, , 6F
發現你真的有料,也會認定你難帶...(主觀強)
01/11 19:30, 6F
我用很誠懇的態度想跟主管解釋啊,哭哭 ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 19:31)
推
01/11 19:34, , 7F
不去也罷 下一間
01/11 19:34, 7F
推
01/11 19:35, , 8F
這種寫法可讀性太差 沒必要還是不要用吧
01/11 19:35, 8F
推
01/11 19:52, , 9F
你有看過short code那本書吧
01/11 19:52, 9F
→
01/11 20:10, , 10F
團隊合作是溝通 > coding, 總覺得你很酸
01/11 20:10, 10F
推
01/11 20:14, , 11F
請問最佳化的說法是您自己判斷還是改參數做過實驗呢?
01/11 20:14, 11F
推
01/11 20:14, , 12F
原PO事後的吐槽也要酸 嘖嘖
01/11 20:14, 12F
→
01/11 20:31, , 13F
有人
01/11 20:31, 13F
推
01/11 20:53, , 14F
好特別的寫法 RI&&..... 那邊
01/11 20:53, 14F
推
01/11 21:04, , 15F
很多人這樣寫吧....至少我研究所就看過不少
01/11 21:04, 15F
推
01/11 21:07, , 16F
他只是一間假美商而已..薪水低到靠北 去那邊幹嘛...
01/11 21:07, 16F
推
01/11 21:07, , 17F
樓上研究所這樣寫跟出去是兩回事.....
01/11 21:07, 17F
推
01/11 21:11, , 18F
那我寫的CODE那位先生一定發瘋:P
01/11 21:11, 18F
→
01/11 21:23, , 19F
樓上教的，我沒看過short code，不過您介紹了我就有興趣看
01/11 21:23, 19F
→
01/11 21:30, , 20F
如果你有談到錢的話應該就不會想去了吧
01/11 21:30, 20F
推
01/11 21:36, , 21F
除了討論語法 還有其他的嗎? 止討論這個擺明不想用你吧
01/11 21:36, 21F
應該是主管認為我基本C語法大有問題，所以其他的連談都不想談吧 ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 21:43)
推
01/11 21:43, , 22F
效能最佳化怎麼不寫組語呢?
01/11 21:43, 22F
1.考題限定C 2.我不會ASM ※ 編輯: deo2000 來自: 140.122.165.222 (01/11 21:45)
→
01/11 21:54, , 23F
C語言標準並沒有保證&&左右的執行順序,所以有潛在風險...
01/11 21:54, 23F
→
01/11 22:00, , 24F
而且業界有在要求coding style,這行應該會被lint tool抓出來
01/11 22:00, 24F
推
01/11 22:02, , 25F
不，C語言標準有保證順序
01/11 22:02, 25F
→
01/11 22:03, , 26F
"&& operator guarantees left-to-right evaluation"
01/11 22:03, 26F
推
01/11 22:09, , 27F
印象中AMI的考題都蠻基本的，可以用可讀性較高的寫法會比
01/11 22:09, 27F
→
01/11 22:09, , 28F
較好
01/11 22:09, 28F
推
01/11 22:11, , 29F
編譯技巧 在研究所與出去外面工作是一樣的 觀念正確就可以
01/11 22:11, 29F
→
01/11 22:12, , 30F
寫出這種語法，不過現在也很多人不會在意這種事情
01/11 22:12, 30F
→
01/11 22:12, , 31F
因為編譯器實在做得太好
01/11 22:12, 31F
→
01/11 22:13, , 32F
有很多人看不起研究所的程式碼，殊不知現在業界一堆比研究
01/11 22:13, 32F
→
01/11 22:13, , 33F
所編譯技巧與習慣還差的...
01/11 22:13, 33F
還有 83 則推文
還有 3 段內文
噓
01/12 10:28, , 117F
你這樣子不只造成自己工作團隊的困擾
01/12 10:28, 117F
→
01/12 10:29, , 118F
也對其他OEM廠的工程師造成困擾呀
01/12 10:29, 118F
噓
01/12 10:55, , 119F
寫得自己很委屈的樣子，還用酸標題跟酸文
01/12 10:55, 119F
→
01/12 10:56, , 120F
這種文章完全是我的作風，不可取~~
01/12 10:56, 120F
噓
01/12 11:16, , 121F
下一位
01/12 11:16, 121F
噓
01/12 11:54, , 122F
面試被電就上來討拍 我看你還是繼續當學生就好
01/12 11:54, 122F
→
01/12 14:17, , 123F
這是&&的short circuit吧，有看過這種寫法
01/12 14:17, 123F
噓
01/12 14:33, , 124F
這篇文好酸...
01/12 14:33, 124F
推
01/12 19:46, , 125F
這寫法真的難維護，而且現在cpu的速度，這樣寫真的沒意義
01/12 19:46, 125F
噓
01/13 04:09, , 126F
AMI應該很高興不用維護你的code和作你的同事
01/13 04:09, 126F
噓
01/13 04:55, , 127F
請相信你的compiler
01/13 04:55, 127F
推
01/13 05:10, , 128F
short code沒有不好，只是這場合又必為了這事情起衝突？
01/13 05:10, 128F
→
01/13 14:33, , 129F
在現代的compiler下這樣寫沒有意義,編譯出來是一樣的.
01/13 14:33, 129F
→
01/13 14:55, , 130F
用comma expressions也不是好習慣,很容易埋bug,也沒比較快
01/13 14:55, 130F
噓
01/13 22:07, , 131F
AMI應該很高興不用維護你的code和作你的同事
01/13 22:07, 131F
噓
01/14 02:22, , 132F
是很厲害沒錯, 不過OEM的工程師可能會幹譙在心裡.
01/14 02:22, 132F
→
01/14 02:24, , 133F
你忽略了這份工作的立場了, 你寫得code是要給人看的.
01/14 02:24, 133F
→
01/14 02:25, , 134F
不是自己在實驗室裡面追求效能用的.
01/14 02:25, 134F
→
01/14 02:26, , 135F
追求效能與code的精簡以外, 也要考慮到客戶的能力與可讀性.
01/14 02:26, 135F
噓
01/14 11:20, , 136F
不是請你來作最佳化運算的，而且你寫的有快嗎？每種CPU指
01/14 11:20, 136F
→
01/14 11:20, , 137F
集也不一樣，你有比較行喔？
01/14 11:20, 137F
→
01/14 14:30, , 138F
自以為寫得短就是好程式嗎...你離開公司後要叫誰來維護
01/14 14:30, 138F
→
01/14 14:31, , 139F
人家不care效能的地方硬是要用難懂的code來加強效能 反
01/14 14:31, 139F
→
01/14 14:32, , 140F
而造成維護的成本增加 公司幹嘛這樣自作孽
01/14 14:32, 140F
→
01/14 16:06, , 141F
重點已經不是程式正不正確的問題了
01/14 16:06, 141F
→
01/14 16:07, , 142F
你要思考濃縮原始碼有無意義 以及如何推銷自己
01/14 16:07, 142F
推
01/14 16:31, , 143F
朝聖推
01/14 16:31, 143F
推
01/14 17:08, , 144F
來朝聖!
01/14 17:08, 144F
噓
01/14 21:20, , 145F
朝聖XD
01/14 21:20, 145F
→
01/14 21:37, , 146F
跟到了
01/14 21:37, 146F
推
01/14 21:55, , 147F
朝聖!
01/14 21:55, 147F
推
01/14 23:03, , 148F
來朝聖 台灣主管容不下大佛的 您還是自己創業吧
01/14 23:03, 148F
推
01/14 23:27, , 149F
你好棒！給你拍拍手
01/14 23:27, 149F
推
01/14 23:34, , 150F
路過朝聖
01/14 23:34, 150F
→
01/15 00:01, , 151F
不會寫code的應該是你沒錯
01/15 00:01, 151F
推
01/15 03:13, , 152F
其實稍微看了一下您以前作過得論文跟研究，您真的很強了
01/15 03:13, 152F
推
01/15 03:16, , 153F
但是就像Goodliffe跟Joel的強調，readbility重要太多了
01/15 03:16, 153F
→
01/15 21:57, , 154F
compiler 是有在做事情的 :)_
01/15 21:57, 154F
→
05/18 07:21, , 155F
這篇的重點是主管認為他寫的程式的錯的 又不是批評可讀
05/18 07:21, 155F
→
05/18 07:23, , 156F
性的問題 一堆人因為看不慣這篇的酸 而把矛頭指向作者
05/18 07:23, 156F
‣ 更多 deo2000 的文章
文章代碼(AID): #1Gx-fA01 (Tech_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 deo2000 的文章
文章代碼(AID): #1Gx-fA01 (Tech_Job)