需要什么样的流程，愚以为要看公司规模，系统特性，人员组成来决定，大象不会跳舞。
打快攻有快攻的流程（抢市占），禁区防守有防守的流程（巩固现有势力），看产业模式
而定，没有一定标准做法。
原PO看起来想用“方便、快速做事”的流程，但想问怎么找到适合这样流程的梦幻人选。
无论后面争论的内部管理与流程，但一开始如何面试合适的人，都是个值得思考。
最近刚好我也在烦恼这个招募问题，我想会用上机考的方式，给一个lab, 里面只有一个
简单的function，但是有bug，我会请面试者找出里面的bug并修复。
实际上bug不只有一个，最粗浅的就是编译失败的语法问题，括号不对称或是变量存取范
围不一致这类，这个解不了，我就送他到门口鞠躬说声谢谢请等待通知。
编译失败的问题解决了，如果面试人立即回报说这题完成了，那我就会知道他不是一个细
心的人，只看见眼前的问题，而没有看到后面跟着的其他问题。
我应该会至少准备四种bug在里面：
1. Runtime error：8元素的阵列，存取指标应该0-7，但循环却用了1-8，或是循环条件
< 故意写成 <= 来产生此错误。
2. 极值检查错误，例如除法，我分母塞入0他有没有想到这种可能，先检查出来？
3. 逻辑错误：程式本身运行正常不会有error, 但是输出的结果都是错的，他找不找得出
原因？
4. 错误处理：在一定会有错误发生的地方他有没有想到并处理掉？例如连数据库或是api
但是面试的办公室根本不可能连到。
后面这四个都会事前准备好单元测试，面试人交件后自动一跑，看几个绿灯，就可以大概
知道这面试人的细心程度....
关于原PO的问题，这应该是我会尝试的方法。
※ 引述《Masakiad (Masaki)》之铭言：
: 其实制度流程没分两种，开发团队讲好规则；约定好软件开发的品质、验证基准并自动
化
: 、约定时间code review的时程，正是加速品质保证及验证软件的速度。这个作法并没
有
: 什么多余跟lock的问题，除非品质跟验证软件本身就是多余。
: 另外有很多方法论来指导上述的实作原则外、也很多公司有进行也持续运转这机制，若
你
: 还没有尝试就赶快试试，不用臆想跟推论这么多。
: 阁下言谈之间我的感觉是不熟这方面的运作，所以另外再建议你找一个熟这方面流程的
人
: 来协助你，这样才可以解决问题。
: 至于怕优秀人才会因为这样感到不被信任的问题也不用担心，优秀人才只会因为没有这
些
: 机制而离去，原因在于他们严格要求自己验证跟品质，团队有这些机制对他们来说已经
很
: 习惯，倒是没有这些机制还要担心我完美的架构混入其他没被验证的粪code，什么叫委
屈
: ？这才叫委屈。
: ※ 引述《accessdenied (存取违规)》之铭言：
: : 唉唉唉，当初我不用“态度”这个字眼就是知道大家会各自解读，到底什么是好的态
度
: ..
: : ...
: : 所以我讲白了就是“细心”和“纪律”，还举了很多实际例子来说明这两个元素的概
念
: ，
: : 结果有人又简化回态度两字，果然底下有开始乱战了...
: : 拉回主题，前阵子忙着赚钱没时间好好回应一些想法。有人说制度和流程可以解决，
还
: 提
: : 到权限控管，为什么我不太认同。
: : 制度流程分两种，一种是协同合作必要的方式，你负责的范围是哪里？东西做好会放
在
: 哪
: : 里？这是让大家做事彼此方便快速的约定，是增加效率的。这类似交通规则的订定，
大
: 家
: : 照着做就流畅。
: : 另一种制度流程，是防弊的，稽核、放行、权限控管，是保持着一种不信任的心态在
做
: 管
: : 理。这就好像除了红绿灯外，又另外安排了一个交通警察指挥交通（权限、审核放行
）
: ，
: : 并看管所有驾驶人。
: : 后者会产生效率瓶颈，因为每台车都要经过检查并放行，交通就堵塞了，开发人员再
多
: 、
: : 效率再高都没用，就是会lock。
: : 每个change都要approve的下场，就是“人皮图章”开始产生的时候。
: : 再来，有些 team 赶专案加班到半夜怎么办？负责approve的人难道发呆配到半夜只
为
: 了
: : 最后帮他开权限和approve？这些都是无谓的人力损耗。
: : 而且优秀的人才，一直在不被信任的环境下做事，心委屈了，流失也只是迟早的事情
！
: : 想想看，你有10个工程师，只为了其中1个心态随便的人员，就把剩下9个优秀的人才
一
: 起
: : 拖下水被绑手绑脚不再信任？
: : 为了那一个人，与其设计各种稽核制度防止他做错，不如一开始九排除他，让剩下九
个
: 人
: : 顺顺利利做事，这才是正解吧！？
: : 让不对的人一开始就不要溜进来，团队也不会被污染，好的人才更不会觉得被牵累！
: : 这才是我为什么要跟大家请益的出发点。

