你项目中用到了哪些设计模式

在线程池的创建，Zookeeper客户端的创建使用到的单例模式，避免重复创建

创建序列化器，编解码器用到了工厂模式，根据用户配置创建不同的序列化方式

在实现不同序列化方式的时候用到了策略模式，把不同序列化方式封装成一个策略，实现统一接口

小程序项目中使用注解+AOP实现权限控制，本质是基于代理方法在方法调用前做拦截，用到了代理模式

在RPC框架中注册中心监听节点变化用到了观察者模式

Spring中用到了哪些设计模式

Bean的创建是单例的，用到了单例模式

Bean的管理使用的BeanFactory，用到了工厂模式

Bean的注入用到了原型模式，每次注入新实例

通用逻辑的封装，比如JdbcTemplate，用到了模板方法模式

Spring事件监听机制用到了观察者模式

SpringMVC的拦截器、过滤器链用到了责任链模式

Bean的生命周期管理用到了状态模式

AOP用到了代理模式

SpringMVC的HandlerAdapter适配不同Controller用到了适配器模式

ES的基本原理

ES中比较关键的概念有索引，相当于MySQL的表，文档，相当于表中的行，字段，相当于表中的列。然后还可以组成集群和分片。

ES内部的索引使用的倒排索引，原理就是把每个文档的内容进行分词，建立词对应文档ID列表的映射

当有新的文档写入时，ES首先会通过分词器做文本分析，建立倒排索引，再把数据写到主分片上，由主分片同步到副分片，写入不是立即可见的，默认一秒钟刷新一次

Nacos如何避免读写冲突

Nacos主要通过两种机制来避免配置读写冲突。一是写时使用乐观锁机制，客户端提交配置时必须带上当前版本号，如果版本不一致则更新失败，避免写写冲突。二是通过Raft协议实现集群间的数据强一致，所有写请求必须通过Leader，读请求默认从本地读取，如果需要强一致也可以强制读Leader。Nacos客户端使用长轮询机制感知配置变更，确保读时的数据是最新的。

为什么Kryo序列化方式的体积小

Kryo直接将对象编码为二进制字节数组，没有像JSON那样的字符冗余，并且Kryo不使用Java的反射机制，而是提前注册类信息，序列化时不需要写类的全限定名，它还支持对象引用追踪，避免重复序列化同一个对象

zk的一致性算法

Zookeeper使用Zab协议来实现集群一致性。有领导选举和原子广播两个阶段。当集群初次启动或者Leader节点宕机时会进入领导选举阶段，主要是通过投票和对比事务ID来选择，原子广播阶段，所有写请求由Leader发起并生成事务，广播给所有的Follower，需被超过半数的Follower写入后才能提交，Leader再广播提交消息，确保所有节点以相同顺序应用事务，从而实现强一致性。

JVM调优

我在参与商城项目的时候有过JVM调优的经历，当时压测的时候频繁出现Full GC，我通过jstat分析内存使用情况，使用-Xms和-Xmx调整了堆的大小，用-Xmn扩大了新生代的大小，后面我还有使用jstack查看线程状态，检查是否有死锁的情况

单机MySQL如果不做任何优化，最大可以承受多大并发

MySQL默认的最大连接数是151，也就是最多151个线程同时连接执行SQL，如果只是执行简单的查询，单机QPS大概5000左右，如果是频繁写入的话，TPS可能在1000上下

如何发现和优化慢SQL

开启数据库慢查询日志，使用mysqldumpslow汇总慢sql，发现慢sql语句之后，使用explain分析这条语句，主要关注是否用了全表扫描，keys是否走了索引，rows是否过大，然后针对常用的字段，使用最左前缀原则建立索引，同时也要避免select *查询，数据量大时，可以用LIMIT限制查询数量，使用分页时避免大偏移量分页，避免慢sql的话可以针对大数据量的表使用分库分表，也可以结合缓存，分担数据库压力

Mysql的行锁什么时候会升级成表锁

  1. 没有用到索引，或者索引失效

InnoDB的行锁是基于索引实现的，如果执行语句没有走索引（全表扫描），那只能锁整张表

  1. 范围查询导致锁范围过大

当范围条件太宽，几乎要扫描大部分数据时，InnoDB可能会退化成表锁，减少锁的管理开销

  1. 事务未提交，锁竞争严重

