面试准备:问题、回答与反问
写在前面:这篇文章还会继续更新
这篇文章不是一份已经完善的求职指南,而是我对求职、面试准备和反向提问的一些阶段性整理。它会随着后续投递、面试反馈、岗位理解和个人选择继续更新,所以现在更像一个持续打磨中的 blog,而不是最终版本。事实上本博客站点中的大部分文章都是不断更新调整的,所以经常见到补丁痕迹和不定时的重构。
这里不会关注如何拿到一个 offer,而是讨论如何去寻找适合自己的工作并尝试。没有找到非常渴望的工作是常态,也不一定是一件坏事。当你对 title 或者别的东西过度渴望时,往往会忽视一些真实成本,最后度过一段并不愉快的时光。
求职不是单向被筛选,也不是简单地把简历投出去等待结果,而是在有限信息里不断确认:我想做什么、我适合什么、这个机会是否真的值得投入,以及进入团队之后我能不能持续成长。
这篇文章也会聊一聊,我可能会问被问到的一些问题,一些我觉得对我来说有价值的观点,可能不值得扩充为一篇blog,不过确实需要找个地方存放一下,那就先放到这里吧。
泛泛而谈的一些建议
求职前先确认方向
首先我们一定需要一个整体规划,工业界和学术界关心的问题往往没那么相近,各大公司中也存在各种业务岗位和 Lab 岗位,工作内容差距还是非常大的。
明确了这个方向,再据此决定简历重点、项目讲法和投递策略。不同方向对经历的解释方式并不一样:工业界更关注你能否解决真实问题、能否协作交付、能否把技术放进业务流程;学术路线则会更关注研究问题、方法创新、论文产出和长期研究潜力。
目标定位也不应该只看岗位名称。一个岗位是否适合自己,通常要一起考虑行业、城市、薪资、成长空间、专业匹配度,以及企业文化是否符合自己对工作节奏和加班强度的接受度。
很多岗位名称看起来相似,但实际工作可能完全不同;同样是算法、数据、后端或者 Agent 开发,有的更偏研究探索,有的更偏业务交付,有的则更接近工程平台和工具链建设。可能需要根据 JD 确定或者多方面打听,最起码需要在面试的时候问出来。
当然,规划不是一次性决定。外部机会、市场需求和个人状态都会变化,真正有用的规划应该允许自己根据投递反馈、面试反馈和兴趣变化不断调整。
怎么判断一个机会值不值得去
我会把机会拆成几个维度来看:收入、方向、成长、匹配度和团队氛围。薪资当然重要,但它不是唯一指标。如果更在意长期前途和能力增长,就要重点看团队方向、业务质量、岗位能提供的锻炼,以及自己能不能在里面接触到真正有价值的问题。
方向是否匹配尤其重要。一个岗位如果短期待遇不错,但实际工作和自己长期想做的事情关系很弱,就需要认真评估它会不会把自己带到一个并不想深入的路径上。反过来,有些机会短期不一定最优,但如果团队问题足够真实、技术栈足够贴近自己的长期方向,也可能值得考虑。
团队氛围同样不能忽略。日常协作方式、决策机制、对技术债的态度、是否允许个人成长和探索,都会直接影响工作体验。很多问题只有在面试反问阶段才能逐渐看出来,所以反向提问不是流程末尾的客套,而是求职决策的一部分。在本篇的结尾我们会讨论一些反问,作为参考。
面试准备不只是背答案
面试准备不能只理解成背八股或者背标准答案。对技术类岗位来说,Coding 基础和常见问题当然重要,它们决定了能否顺利通过筛选和技术面。但项目经历本身也需要提前整理,否则很容易在面试时讲成流水账。
我会尽量把每段经历整理成几个问题:当时要解决什么问题,难点在哪里,我具体承担了什么角色,用了什么方法,最后产出了什么结果,这件事的价值和边界分别是什么。这样组织之后,面试官更容易理解项目,也更容易判断我在其中的真实贡献。
科研项目、企业合作项目、解决实际问题的论文、比赛经历和实习经历,只有被整理成清晰的问题链条,才会真正变成面试中的有效材料。否则经历再多,也可能只是简历上的几个名词。
一些关于我的相关问题
非客户端开发背景,能为游戏研发 AI 提效带来什么
我没有传统的游戏客户端开发背景,过去主要做统计学、机器学习和不同领域的 AI Agent。这个背景放到游戏研发 AI 提效里,我觉得反而有一个优势:我比较容易先跳出既有岗位和工具的划分,从模型能做什么、团队最终要交付什么出发,重新考虑中间的工作应该怎样组织。既有的岗位分工、工具和交接方式,都可以拿出来再想一遍。有些需要保留,但我希望先弄清楚,它们是在满足什么需求。
现在的管线里,有不少安排是为了方便人工作:一个岗位产出文档,下一个岗位把文档翻译成工程,再交给别人接入和检查。模型能够读取的信息、调用工具的方式,以及获得反馈的速度,都可能让这些交接有了新的做法。我们可以给每个岗位配一个助手,也可以沿着最终交付物往回看,重新判断哪些中间步骤还有必要。我更感兴趣的是后面这条路。对既有流程没有那么强的依赖,让我更容易从外部提出这些问题,也更愿意尝试适合 AI 执行的任务划分。
我在《企业 AI 为什么总卡在试点?》里也聊过相近的问题。员工会用 AI,团队仍然要把一次生成接成能够反复交付的一段工作:输入由谁提供,结果由谁验收,出错以后谁接手,人工改过的地方又怎样留给下一次使用。我想探索的是,把这些关系和工具一起重新设计,让 Agent 推进常规任务,由人确定目标、作关键判断并处理例外。已有的团队分工会影响系统设计,新的系统也可以反过来改变交接和协作方式。这种变化可以先从一段具体工作开始,随着实际使用逐步调整。
这种考虑和我过去跨领域做 Agent 的经历有关。安全、舆情分析和游戏 UI 的业务相差很大,我却一直在处理一些相近的问题:模型缺少什么信息,哪些判断可以交给它,工具执行以后又该怎样验证。换一个场景,我会先把目标和约束拆清楚,再选择系统怎么组织,人的岗位划分只是其中一种参考。在网易做 UI Agent 时,我尝试让模型判断语义和结构,通过中间表示把结果交给确定性代码装配,再复用历史控件,用编辑器反馈检查。从设计稿到可用工程,这条路径让我看到,表示方式和工具接口也值得重新设计。它们会影响模型是否容易完成任务,以及出错以后能不能及时修正。游戏项目的具体规范要满足,完成任务的操作方式则可以继续探索。
统计学背景让我会接着追问,这种改法到底好在哪里。一张设计稿跑通了,换一个复杂界面是否还能用?同一个任务多跑几次,结果是否稳定?这些都需要样本和对照。准备资料、等待交接、检查结果和返工的时间,也得一起算进去。模型生成得快,后面的人花更多时间收拾,整条流程就未必省了工作。我希望用这些反馈决定下一步:保留有效的改动,弄清失败发生在哪里,再修改自己的判断。人工修正和异常记录也应该留下来,把其中验证过的经验补进后续的知识、工具和评测里,让团队下一次处理相近任务时能够继续用上。
我在《AI Native Game》里反复问过,AI 最后能给玩家带来什么。放到研发提效里,我也希望把这个问题留着:省下的时间,能否让团队多试一个方案,让设计想法更早进入引擎、得到反馈?模型的能力决定了我们可以尝试哪些新的做法,作品的方向、审美和体验仍然要由人把握。我期待 AI 能让过去因为制作成本太高而停在纸上的想法,多一些被做出来、被验证的机会。非客户端出身给了我重新看待流程的位置,跨领域的 Agent 经验和统计训练,则让我能够把设想做成原型,检查它有没有用。我想在游戏研发 AI 提效里承担这样的工作。
对具身智能的一些理解
看起来我的简历和具身智能以及机器人没有任何关系,但是我确实对这个方向很感兴趣。我不关注 VLA 模型的训练,跟我之前一直研究的问题一样,我更关注应用,以及这个东西应该如何被真实地落地。
具身智能的落地可能不是一个强大的 VLA 模型,GPT 6 Astra 的发布可能为 Gen-AI 带来了一些新观点。
如果我们想画一张图片,可能并不需要一个扩散模型生图,而是可以让一个文本模型通过 Tool Calling 靠 SVG 画出鹈鹕;如果你想去建出一个优秀的三维模型,那么类似于 Meshy AI 的生成式模型或者混元的三维生成模型,可能不如直接让 AI 根据视觉效果在 blender 里面靠调工具慢慢画。生成式语言模型现在有 Omni 的输入,可以通过”生成—渲染/执行—检查—修改”的反复执行去更加贴近人类目标。
我们可以将其称之为 Agentic Generation,一种在 End2End Model Generation 以外的新形态,此时无论是我在网易做的 UI Gen 工作流还是 Embody-AI 的落地,最终都可以被归类为 Agentic Generation,与此同时,传统的生成模型,无论是生图还是视频和动作,都可以被视为 Agentic Generation Tools 的一部分,而优化这个 Agent 系统本身将成为微调 Pi-0.5 以外的核心工作。
Agentic Generation 相比于通过端到端模型进行生成,还会带来一个更大的优势,**整个生成 Pipeline 的可检查和可控性。**用户需要的是满足要求的结果,而实现它可能需要选择表示方式、调用工具、观察中间结果、局部修改和验证。Agentic Generation 可以接受用语言或者 Agent 逻辑代码描述的约束、路由多种多样的能力、保留中间状态并进行局部修正,当整个系统可以被追踪和复现,它的调试和修改速度总会比训练一个模型更快。
Agentic Generation 又在尝试找到**哪些决策适合留在模型内部,哪些能力需要通过外部工具、状态管理和执行机制实现?这些边界如何随任务变化?**等选项之间的 TradeOff,底层 VLA 和高层 Agent 混合可能是短期来看更现实的路线,但那个平衡点在哪?
工作在物理世界的机器人,很多动作做完以后就不能再 Ctrl+Z。具身智能的 Tool 应该如何被设计,应该给出大脑什么样的反馈?我在《当我们构建 AI Agent 时,我们究竟在解决什么问题?》讨论前向知识与后向反馈的部分里写过:Tools 从来不是一份工具列表,而是 AI Agent 能看到、也能影响的整个世界。,之前的 Tool Calling 主要集中在虚拟空间,到了物理世界,这个判断需要落到更具体的接口和反馈设计上。
把这些问题放到具身智能里,工具返回的就不该只有一句“调用成功”,还需要让大脑知道动作是否真的完成、环境发生了什么变化,以及失败以后还能做什么。这些信息怎样从传感器、VLA 与底层控制系统中获得,又应该以什么粒度、什么时机交给上层 Agent,仍然是我想进一步研究的问题,应该还没有任何人能够给出这个问题的答案。
我遇到的最大的困难是什么
好像不止一次在被面试的时候问到这个问题,尤其是现在开始流行的 AI 面试,非常喜欢给你问一堆没什么卵用,但是就是想问。
如果一定要说我遇到过最大的困难,我觉得可能不是某一个具体的技术问题,而是:在不知道答案是否存在的时候,仍然要决定下一步做什么。
因为我过去做的很多事情,其实不是那种已经定义得非常清楚的工程题。尤其是 AI 和 Agent 相关的项目,很多时候一开始连问题的边界都不是很清楚——模型能力到底够不够,这条技术路线能不能走通,甚至什么样的结果才算“有效”,这个问题本身是否有解,都不一定知道。
而我现在比较习惯的一种方式,是先根据自己当前掌握的信息和经验,形成一个 Belief,也就是我现在最相信、最值得尝试的一条技术方向。对于一个技术出身的开发者而言我认为有 Belief 是应该的,也是大概率的事情,这是之前做过的项目总结下来的经验。
然后我不会花很长时间试图证明自己一开始就是对的,而是尽快围绕这个方向做出一个最小原型。因为对我来说,原型最重要的作用不一定是把东西直接做成,而是让我从真实的技术反馈里获得新的信息。因为每一次原型、每一次失败,都会改变我对这个问题的理解。然后我再根据新的信息去修正自己的 belief,选择下一条更有可能的路线,再做下一轮尝试。
所以后来我越来越觉得,面对未知问题的时候,最重要的能力可能并不是一开始就找到正确答案,而是:你能不能形成一个足够好的判断,快速走出去,然后让现实不断纠正你的判断。
这也是为什么我现在其实挺喜欢处理一些答案不明确的问题。因为一个已经知道怎么解决的问题,本质上更多是在执行。但一个一开始不知道有没有解的问题,你需要不断观察、判断、尝试,然后慢慢从混乱里找到结构。它有挑战性和以及本身的乐趣。
我觉得这可能是我这些年面对困难时形成的最重要的一种习惯。
面试反问:我会重点确认什么
反向提问的核心目的,是确认团队真实在做什么、岗位真正需要什么、自己加入后会承担什么,以及这份工作是否符合自己的判断。
下面这些问题更偏 AI Agent 工程化岗位,主要用来判断团队的技术路线、产品落地方式、工程成熟度和协作方式。也存在一些通用的问题,均可以作为提问的参考,或者参考这个仓库:viraptor/reverse-interview。
Agent 与工程化方向
我了解到公司在积极布局 Agent。在目前的规划中,咱们的 Agent 应用是更偏向于对内赋能,比如研发提效、内部知识库问答和运营自动化,还是已经有明确的对外商业化产品落地场景?团队主要在解决什么问题,我进去以后的主要工作会是什么?可以给出一些具体的例子。
注1:这是非常公式的提问,是作为了解部门业务的基础提问,基本上所有的反问环节都应该包含一个这样的问题或者类似的问题。
注2:ToB(面向公司内部)和 ToC 对于 AI Agent 是一个我认为的关键问题;Agent ToB 的容错相对更高,也更容易推进新技术测试和迭代,但可能属于边缘业务;ToC 则更需要关注幻觉、稳定性和用户体验等问题,它会更利于学习系统的工程化以及安全边界的设置,但推进新技术相对更难。
注3:基于这个问题的答案进行一些更加细节和专业的追问可能会为你加分,最好提供一些二选一的选择题以及进行引导性提问。如果 A or B 总是被回答成 both 或者绕开回答,那就把自己的假设说清楚,然后等对方否定,也是个可以的方案。
目前行业里 Agent 的应用百花齐放。咱们团队聚焦的场景,是更偏向于处理明确的结构化任务,比如通过 API 调用执行自动化流程,还是更侧重于对非结构化知识的深度理解与推理,比如基于复杂长文档的结构感知与 Agentic RAG?
注:前者更加侧重自动化 workflow,需要对业务本身有深入理解;后者则更侧重 Agent Dev 相关技术,更高的自主权也更依赖模型能力,以及开发者对安全边界的认知。这属于一个 A or B 的技术拷打,和 Agent 本身关系紧密。
关于咱们关注的 Agent 应用场景,目前的系统设计是更多定位在 Copilot 模式,也就是需要频繁的人类反馈和确认,还是致力于在特定垂直业务流中实现高自动化率的闭环工作流?
注:Human in the loop 目前来看依旧很重要。如果希望打造高自动化率系统,自动化的高质量校验会是核心问题;如果更多允许人工介入,那么扩展系统功能可能会比打磨极致自动化更值得关注。这属于一个 A or B 的技术拷打,和 Agent 本身关系紧密。
考虑到复杂业务场景的需求,咱们目前的重心是在打磨单智能体的复杂任务拆解能力,还是已经开始探索多智能体协作的业务落地?
注:多智能体协作已经从技术报告逐渐进入 Demo 阶段,虽然稳定性依旧堪忧,但它仍然是值得关注的前沿方向。当然,它更偏技术探索而非成熟技术,高自主性的 MAS 很可能会带来和人类协作类似的问题。这属于一个 A or B 的技术拷打,和 Agent 本身关系紧密。
团队目前是如何构建 Agent 评估指标的?除了传统的 LLM Benchmark,有没有针对业务建立特定的工具调用准确率、执行轨迹或者自动化评测框架?
注:Evaluation 永远是 Agent 绕不开的问题。没有评估,就很难判断系统是真的变好,还是只是 Demo 看起来更顺。如果一家公司希望搞高自主 Agent 但没有维护自己的专用 Evaluation,那么他们还没有走上正轨。
在成本和延迟上的权衡策略是什么?团队更多依赖成熟的闭源大模型,还是已经考虑将不同请求路由给不同层级的模型?是否会系统性评估成本、延迟与性能之间的 trade-off?
注:这是工程化绕不开的问题。从技术 Demo 走向生产,需要认真处理成本、延迟、性能和安全边界之间的关系。生产环境的安全边界不能轻易 trade-off,但慢一点、贵一点,有时反而是可以接受的。
如果一个团队已经深思了这个问题,那么证明他们的业务至少已经相当可用了。当然,只用自动 router 不算,但不用任何 router 更烂。
团队、协作与个人成长相关的问题
每个开发者有多大的自由来做决定?团队内部结构、协作方式和日常工作划分是什么样的?如果遇到不同意见,通常会怎样处理?
注:了解一下团队整体的工作情况,这个问题可以追问一些团队氛围,技术协作之类的问题。
一个典型的一天或者一周的工作是怎样安排的?
注:你就可以追问这个。
AI Coding 已经介入了绝大多数程序员的工作流。公司如何看待 AI Coding?是否允许员工在项目中较多使用 AI Coding 来加速迭代?团队是否会提供统一的 AI 工具、账号或使用规范?
注:程序员现在没得 AI 用确实活不下去了,当然这个问题目前来看和 Infra 大神以及写算子选手无关。一个 Pro5x 是公司及格线。
你对在这里工作最满意的地方是什么?你为什么选择并留在这家公司?
注:感觉在拷打面试官,本问题是网上抄的,本身不对此问题负责。
团队的工作时间和加班情况是怎么样的,On-call 的情况,以及加班费相关问题。
注:正式入职可以多考虑考虑 WLB,实习生感觉无所谓。
我可以为开源项目做贡献吗?是否需要审批?
注:这个问题注释就在题目里。
公司是否有技术分享交流活动?有的话,多久一次呢?
注:这个问题注释就在题目里。
有公司级别的学习资源吗?比如电子书订阅或者在线课程?有获取证书的预算吗?有官方的学习经费吗?
注:花公司的钱,干自己的事情,让人感到有薅羊毛的爽快感,虽然和工资相比可能九牛一毛,但莫名的爽怎么回事?
你们现在盈利吗?如果没有的话,还需要多久?如果有的话,年度营业额是大概有多少?公司未来的计划是怎么样的。
注:去 Startup 和偏向 Startup 风格的小公司可以提问,毕竟公司不赚钱等于慢性倒闭。
远程工作和办公室工作的比例是多少?
注:CN 真有远程工作?
HR 面与谈薪:必须确认的问题清单
到了 HR 面和谈薪环节,判断一份工作是否适合自己,还需要落到一些很具体的条件上:收入怎么组成、在哪里工作、要投入多少时间,以及哪些待遇真正适用于自己。下面这份 check list 可以在 HR 面、谈薪和接收 offer 之前逐项确认。
薪资:年包、兑现与谈薪空间
1. 年包由哪些部分组成?
问:这个岗位的薪酬结构是怎样的?税前固定月薪是多少,固定发几个月?额外几薪是否有条件?季度绩效、年终奖和补贴分别怎么计算,是否已经包含在报出的年包里?
记录:把固定工资、保底奖金、目标绩效和非保底奖金分开记,核对季度奖金与年终奖有没有重复计算。另问清报价是否包含公司承担的社保、公积金或其他福利成本。
2. 浮动绩效到底有多大,通常能兑现多少?
问:年包中的奖金哪些保底,哪些按考核浮动?季度奖金和年终奖分别受个人、团队或公司业绩怎样的影响?方便的话,同岗位正常绩效水平近一两年的兑现情况大概是什么区间?
记录:考核周期、等级对应的奖金、发放条件,以及是否存在没有奖金的情况。把目标奖金和实际兑现情况分开,往年情况也不能直接当成未来承诺。
3. 试用期待遇和首年收入有什么区别?
问:试用期多久,工资是否与转正后相同?校招入职当年的季度奖金、年终奖和额外几薪是否按月份折算?有没有最低在岗时间或转正时间要求?
记录:分别确认入职当年、入职后十二个月和首个完整年度的收入计算方式,并标明各自依赖的绩效假设。
4. 工资和奖金什么时候发?
问:每月发薪日是哪一天?季度奖金、年终奖和额外几薪通常什么时候发,是否分批或延后?发放时是否要求仍然在职,离职或岗位变动会怎样影响结算?
记录:每笔钱对应的工作期间、发放日期和领取条件,避免把已经计入年包、但尚未到领取时间的钱当成手头收入。
5. 是否有签字费、入职奖或股权激励?
问:有没有签字费、入职奖、留任奖、股票或期权?现金奖励何时发、是否分期?股权的授予、归属和兑现条件是什么?提前离职是否需要返还奖励,返还范围怎样计算?
记录:一次性现金、附带服务期限的奖励和股权分别列出,股权注明授予数量、归属时间与兑现条件,单独评估。
6. 当前报价对应什么职级,还有哪些可以协商?
问:这个报价对应什么职级和薪酬档位?固定月薪、奖金、职级或入职奖中,哪些还有调整空间?如果调整其中一项,是否会减少其他部分?
记录:最终谈定的每一项及其条件。比较调整前后的固定收入与浮动部分,确认“年包提高”具体提高在哪里。
工作地点:地址、驻场与调动
7. 日常办公地点具体在哪里?
问:日常办公地点在哪个区、哪个园区、哪栋楼?可以提供详细地址吗?培训期、试用期和转正后的地点是否一致?
记录:拿到能直接查询通勤的地址,核对通勤时间、租房位置,以及工作地点是否已经确定。
8. 是否需要出差、驻场或跨城市工作?
问:岗位是否经常去工厂、客户现场或其他城市?有没有固定驻场安排?通常一次多久、一年大概占多少时间,周末能否返回?
记录:地点、频率、持续时间和是否必须接受。尤其是集团 IT 服务或客户交付部门,要问清自己日常跟哪个团队、在哪里工作。
9. 地点调整和远程办公怎样安排?
问:后续是否可能轮岗、换园区或异地调动?调整前怎样沟通?如果有远程或混合办公,适用于这个岗位吗,需要什么审批,试用期能否使用?
记录:已确定的安排、可能变化的范围,以及劳动合同中关于工作地点的表述。把远程政策与这个团队实际允许的安排一起核实。
工作时间:日常节奏、加班与值班
10. 实际上下班时间和双休情况怎样?
问:制度规定几点上下班,团队平时实际几点到、几点走?午休多久,周末通常是否双休?项目上线、交付或业务旺季时,工作节奏会变化多久?
记录:分别记制度工时、日常实际工时和高峰期安排。实际节奏请未来负责人补充,最好给出最近一个项目的具体情况。
11. On-call、夜间响应和节假日值班有多频繁?
问:有没有轮值或 On-call,需要随时在线还是到现场?一个人通常多久轮到一次,夜里和节假日响应有什么要求?校招生何时开始参与,有没有交接和支持?
记录:值班频率、响应要求、实际占用的休息时间,以及值班后如何安排休息。
12. 加班和调休怎样认定、补偿?
问:岗位执行什么工时制度?晚上、周末和节假日加班分别怎么记录,是否需要事前审批?加班工资、值班津贴和调休各自适用什么情况?调休怎样申请,有没有使用期限?
记录:认定方式、补偿标准、审批流程和调休能否实际安排,取得适用于这个岗位的制度说明。
岗位内容与职业发展
13. 实际工作属于什么技术方向?
问:这个岗位主要做大模型和 Agent 系统研发,还是业务应用集成、数据治理、IT 系统建设或运维支持?入职后最先参与什么项目,研发、交付和支持工作大概怎样分配?
记录:具体项目、交付物和职责边界,确认能否积累自己希望发展的核心技术。HR 不清楚的部分,请未来负责人继续说明。
14. 部门、团队和岗位是否已经确定?
问:属于集团哪个业务部门、哪条团队,向谁汇报?是招聘时就定岗,还是入职培训后再分配?有没有轮岗,定岗依据是什么,个人能否参与选择?
记录:确定的岗位安排和仍待分配的部分,确认最终定岗时间,以及实际职责是否与 JD 和技术面介绍一致。
15. 试用期和日常绩效怎样考核?
问:入职前三到六个月主要期待完成什么,转正由谁评价?正式绩效多久评一次,依据哪些目标,怎样反馈结果?驻场或跨团队工作时,由谁负责考核?
记录:目标、评估人、周期和反馈机制,把转正要求与后续奖金考核对应起来。
16. 调薪、晋升和培养机会是什么?
问:一年通常有几次调薪或晋升评审,校招生最早何时有资格参与?技术岗位有什么发展通道?是否安排导师、培训或内部转岗机会,各自需要满足什么条件?
记录:评审制度、参与资格和实际可获得的机会;“每年有评审”本身不能算作已经约定的调薪。
合同与入职安排
17. 最终和哪家公司、以什么形式签约?
问:劳动合同主体的完整名称是什么,合同期限多长?是直接与用人单位签劳动合同,还是涉及劳务派遣、外包等安排?实际用工、发工资和办理社保的主体分别是谁?
记录:各主体及其关系,确认招聘品牌、所在部门和实际签约公司之间的对应关系。
18. 接收 offer 和正式入职有哪些条件、时间节点?
问:offer 答复期限、三方签约时间和最晚入职时间是什么?需要哪些毕业、学位、体检或背景核验材料?如果毕业或报到时间变化,怎样协调?此前实习经历是否影响试用期和待遇?
记录:材料清单、关键日期、尚未完成的入职条件和联系人。
19. 是否有竞业、服务期或费用返还约定?
问:合同或附件中是否涉及离职后的竞业限制,其适用范围、期限和补偿怎样约定?培训、入职奖有没有服务期或返还条款?保密与知识产权约定怎样涉及个人项目、开源贡献或兼职?
记录:具体条款和适用条件,签约前拿到相关文本;有不清楚的地方,继续核对适用规定。
20. 谈定的条件可以在哪里书面确认?
问:薪酬明细、岗位、地点、入职时间和关键福利,哪些写入 offer、合同或附件?其余制度可以提供文件或邮件确认吗?如果几份文件的说法不同,能否先解释并更正?
记录:最终版本、确认人和适用日期,把仍未答复的问题一起列出来。
福利:逐项确认内容、资格与成本
福利部分可以沿着一套共同的问法往下聊:具体提供什么、谁能用、何时开始、个人要付多少、怎样领取,以及是否占用已经报出的年包。社保、公积金和各类假期也放在这里逐项核对。
21. 社会保险在哪里、按什么标准缴纳?
问:社保在哪个城市办理,各险种的缴费基数和个人承担部分怎样确定?新入职从哪个月开始办理,试用期与转正后怎样衔接?如果办公地、合同主体所在地和缴纳地不同,异地就医或关系转移由谁协助?
记录:缴纳地、基数计算方式、个人扣款和办理时间,核对缴纳地现行规定与实际工资扣款。
22. 住房公积金的基数、比例和开始时间是什么?
问:公积金在哪个城市缴存,个人与单位的缴存比例分别是多少?新入职的基数如何确定、何时调整?从哪个月开始缴存,单位部分是否已经算入报出的年包?
记录:缴存地、基数、双方比例及月缴存额。单位缴存额单列,工资里的个人扣款也单列。
23. 除此以外有什么补充保障,如补充保险、体检等
问:除了基本社保和公积金,还有哪些补充保险、企业年金或补充公积金?个人是否需要出资,参加是否自愿?何时有资格参加,单位投入部分是否有归属或服务年限条件?
医疗与商业保险:是否包含门诊、住院、意外或其他保障,能否覆盖家属?适用哪些医院和项目,有没有等待期、免赔额、报销比例和年度上限?需要先垫付吗,怎样申请理赔?
体检与健康服务:入职体检费用由谁承担,是否指定机构?有没有年度体检、心理咨询或其他健康服务,个人要付多少?体检如何预约,是否需要占用自己的休假?
记录:逐项记下项目名称、双方出资、使用资格和开始时间;保险另记保障范围与理赔流程,健康服务另记内容、频次和费用。涉及归属或服务年限的保障,确认领取与离职处理规则,并保留相应说明。
24. 住房、宿舍或租房补贴具体是什么?
问:有没有宿舍、人才公寓或租房补贴?房型、距离、排队时间和可住期限怎样,房租、水电、网络或押金由谁承担?租房补贴多少钱、发多久,需要哪些材料,试用期能否领取?
记录:实际住房成本、资格、期限和开始时间,确认住宿与租房补贴能否同时享受,以及补贴是否已包含在年包中。
25. 通勤和加班交通有什么支持?
问:班车有哪些路线、站点和时间,末班车能否覆盖团队实际下班时间?有没有交通补贴、停车优惠或夜间打车报销?报销需要满足什么时间、金额和审批条件?
记录:自己通勤能用上的安排、个人费用和报销上限,把班车时间与实际工时一起看。
26. 带薪年假有多少,实际怎样安排?
问:法定年假与公司额外年假分别有多少,工龄如何认定?入职当年怎样折算,什么时候可以开始使用?项目期间怎样请假,未安排的年假如何处理,公司额外假期是否有结转规则?
记录:适用天数、计算方式、请假流程,以及团队是否能实际安排休假。
27. 病假和其他假期的待遇是什么?
问:病假、婚假、育儿或护理等适用假期怎样申请,需要什么材料?期间工资、绩效与补贴怎样计算?公司是否另有福利假,试用期适用规则是什么?
记录:与自己相关的假期规则和工资计算方式,区分当地规定与公司额外提供的待遇。
28. 其他福利与领取规则还有哪些需要确认?
问:有没有通讯、健身、节日或其他福利?各项福利是否受城市、职级、合同形式、绩效或转正状态影响,哪些只适用于总部或特定园区?通过现金、卡券还是报销提供,需要主动申请吗?
记录:适用于自己的福利清单、发放周期、申请入口和个人成本,确认金额是否已计入工资、年包或其他补贴。
对比这些内容可以判断这个 Offer 是否符合我们的预期,并考虑是否需要展开横向的比对。
本文仍旧在长期更新。
- 标题: 面试准备:问题、回答与反问
- 作者: Hyacehila
- 创建于 : 2026-09-06 16:00:00
- 链接: https://hyacehila.github.io//blog/2026/09/07/about-interview/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。