Walmart 研发人员招聘的Leetcode测评(Tech Platform 运维岗测评)

然后自动：

查询 Deployment

查询 Pod 状态

查询 Error Log

查询 Metrics

查询 Trace

查询最近 Change

查询历史类似 Incident

最终生成：

可能 Root Cause

相关证据

建议操作

风险等级

是否需要人工确认

再进一步甚至可以：

AI Agent
↓
创建 / 更新工单
↓
通知负责人
↓
执行 Runbook
↓
扩容
↓
Rollback
↓
验证结果
↓
关闭工单

如果 Walmart 团队真的在做这种东西，那么我觉得面试重点一定会和传统 DevOps 有明显区别。

3. 所以我会重新调整准备比例

之前我的理解大概是：

40% Coding

30% Python / Go

30% Linux / DevOps

现在我会重新调整成：

30% Coding / Python / Go

30% AI / LLM / Agent

25% Platform / DevOps / SRE

15% System Design / Developer Productivity

当然这只是我自己的备考比例，不代表 Walmart 官方考核比例。

但至少从 HR 的描述来看，我觉得这样更合理。

4. LeetCode 还要不要刷？

要。

但我现在不会把它当成最重要的部分。

因为线上 Coding Assessment 很可能还是公司统一流程，第一轮依然可能出现普通算法题。

目前我查到的 Walmart 历史题里，还是值得准备这些：

LC 1 — Two Sum

LC 15 — 3Sum

LC 26 — Remove Duplicates from Sorted Array

LC 41 — First Missing Positive

LC 198 — House Robber

LC 295 — Find Median from Data Stream

LC 347 — Top K Frequent Elements

LC 560 — Subarray Sum Equals K

LC 1004 — Max Consecutive Ones III

但我现在的目标不是疯狂刷数量。

而是保证：

Array

HashMap

Two Pointer

Sliding Window

Heap

基础 DP

这些 Medium 以内的题，可以比较稳定地写出来。

因为如果岗位真正偏 AIOps，我觉得后面的技术面大概率不会把重点放在复杂算法上。

5. Python 我现在会放得更重要

如果是 AIOps / AI Engineering，我觉得 Python 的重要性会明显提高。

不仅仅是：

会写算法

而是：

会处理数据

会调 API

会写 Service

会调用 LLM

会处理 Streaming

会做 Automation

会接内部系统

我至少会熟练：

dict

set

list

deque

heapq

Counter

defaultdict

dataclass

asyncio

requests / httpx

json

re

logging

另外会认真看：

FastAPI

Pydantic

async / await

REST API

WebSocket / Streaming

Retry

Timeout

Concurrency

因为一个真正的内部 AI 平台，后面很可能就是大量 API Integration。

6. 我觉得很可能会考：怎么设计一个 AI 工单系统

如果面试官现在问我：

给公司内部研发团队设计一个 AI 工单助手，你会怎么做？

我不会直接回答'接一个 GPT API'。

我会先拆问题。

第一步：用户到底想解决什么？

研发提工单，通常并不是为了'创建一条 Ticket'。

真正想要的是：

解决问题

比如：

服务为什么挂了？

为什么发布失败？

为什么权限申请没下来？

为什么数据库连不上？

应该找哪个团队？

这个错误以前出现过吗？

怎么修？

所以 AI 工单真正应该优化的是：

Time to Resolution

而不是：

Time to Create Ticket

这个区别我觉得很重要。

7. 一个我认为比较合理的 AI 工单架构

我现在会这样设计。

User
↓
Chat / Ticket Portal / Slack
↓
AI Gateway
↓
Intent Classification
↓
Context Retrieval
↓
Agent Orchestrator
↓
Tools
↓
Reasoning / Analysis
↓
Recommendation / Action
↓
Human Approval
↓
Execution

Tools 里面可能包括：

Jira

ServiceNow

GitHub / GitLab

Jenkins

ArgoCD

Kubernetes

Prometheus

Grafana

Loki / ELK

Tracing

CMDB

Internal Wiki

Runbook

Incident Database

真正有价值的是把这些系统串起来。

8. RAG 我觉得一定要准备

如果做企业内部 AI，最自然的问题就是：

模型怎么知道公司的内部知识？

不可能只靠模型训练数据。

所以基本一定会涉及：

RAG。

比如 AI 工单需要知道：

内部服务说明

SOP

Runbook

历史 Incident

历史工单

API 文档

架构文档

Owner 信息

故障处理流程

