- 日期：2026-06
- 企业与岗位：Netomi｜SDET四轮面试
- 适用层级：SDET／自动化测试与编程
本篇为社区对用户分享面经的整理汇编，旨在帮助求职者了解面试考察方向。问题部分力求忠实还原原帖问答脉络；「参考答案 / 复盘思路」为整理方结合工程实践原创补充，仅供交流参考，不代表官方标准答案。
面试问题与参考答案
1. 考核方向：四轮技术面与HR：编码能力（考核方向）
参考答案 / 复盘思路
准备可运行的字符串、数组、集合和异步控制练习，回答时说明输入约束、时间与空间复杂度。SDET不仅要解出算法，还要能给自己的函数补边界测试，例如空值、重复值、极端大小和非法输入。原记录只说明考查编码能力，没有公开具体算法题名。
若遇到一道题只给了模糊输入，可先问是否允许空值、是否需要稳定排序、规模上限是多少，再选择算法。面试官往往通过这些澄清判断候选人是否具备工程意识。
2. 考核方向：脚本编写能力（考核方向）
参考答案 / 复盘思路
脚本应包含清晰的输入输出、异常处理、超时与重试上限，并且能在CI里非交互执行。对于接口巡检，可把鉴权、请求、断言、日志和报告分开，避免把凭证硬编码。面试时讲明如何让脚本在网络波动和依赖服务失败时给出可定位的结果。
例如脚本需要每30秒查询任务状态，应支持取消信号、请求超时、日志脱敏与最终退出码。不能把失败吞掉后输出“成功”，否则CI无法正确识别异常。
3. 考核方向：轮询机制（原记录披露的考核点）
参考答案 / 复盘思路
轮询要先明确终止条件、间隔、总超时和失败策略。固定间隔简单，但大量客户端容易形成同步冲击；指数退避加抖动适合降低重试风暴。若业务支持事件推送，可比较WebSocket或消息通知与轮询的成本。测试覆盖任务完成、永不完成、间歇性500、重复结果和取消请求，断言最终状态而非只看次数。
实际实现时可用截止时间而不是固定重试次数控制总预算：每轮先检查是否超时，再发起请求。若服务返回Retry-After，应优先遵循服务端节流建议，并在日志中保留尝试次数。
4. 考核方向：场景分析与代码时间复杂度（考核方向）
参考答案 / 复盘思路
场景题先澄清业务目标、约束和失败模式，再列出正常、边界、并发、权限与恢复路径。对代码复杂度要区分最坏与均摊成本，解释嵌套循环、哈希表冲突和排序成本。原记录没有公开具体场景或代码，不能补写成“面试官要求设计某个业务系统”的原题。
例如O(n²)嵌套扫描是否能用哈希索引改成均摊O(n)，需要结合数据规模与内存限制讨论。若输入会持续流入，还要解释批处理算法与流式算法的不同。
延伸思考（社区补充）
任务状态轮询遇到HTTP 429和间歇性503时，如何设计退避策略与可复现的自动化测试？
