这篇其实提到很多重点, 我想在这边补充一些细节
个人背景: 美国某特爱考BQ大厂面试官, 面试数十人, 跨各种level&role
※ 引述《yschen25 (卡)》之铭言：
: 我自己在准备 behavior questions 的时候，
: 会把题目按照不同类型分类，
: 这样你在回答的时候，知道某种情况的问题大致是可以回答哪一种答案。
: 再来列下各别问题的答案，但这里要注意的是
: 面试官问的问题，其实是隐含他想知道的事情，比如说这题 :
: "Tell me about a time you failed. How did you deal with the situation?"
: 面试官其实是想知道 :
: * 你是否愿意承担责任，不是找借口或是责怪别人，而是从错误中学习，
: 并且利用此经验在下一次处理事情上。
所有的面试过程 (phone interview, on-site, BQ, coding) 其实都是为了回答一个
终极问题: 这个申请人到底能不能胜认这份工作?
所以回答的重点应该是 "以实际的例子去佐证你具有某些能力"
: 这边回答的技巧是 :
: * 不要说自己从没失败过
: * 简短的举出实例说明
: * 但不能是频繁发生的问题 (会显示你很粗心，没学到教训)，或是很严重比如损失好几万
: 的订单 (讲了应该会不敢用你)
: * 不要找借口，不要抱怨，不要把错怪在别人身上
: * 显示出你从这件事学到什么，怎么避免下次再发生
: 回答范例可以按照 Situation, Action, Result 去回答
: Situation (情况): I was managing a project for one of our biggest clients in
: my previous company, and I was so eager to please them that I told them we
: could finish the project within 2 weeks. I thought this was doable, but it
: ended up taking 3 weeks and they were not happy. Looking back, I realized I
: should have been more conservative in my estimate to the client. I realized
: that a client isn't going to be upset if you're clear about the timeline in
: advance, but they are going to be disappointed if you promise something and
: then don't deliver.
: Action (行动): So I took this experience and used it to become much better at
: managing the expectations of clients during projects I oversee
: Result (结果): on the next project with a different client, I told them it'd
: take 4 weeks and we finished in 3. They were very happy about this.
这个范例很有意思, 可以很清楚的说明面试官跟申请者在意的不同点在哪里
你心中想的:
S: 团队承诺2周deliver, 结果花了3周, 客户很不高兴
A: 你学到下次估计要估得更好
R: 下次专案超前完成
面试官的笔记:
S: 团队承诺2周deliver, 途中遇上困难, 可能无法如期完成
A: candidate没有采取任何行动 (no data)
R: 专案延迟, 客户非常不高兴
Debrief: 介于 no hire 跟 strong no hire 之间, 取决于其他 follow-up question
那么这个回答有什么问题呢?
首先, scope 太小, 但凡工作超过 2 年以上的人都不该给出这么 "浅" 的范例
再来, 细节含糊不清, 你中间提到 "become much better at managing the
expectations", 但是却完全没有解释 "how", 说服力很低
最后, 估计4周但3周做完未必是好事, 这种行为有个专业术语叫 "sandbagging",
意指故意估一个比预期长的时间, 面试中给这种回答风险很高
如果我是面试官, 我期待的理想回答会是这样的:
S: 团队承诺2周deliver, 途中遇上困难, 可能无法如期完成
A: 我采取以下行动
1. 首先尝试排除障碍, 争取如期完成
2. 发现#1不可能, 立刻对目前及剩余的工作reprioritize
3. 跟stakeholder沟通, 重新定义 minimum viable product (MVP)
4. 跟leadership沟通, 设法争取额外资源/人力
5. 发起 daily standup 加速团队沟通, 可以第一时间排除困难
R: 虽然2周无法完成所有功能, 但是最核心的 MVP 有交出去, 团队额外花一周
补齐所有功能, 事后我主动召开检讨会, 制定下次的预防措施及流程
这样就是一个最标准的答案了, 但实际上在我经历过的所有面试里面, 大约只有不到
30% 的人可以完整回答
换句话说, 如果能说到这种程度, 基本上就赢过一半以上的人了
: 别人问问题的时候，也不一定要直接回答，可以先反问对方，
: 厘清说对方想问这个问题的用意，而且这样也有更多互动，
: 显示出你是会去思考问题的人，而不是只会回答。
: 比如说对方问 : Do you think you are a good developer?
: 你可以反问说 : How do you define the definition of good?
: The developer who can write the good code? Or they have good communication
: skills?
这个例子也蛮微妙的, 如果说面试官是我, 就会反问你 "What do you think?"
通常面试的问题都是有设计过的, 像这种很直接的反问很吃面试官的脾气
(但如果你是真的不知道何谓 "good", 又恰好说明你经验不足)
如果真的要反问, 可以这样说: "Yes, I do consider myself as a good developer,
I can expand on this topic in two areas: coding competency and soft skills.
Which one do you prefer me to explain first?"
=====
如果有人需要的话, 我可以帮忙提供 1-1 的 mock interview
流程大概是: 花20-30分钟按on-site标准问BQ, 10-20分钟讨论反馈, 回答问题
虽然是杯水车薪, 但还是希望可以多少帮助最近要面试的人
有需要的麻烦在这篇文章推文, 我会乱数选出3-5名, 预计7/25-8/5这两周左右安排