最基本流程：

Document
↓
Chunk
↓
Embedding
↓
Vector Database

User Query
↓
Retrieve
↓
Relevant Context
↓
LLM
↓
Answer

但我觉得面试不会只问：

RAG 是什么？

更有可能问：

为什么你的 RAG 搜不到正确 Runbook？

或者：

如果搜出来 10 个历史工单，怎么判断哪个真的相关？

所以我会准备：

Chunking

Embedding

Vector Search

Hybrid Search

BM25

Reranking

Metadata Filter

Query Rewrite

Context Window

Citation

Permission Filter

9. 企业内部 RAG 有一个特别重要的问题：权限

这个我觉得很容易成为面试加分点。

企业内部系统不是：

所有人可以看所有东西

比如：

研发 A

可能没有权限看：

财务系统日志

安全 Incident

生产数据库信息

其他团队 Secret

所以 AI Retrieval 不能只是：

Query
↓
Vector DB
↓
返回结果

必须加：

Identity

Role

Team

Resource Permission

也就是：

Permission-aware RAG。

否则 AI 本身就可能成为新的数据泄露入口。

这个问题我觉得在 Walmart 这种大型企业尤其重要。

10. Agent 我现在也会重点准备

如果只是：

输入问题
↓
RAG
↓
回答

其实还只是一个 Knowledge Assistant。

真正的 AIOps 往往需要 AI：

调用工具

比如：

payment-service 为什么报警？

Agent 可以：

1. 查 Prometheus

2. 查 Deployment

3. 查 Pod

4. 查最近 Release

5. 查 Error Log

6. 查 Trace

7. 查历史 Incident

8. 汇总证据

这就是典型 Agent。

所以我会准备：

Tool Calling

Function Calling

Agent Loop

Planner

Executor

Memory

State

Workflow

Human-in-the-loop

11. 但我不会把所有东西都设计成 Agent

这一点我觉得面试里也挺重要。

LLM Agent 很灵活，但它的问题也很明显：

不可预测

成本高

延迟高

可能重复调用工具

可能 Hallucination

执行动作存在风险

所以企业系统里很多流程更适合：

Workflow
+
LLM

而不是：

全部交给 Autonomous Agent

比如：

识别工单类型
↓
固定 Workflow
↓
LLM 做信息提取
↓
调用确定工具
↓
规则判断
↓
LLM 总结

我觉得这种设计通常会比'让 Agent 自己决定一切'更靠谱。

12. AIOps 最核心的一件事：怎么避免 AI 乱操作生产环境

如果 AI 只是总结日志，出错可能还好。

但如果 AI 可以：

Restart Pod

Scale Deployment

Rollback

修改配置

关闭 Incident

风险马上就完全不一样了。

所以我觉得一定要准备：

Read-only Tool

Write Tool

Risk Classification

RBAC

Approval

Audit Log

Rate Limit

Rollback

比如：

查询 Pod

可以自动执行。

但：

Rollback Production

必须：

Human Approval

类似：

AI:
发现 95% 可能是版本 v123 导致。

建议：
Rollback 到 v122。

证据：
1. Error Rate 从发布后开始上升
2. v122 无该异常
3. 历史 Incident #1234 类似

是否执行？

这种 Human-in-the-loop 我觉得才更符合企业 AIOps。

13. AI 工单可能出现哪些具体功能

结合 HR 给出的方向，我现在觉得这些功能特别值得提前想。

自动分类

Bug

Infrastructure

Permission

Database

Network

Deployment

CI/CD

Security

自动设置 Priority

根据：

影响范围

用户数量

生产 / 测试

Error Rate

业务 Criticality

判断：

P0 / P1 / P2 / P3

自动补全工单

用户可能只写：

payment 挂了

AI 自动查询后补全：

Service: payment-service

Environment: production

Cluster: sg-prod-01

First detected: 14:32

Error rate: 23%

Recent deployment: v182

Owner: Payment Platform

自动 Routing

AI
↓
判断 Service Owner
↓
找到对应 Team
↓
自动 Assign

Similar Incident Search

自动查：

历史工单

历史 Incident

RCA

Runbook

回答：

去年发生过一次类似问题，当时是 Redis connection pool exhausted。

Root Cause Suggestion

根据：

Logs

Metrics

Tracing

Deployment

Change History

给出可能 Root Cause。

自动执行 Runbook

例如：

Restart

Scale

Clear Cache

Rollback

Switch Traffic

当然需要权限和审批。

