在软件专案的开发品质上，我个人的经验认为，懂很多技术或是开发技巧都是次要的，反
而我更重视“纪律”和“细心”这两个工作态度。
很多工程师面试的时候，技术方面可以跟我讲的头头是道，什么架构、名词、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命名也没有意义 沟通无效后 程式要调整我都直接跟主管说 让主管去请他调整了 我个人是无法跟他沟通 试过几次两边的理解总是无法一致

你提出的两点很重要 但好像跟优不优值无关

像你崩溃都打成奔溃 看也知道不优质考试不就看得出实力？ 不会出考题实力也就是那样主管没实力要凭什么带好的工程师？像你断行这水准 中英都不知道要隔半角毫不整齐 光看发文就知道不是好工程师看发文就知道错字跟排版跟逻辑条理