长事务占用大量行锁时，可能导致其他事务阻塞，MySQL为了保证一致性，有可能会升级成表锁来避免锁资源耗尽

RocketMQ和RabbitMQ的异同点，使用场景

RabbitMQ基于AMQP协议实现，消息存储在Broker上，采用push模式，消息主动推送给消费者，可靠性一般通过确认机制保证，部署简单，适合中小型系统

RocketMQ采用的分布式架构，消息存储在Broker集群，消息被分为多个Topic和Partition，不同分区可并行处理，支持顺序消息、分布式事务等特性，采用pull模式，消费者主动拉取消息，适合用于大规模、高吞吐量场景

Unity中C#的生命周期

C#脚本的生命周期主要围绕MonoBehaviour类展开，首先是初始化阶段，可以使用Awake（最早被调用，仅执行一次），Start（在第一次 Update 前调用，仅执行一次）进行初始化，然后是运行阶段，使用update、fixedupdate，然后是渲染阶段，OnPreRender，OnRenderObject，OnPostRender，最后是销毁阶段，OnDisable

Unity为什么需要协程

  • 实现延时执行而不阻塞主线程：Unity是单线程的，而协程允许先等待一段时间后再执行后续代码
  • 逐帧执行复杂操作，防止掉帧：当某个任务太重时（如大量计算、加载资源等），协程可以把任务分成多帧执行

SpringBoot相比于Spring有哪些优点

  • Spring需要XML或Java配置类进行配置，SpringBoot提供了自动化配置，大部分默认配置就能满足开发需求
  • SpringBoot内置了Tomcat容器，项目可以直接打包成jar运行，不需要部署到外部服务器
  • SpringBoot提供了多种starter依赖（如 spring-boot-starter-web、starter-data-jpa），解决了版本兼容与依赖整合的问题
  • SpringBoot提供了对主流中间件的默认整合，如Redis、RabbitMQ、MyBatis、Elasticsearch等，通过yml文件即可完成连接配置，无需手动创建Bean

SpringBoot项目中的分层架构，以及会用到的注解

  • Controller层（处理请求，参数解析，返回响应）：@RestController、@Controller、@RequestMapping、@GetMapping、@ResponseBody、@RequestBody
  • Service 层（处理具体业务逻辑）：@Service、@Transactional
  • DAO层（与数据库交互）：@Mapper

Linux相关

  • 如何在Linux系统中查询所有运行的java项目：ps -ef | grep java
  • linux中查找文件：find -name “filename”
  • linux中查看端口号占用情况：netstat或ss -tunlp | grep 端口号
  • linux查看进程占用了哪个端口：lsof -p -i

性能测试的指标

  • 响应类，比如响应时间、延迟、TPS、帧时间
  • 资源占用类，比如CPU、内存、带宽和磁盘I/O
  • 稳定性和并发类，比如并发用户数、崩溃率、卡顿率、内存泄漏等

实际测试中结合场景，比如副本战斗关注FPS与卡顿率，主界面关注内存占用和帧时间，PVP联网则重点看延迟和同步情况，服务器端则关注并发连接、TPS和崩溃率等。

如何发现性能测试的瓶颈

首先要明确测试的目标和场景，是为了找到响应慢的接口还是检查资源使用过高，可以重点关注CPU使用率、负载、内存的占用率、网络的吞吐量和延迟、磁盘的IO次数和数据库的查询耗时、连接数等，如果是接口响应慢可能是有慢SQL、或者出现远程的资源调用与加载比较慢，如果是高并发时崩溃，可能是数据库连接池出了问题，内存溢出，如果是频繁丢帧和卡顿，可能是机器配置不足或者优化没到位等等

游戏中哪些地方需要性能测试

开放世界的流式加载，就是从一个地方跑到另一个地方不会产生卡顿和割裂感，玩家快速切换视角和缩放场景的时候的流畅度

城市场景和高密度对象共存的场景，对于NPC密集的地方，统计一下帧率和抖动的情况

战斗场景，对于放技能时特效的加载和多种角色技能共存时对于帧率和电脑或者手机负载的影响

资源的加载和切换，当使用传送功能的时候，资源加载的效率

长时间运行的稳定性，就是模拟多个小时不间断游戏，看看与刚进入游戏时对比，帧率和负载是否有比较大的变化

