在軟體專案的開發品質上，我個人的經驗認為，懂很多技術或是開發技巧都是次要的，反
而我更重視「紀律」和「細心」這兩個工作態度。
很多工程師面試的時候，技術方面可以跟我講的頭頭是道，什麼架構、名詞、Pattern 都
能侃侃而談，也有相當經驗，但是實際上工如果缺乏上述兩項特質，往往會造成很多團隊
問題。
沒紀律：
例如需求開發完後，自己不測試就丟給QA，連一開始畫面都載入失敗，讓QA奔潰。或是bu
g隨手改幾行就說修完，QAㄧ測試立刻 reopen。又或是自認快手經驗老道，本機都不編譯
就直接commit下班，留著大家拿到 build failure 的 code 或是 CI 一跑直接讓QAT 壞
光光。
上線週期或是解重大issue 沒有遵守code freeze 禁令，或是認為改幾行的小需求小修改
懶得開新的 branch 就直接在 trunk or develop上草草開發，QA沒來得及驗證就被帶上
線。
QA 已經測試過說沒問題，可以上線，之後又偷偷改東西沒講，認為程式結構不夠好或是
命名不夠簡潔手癢又偷改。
不細心：
不檢查自己的修改有沒有可能影響其他東西，不仔細反覆確認理解需求定義，自以為理解
，然後做出不對的東西。
修改總是東漏西漏，這一頁改到，下一頁又沒改到。該上的 config 到不同環境總是又漏
掉。版控遇到 conflict 總是不小心蓋掉隊友寫的 code，always using mine....
Production support，下 SQL 修資料，忘了補上 WHERE 條件就執行了....或是WHERE條
件下錯...（這點最讓我害怕）
我想這種開發隊友大家應該不陌生才對，所以，想跟大家請教，有什麼方法可以在面試過
程透過什麼類型的問答或是測驗可以預先察覺這種人格，提前過濾掉？

樓下會酸你只要奴才

www.ptt.cc/bbs/GameDesign/M.1492093826.A.B89.html

可惜我遇過的主管都不是這樣用人

扣錢啊 違反rule砍獎金

講得好，不只軟體，任何工作都該如此。

這兩點可以直接用六字概括 就是"自我感覺良好"確實遇到會讓人很頭痛

開發式的情境題如何？說段故事問他想法

其實我看到這種"如何在面試中挑人"的文章，都有種在看"如何在第一次碰面就知道對方不是恐怖情人"的即視感

你的id讓我不知道要不要認真回

哈哈哈就事論事啊

是不是能了解之前團隊開發經歷過什麼痛苦的合作？還是需要試用期的方式（除了業主在看員工合不合適，員工也能了解自己適不適合公司），不過，freezed code 還能 commit 上 develop 分支，應該可以設定某些分支受到保護

覺得好難喔

考細心度測試啊 沒耐心寫完的都是這種人

好像很多問題的避免可以靠 code review 把關，不要讓成員能輕易的把 project 搞爛掉

要有商業邏輯

所以你的workflow根本就有問題啊

不是人沒紀律 是公司沒紀律

這次推你啦，終於說一些比較有意義的遇到自我感覺良好的人，公司再有紀律也沒轍

這些不能在制度面改善？

我認為你提的這兩點都可以從制度改善

先找一個能把 workflow 搞好的人

你講的這些,靠git權限管理大半都能避免啊

sql忘記where，好像很大條…太恐怖了

趕時程又沒人幫看其實難免會忘記一些東西

權限管理是兩面刃啊

sql忘記where通常都是工作範圍太大 不如找個人只負責sql

workflow +1，可以這樣亂搞也滿有問題的

可以設計情境題「如果你程式已經交出去給QA了，但是你突然發現有個小bug只要改動幾行code就行了，不會產生意外。而你也有gitlab或SVN權限，你會求好心切主動去修改？還是先跟QA或主管提醒再改？」

公司或者部門制度問題+1 人再細心沒有完美的…

另外也推anumis大大

我覺得只要對自己的code肯負責，有bug可以獨立快速處理就好了你如果找到那種超細心但是動作慢到時程爆炸的也不行吧

想知道到底用了哪些DevOps的軟體? 應該沒這麼糟吧!?

看年資，資深50%，但是資淺80%，機率問題

這些問題都可以在流程與工具上解決。要一個很細心的人永遠很細心不可能，要每個人都很細心更是理想。

講得不錯 你講得這兩點也是我們遇到的問題

靠北我專題真的有同學沒建置直接丟給我，真的是哇靠到爆

出一些陷阱題，不夠細心的會上當

我的確受不了 寫好沒自己先驗證一下 就丟出來的垃圾程式

這明明是流程問題 應該要發pr才能MERGE進產線

流程+制度 可以解決。怪天怪地就是不怪自己