14. 如果让我设计'AI 提升研发效能'，我不会只想到工单

HR 举的是 AI 工单，但我觉得真正方向应该更大。

内部研发效能可以做很多事情。

AI Debugging Assistant

开发贴一段错误：

Connection timeout to redis-prod-02

AI 自动：

查文档

查 Redis 状态

查网络

查历史 Incident

查 Owner

给解决建议

AI CI/CD Assistant

比如开发问：

我的 Pipeline 为什么失败？

AI 自动读取：

Build Log

Test Result

Docker Build

Deployment Log

然后回答：

第 4 步失败

原因是 Unit Test xxx

关联 Commit abc123

建议修改 xxx

AI Kubernetes Assistant

开发问：

为什么 Pod 一直 Pending？

AI 自动：

kubectl describe

Node Resource

PVC

Taint

Affinity

然后直接告诉他：

没有 Node 满足 memory request。

AI Incident Assistant

发生事故时：

自动汇总告警

生成 Timeline

关联 Change

查历史 Incident

生成 Incident Summary

辅助 RCA

AI Knowledge Assistant

内部工程师可以直接问：

怎么申请 Kafka Topic？

生产环境怎么发布？

payment-service 谁负责？

怎么接入 Prometheus？

这个 API 有没有限流？

减少大量重复问人。

15. 怎么衡量 AI 到底有没有提升研发效能？

这个问题我觉得很可能被问。

因为企业做 AI 最大的问题是：

Demo 看起来很好，但到底有没有价值？

如果是 AI 工单，我会看：

Ticket Deflection Rate

自动解决比例

平均响应时间

MTTR

人工介入比例

Routing Accuracy

Classification Accuracy

Reopen Rate

如果是研发助手，我会看：

Time to Resolution

Time to First Answer

Developer Satisfaction

Task Completion Rate

Tool Success Rate

我觉得不能只看：

Token Usage

聊天次数

DAU

这些不等于研发效率提升。

16. AI 系统本身也需要 Observability

以前我准备 Observability，主要想的是：

CPU

Memory

QPS

Latency

现在还需要加一层：

LLM Observability。

例如：

Prompt

Response

Token

Latency

Cost

Model

Tool Call

Tool Result

Agent Step

Error

甚至还要记录：

最终回答有没有解决问题？

用户有没有重新提问？

有没有执行错误工具？

有没有 Hallucination？

这对 AIOps 系统非常重要。

17. Hallucination 怎么处理

这个问题我觉得基本逃不掉。

比如 AI 告诉研发：

payment-service 是 Redis 挂了。

结果其实不是。

所以不能只是：

让模型更聪明

而应该从系统层解决。

我会考虑：

RAG

Tool Grounding

Citation

Confidence

Structured Output

Rules

Verification

Human Approval

比如 AI 输出 Root Cause 时：

结论：
Deployment v182 可能导致错误。

Confidence：
82%

Evidence：

1. 发布后 Error Rate 上升
2. Error Log 出现新的 exception
3. Rollback staging 后恢复

比一句：

应该是 Deployment 导致的。

靠谱很多。

18. Prompt Engineering 要懂，但不能只会 Prompt

如果岗位写 AI，我觉得很多人第一反应可能是：

Prompt

但企业 AIOps 真正困难的地方通常不是：

怎么写一个漂亮 Prompt？

而是：

数据从哪里来？

工具怎么接？

权限怎么做？

上下文怎么找？

怎么评价结果？

错误怎么办？

怎么保证安全？

怎么上线？

成本怎么算？

所以我会准备 Prompt Engineering，但不会把它当核心能力。

19. Linux / Kubernetes / Docker 为什么还是重要

虽然方向现在更偏 AI，但我反而觉得这些基础能力不能丢。

原因很简单。

如果 AI 要帮研发解决：

Kubernetes

Deployment

Network

CI/CD

Logs

Alerts

自己连这些东西都不理解，就很难设计靠谱的 AI Agent。

比如 AI 看到：

CrashLoopBackOff

你自己应该知道优先查：

kubectl describe pod

kubectl logs

kubectl logs --previous

以及：

Probe

Config

Secret

OOM

Exit Code

否则很容易变成：

我会调 LLM，但是不知道工具返回的数据是什么意思。

所以 Platform 基础现在对我来说更像：

AI 的 Domain Knowledge。

20. 我现在会怎么准备 Kubernetes

不会大量背 YAML。

重点变成：

AI 怎么调用 Kubernetes？

