这个问题的话基本上也是根据业务场景深挖，然后一些性能场景，如果有问题 怎么根因分析，然后问了一个八股问题，就是full gc和young gc的问题，这个jvm的我都没背多少，然后被问到了，然后我说了一下常见的垃圾回收机制，然后还问了一下怎么sql分页进行查询。这一块儿我也不知道，然后的话问了一下怎么对风控场景进行校验，然后如果说对线上问题的解决，然后定时巡检做了哪些工作，基本上还是一些业务场景的询问，然后八股相对来说少一些，基本上还是问你的简历，然后有一些前端知识的了解什么的，然后还问了一下怎么做一些场景设计，如果说遇到一些消息丢失，消息重复，消息有序性的这些业务场景的校验。然后问我会不会go，这个go确实不会。然后问了一下我的期望薪资，然后我说了一下我的期望，最后我反问，问了一下。电商业务的战略规划以及测试的空缺需求，以及稳定性怎么样，然后他也问了一下我能不能接受广州。最后我还是表达了一下我的意向，还是挺想去的。还问了下装饰器 印象深刻的 有成就感的bug  能接受的工作强度

虽然加班严重 讲求奉献虽然公积金5%虽然很多办公地点都在郊区虽然od招聘负面新闻曝光但西电南邮杭电重邮深大的著名学校里面 能力一般的同学也可以拿华为当做自己的备胎 有了一份保底和希望但就凭这一句遥遥领先 敢为人先 追求卓越 中华有为的宣言成为妇孺皆知 老少咸宜的民族企业加入华为就像是 为国为民 大义凛然的英雄豪杰加入华为就像是 毫不为己 专门利人的道德楷模加入华为就可以 把自己的热血泼洒在祖国最需要的地方加入华为就可以 立鸿鹄志，做奋斗者，为中国梦的实现贡献自己的青春力量和青春智慧总结来看如果能加入华为 这辈子就有了！

一、主从库读写测试步骤1. 环境准备：- 搭建主从架构（1主1从或多从），确保主从复制正常（可通过 SHOW SLAVE STATUS 查看IO和SQL线程状态）。- 主库配置 server-id=1 ，从库配置 server-id=2 ，主库开启二进制日志（ log-bin ）。2. 读写测试核心操作：- 写操作测试：在主库执行增删改（如 INSERT/UPDATE/DELETE ），观察从库数据是否同步（可通过定时查询或触发器验证）。- 读操作测试：在从库执行查询（如 SELECT ），确认数据与主库一致，同时测试从库负载能力（可通过压测工具如 sysbench 模拟并发读）。- 异常场景测试：- 主库宕机：验证从库是否可切换为读写模式（需手动或通过中间件如MHA自动切换）。- 网络延迟：模拟主从网络波动，观察数据同步延迟（ Seconds_Behind_Master 参数）。3. 关键指标记录：- 同步延迟时间、读写性能差异、高并发下的一致性表现。二、主从复制原理1. 核心机制（基于二进制日志）：- 主库（Master）：将数据变更记录到二进制日志（Binlog），包括DDL和DML操作。- 从库（Slave）：通过两个线程实现复制：- IO线程：连接主库，读取Binlog并写入本地中继日志（Relay Log）。- SQL线程：解析中继日志，在从库执行相同操作，实现数据同步。2. 复制模式（3种）：- 异步复制：主库写入Binlog后立即返回，不等待从库确认（性能高，一致性差）。- 半同步复制：主库等待至少一个从库确认接收Binlog后返回（性能和一致性平衡）。- 全同步复制：主库等待所有从库确认后返回（一致性高，性能低）。3. 常见问题与面试考点：- 主从延迟：高并发下从库同步慢，解决方案：升级硬件、读写分离、分库分表。- 数据一致性：异步复制可能丢失数据，可通过半同步或中间件（如Canal）弥补。- 切换与故障恢复：手动切换主从时需锁定主库（ FLUSH TABLES WITH READ LOCK ），避免数据不一致。三、面试场景- 结合场景说优势：主从架构用于读写分离，减轻主库压力，适合读多写少场景（如电商商品页查询）。- 提扩展知识：主从是分布式基础，可延伸到集群架构（如MGR、InnoDB Cluster）或中间件（MyCat、ShardingSphere）。