我的建议是... 告诉面试者,这个Lab有几项设计缺失请你修正.... 而不单单只说 里面有bug请你修正对于脑筋简单 直来直往的工程师 很容易就中招有时候不是能力不足, 而是心还太嫩....单纯建议 无意引战 我老了......

楼上说的有理谢谢指教

原Po的问题在于标题下了"优质",然后讲了一堆为什么细心和纪律很重要,好像那就===优质

有点像是找日本人的奴工

不过这一串下来可能只有你真正的给了建议 :)

他破题不就说看产业内容 没有标准做法然后试着举了一个case

我没有要找神人，这个面试设想只是要找能安心做事的一般员工神人的重点不会在细心和纪律这两个条件吧？另外其实软件业的工作，维护大概占据了89成的工作量，除了接案公司，没有天天都有全新专案可以开发的公司

你只是找一个可用的人力而已 不觉得可以叫优质

推原po跟一楼

哈哈，现在连优质的定义都要各自解读了，真无聊你们。我认为态度细心有纪律的人就已经凤毛麟角，所以对我来说是优质

考这种总比写白板好啦，至少比较实际，工作上也可能碰到

你们玻璃心有你们自己的定义，干我屁事？我就是要细心、有纪律的人，而且我觉得这种人难找很优质，这么简单听不懂吗？

linkedin不是很多HR讨论区吗？

感觉这篇的建议 挺具体的阿

这篇很具体，但我觉得一楼的想法我更认同

原po找的是码农吧

看别人的code修到好太痛苦了 比自己重写还累谁知道他埋了多少bug在里面

能有优秀成果的,便是优秀工程师.一个优秀成果的细节,岂是短短的一些面试问题就能包含的了的...

推这篇建议 学起来 谢谢^^

推

干脆请他找亨利或是拼拼图不是更好感觉考察面还是不够全面　顶多看基本知识跟细心度

楼上要不要建议一个2个小时能全面了解的面试法？

这篇提供的方法很实际，但老实说我觉得原Po（指禁止存取）想在面试阶段过滤的应该不是这种程度的不细心面试者（甚至我认为这根本不专业）应该是在架构复杂的状况下产生的逻辑错误等bug，而不是能不能build过这样的状况。实际上就是工程师怎么撰写他的测试案例已经决定他的态度跟细心度了。

本来优质就是各自解读, 也才因此而有前面一堆讨论直到现在才有一篇算是真正的建议问题问精准一点会比较快得到有用的回复

感觉你连function都不用帮，让面试者写出来再让他写单元测试测就好.

我个人认为考这个会比要面试者背sort的时间复杂度实际

sort的复杂度不是算法常识吗? 不需要特别背吧现在G家人资还会直接问你sort复杂度来决定你够不够格电面

就陷阱题

C++ 的 STL algo 都有时间复杂度保证，和资结当初上的差不多，我遇到履历写会 C++ 的也会去问这问题。遇到写擅长物件导向的我会给一个烂架构叫他重构给我看

说实在...能找到可用的人已经很不错了~神人那是另一个境界

推原 PO 跟一楼

在找打杂的吧无聊

1.2是基本的 但是3.4有点搞人了

曾经我有想过 找个大型的Opensource专案开题目让新人加功能

真的是好建议耶

推这篇 也推一楼

后面考细心在搞人吧...面试时间短短，当然迅速解重点刻意埋逻辑错误不讲更何况要短时间适应、爬完别人的code，抓出所有坑

...真不会找人捏 面试心法完全是靠聊天 但大多工程师主

他如果在高手环境待久了 看到这种程式搞不好反应不来

真的，traceCode找bug是没用过ide吗?是只想找到喜欢用笔记本写code的高手吗尤其无限上纲错误，难道他硬加了七八个防呆你反而大喜?这种怕死的面试法是以前测试不流行的年代，可以改进的