异常网络环境测试，对于弱网环境也可以测试一下

Caffeine和Guava Cache的区别

  • Guava和Caffeine底层都使用的ConcurrentHashMap来实现缓存
  • Guava在内存淘汰上用的LRU，支持基于时间和数据大小的回收策略，Caffeine使用的TinyLFU，与LRU相比锁竞争更少，命中率更高
  • 在数据过期刷新上，Guava使用的阻塞式刷新方法，Caffeine是异步刷新

用户端程序崩溃，如何复现

从用户或日志中获取尽可能完整的上下文信息，比如崩溃发生的设备型号、操作系统、内存情况，是否有崩溃弹窗/错误码/闪退提示，崩溃前执行了哪些操作，点击了哪个功能和崩溃时的网络状态（在线/离线/弱网），然后查看日志文件，搜集信息。然后在调试环境下，执行与用户相同的操作流程

黑盒测试、白盒测试、灰盒测试

黑盒测试是不关注代码逻辑，只关注功能是否符合需求，从用户的视角测试系统的输入输出。主要测试软件或者游戏的一些功能是否符合规格，边界值处理是否正确，系统响应是否正确等等，常见的方法有等价类划分、边界值分析、错误推测法、场景法等

白盒测试是从开发者视角出发，测试代码的各个逻辑分支，条件和循环结构。常见的方法有语句覆盖、分支覆盖、条件覆盖、循环覆盖等

现在一般两者融合使用，就是部分了解系统内部逻辑，同时也关注一些功能表现，叫灰盒测试，主要测试一些业务流程是否合理，模块之间的接口是否生效，安全验证是否生效等

JMeter的断言方式

最常用的是响应断言，用于检查响应的数据中是否包含某些字符串或者关键词，可以校验文本、状态码、响应头、响应数据等

JSON断言，校验JSON格式相应的数据结构或字段值

HTML断言，检查返回的HTML页面是否符合规范

大小断言和持续时间断言，判断响应的数据长度或者相应的时间是否符合预期

如何做分布式压测

单机压测并发有限，所以分布式压测一般采用Master/Worker模式

Master负责分发压测脚本和任务，Worker负责实际发压，执行请求并收集结果，最后由Master聚合并生成报告

常见方案有JMeter分布式或Locust，也可以自己搭建调度平台，统一脚本和结果展示

xxl-job的架构和实现原理

xxl是一个分布式任务调度平台，主要分为调度中心和执行器，调度中心负责管理任务、选择调度策略、分发调度指令，支持任务配置和日志查询。执行器部署在业务中，接收调度中心下发的任务执行请求，并将执行结果回调给调度中心。两者通过Http通信

执行器启动时，会向调度中心进行注册，然后调度中心内部使用Quartz作为底层调度器，根据任务配置的CRON表达式触发调度，通过HTTP向执行器的任务API发送执行请求，执行器收到请求后，根据任务Handler名称找到对应的方法执行，执行器会将结果和执行日志推送到调度中心，在调度中心进行统一的任务监控

xxl-job怎么保证每一个实例任务只调用一次

调度中心自身可以做集群部署来提高可用性和任务执行效率，调度中心之间会通过数据库xxl_job_lock表的行锁机制保证，在同一时刻，一个任务只有一个调度中心节点会触发调度

如果需要任务多实例执行，可以用分片广播模式

如果某个接口的响应时长变长，不符合预期，有什么优化思路

首先看一下接口层面的优化，是否是代码逻辑上有问题，有没有用到缓存，然后长耗时的任务可以放到消息队列或者异步执行。然后是服务层面的优化，看一下线程池有没有什么问题，锁的竞争，有没有造成死锁或者线程饥饿，IO优化，用多路复用。然后是数据库层面的优化，查询慢SQL，减少Join，添加索引，分库分表、读写分离和冷热数据分离。再是外部依赖优化，网络是否通常，请求第三方接口会不会遇到连接超时，降级和熔断策略的配置。最后是系统层面的优化，JVM调优或者Nginx负载均衡

假如别人调你的接口，说接口超时了，但是排查发现接口没有问题，问题出在哪（客户端显示超时，但是服务端不超时)

可能是客户端和服务端的超时配置不一致，可能客户端超时时间设置的过短。然后可能是网络问题，网络抖动、丢包、带宽不足，导致服务端返回的响应未能及时到达客户端，还可能是TCP层和HTTP的问题，TCP连接断开、HTTP长连接复用，某些请求排队太久