1. 基本路径表达式node选取当前节点的所有子节点（包括元素、文本、属性等）。bookstore/book//node从任意位置选取节点（全局搜索）。//book.选取当前节点。...选取当前节点的父节点。book/..@attribute选取属性节点（@后接属性名）。book/@category2. 谓语（Predicates）用于筛选节点，用方括号 [] 包裹条件：bookstore/book[1]选取第一个 <book>节点（XPath 索引从 1 开始）。bookstore/book[last()]选取最后一个 <book> 节点。bookstore/book...

懒加载定义：按需加载资源，仅当用户需要时才动态加载，避免一次性加载全部内容。核心场景：图片懒加载：滚动到图片位置时才加载真实图片（如淘宝商品列表）。组件/JS懒加载：SPA路由切换时加载对应页面JS（如React的React.lazy）。数据懒加载：分页加载表格数据（如微博下拉加载更多）。实现方式：传统：通过IntersectionObserver监听元素是否进入视口。现代：HTML原生属性loading="lazy"（Chrome 76+支持）。优点：提升首屏加载速度（减少初始资源请求）。节省用户流量（仅加载可见内容）。降低服务器压力。缺点：实现不当可能导致图片“闪现”（...

一、前端Bug定位：从控制台到代码调试场景1：页面白屏/渲染异常控制台查错：按F12打开Chrome DevTools，查看“Console”面板JS报错（如Uncaught TypeError）。例子：报错“Cannot read properties of null (reading 'appendChild')”，定位到JS中操作空DOM元素，如图片未加载时提前操作img节点。网络抓包：切到“Network”面板，刷新页面查看资源加载状态： 若CSS/JS报404，检查CDN路径是否正确（如版本号写错v=1.0写成v=10）；若图片加载慢，查看Size列（如未压缩的原图导致加载超时）。断...

今天面试官问我的 没回答上来 总结一下前端性能测试核心知识点与实操详解一、用户感知与性能维度拆解1. 用户核心关注点是否正在发生：输入URL后服务器响应速度（如输入网址后浏览器是否立即显示加载动画）。是否有用：首屏核心内容是否快速呈现（如电商首页的轮播图、商品列表）。示例测试：打开淘宝首页，用秒表计时从点击链接到首屏商品卡片出现的时间，对比不同网络环境（4G/WiFi）的差异。2. 性能测试维度感知加速度（FCP/LCP）：衡量页面渲染速度；加载响应度（FID/TTI）：衡量交互准备时间；视觉稳定性（CLS）：衡量布局偏移程度。二、核心性能指标与测试实操1. FCP（首次内容绘制）定义：浏览器...

这个主要还是围绕在一些自动化测试，然后一些项目的风险管理的一些考察定位bug，然后反正就是那一堆的常规的业务场景题还是挺简单的，然后怎么写的UI自动化，怎么写的性能测试之类的，然后没啥特别难的八股问题，问了一个if else和switch的区别，这一块儿确实是太简单了。然后最后问了一下他那个是做啥的，是做一个跨境电商的建站的，涉及前端的比较多，接口层面的相对来说比较少一些，那就基本上是客户端测试，就不是服务端测试，然后测试中心有100多个人，然后涉及到一些交易呀，商品呐，大数据呀之类的相关的组。然后我问了一下会不会有一些专项？他说还是有很多专项的，你进来可能也跑不了的，然后一些AI测试啊什么的，自动化测试也有不少的相关的一些专项工作。然后我最后说如果觉得我还行的话，麻烦尽快推进吧，再不推进我就入职别的公司了。我对这家公司还是挺心仪的。

一、RAG（检索增强生成）基础与优化方向RAG是一种结合检索与语言模型生成的技术，核心流程包括：数据收集：将数据分块、生成向量嵌入并存储到数据库；推理过程：根据用户查询检索相关文档，结合提示生成回答。文章提出RAG优化的4个关键方向：分块方法、嵌入模型、向量搜索策略、提示工程，并通过实验验证效果。二、4种优化策略及实验验证分块方法优化目标：平衡块大小，避免过小（丢失上下文）或过大（检索冗余）。实验：尝试“父文档检索器”，同时检索相关片段及其父文档以保留上下文，但结果显示性能下降（如上下文召回率降低），需进一步调整分块逻辑。嵌入模型选择对比：DPR（密集 Passage 检索模型）和Senten...