哪些操作只读？

哪些操作危险？

返回结果怎么解析？

怎么让 Agent 判断下一步？

比如一个 Pod 故障 Agent：

get pod
↓
describe pod
↓
get events
↓
logs
↓
previous logs
↓
metrics
↓
deployment history

然后综合判断。

这种问题我觉得比：

DaemonSet 定义是什么？

更接近真实工作。

21. Git / CI/CD 同样如此

以前可能只是准备：

git merge

git rebase

现在我会继续想：

AI 能不能自动分析 CI 失败？

比如：

Git Commit
↓
CI Fail
↓
AI读取 Log
↓
找到真正 Error
↓
关联代码修改
↓
找到可能原因
↓
给修复建议

甚至：

生成 Patch

这样就已经变成 AI Developer Productivity。

22. 我现在最想自己做的几个 Demo

如果有时间，我觉得做 Demo 比再刷几十道 LeetCode 更有价值。

Demo 1：AI 工单助手

输入：

订单服务 staging 发布之后一直 500。

系统自动：

Intent 分类

提取 Service

提取 Environment

查询 K8s

查询 Logs

查询 Deployment

查询历史 Incident

生成 Diagnosis

最后自动生成一张 Ticket。

Demo 2：AI Kubernetes Troubleshooter

输入：

为什么 payment Pod 一直重启？

Agent 自动执行：

kubectl get

kubectl describe

kubectl logs

kubectl logs --previous

然后给结果。

Demo 3：AI CI/CD Debugger

输入：

为什么我的 Jenkins Build 失败？

自动：

读取 Pipeline Log

提取 Error

过滤无关输出

定位 Stage

关联 Commit

给建议

Demo 4：Incident Copilot

Incident 发生之后自动：

收集 Alert

收集 Logs

收集 Changes

建立 Timeline

查 Similar Incident

生成 Summary

生成 RCA Draft

我觉得这几个 Demo 都非常贴 HR 描述的方向。

23. System Design 我现在会重点准备这些题

如果是 AIOps 岗，我觉得下面这些题都很合理。

题 1

设计一个面向 10 万研发人员的内部 AI 助手。

题 2

设计 AI 工单系统。

题 3

设计一个可以自动排查 Kubernetes 故障的 AI Agent。

题 4

设计一个可以查询公司内部知识库的 RAG 系统。

题 5

怎么让 AI 安全地执行生产环境操作？

题 6

怎么评价一个 AIOps Agent 到底有没有效果？

题 7

如果 AI 调错了一个工具怎么办？

24. LeetCode 的优先级，我现在重新排一下

第一优先级

我还是会刷：

LC 1 — Two Sum

LC 15 — 3Sum

LC 26 — Remove Duplicates

LC 41 — First Missing Positive

LC 1004 — Max Consecutive Ones III

保证 Coding 基础。

第二优先级

LC 3 — Longest Substring

LC 49 — Group Anagrams

LC 121 — Best Time to Buy and Sell Stock

LC 347 — Top K Frequent Elements

LC 560 — Subarray Sum Equals K

第三优先级

LC 198 — House Robber

LC 295 — Find Median from Data Stream

再往后的复杂 DP / Graph Hard，我暂时不会投入太多。

25. 我会新增一套 AI Coding 题

这部分现在对我来说优先级甚至高于很多 LeetCode。

JSON / Log Parsing

解析几十 GB 日志

Similarity Search

给一批历史 Ticket
找到最相似的几个

Top K

找到 Error 最多的 Service

Sliding Window

找到过去 5 分钟 Error Rate 最高的时间窗口

API Aggregation

同时调用多个内部 API

处理 Timeout

Retry

Partial Failure

Async

并行查询：

Logs

Metrics

Deployment

Ticket

我觉得这类题和实际 AIOps 关联非常高。

26. 我现在觉得最应该掌握的 AI 技术栈

不是说每一个都必须精通。

但至少面试里不能完全陌生。

LLM

Embedding

RAG

Vector Database

Hybrid Search

Reranking

Tool Calling

Agent

Workflow

Structured Output

Evaluation

Guardrail

Prompt Engineering

LLM Observability

如果是 Python：

FastAPI

Pydantic

AsyncIO

Agent Framework 可以了解：

LangChain

LangGraph

LlamaIndex

但我觉得面试重点不应该是：

你背不背得出 LangChain API。

而应该是：

你知不知道什么时候应该用 Agent，什么时候不应该。