Docker容器编排的作用

容器编排的作用主要是为了解决大规模容器应用的管理问题，现在应用普遍都会在分布式环境下部署成几十上百个容器，人工管理比较困难。容器编排主要可以：

  • 管理容器的生命周期，自动创建、启动、停止、销毁容器，保证服务按照预期的副本数运行
  • 多个容器实例运行时，自动注册和发现服务，提供内置的负载均衡，让流量在多个容器间均衡分配
  • 提供对容器运行状态、性能指标的监控，集中化收集和管理容器日志

核心作用就是“让成百上千的容器能够自动化、高可用、可扩展地运行”，常见的编排工具是Kubernetes

K8S的架构

本质上是一个主从架构，由控制平面和工作节点组成

控制平面负责整个集群的调度、管理和控制，主要包括：

  • API Server：所有组件交互的唯一入口，接收 kubectl 命令、外部系统请求
  • etcd：分布式键值存储系统，存储整个集群的状态
  • Controller Manager：运行各种控制器，保证集群的目标状态和实际状态一致
  • Scheduler：负责 Pod 调度，即决定 Pod 应该运行在哪个 Node 上

工作节点是Pod的运行载体，相当于集群里的工人：

  • kubelet：负责与 API Server 通信，监控 Pod 的运行状态
  • kube-proxy：负责实现 Kubernetes Service 的流量转发与负载均衡

Docker网络模型

  • bridge模式（默认）：每个容器分配一个独立的网络空间，Docker在宿主机上创建一个虚拟网桥（默认docker0）。启动容器时，会创建一对虚拟网卡，一端放到容器内作为eth0，另一端放到宿主机并挂在 docker0 上。容器之间通过 docker0 进行二层通信，出外网走宿主机 NAT
  • host模式：容器和宿主机共享网络空间，容器直接使用宿主机的网卡和端口，没有虚拟网桥，没有NAT，容易造成端口冲突
  • none 模式：容器只创建网络空间，但不做任何网络配置，需要自己手动配置

Docker容器虚拟网卡（veth pair）收发包过程

以bridge模式为例：容器内有一端虚拟网卡作为eth0，另一端在宿主机上挂在docker0。容器发包时，数据经过 veth → docker0 → 宿主机路由/NAT → 物理网卡；外部访问容器则反过来，先到宿主机物理网卡 → DNAT → 容器 veth → 容器应用

Nacos注册中心的架构

  • 在服务实例启动时，会把自己的信息注册到Nacos，客户端通过服务名拉取可用实例，实现服务发现
  • 数据模型是基于服务命名空间、分组、集群的扁平化结构

  • Nacos支持主动心跳（客户端定期上报）和被动检测（Server发起TCP/HTTP检测）

  • 如果实例不可用，Nacos会自动剔除，保证服务列表的实时性

  • Nacos同时支持AP模式（默认，基于Distro协议，保证可用性和扩展性）和CP模式（基于Raft协议，保证一致性）

  • 多台Nacos节点可以组成集群，通过MySQL存储元数据，保证数据持久化

java线程栈跟内核栈的对应关系

每个Java线程是1:1映射到内核线程的，因此它既有JVM分配的Java栈（用户态，用来执行 Java 方法调用），也有操作系统分配的内核栈（内核态，用来处理系统调用和中断）

两者是独立的：执行普通Java代码用Java栈；执行系统调用时切换到内核栈

Java栈大小可通过-Xss设置，内核栈大小固定（Linux下通常 8KB/16KB）

怎么编写GC友好的代码

  • 减少临时对象创建
  • 避免大对象频繁分配
  • 对频繁使用的对象进行缓存和复用
  • 合理使用弱引用、软引用
  • 避免内存泄露

GC调优思路：先监控 → 分析 GC 日志 → 定位根因（配置/代码） → 调整 JVM 参数 + 代码优化

分布式锁如何实现可重入

