优先选那种能长期用、能反复迭代的项目，而不是一次性demo。比如做一个“个人效率工具”：自动整理信息、总结内容、生成报告，自己真的用一段时间，就会知道哪里不够好、该怎么优化。

我自己没遇到特别极端的，但感觉差异确实挺大。有的公司补贴比较全，餐补、打车、设备这些都有；也有的基本靠自己解决，加班福利也比较少。整体还是看公司阶段和业务情况，互联网大厂一般福利更规范一点，小公司波动会更大。

基本卡在一面比较多。很多时候是项目还没讲清楚，或者基础问题答得不够稳，就容易被刷。现在主要在补基础和把项目梳理得更清楚一点。

最怕听到的是“这个不急，你先看着做”。听起来很轻松，但其实意味着没有明确截止时间和标准，很容易反复改，还不知道做到什么程度算完成，心里反而更没底。

可以去，而且很多时候比空窗更划算。如果大厂还没结果，小厂先做着至少能积累真实经验，后面再投大厂也更有底气。真正需要担心的不是“去不去小厂”，而是去了之后有没有学到东西、有没有产出能写进简历的内容。至于“两难”的情况，其实也很常见。一般可以先接，再看大厂结果，真拿到更合适的机会再做取舍就行。关键是别让自己一直停在原地。

那段时间基本是“自己给自己找事做”。把之前项目重做一遍，把能补的细节都补上；顺手整理一份常见面试问题的笔记，逼自己能讲顺。偶尔也会刻意放空一会，比如出去走走或者做点别的事，不然一直盯着招聘信息，反而更容易焦虑。

写过“主导项目实现”。其实当时只是参与其中一部分，很多关键决策是别人定的。面试被问到整体方案和取舍时有点接不上，从那以后写这种词都会更谨慎，尽量按真实贡献来写。

我会优先选“有真实使用场景”的项目，而不是只跑demo。比如做一个能长期用的工具：自动整理资料的Agent、个人知识库问答（RAG）、或者帮写总结/周报的小助手。重点是你真的用过一段时间，能说出它哪里好用、哪里有问题。面试更看的是：你有没有把一个想法做到“有人能用”，而不是模型多复杂。

我一般会避免写“会用XX模型”，而是把过程拆开写清楚。比如写：怎么拿到数据、做了哪些处理、模型是怎么选的、有没有做过调参或优化，最后效果怎么样（哪怕是简单指标也行）。再单独强调自己负责的部分，比如是做数据、写训练流程还是部署接口。让人一眼能看出来你是“真做过”，而不是只调过API。

最怕听到的其实是“这个你先试一下”。听起来很轻，但往往意味着没有明确指导，要自己摸索一堆不确定的东西，还不太好问太多细节，只能边做边改。

没面试的时候基本就是三件事循环：改简历、投递、补能力。白天会看有没有新岗位，顺手投一轮；中间穿插刷题或者补一个小项目，把简历内容再“实一点”。说实话焦虑肯定有，但如果什么都不做更容易乱想，所以会尽量让自己每天都有点具体进度。偶尔也会出去走走，不然容易越想越紧。

“熟悉某某技术栈并有实战经验”。实际上当时只是做过一个很基础的demo，很多细节都是跟着教程走的。面试一细问原理和优化思路就露馅了。后来写简历就收敛很多，不敢用这种绝对化表达了。

一类是 RAG知识库问答，比如自己抓一批资料（论文、笔记、技术文档），做清洗、切分、向量检索，再接LLM生成答案，这个最容易体现工程能力。一类是 简单Agent系统，比如“自动查资料+总结+生成报告”，重点是工具调用和流程编排，而不是模型本身。还有一类是 垂直小应用，比如学习助手、面试辅助、或者某个细分场景工具，关键是要有明确用户问题。

第一是问题背景：比如解决什么业务/学习问题，而不是一句“做了一个模型”。第二是具体方法：用了RAG、embedding、prompt优化还是微调，把你做的步骤讲清楚。第三是结果+你做的贡献：比如延迟下降多少、准确率提升多少，或者系统跑通了哪一段，你具体负责哪块。