※ 引述《jamo (hi)》之铭言：
: : 附记：
: : 好像四十五岁以后，我就不再给面试的新人丢程式码考试卷了。
: : 因为工作态度跟人和根本考不出来，不过还是会问一下基本的罗辑思考，
: 你说的对,考卷只能考一部分的专业
: 最重要的工作态度跟人和根本考不出来
: 这也是我最头痛的问题,想问问看大家都怎么解这一题?
有心就问得出来
就跟做专案一样 是不是自己做的
从回答的自信度 详细度 就一定有差异
2017年的时候 我职位刚好担任面试官
针对 游戏程式面试 设计了一个测试方法
细节我觉得不需要讲太多 连结放推文
因为毕竟隔行如隔山 每间产业公司都有自己的文化与标准
每个工程师都有自己人生意义
这种软性 工程师又很少讨论的议题 不太容易取得共识.
这个方法我觉得有优点也有缺点 有比我更有CP值得方案分享出来说服我.
我简单讲两个要点
第一个是 上机考:
我设计的上机考是: "一起来DEBUG"
我设计了三到五题 "有数个不等问题的程式" 请面试者找出问题在哪里
面试者找到几个 怎么觉得那个是问题 有没有跟我讨论 都是评鉴标准.
这个上机考是一个未来会与你共事的考试 我们未来要一起解决问题的模拟
所以技术能力(有没有找到问题)只占一半分数
沟通能力 对技术的观念 是另一半分数
缺点 面试者求好心切 一题会看二十分钟 要是连闯五题我最惨得陪着干瞪眼一小时
第二个是 经历访谈:
狭义来讲我的目的是找到一个能跟自己配合的开发者
广义来说目的是尝试找出以下特质：
经验丰富，愿意采用不同的方法，接受与团队以非程式的方式沟通，
具备其他选项思维的可能性，同时能够在结问的过程中顺利说明出来的开发者。
因为开发过程中 所有的技术决策都一定是trade off.取了优点就一定付出缺点.
所以对于每个项目或专案，我的问法会像是不只结问有没有做过？
而更重要的是为什么（Why）及怎么（How）作？
使用了什么样的方法解决问题？使用了几种方法？
每个方法有什么优缺点？
遇到什么问题？
有没有辨识到问题的成因，有没有尝试任何解法？
尝试了之后有没有解决问题？
环境因素造成无法解决问题时怎么思考？
从事后来看，有没有更好的做法？
缺点 通常要聊一个半小时
双方才会逐渐建立互信 才能让对方卸下心防开始坦承(抱怨)
有用吗?
当时有录取(且拿到offer)的那位同仁
入职公司半年内在一次公司危机状况有表现而受到公司层级的表扬.
这样应该算有用