First, relax and treat the interview as a consultation where I aim to learn, understand, or delve deeper into a certain field. The interviewer is usually a department head or key person in charge, with broader and deeper expertise in the professional area than I (and of course, a higher salary). This is a great opportunity to recognize your shortcomings and fill in the gaps. Well, the word “interview” fits perfectly—it’s like saying, “瞅你咋啦” “瞅你咋地”.
So I record some Q&As to modify my story.
LSTM搭建情感分析模型
评估指标
二分类：准确率、F1-score、AUC-ROC
预处理
- 文本清洗（去除HTML、特殊字符）
- 分词
- 构建词汇表（限制大小，如20000词）
- 序列化（词→索引）
- 填充/截断至固定长度
架构
输入 → 嵌入层 → LSTM层 → Dropout → 全连接层 → 输出
- 输入层: 清洗数据, 固定序列长度, 多则截断, 少则填充
- 嵌入层: 使用预训练词嵌入（Word2Vec）, 这里使用了知乎的一个预训练权重
- LSTM层:
- Dropout层: 提高泛化性能
- 全连接层: 对其输出
- 输出: sigmoid二分类
超参数
- 序列长度：50-200个词（覆盖大多数评论）
- 批次大小：32-64
- 学习率：0.001（Adam优化器）
- 训练轮次：10-20（早停防止过拟合）
- 正则化：L2正则化 + Dropout
Q&A
- 数据怎么清洗: HTML标签, 特殊字符, 停用词, 分词
- padding 怎么处理？pad到max_len, mask避免参与到loss
- 用随机初始化 embedding 还是预训练? 用了预训练的, 提高收敛速度与泛化性能
- 类别不平衡: 重采样
- learning rate? 1e-3开始, 通常可以根据epoch设置milestone, 逐渐降低
合同识别中的印章识别与手写识别
项目架构
- OCR 层（图像 → 文本 + 坐标）
- 结构化解析层（段落 / 表格 / 条款识别）
- LLM 风险识别层（语义分析）
- RAG 法规增强层（知识校验）
架构
pdf 输入 →
最成功的一件事
你推动事情落地、解决复杂问题、带来明确价值
我觉得我目前比较成功的一件事，不一定是某一个单点模型效果，而是我能把偏分散、偏经验化的数据分析或预测工作，逐步整理成更结构化、可复用的流程。
比如在之前的工作里，很多需求一开始都是临时分析、口径不统一、结果依赖个人经验。我做的一件比较有成就感的事，是把这类工作慢慢沉淀成相对标准化的处理流程，包括数据清洗、特征整理、结果校验，以及必要的可视化和复盘。
这样做之后，一方面提高了交付效率，另一方面也让结果更稳定、可解释，业务方沟通成本更低。
我觉得这件事对我来说比较有代表性，因为它体现的不是一次性的“做出来”，而是把事情做得更可持续、更容易协作。
最失败的一件事
失败不致命，但你确实学到了东西
我印象比较深的一次“失败”，其实是我早期做项目时，有一段时间会更关注技术方案本身，想把方案设计得更完整、更理想化一些。
但后来我发现，实际业务环境下，很多时候最重要的不是“理论上最优”，而是能不能在当前数据条件、时间要求和业务约束下，先交付一个稳定可用的版本。
有一次我就在方案上花了比较多时间，虽然最后结果不算差，但推进节奏偏慢，也让我意识到自己当时在优先级判断上还不够成熟。
后来我就比较注意先明确目标、时间边界和验收标准，再决定做到什么程度。这个调整对我后续工作帮助挺大。
避免:
- 和领导闹翻
- 把项目搞砸
- 拖垮团队
- 因为情绪影响工作
- 技术太差导致重大事故
突出:
- 失败点温和
- 很像成长中的技术人
- 不会显得人品有问题
- 顺手体现成熟度提升
三个优点
- 结构化分析能力比较强
- 能兼顾技术和业务落地
- 学习和迭代能力比较强
三个缺点
- 有时会对细节投入过多
- 对不合理的事情会想弄明白
- 早期更偏独立完成，现在在加强协同
避免:
- 我抗压差
- 我不爱沟通
- 我不稳定
- 我容易和领导冲突
- 我执行力差
- 我经常拖延
什么情况下会离开公司
我还是希望在一个合适的平台长期稳定发展，不会因为短期情绪或者一时的不顺就轻易离开。
但如果出现一些比较根本性的问题，比如:
- 方向: 公司的发展方向和我的职业方向长期不匹配，或者岗位内容和最初沟通差异很大，长期无法发挥价值
- 团队: 团队协作方式、管理方式存在持续性问题，而且经过沟通也很难改善，那我可能会认真考虑是否还适合继续合作。
对我来说，离开通常不会是冲动决定，而是对双方是否还匹配的理性判断。
玻璃球强度测试
Question:
有 2 颗玻璃球，一栋 100 层楼。
存在某一层 ，满足：
- 从 高于 的楼层扔下，球会碎
- 从 不高于 的楼层扔下，球不会碎
要求设计策略，在 最坏情况下，用尽量少的次数找出这个临界层 。
Solution:
因为只有两颗球，所以不能直接二分。
如果第一颗球碎了，第二颗球只能线性试，因此关键是平衡“第一颗球试探次数”和“碎了之后剩余线性搜索次数”。
设第一次扔在第 层，之后依次减少步长：
第一次加 ，第二次加 ，第三次加 ……
这样无论在哪一步碎，最坏总次数都相同。
需要满足
即
解得最小 .
所以最优策略是从 14 楼开始，然后 27、39、50……逐步测试，最坏情况下 14 次能确定临界楼层。
面试岗位: 机器学习算法
时间序列预测
已经经历2轮面试
在面试过程中, 我没写在简历中, 但是在交流中提到了 AI 落地的应用, 反而是面试官都比较感兴趣的内容.
比如 Copilot: 类似于chatbot, 和产品结合更深, 问题在于, 做这个东西有多大的价值, 能做的多深入 在技术实现上, 我采用了 web page → java → python adapter → Dify/KB →LLM → return 的链路, 问题在于 Dify 内的workflow 比较不灵活, 优点是 监控/审计 都比较清晰
比如 Agent: 现在比较火, 怎么设计 agents, skills, 怎么给用户使用, 能力空间会更大一点, 更加灵活 对于内部工具, 有自动化/备份流程就ok. 对于外部应用的话, 几乎都会进行写权限的约束, 只读的能力不一定足够. 具体可以参看Building KnowledgeBase with Opencode
自我介绍的更新
除了常规的自我介绍, 还应该包含
Why match this job and this company Why me
如何解决特征的多重共线性
PCA 对树模型未必是默认好选择:
- 降低解释性
- PCA 无监督 方差大 ≠ 有效
- 树模型擅长原始模型切分