一切的路都不会白走我既然面试了这么多场 就算是fw也能百炼成钢了现在我最大的缺点就是缺乏工作经验走社招运动人体科学的非科班专业走校招 加上积累了一些拉胯的面评导致大厂极其容易失败 面试官直接带着有色眼镜用我刷KPI了在工作岗位上沉淀两年 相信定能逆转结局到时候我的学历缺陷变成我的优势希望每一步都不会白走一切选择都是我选的 到现在也是咎由自取什么输赢 到最后还是比寿命的长短后边能在下了班 休息的时候多爽一爽上班的时候少摸会鱼 多跟领导同事交流把工作以内的事情安稳做好吧 毕竟我的起点不是外包  那么就还有向死而生的机会

我已经竭尽全力了 但还是没有offer快到预定的入职时间了真的感觉要失败了也有很多 和我一起开始求职的同学 他们早就拿下了大厂不再使用牛客 不再继续战斗了希望快变成失望 梦想快要变成幻想我的未来要何去何从看看接下来这个周的进展 如果不行 就认命了如果有进展 那就再拖一下入职时间 7月初入职再战斗两个周 下个周学校就要劝退了真的是拼尽全力了  只能说是 悠悠苍天 何薄于我这辈子还很长  还有大概10几年的工作时间期待老天能放我一马  让我赢一次吧任何私信我 问我经验的 求安慰的同学你们先找别人吧 比如小浪coding之类的 我这种fw现如今真没心情回复你们

一、性能测试：前置物料与线上环境一致性保障方案1. 核心挑战场景数据一致性难题：测试环境数据量（如商品SKU数、用户行为日志）仅为线上1/100，导致缓存命中率、数据库索引效率差异显著。网络环境模拟缺失：测试环境通常部署在同一机房，未模拟用户端弱网（2G/3G）、跨地域链路（如电信/联通骨干网延迟）。中间件配置差异：测试环境Redis分片数、MQ队列消费线程数等参数未按线上压测预案配置，导致瓶颈提前出现。2. 多层级一致性保障方案数据层全量数据同步耗时耗资源分层数据构造+流量录制回放1. 核心业务数据（如TOP10%商品）通过OGG实时同步<br>2. 非核心数据用造数工具生成相似...

一、业务背景与技术痛点1. 业务特性多域协同：覆盖C端（猫超交易、直播导购）与B端（供应链、物流履约）等20+技术团队，业务链路深度达10+系统节点。工具碎片化：各业务域独立建设工具平台，累计超500+工具，存在“工具烟囱”现象（如交易域造单工具、供应链对账工具）。2. 技术痛点解析工具调用门槛高：人工需记忆工具协议（HSF/HTTP）、参数格式，调用失败率超30%。数据构造低效：测试数据需跨ODPS（阿里大数据处理平台）、ADB（分析型数据库）多源查询，单次数据构造耗时4小时+。异常诊断复杂：全链路调用链日均50亿+日志，人工排查需逐节点回溯，平均耗时8小时/次。二、AI智能体核心技术架构与...

也基本上就是对我一些实习需求的问题拷打，然后对性能测试和UI的自动化测试，然后接口自动化测试进行了一些询问，遇到的比较困难的问题，就是有没有跟开发一块儿对接解决问题，然后就是你在性能测试的时候，怎么保证，你准备的这些前置的物料跟线上的环境是高度模拟保持一致的，这块儿我确实不知道，然后还有的就是你的UI自动化的这个场景下遇到过什么样的问题，然后怎么解决相关的问题。基本上还是对一个实习经历的相关的问答这样，然后最后我反问了一下会不会涉及到一些AI赋能测试的这个相关的东西，然后他说如果说投入产出比还可以的话，是不会禁止你去做这个的。然后平时如果说运用的一些接口自动化的维护主要用的是JAVA，然后UI自动化的维护主要用的是Python。主要的业务是用户社区这个bu，涉及到帖子发布，然后还有就是搜索推荐和广告，分为设置端和前端，感觉这个业务确实还是比较核心的，比较好的，然后最后我也做了一些自我推荐，表达了我的意愿，希望能够进行一些推进，感觉这家也挺不错的，算是一个电商行业的中等的公司，加班强度听说也不是那么大，所以说还是挺想去的，再加上有杭州也挺好的，人才补贴也比较多，希望能给个机会吧，大厂现在是不指望了。