紅明顯 沒惡意 話說clean coder書裡面有提到 改命名改架構很好 要多改 如果你害怕改 也就證明了你沒有良好的測試 支持你改動後執行結果會是正確的 是你沒有寫測試的錯誤當工程師害怕改變架構 害怕整理程式碼 很有可能在後面的開發反而要額外花費大量時間心力去配合有問題的架構 理解可悲的命名

關於你提的細心問題，很多看起來都是程式寫太爛導致的

你是QA后

..你就出狀況題問他會怎麼做啊

版控流程有問題，光能直接push dev就代表權限設定不夠

年薪300萬這都要問鄉民 扣分

七個小矮人也上得了白雪公主，所以樓上不要看不起鄉民啊！

dev 分支 protect 起來, 要 PR 才能上 code

code能動就好 想那麼多幹麻？

可以整合CI tools 進去git, push的時候要跑測試過才merge就傳統的開Pull request 這是 事 的部分人 的部分就是 人在江湖飄 哪有不挨刀 看同事間感情囉

你的商業邏輯怎麼沒辦法解決這種問題呢

能不能互相提醒支援 一直玩找錯樂挺累的

argos，code能動我真的不會管這麼多，上面我說的狀況都是code不能動啊......

再等幾十年 等人工智慧發展成熟就可以完全避免啦

補充:要預先知道有點難 通常要合作過吧 或是git上作品

審核機制擋不住就強化淘汰機制

你不就是屬於那種人嗎XDD

CI/CD有做好應該不會發生阿? 怎麼會有不能動的狀況?

AOSP一堆CI/CD做好卻不能動的例子好嗎@@根本問題取決於系統的規模

測試覆蓋率有到一定水準，又有搭配CI/CD跟QA人員，就算是上述這種不細心或懶惰也不影響產品品質。面試過程只要針對面試者在測試/CI/CD熟練度多了解也能避免碰到不細心/沒紀律雷。不過如果你本身就不熟或沒嚴格執行政策在這一塊也面不出什麼就是了

看起來問題比較大的是整個專案控管的行政制度面問題人看起來其實問題不大

問題本質還是在建立良好的workflow & SOP就算找到良好紀律與細心的工程師 還不是有可能會發生同樣的問題XDDDD不過面試者細心的部分的確值得深入評分 因為直接影響產出code的quility，這部分直接考白板或leetcode或是給一份code，可以挖空或是fix bug實際看他怎麼改

根據物以類聚法則 我看大概不可能 什麼樣的人找什麼樣的人

300萬了，還來發文問鄉民喔 可愛

有沒有試過用一樣的薪水去請工程師

我的確沒打算問THEWORLD這種鄉民的意見，謝謝指教

碩士還沒畢業很久的，可以考慮翻一下論文

紀律和細心是蠻重要的啦，但你提的是制度流程就能預防，這也反映樓主所處的文化風氣比較偏好怪罪個人特質，甚至抓戰犯，而不是改進制度流程與管理另外也反映了測試覆蓋率應該很低，甚至沒有，還可能沒要求寫測試

這些有些都是基本的敬業問題 還沒跟工程扯上邊....

推

其實公司管理是這樣的 上行 下效 有紀律與細心的主管 自然會讓下屬也有紀律 做事細心不敢說100% 但至少風向能帶起來

查了某噓的 發的文真的很差 不知道在自以為啥

不過還是要話說回來 a大你的發文 這篇也好上篇也罷比較像是對人不對事 是因爲人而引發的事 個人感覺這世界就是充滿各式各樣不同的人跟事 很多事一體兩面的

我相信有可能靠紀律朔造良好的組織/團隊 但前提是提出規則是對的 是經過驗證的 是適合主事者的(最少)..所以比較認同Argos大的意見..畢竟有些事最大的問題就是一開始主事者就錯了..後面當然不管怎弄最終滿滿問題 = = 這種問題感覺就很像一休和尚和大力士比做"完美米糕"誰做的快的例子...

DB不是都有一份專門給測試用的?上線版本沒加where很誇張

曾經遇過同事剛到我們公司 就不斷抱怨前公司制度 同事寫的CODE多爛 自己寫的CODE別人程度太差看不懂等等後來看過他的程式 if包個四五層是基本 完全不寫註解對比較難直翻英文的變數或FUNCTION命名也沒有意義 溝通無效後 程式要調整我都直接跟主管說 讓主管去請他調整了 我個人是無法跟他溝通 試過幾次兩邊的理解總是無法一致

你提出的兩點很重要 但好像跟優不優值無關

像你崩潰都打成奔潰 看也知道不優質考試不就看得出實力？ 不會出考題實力也就是那樣主管沒實力要憑什麼帶好的工程師？像你斷行這水準 中英都不知道要隔半形毫不整齊 光看發文就知道不是好工程師看發文就知道錯字跟排版跟邏輯條理