27. 我现在最关心的几个面试问题

如果让我押题，我反而会重点准备这些。

为什么要用 AI？

而不是直接：

Rules Engine

什么情况下不应该用 LLM？

RAG 搜不到正确答案怎么办？

Agent 调错工具怎么办？

AI 执行生产操作怎么保证安全？

怎么做 Permission-aware RAG？

怎么降低 Hallucination？

怎么评价一个 AI 工单系统？

AI 工单真的能减少多少人工工作？

什么时候应该 Human-in-the-loop？

LLM 成本太高怎么办？

一个请求要查询 10 个内部系统，怎么降低延迟？

这些问题我觉得比单纯问：

Transformer 是什么？

更贴近这个岗位。

28. 如果只有一天准备

我现在会这样安排。

上午

Coding：

LC 1

LC 26

LC 15

LC 1004

Top K

Log Parsing

Sliding Window

下午

AI：

RAG

Embedding

Vector Search

Agent

Tool Calling

Structured Output

Evaluation

Hallucination

重点把：

AI 工单

完整设计一遍。

晚上

Platform：

Linux

Kubernetes

Docker

CI/CD

Observability

但不会背大量八股。

重点想：

这些系统怎么接入 AI Agent？

29. 如果有三天

Day 1：Coding

Python

Array

HashMap

Sliding Window

Heap

Log Processing

Async API

Day 2：AI

RAG

Agent

Tool Calling

Evaluation

Guardrail

Permission

LLM Observability

做一个 AI 工单 Demo。

Day 3：Platform + System Design

Kubernetes

Linux

CI/CD

Monitoring

Ticket System

Developer Platform

然后完整模拟：

设计 AI 工单系统

和：

设计 AIOps Troubleshooting Agent

30. 我对线上测评形式的最新判断

如果第一轮还是统一 LeetCode Assessment，我觉得大概率不会因为岗位变成 AIOps 就完全不考算法。

所以可能还是：

Q1

Array / HashMap


Q2

Sliding Window / Medium


Q3

Coding / Debugging

但真正到了团队技术面，我现在会把重点押在：

Python

AI Application

RAG

Agent

Platform

AIOps

System Design

而不是：

LeetCode Hard

31. 我现在对岗位的最终理解

和 HR 沟通之后，我觉得'Tech Platform 运维岗'这个名字其实很容易让人误解。

我现在反而觉得它真正的核心可能是：

用 AI 重做内部研发和运维工作流。

不是 AI 为了 AI。

而是：

减少工单

减少人工排障

减少重复查询

减少跨团队沟通

减少等待

减少手工操作

让研发人员：

更快找到答案

更快排除故障

更快完成发布

更快获得平台能力

所以这个岗位最终衡量的，也许不是：

你能不能把 Kubernetes 八股背得很好。

而是：

你懂不懂研发工程师每天真正浪费时间在哪里，以及能不能用 AI + Platform Engineering 把这些时间拿回来。

这一点我觉得才是 HR 最新信息里最值得重视的地方。

32. 我现在的最终备考清单

Coding

Python

Array

HashMap

Sliding Window

Heap

Log Processing

API Integration

Async

AI

LLM

RAG

Embedding

Vector Search

Hybrid Search

Reranking

Tool Calling

Agent

Workflow

Evaluation

Guardrail

Permission-aware RAG

LLM Observability

Platform

Linux

Git

Kubernetes

Docker

CI/CD

Prometheus

Logs

Tracing

AIOps

Incident

Alert

Ticket

Runbook

RCA

Root Cause Analysis

Automation

Human Approval

Developer Productivity

AI Ticket

AI Debugging

AI CI/CD

AI Knowledge Base

AI Incident Copilot

Internal Developer Platform

33. 最后

如果按照我现在拿到的信息重新排优先级，我会变成：

1. Python / Coding

2. AI 工单 System Design

3. RAG

4. Agent / Tool Calling

5. AIOps

6. Kubernetes / Linux

7. Observability

8. CI/CD

9. AI Evaluation / Guardrail

10. LeetCode Medium

LeetCode 仍然要准备。

Platform 基础也仍然重要。

但这两件事现在更像：

门槛

而不是：

最终目标

真正值得重点准备的是：

怎么把 AI 和研发基础设施结合起来，做一个真的能减少研发工作量、缩短问题处理时间、提高内部工程效率的系统。

如果 HR 给出的方向就是团队接下来真正要做的事情，那我觉得这应该成为整场面试准备的主线。