※ 引述《del680202 (HANA)》之铭言： : 最近被上面指派去面试跟招募人才 : 所以开始有了去面试其他人的机会 : 会想到这问题，是前天面了一个有十年左右工作经验的工程师 : 面试过程中他聊了他如何设计一个系统架构，解决各种业务逻辑 : 包含他如何解决遇到的难题。 : 使用了哪些open source，选用的时候有哪些考量等等 : 整个过程对方充满着自信，而我个人听起来觉得这位面试者底力很够没啥问题 : 之後跟我同行的另一位同僚问了一个二元树找最大子树的白板问题 : 此时这是该面试者第一次让我觉得他露出一点尴尬的表情 : 後来他要求给他点时间思考，我问我同事说为什麽要问这问题 : 他说面试工程师问这种问题应该是很基本的 : 我自己觉得对於这种工作好几年的工程师比起考他这类问题 : 应该更注重对方对於系统架构等全面的理解，所以我不太喜欢问这种白板问题 : 事後针对这点我跟我同事讨论了一段时间 : 不知到板上各位高手是如何面试一个资深工程师的 刷题是大公司的作法，因为履历有千万封自然要先筛选 反正筛完还是有一大堆可挑 然而个人认为一般公司而言 senior 最重要的是, 遇到困难时怎麽去处理 但这个困难不完全是技术层面的问题 而是是一些外部性/内部性问题所衍生的情况 例如startup下礼拜要出一个demo，现在要怎麽冲prototype？ 决定专案合适的 tool chain? 确认 CI/CD 范畴跟深度？ 当面临资安/系统性问题时可以提出不同的方案？ 虽是技术，但必须考虑目前手上资源 junior 是找方法 senior 则是选方法，并且可以提供时程跟效率评估 cto / tech lead 则是带人/确保下面提出的方法跟公司战略align 让 senior 去带人则是台湾软体业普遍常态 但不见得跟公司策略 align 像我认识很多优秀工程师 都会希望用最屌的新语言/架构 那的确是 senior 很爱做的事情 但重构必须是建立在有更好的转换率情况 反过来说 如果他是不断追求架构/或是接纳新语言的工程师 那我会给他高度的 senior 评价 所以白板问题可以问 但不该是你选择他的唯一重点 如果你手边架构能力/解决问题能力/提出解决方法多样性的 candidate 实在太多 那这时用白板题就 ok 虽然这种人很少(经验丰富又是刷题高手) 这种咖通常去FLAG/去新创当cto了 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.228.123.169 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1514180380.A.533.html ※ 编辑: jackypan1989 (61.228.123.169), 12/25/2017 13:40:24 仅是字义讨论，未必有什麽实益 以我较擅长的前端来说 光 redux 这种state mangement tool chain 就有 n 种变化 redux, redux-promise, redux-thunk, redux-saga, redux-observable 我面试一定会问上面的几种差异, 还有各自的优势 有哪个 junior 能轻松回答的？ 难道就不是追求架构？ 而 "认为最新最流行的才是唯一解" 其实不是只有junior才会犯 :D ※ 编辑: jackypan1989 (59.115.132.200), 12/26/2017 15:37:40