普通的分布式锁是不可重入的：同一个线程/进程拿到锁后，如果再次申请，会直接失败。而可重入锁要求：如果同一个客户端已经持有锁，再次申请时应该能直接成功并且计数+1，直到释放次数等于加锁次数才真正释放。可以在锁的value里保存持有者ID和重入次数。加锁时如果key不存在就创建 {ownerId, count=1}；如果key已存在并且ownerId相同，则说明是重入，把count+1并刷新TTL；释放时只有持有者能操作，count减一，直到为0才真正删除锁。实现上必须用Lua保证检查和更新的原子性，TTL需要续租机制避免锁提前过期

线程池中核心线程数和非核心线程数一般如何配置，为什么

核心线程：

  • CPU密集型任务：比如加解密、图像渲染、排序等
    • 核心线程数 = CPU核心数
    • 原因：一个线程对应一个核心跑满效率最高，多了会导致上下文切换
  • IO密集型任务：比如数据库查询、RPC调用、文件读写
    • 核心线程数 = CPU 核心数 * 2 ~ 3
    • 原因：线程很多时候在等待IO，可以用更多线程填补空闲，提升整体吞吐

非核心线程：

  • 短时流量波峰场景:
    • 非核心线程数要留扩容空间，避免请求被丢弃
    • 一般设置为core的1~2倍
  • 高并发+长队列场景:
    • 如果队列够大，可以适当降低非核心线程数，避免线程数暴涨导致上下文切换

讲讲大模型中知识蒸馏是怎么做的

因为大模型的参数量非常大，推理开销很高，部署比较麻烦，所以要通过知识蒸馏，利用大模型作为教师，把知识迁移到小模型。

比较常用的方法有Soft Target蒸馏，通过温度Softmax平滑，小模型学概率分布而不是单一标签

Feature-based蒸馏，不仅蒸馏输出，还让小模型网络对齐教师的中间层特征

Response-based蒸馏，不止学分类概率，还学隐藏向量、排序得分等任务相关输出

自蒸馏，让大模型自己指导自己

整体介绍一下你对于Agent、Workflow、RAG、MCP、A2A的理解

  • Agent:一个能自主决策并执行任务的大模型实例，它结合了LLM的推理能力和工具调用能力

  • Workflow:任务编排的方式，把复杂目标拆解成多个步骤，形成有序的执行流程，Agent可以被放在Workflow的节点里，负责某个子任务，Workflow强调流程控制和可复现，Agent强调自主性

  • RAG：检索增强生成。LLM在生成前先去外部知识库检索相关信息，再把结果拼接到Prompt中作为上下文，LLM训练数据会过时，RAG能引入最新的外部知识

  • MCP：一种协议，帮助大模型在复杂系统中统一访问上下文、工具和数据源

  • A2A：Agent-to-Agent，让不同Agent负责不同能力，它们之间通过消息传递或协同协议沟通

讲一下RAG的流程

接收用户请求，通过向量数据库或者传统索引，把用户问题转化为向量表示，与知识库中的文档向量进行相似度匹配，取Top-K的相关文档作为候选知识，然后将相关文档与问题一起拼接到Prompt中，最后大模型基于增强后的上下文生成回答，它的优势在于降低幻觉、快速更新知识

大模型应用中prompt包含什么

prompt是模型理解任务的入口，主要包括：

  • 上下文信息：给模型提供必要的背景知识，让模型理解任务环境，输入的文本，与任务相关的文档，角色设定
  • 指令：明确告诉模型要完成的任务或目标
  • 约束条件：规定输出的格式、长度、风格等限制

你在之前的项目里做过哪些测试相关的工作

在Unity中做过场景状态保存和回放，我觉得就是一种测试的思路，可以复现问题

还做过性能优化，使用Unity的LOD调整不同距离的建模精细度，多智能体训练时，按照职能分组训练，避免同时渲染多个摄像头管线

如果让你开发一个性能测试平台，你会怎么设计

采集层：客户端采集帧率、CPU、内存；服务端采集 QPS、RT、错误率

传输层：上报到日志/监控系统（Kafka、MQ、ES）

存储层：集中存储在数据库（MySQL/InfluxDB/ES）

展示层：可视化（Grafana、前端大屏）

告警层：超过阈值自动告警（钉钉/飞书机器人）

客户端卡顿，怎么排查

首先复现问题，确定是单机问题还是所有人都有问题

然后分层：

渲染性能：材质、批处理

逻辑性能：Update/FixedUpdate 开销

内存：GC频繁触发

网络：延迟、丢包

