※ 引述《Zoe519 (Zoe)》之铭言： : 面试公司: Facebook : 面试会是一个漫长的等待过程，我好像都没有因为直接投履历而 : 得到面试过。但是如果是经由内部推荐或是联络到recruiter就 通常来说，抢手的公司或职缺，内推的人就排队到爆炸了 :D 其实这其中的「人性」道理很简单，後面会详述。 : Anyway, Facebook的理念就是move fast，从面试的过程中 ^^^^^^^^^^^^^^^^^ 羡慕... :D : 大概面试完过一两个工作天recruiter就打电话给我了。（也 : 是一大早打来，接电话的时候我还在睡觉。）就是恭喜我得到 : onsite的机会，告诉我前一个面试的时候interviewer对我的评 : 价跟建议。被发现我写code有点生疏了，叫我下个面试前多练习。 个人经验，面试前练习写程式最好是以「手写」方式练习；若有机会 的话要练习在白版上解题，尤其是「解释解题方法」的部分。 不过，我也看过有爆强者带自己的笔电，接会议室的投影机; git init 起手式，开了 vim 就开始喷 code 出来, 解题同时还写 unit test, 甘拜下风 orz : 於我的履历经验兴趣的问题，就是很基本的behavioral questions， : 气氛很像在闲聊。最後问了一题简单的DFS的地图题。最後也是 : 留很多时间给我我问题。我建议把想问的问题都留在这里问。因 : 为这轮面试主要是在看你的个性跟职涯规划，所以你问的问题如 : 果可以透露出你的求知慾跟上进心应该是有加分的。（我猜啦XD） 下面这些都是以前提过的，在这里重新作个整理 * 正常的面试是双向的。以北美的知识性工作来说，如果一场面试给 你一种「单向」的感觉，个人建议是: 块陶。 * 资方这边想知道的有三件事 1. Can you do the job? 你是否有胜任这工作的能力? (知识、经验、技能、天赋) 2. Will you do the job? 你是否有执行这任务的意愿? 3. Are you going to fit into this company's culture? 你是否能适应接受整个公司、团队的文化? 通常 #1 是很直接的，以科技业来说，最常见的方式就是出题在白版 上给你解。 #2 与 #3 就很微妙；基本上没有办法在一般单天六小时左右的面试 行程里得到精确、准确的答案. 是故，所谓「问『好问题』有加分」 ，通常就是加在 #2 与 #3 这背後的「人性」道理，就在於 一个年薪十万镁的职缺背後的真正成本在 15 至 30 万镁；在 corporate 环境里最有价值的「资产」可说是 "head count"; 今天你是 hiring manager 的话，你会想怎麽使用你得来不易的 head count? 当然是用在「 看起来不会摆烂难管理，或在 18 个月内离职走人，以至於让『我 』这个 hiring manager 看起来像个 idiot 的求职者」 是故，为什麽「内推」受重视? 最根本的理由在於 *spread of accountability* XD 「内推」进来的新人作得好，那自然是 hiring manager 识人有方 ( 同时，内推推荐人也能拿到笔奖金) ；若推进来的是个白烂，那可以 把责任倒一半到内推推荐人头上 XD 易言之，就「资方想知道的三件事」而言 1. Can you do the job? 给所有的新人: 不要去担心你「够不够资格」 不要去担心你「够不够资格」 不要去担心你「够不够资格」 刚毕业就是菜，大家都知道 :D 把你所学好好地用 "specifics, examples, results" 三原则展现出 来，资方要怎麽去评量，是他的事；事实上, 他比你更担心。 :D 2. Will you do the job? 3. Are you going to fit into this company's culture? 以 #2 为例，问你自己: 「我需要哪些资料来帮助我回答 "Will *I* do this job?" 这个问题? 」，然後把这问题用 open-ended 的方向问出去 例如 (x) 贵公司是否有员工餐厅? (o) 通常你们怎麽解决三餐? 不一定要问些大题目，例如「请问贵公司在此产业里的十五年 roadmap 为何? 」，这种题目通常太空泛 (除非你是应徵 director 以上的职 位) 但可问些管理制度的问题，例如这个问题是可以双方通用的 你如何应对 / 调解 / 裁决在工作上的冲突? 以下 combo 技也是双方通用的 * 能不能举个例子? * 如果能重来，会不会在某些地方采取不同的作法? 能在 #2 与 #3 方面，双方能交换愈多的 data points 愈好; 「让 hiring manager 『觉得』他了解你、能掌握你、能管理你」, 那他 把 head count 花在你身上的机会也就大些 总结: hiring manager 也是个活生生的人，在 corporate 环境里他也只 是领薪水的。把自己当商人，商品是自己的时间，「求职」也就只是 「出售自己的时间」而已，从买家的角度去推销商品, business 101 :D : 我现在在忐忑等结果，想说发个心得，帮助需要的人，做好 : 事希望有好报 XD 祝好运 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 68.4.199.75 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Oversea_Job/M.1422726438.A.AEE.html 补述: 有些问题是需要拿捏的，例如，正式的福利(benefits)、薪资 、法律、签证问题，大概就不适合在技术面试里问，因为那些是 HR 才有被授权回答的问题；管理制度、文化、评量制度、风气，通常都 可以问，因为管理与评量是 hiring manager 的工作内容。 有些问题很明显是「白目」级的，例如，询问对方未公开产品的八卦 流言这类的，除非你想申请的职缺称谓就是「白目」，不然别问。 ※ 编辑: AmosYang (68.4.199.75), 02/01/2015 05:06:50 补述上面提到那位爆强者的作法: 先 O(scary) 暴力解，用这暴力解 来建构 unit test cases, 尤其是 edge cases, 然後再一步一步把 big-O 往下降, 同时继续增加 unit test, 虽然最後不总是能找出最 佳解, 但在工程纪律上是十分让人赞赏的 ※ 编辑: AmosYang (68.4.199.75), 02/01/2015 05:15:47 每家公司面试流程多少都有差异吧，无法一概而论 :) ^^^^^^^^^^^^^^^^ 这是一个很好的例子；以我自己来说，我观察到我自己在 MVP 三原 则里是先 mastery, 再 performance, 最後才是 visibility; 是故 我也对能展现 mastery 的求职者多少比较欣赏。相对地，我能理解 别的想法，例如「工具使用法可以再训练，脑子里有料才是最重要」 易言之，这就是为什麽这类「面试守则」总是只讲大方向。因为面试 双方都是活生生的人，无法有效穷举所有的组合然後制定最佳战术。 ※ 编辑: AmosYang (68.4.199.75), 02/01/2015 10:55:50 通常一「局」面试是 50~60 分钟，他从 O(scary) 到 O(n log n) 花了大约 25 分钟，但完全地以再实际不过的方式展现他的程式能力 ，包括使用 TDD + ALM 工具的能力；就 "Can you do the job?" 来说，我得到了 100% 精确(precise) 的答案。 又，个人觉得极细白板笔不见得适合；从面试者的位置 (离白版 5~10 尺) 通常无法看清楚极细白板笔写出来的东西。 ※ 编辑: AmosYang (68.4.199.75), 02/01/2015 11:09:46 与其说「特别待遇」，我的看法是 1. 我希望与我共事的人收到的讯息是「只要合情合理合法(ethically, professionally, legally)，符合验收条件，我不在乎你到底要 怎麽作」 2. 面试是双向的；既然舞台已经交给了求职者，他要怎麽展现他的 能力及证明他的 business value, 我不在乎，只要能让我看懂 就好 易言之，我崇尚的是 "absolute yet disciplined freedom"; 白板 或笔电都好, 以软体业来说，工程纪律是必要的，但其他环节上我宁 愿舍「制式流程的效率」，取「创意」 那你比我强太多了 orz git 的确是用熟就好，会了就是会了 但我没有自信能在面试场合的压力下还能走 TDD; 我玩 topcoder 或 ACM ICPC 题目写出来的程式都是无可读性的 hacky spaghetti clusterfuck black magic code... XD 我想，就这个话题，我们唯一能达成的共识就是「因为这类理念是建 构在更广层面的『人生态度』上，并无好坏优劣之分，但也因为基本 价值观的差异，所以无法达成共识」 XD ※ 编辑: AmosYang (68.4.199.75), 02/01/2015 11:55:38 如果「软体测试」指的是有能力作 test automation, 从 functional, integration, performance, 到 stress testing; security vulnerability scanning & analysis; legal compliance; 领导 testing strategy, 这类事的话，虽说专门开给这方面的职缺不多(感觉上 contractor / consultant 居多), 但收入还不错 如果「软体测试」指的是手动测试後写报告, 顶多走走 exploratory testing 的话，低。 ※ 编辑: AmosYang (68.4.199.75), 02/01/2015 14:21:51 *感觉上*, 公司规模大的才有资源去开 Test Engineer, Software Engineer in Test 这类职缺；规模小的必须把资源集中在开发。 虽说这种工作难找，但相对的，也因为工作难找，所以有实战经验的 人也少，竞争也少。近年吹起的 DevOps 风的确提昇了对这方面的需 求 有些公司是真正开始了解 DevOps 的意义，有些公司则是追着 buzzword 跑，把 DevOps 当成「一个 dev 抵三人用」的仙丹，就像之前什麽 东西都要来 cloud computing 一下… ※ 编辑: AmosYang (68.4.199.75), 02/02/2015 00:22:26