实用指南Guide

把 JD 变成面试题库：面试官其实在问什么Turning a job description into your question bank

拿到 JD，怎么知道面试会问什么？How do I know what they'll ask from just the job description?

JD 的每一条职责，都是一道行为题Every responsibility line is a behavioral question

「负责核心系统的性能优化」几乎必然对应「讲一个你做过的性能优化项目，效果如何量化」。把 JD 的职责逐条改写成「请举例说明你做过……」，你就得到了一份八成准确的题库。"Own performance optimization for the core system" almost certainly becomes "walk me through an optimization you led and how you measured it". Rewrite each responsibility as "tell me about a time you…" and you have a question bank that is right most of the time.

任职要求里的动词，决定了技术题的深度The verbs in the requirements set the technical depth

「熟悉」通常问概念和取舍，「精通」会问实现细节和边界情况，「有…经验」会追问具体项目背景。看清动词，你就知道该准备到哪一层——准备过深浪费时间，过浅当场露怯。"Familiar with" usually means concepts and trade-offs; "proficient in" invites implementation details and edge cases; "experience with" invites project specifics. Read the verb and you know how deep to prepare — too deep wastes time, too shallow shows.

JD 里没写的，往往是最该问回去的What the JD omits is what you should ask about

没写团队规模、没写这个岗位为什么空缺、没写成功标准——这些恰恰是你反问环节最有价值的问题。一个准备充分的反问，比多答对一道技术题更能改变面试官的印象。No team size, no reason the role is open, no definition of success — these are exactly the questions worth asking back. A well-prepared question changes an interviewer's impression more than one extra correct technical answer.

答案骨架比背答案有用Skeletons beat memorized answers

不要背逐字答案，准备骨架：情境-任务-行动-结果，每个骨架配 1-2 个真实数字。数字是可信度的来源；没有数字的故事听起来都像编的。Don't memorize scripts — prepare skeletons: situation, task, action, result, each with one or two real numbers. Numbers carry credibility; stories without them all sound invented.