如果现在要让你开发一个自动化测试工具，你会考虑哪些功能

  • 脚本驱动自动化（模拟玩家行为）
  • 数据采集（帧率、CPU、网络延迟）
  • 兼容性测试（不同设备/分辨率）
  • 压测工具（模拟并发）
  • 报告生成（错误日志、性能趋势）

把你做的性能优化思路，怎么迁移到一个游戏性能测试平台

  • 游戏测试时应该会生成很多日志（帧率、内存、GC、网络延迟）。可以借鉴分页+索引优化思路，用MongoDB存储性能指标，支持快速检索与分析
  • 测试平台经常重复查询某些数据（历史测试结果、性能曲线），可以在平台层引入多级缓存方案（内存缓存 + Redis），减少后端数据库的压力
  • 性能测试通常涉及批量脚本执行（跑不同地图/角色/场景），可以用消息队列解耦测试发起和执行，提升吞吐
  • 测试过程中产生的性能日志/崩溃日志，用消息队列异步写入存储，避免阻塞游戏运行
  • 在无人艇项目里，我用过摄像机/渲染优化来减轻GPU压力，类似的方式也能迁移到性能测试平台，比如在跑批量性能测试时降低渲染保真度，只采集关键性能指标

设计一个跨平台自动化兼容性测试平台，架构如何划分，关键指标和监控怎么做

控制平面：用例管理、调度策略、任务编排、权限与版本管理（Web UI + API）

执行平面：Device Farm（真机 / 模拟器 / 云设备）、Runner Agent（分布式 Worker），每个Runner支持多种驱动（ADB / XCUITest / UIAutomator / Unity Test Runner / Python客户端）

采集与上报层：性能采集 Agent（嵌入客户端或通过系统 API），日志/崩溃收集、帧率/内存/GPU/耗电等时序数据。

消息/队列层：MQ（Kafka/Redis Stream）用于任务下发、日志上报与异步处理。

存储与索引层：时序数据库（Prometheus/Influx）+ 日志搜索（es）+ 对象存储（崩溃包/视频/快照）

分析与报表层：告警、回放工具（自动构造可复现环境）

监控与运维：Grafana、健康检查、自动扩缩容模块

hr面相关

为什么选择我们公司

我认为贵公司身为一线互联网企业，技术栈和工程实践能力一定都非常成熟，我相信内部一定非常重视技术氛围。在这样一个重视技术、节奏高效的环境，我认为我的能力可以快速得到提升，而且贵公司应该也会有完善的新员工或实习生的培养流程，可以更好的进行线性成长。并且可以在真实项目中锻炼自己的工程能力。而且我了解贵公司在业务领域持续扩展，也有很强的发展潜力，我希望能在这样的平台上深入了解业务

你对自己的职业规划是怎样的

短期内，我希望能在本职岗位上打好基础，快速的了解所负责的基础业务和大体流程，在熟悉业务的同时提升自己对系统架构、质量保障的理解，同时也要重点看一下需求文档和开发文档，着重关注侧重点。中期来看，我希望自己不仅仅是执行需求，还能参与到平台的开发或质量体系建设中，在“懂技术又懂业务”的方向上深入发展，培养自己的产品意识和工程能力

是否接受加班

加班我是完全可以接受的。我理解研发和测试周期中有一些阶段确实需要投入更多，尤其是版本上线前或者新项目初期，我也愿意配合团队冲刺目标

你有没有其它公司的offer

之前收到过一些offer，不过我都拒绝掉了，目前有一些面试在进行中，也收到了部分反馈，但从技术氛围和业务来看，我个人更倾向于贵公司

用几个词描述一下自己

踏实、自驱、逻辑性强。我在项目中喜欢梳理问题和业务逻辑，有条理地分解任务，也习惯自己查资料解决问题；同时我也具备较强的执行力，能把任务落地

最有成就感的一件事

是我在读研期间负责的一个国家自然科学基金项目，当时是从零开始写系统设计书，在一次次的项目对接中实现各种功能和交互的逻辑，并且最后的算法训练也是我来做的，期间遇到了项目开发冲突，需求推倒重做，智能体训练失败等问题，但是最终也是平稳交付。负责一个成功交付的项目让我很有成就感

最成功的一次团队合作经历

我在去年做一个导师的横向课题时，担任的是场景构建的角色和团队负责人之一，在项目初期，我们带领团队成员制定了一个详细的项目计划和时间表，明确了每个人的职责。然后我进行场景构建的时候，也会与进行具体逻辑开发的成员进行及时的沟通，说明场景的构建蓝图和可行的训练方案。然后我的任务完成之后，由于我也是负责人之一，我也会及时的跟进项目当前的进度。

在项目快收尾的时候，我们遇到了一个问题，就是强化学习智能体达不到合同中规定的性能要求，在进行增加训练轮次，修改奖励函数等补救措施之后依然不行，然后我决定重新构建一版场景，让智能体更容易探索，最终解决了这个问题，然后我们合作的项目也成功的结题了

团队合作让我认识到成功的关键在于及时的沟通和协作，就是每个人不能只干完自己的事情就啥都不管了，也要力所能及的跟进到项目的整体中

为什么从上一家公司离职

我在那边主要负责停车平台的开发，用的技术栈比较固定，个人感觉成长空间有限。我在前公司锻炼了开发能力和项目协作经验，也积累了微服务、分布式系统的经验。接下来我希望能结合这些经验，进一步挑战更大规模的系统和更复杂的架构，因此寻找一下新的机会

什么情况下会感到压力大，压力大了对你有什么影响

我觉得压力在工作中很常见，比如项目时间比较紧，或者遇到新技术需要快速上手的时候。我通常会先冷静分析，把大任务拆解成小目标，合理安排优先级，并和团队保持沟通。压力大的时候反而会让我更专注，推动我快速学习和提高效率。当然，我也会通过运动或者短暂休息来调整状态，保证工作的持续性

遇到过什么挫折，怎么解决的

我觉得我遇到过的一个比较大的挫折，是在做项目的性能优化时。刚开始做压测的时候，系统在高并发下频繁出现超时和数据不一致，我当时一度很沮丧，因为这说明架构设计有漏洞。后来我静下心来，把问题拆解：先用JMeter精确复现问题，然后逐步排查数据库瓶颈、Redis热点key、RabbitMQ消息积压，最后通过缓存优化、消息削峰和读写分离，才逐步稳定住系统。这件事让我认识到，挫折其实是暴露问题的机会，关键在于冷静分析、和团队合作、持续优化。之后我遇到类似的问题时，能更快地定位和解决，也增强了我面对压力的信心

领导与你意见不同怎么办

我觉得首先要尊重领导的判断，因为他站的角度更高，可能考虑的是我没看到的整体目标。如果我确实有不同意见，我会先准备充分的依据，比如测试数据、性能指标或者用户反馈，然后在沟通时尽量客观地表达我的观点。如果最后领导坚持原来的方案，我会毫不犹豫地执行，并在过程中记录情况，方便后续复盘。这既能保证团队效率，也能避免因为争执影响项目推进

领导让我做，但我觉得没必要做怎么办

我会先弄清楚领导的真实意图，也许背后有我不了解的业务需求。如果确认确实可能是重复劳动或收益不高，我会礼貌地提出：“能不能先验证一下效果，再决定是否投入大规模开发”，并拿出更优的替代方案。如果领导仍然坚持，那我会按要求完成，同时尽可能优化执行方式，把事情做到最好。这样既尊重了决策，也保证了效率

希望和什么样的上级共事

我希望和一个沟通顺畅、目标清晰、愿意给予指导和反馈的上级共事。这样我能更快理解业务目标，同时在遇到困难时能得到方向性的帮助。我也很看重上级对团队成员专业性的尊重，能给大家一定的自主空间。当然，不同领导有不同风格，我也会主动适应，关键是我们有共同的目标，一起把事情做好

有没有遇到过冲突，怎么解决的

在团队合作中确实遇到过分歧，比如在实验室的项目中，我们对任务优先级有不同看法，当时我当时倾向于优先实现环境的真实性，另一位同学觉得应该优先实现环境的可扩展性。当时我先倾听了对方的思路，把争议点明确下来，然后把方案放到团队会议里对比分析，同时请导师帮忙确认项目阶段目标，结合性能和实现难度来做客观判断。最终我们达成了一致，项目也顺利推进。这次经历让我意识到，冲突不可怕，关键是沟通透明、聚焦目标

反问

  • 部门业务、技术栈
  • 新人培养机制
  • 公司文化和部门氛围
  • 面试中没有回答好的问题
  • 后续流程