答题参考

职位：Software Engineer, Smart Cameras

每晚「面试准备助手」2026-10-13 整理，2026-10-24 按写作标准重写，并按已约好的日程改了「可能被问到的」。职位调研（Data Engineering） 写的是已经关掉的 Data Engineering 那个职位，这页是她 10/8 转投的 Smart Cameras。JD（job description，职位描述）来自转载站 zapply（2026-10-07 发布，预计 10-27 截止），官方链接见文末。经历只取自 简历（文字版） 和 简历项目的 STAR 素材；标【推断】的是判断，标「待补」的是这两页里还没有、要她自己填真实情况的地方。

Data Engineering 和 Smart Cameras 两次投递是同一位招聘方。10/8 初面时她对离职原因的说法，和 被问到为什么离开微软怎么答 里定下来的说法（定稿）不完全一样，记录和后面几轮的接法在 职位调研（Data Engineering）「2026-10-08 recruiter 面里说过的话」；后面几轮照那一节接，不另起一套。

这页给哪一轮用

主要给 10/30（周五）8:30–9:30 的 HM 面试用。HM 是招聘经理（hiring manager），也就是招这个职位的经理，通常就是将来的直属经理。这一轮在 Webex（Cisco 自己的视频会议软件）上，1 小时，是最后三轮里日期最晚的一场。Cisco 其他组的 HM 轮形式不固定，有的是 30 分钟简历加行为题（behavioral question，讲过去经历的题），有的出脑筋急转弯，汇总在 面试概览「HM（10/30）」。

【推断】经理在这一轮最想弄清三件事：她做过的事和组里的活对不对得上；对不上的地方她自己清不清楚、打算怎么补；讲自己的项目时，能不能把为什么这么做、结果怎样说清楚。所以这页先拆 JD，再逐条对简历，然后是开场会用到的 Why Cisco 和自我介绍，最后是可能的问题和完整答法。

另外两轮也用得上：「可能被问到的」第 1、2 条是 10/28 Coding 轮开头聊简历时的讲法；「按 JD 建议练的题」是给 10/29 System Design 轮的练习。

职位要点

2026-10-25 拿 Cisco 官方招聘页的原文（JD 原文）核对过下面几条，和原来依据的 zapply 转载一致。官方原文多出两处，补在第 1 条和第 8 条。招聘页写着申请窗口预计 10/27 关闭，之后以 JD 原文 为准。

Smart Camera 团队属于 Meraki。Meraki 是 Cisco 做云管理网络设备的部门：设备装在客户现场，配置和监控都在云上的 Meraki Dashboard（Meraki 给客户用的网页管理后台）里做。这个组做 Meraki 摄像头背后的云端服务，包括视频流（streaming，实时看画面）、视频导出（export，把一段录像取出来下载）和云存储。JD 说客户从加油站到连锁健身房都有，要求 24×7 可用。美国境内可远程。base（基本年薪，不含奖金和股票）是 $155,000–$222,600（JD 原文）。

JD 的职责和要求按顺序是：

1. 建设和维护上面这三块云端服务，JD 原话是 Cloud services for video streaming, exports, and storage。团队介绍的第一句是 merging edge-storage architecture with sophisticated AI-powered analytics，意思是录像存在设备这一侧（edge storage，边缘存储），再加上 AI 分析。以前网上的说法「Meraki 摄像头把录像存在本地」只有竞品文章作依据，现在 JD 原文也这么写了，可以当成这个组的前提来讲系统设计。云端到底存什么、什么时候上云，JD 没写，还是留到反问第 2 条去问。
2. 写 high-performance APIs and backend services，并且接进 Meraki Dashboard，也就是说她写的接口是客户的管理后台直接在调。
3. 在 AWS 上做到高可用（high availability，部分机器坏了服务照常可用）、容错（fault tolerance，局部出错时系统自己兜住）和性能。
4. 必要时 across the stack（全栈）干活，既写 UI 组件，也处理和摄像头固件（firmware，设备上跑的底层软件）的交互。
5. Own services end to end，服务从开发到上线运行都归自己管，包括测试、埋点（instrumentation，在代码里加指标和日志）和线上可观测性（observability，能从指标和日志看出系统现在的状况）。还要牵头处理复杂的线上故障，写 post-mortem（故障复盘报告，讲清发生了什么、根因是什么、以后怎么防）和根因分析（root cause analysis）。
6. 最低要求是本科加 3 年以上（或硕士加 2 年）。有 Go、TypeScript 或其他静态类型语言（编译时就检查变量类型的语言，比如 Java、C#）的生产经验，再加一门脚本语言（Ruby 优先，或 Python）。懂 RESTful API 设计和关系数据库。做过分布式系统（distributed systems）、微服务（microservices，把一个大应用拆成多个能独立部署的小服务）和 Kubernetes。会用 AI 辅助开发工具（JD 举的例子是 Copilot、Cursor、Claude）。Kubernetes 是管理容器的平台：容器（container）是把程序连同它依赖的环境打成一个包，放到哪台机器上都一样跑。Kubernetes 负责把一个服务的多个容器副本排到机器上跑，崩溃了自动重启，按负载增减副本。
7. 加分项有全栈（React、TypeScript），「Domain expertise in video streaming protocols (RTSP, HLS, WebRTC)」，CI/CD（持续集成和持续部署，continuous integration / continuous delivery，代码合入后自动构建、测试、发布的流水线，即 pipeline）和 Prometheus / Grafana / ELK，AWS（Lambda、SQS、DynamoDB）和 Terraform。她没做过的那几样，在下面「对不上的地方」逐个解释。
8. 和产品经理、兄弟团队一起定需求和路线，JD 原话 Strategic Collaboration: Partner with Product Managers and partner teams to define requirements, architecture, and long-term project roadmaps。HM 轮可能顺着这条问她怎么和产品经理合作【推断】。

简历对照

表里几个词先说清楚。Fluent UI 是微软的前端组件库；SmartArt 是 PowerPoint 里把文字排成图示的功能；Azure DevOps 是微软的开发平台，CI/CD 流水线就建在上面；gRPC 是 Google 开源的远程调用框架，适合服务之间高频调用，和 REST 的区别在「可能被问到的」第 1 条讲。AKS 是 Azure Kubernetes Service，Azure 托管的 Kubernetes；横向扩展（horizontal scaling）是靠增加副本来分担流量，而不是换更大的机器。BIG-IP 是 F5 的网络设备，BIG-IQ 是集中管理大批 BIG-IP 的平台，SSL Orchestrator 是其中一个产品。任务编排（task orchestration）是把一次下发拆成有先后顺序的几步，由后端按顺序执行并记下每一步的结果。ring 发布和自动回滚在「可能被问到的」第 3 条讲。

最贴的是两段。F5 那段是「从一个中心管一大批分布在各处的设备」，正是 Meraki Dashboard 管摄像头的模式；微软那段是「别人依赖的高可用服务，加上发布纪律和前端」，对上 JD 的端到端负责和全栈。HM 问「你的经历和我们组有什么关系」，就从这两段讲。

Kubernetes 是最低要求，经理很可能追问。简历写的是缩略图服务部署在 AKS 上，但 简历项目的 STAR 素材「其他待补」里还列着「服务具体跑在 Azure 的哪个服务上（AKS、Service Fabric、App Service 等）、部署了几个地区」，后两个是 Azure 上另外两种跑服务的方式。面试前先确认这一条，再准备好副本数、扩容是手动还是自动、按什么指标触发这几个追问的真实答案。

对不上的地方，怎么诚实地补

HM 会顺着简历往下挖。说自己做过、又答不上追问，比直接承认没做过更伤，因为经理会由此怀疑简历上别的条目也有水分【推断】，所以每一条都按「没做过什么、最接近的经历是什么、打算怎么补」三步说。

• AWS（Lambda、SQS、DynamoDB）和 Terraform。Lambda 是 AWS 的无服务器函数（serverless，只写函数，机器由 AWS 管）；SQS 是 AWS 托管的消息队列；DynamoDB 是 AWS 托管的键值数据库；Terraform 是用代码描述云资源的工具，这种做法叫基础设施即代码（infrastructure as code，IaC）。她没有 AWS 的生产经验，用的是 Azure，给两个服务从零搭过所有环境。讲法是云上的概念相通，具体服务要上手；如果上面 AKS 那条确认属实，Kubernetes 本身的经验能直接带过去，因为 AWS 的托管 Kubernetes 服务 EKS 跑的也是 Kubernetes。当时的资源是怎么建的（是否用了 ARM / Bicep 模板，这是 Azure 自己的 IaC 格式）在 简历项目的 STAR 素材 里还是待补；没用模板就不要说做过 IaC。英文讲法见第 6 条。
• 视频流协议（RTSP、HLS、WebRTC）。RTSP（Real Time Streaming Protocol）是网络摄像头常用的实时流协议，客户端用它控制播放（开始、暂停、停止），视频数据本身通常由配套的 RTP（Real-time Transport Protocol，实时传输协议）传。HLS（HTTP Live Streaming）把视频切成几秒一段的小文件，配一个列出这些文件的播放列表，全走普通 HTTP，所以能借 CDN（内容分发网络，把文件缓存在离观众近的服务器上）扩到很多观众，代价是延迟通常有好几秒。WebRTC 是浏览器里的实时音视频，延迟能到一秒以内，代价是连接建立复杂，也不能像 HLS 那样直接靠 CDN 扩容。她没做过，照实说这是要补的领域知识，但能讲清这组取舍：看实时画面要低延迟，看录像回放能接受几秒延迟、更在乎成本和扩展性【推断】。
• Go 和 Ruby 都没写过。静态类型语言写过四门，脚本语言用的是 Python；换语言照实说需要上手时间，不说「很快就会」这种没法验证的话。
• Prometheus / Grafana / ELK。Prometheus 定时从各个服务拉取指标、存成时间序列并按规则告警；Grafana 把指标画成仪表盘；ELK 是 Elasticsearch、Logstash、Kibana 三件套，用来收集、检索和查看日志。简历上都没有。她做过按错误率和延迟做的健康检查，但这两个指标从哪个监控系统读、告警怎么配，简历项目的 STAR 素材 里列为待补（「监控和告警」），照实说当时用的工具。
• 摄像头固件。简历上没有固件的经历。F5 那段是中心端给设备下发配置，不是写设备上跑的软件；照实说，能讲的是中心端怎么和大批设备打交道（第 2 条）。
• 牵头处理线上故障、写 post-mortem。简历项目的 STAR 素材 里还没有现成的故事，怎么准备见「可能被问到的」第 5 条。

Why Cisco（Smart Cameras）

Meraki 的摄像头是「设备在现场、管理在云上」：云端服务要 24×7 稳定地做好视频流、导出和存储，还要通过 Dashboard 管一大批设备。她在 F5 做的就是集中给大批设备下发配置的后端，在微软做的是别人依赖的高可用服务，另外写过 PowerPoint Online 的 React 前端，正好覆盖这个岗位后端加 Dashboard 两头。

这样讲的理由是：HM 问 Why Cisco，想听的是为什么是这个组的活。先说组里的活哪里吸引她，再用两段经历证明两头她都做过，最后落到她想做的事。

What draws me to the Smart Camera team is the mix of devices in the field and cloud services behind them that have to be up 24/7. At F5 I built the backend that pushed configuration to large fleets of distributed devices, and at Microsoft I built high-availability backend services and React frontend features in PowerPoint Online. So owning an API from the service all the way into the Meraki Dashboard is exactly the kind of work I want to do.

追问「你对 Meraki 摄像头了解多少」时，只说 JD 里写的：云管理、通过 Dashboard 管理、客户从加油站到连锁健身房、要求 24×7，再加上团队介绍里的 edge-storage architecture 和 AI-powered analytics，也就是录像存在设备这一侧、再做 AI 分析（JD 原文，2026-10-25 核对）。网上还有说法称只把元数据（metadata，描述录像的小数据，比如时间和事件标记）传上云，这一点 JD 没写，不要当事实讲，改成反问第 2 条去问。

自我介绍怎么调

在 自我介绍 通用部分的基础上，结尾换成同页「ALSO 版」的说法。那一版是给 ALSO 这家公司的设备管理岗写的，结尾落在「设备 + 云服务」上，和这个组的活一样。正文突出三点：

1. F5 那段放到前面讲。通用版先讲微软、再讲 F5；这里按时间顺序先讲 F5，并比通用版多讲一点：下发前不只校验，还把下发编排成任务，因为下发错了就是客户网络的线上故障。放前面是因为这段和 Meraki 最像，HM 先听到的应该是最贴的那段。
2. 微软的高可用服务和发布纪律，包括按 ring 分批发布、自动回滚、一路部署到美国政府云，对上 JD 的「端到端负责」。AKS 等「简历对照」下面那条确认后再加进去。
3. 全栈，TypeScript + React 前端，对应 Dashboard 那一头。

合起来是下面这一版，最后一句是 ALSO 版的结尾（remote devices 换成了 devices in the field）：

I'm a backend-focused software engineer with close to eight years of experience, mostly on services other people depend on. At F5, I built Java REST APIs on PostgreSQL that validated security policies and pushed them to large fleets of distributed BIG-IP devices, orchestrated as tasks, because a bad push meant a real outage on a customer's network. Then I spent close to six years at Microsoft on PowerPoint, building high-availability services in C++ and C# — including a thumbnail service behind REST and gRPC that multiple product features depend on — plus their CI/CD pipelines with ring-based rollouts and automated rollback, and React and TypeScript frontend features in PowerPoint Online. That mix — devices in the field on one side, cloud services on the other — is what this role is about, which is why it caught my eye.

可能被问到的

【推断】下面是按 JD 和 Cisco 其他组的 HM 轮推测的（来源见 面试概览），不是这一轮的面经。每条写了为什么会问、怎么答、追问和要补的事实。

1. 讲一个你端到端负责的后端服务

JD 要求 own services end to end，最直接的考法就是让她讲一个这样的服务。用缩略图服务讲，因为按简历，这个服务的架构、各环境的基础设施和发布流水线都是她做的。按「做什么、谁在用、怎么搭、怎么上线」的顺序讲：服务生成 PowerPoint Online 的缩略图；用 C# 和 C++ 写，用 REST 和 gRPC 对外，多个产品功能都调它；打包成 Docker 容器放在 AKS 上横向扩展，部署在 Azure 的多个地区；CI/CD 是她写的，按 ring 发布，环境从 EDOG（Office 内部最早的测试环境，Early Dogfood）到全球生产，再到美国政府云。

I architected PowerPoint's thumbnail service in C# and C++, exposed it over REST and gRPC to several product features, and ran it on AKS so it could scale out horizontally.

这句里的 AKS 同样以「简历对照」下面那条确认为前提。追问和答法：

• 规模多大，即吞吐、P99 延迟（99% 的请求都不超过的那个延迟值）、几个调用方、几个地区。全部待补（简历项目的 STAR 素材 第 3 条）。没有数字这个故事站不住，面试前一定要补。
• 为什么同时提供 REST 和 gRPC。gRPC 用 protobuf（Protocol Buffers，Google 的一种先定义字段、再按二进制编码的数据格式）定义接口、二进制传输，所以适合服务之间高频调用；REST 走 HTTP 加 JSON，调用方接入门槛低。哪些调用方用哪种、当初为什么两种都给，记录里没有，待补；别拿这段通用解释代替真实原因。
• 为什么能横向扩展。通常的前提是服务无状态（stateless），每个请求不依赖之前留在某台机器上的数据，所以任一副本都能接任一请求。缩略图服务是不是这样、有没有缓存，待她确认。

2. 云端怎么管一大批设备？设备离线或下发失败怎么办

用 F5 那段。Meraki Dashboard 管摄像头和 BIG-IQ 管 BIG-IP 是同一种模式，HM 想知道她是不是真懂这类系统的难点。事实部分：Java 写的后端 REST API 对接 PostgreSQL，下发前做策略校验，把下发编排成任务执行；前端用 AngularJS 和 React。

At F5, the backend validated a policy before pushing it to many BIG-IP devices and orchestrated the rollout as tasks, because a bad push meant a real outage on the customer's network.

追问「离线或失败怎么办」时，面试官想听三点：每台设备的下发结果有没有单独记下来；失败的是自动重试，还是标出来让用户处理；同一份策略重复下发会不会出问题，也就是操作是不是幂等（idempotent，做一次和做多次结果一样，所以重试才安全）。F5 实际做了哪几点记录里没有，按她的真实做法讲；没做的就说没做，再讲现在会怎么做。下面是通用做法，不是 F5 的经历，所以说成「我现在会」【推断】：

• 每台设备单独记下发状态（待下发、成功、失败及原因），一台失败不会让整批状态说不清，用户也能只重发失败的几台。
• 只对网络超时这类暂时性错误自动重试，间隔逐次拉长（指数退避，exponential backoff），免得大批设备同时重试压垮服务端；策略写错、设备拒收这类重试也不会好的错误，直接标失败、把原因给用户看。
• 下发的是设备应有的完整配置加版本号，而不是「在现有配置上再加一条」，这样下发就是幂等的，重试才安全。
• 离线的设备不算失败：设备重新上线时比较它手上的版本和应有的版本，落后了再补发。

Today I'd track push status per device, retry only transient failures with backoff, and send each device its full desired config with a version number, so a retry or duplicate push is harmless. An offline device isn't a failure: when it reconnects, we compare versions and resend if it's behind.

支持多少台设备、配置耗时降了多少，待补（简历项目的 STAR 素材 第 5 条）。

3. 怎么让发布不出事，出了问题怎么发现

JD 要求可观测性和牵头处理故障，HM 会从发布流程问起。她用的是微软的安全部署（Safe Deployment Practices，SDP）：按 ring 分批上线，ring 是一圈比一圈大的部署范围；每推进一圈之前看错误率和延迟两个健康指标，不达标就自动回滚。好处是问题在只影响最先那一小圈时就被拦住，代价是发布变慢，因为每一圈发完都要观察一段时间、指标没问题才往下推。

Releases went out ring by ring, gated on error rate and latency, with automated rollback — so problems would show up in an early ring, not across every customer.

追问都在 简历项目的 STAR 素材「面试前要想清楚的」里，目前全是待补：ring 怎么划分（那一页的例子是 EDOG → 内部用户 → 第一个生产地区 → 全部地区 → 政府云）；阈值多少，跟上一版比还是跟固定的 SLO（service level objective，服务给自己定的指标目标）比；每一圈发完观察多久再往下推（bake time）；自动回滚是退回上一版、停止往下推，还是关掉功能开关（feature flag），是平台自带的还是她在自己写的流水线里配的；有没有真触发过。最后一问的答案也是第 5 条的素材。

4. 视频导出、存储这类系统怎么设计

HM 可能不展开画图，但会问思路。三句话的骨架【推断】：导出要几分钟，一个 HTTP 请求等不了，所以接口做成异步的，提交时返回任务 ID，客户端拿 ID 查状态；存储按保留期（retention，录像留多少天）清理，新录像放快而贵的存储，旧的挪到慢而便宜的，因为旧录像很少有人看；视频文件大，瓶颈通常在带宽和存储成本，不在每秒请求数（QPS）。完整讲法见 面试概览「怎么准备」里的视频导出，练习题见下面「按 JD 建议练的题」。

追问「导出到一半摄像头断网怎么办」（前提是视频存在摄像头上，这一点未核实，见反问第 2 条）：让摄像头分块上传，服务端记下收到了哪几块，设备重新上线后从缺的那块接着传，不用从头传；超过约定时间还不上线，就把任务标成失败，并告诉用户卡在哪一步【推断】。

5. 讲一次你处理的线上故障和 post-mortem

JD 原话要求牵头处理故障、写 post-mortem，这题大概率会问。先查一件事：自动回滚有没有真触发过（第 3 条最后一问）。有的话，按「怎么发现（哪个指标报警）→ 影响多大 → 怎么止损 → 根因是什么 → 改了什么让它不再发生」讲，最后一步最重要，因为 post-mortem 的价值在于防止再发。没有她牵头处理过的故障，就照实说，转去讲她做的预防机制，不要编：先说下面这句，再接第 3 条那段英文。

I haven't led a major incident myself; where I've put my effort is prevention.

不要用离职那件事。 那件事是 被问到为什么离开微软怎么答 里的跨组事件：一个项目牵涉的服务太多，漏了一个相关的组，后来那一块从另一条路径进来的改动产生了重复数据；她当天发现、当天找到根因，之后的绩效谈话也提到了这件事。同一页「这个故事的其他用途」允许把它当 ownership（对结果负责到底）的例子讲，也写明不要用它答跨组合作题。故障复盘题不适合用它【推断】：复盘一定会问根因和以后怎么防，而那件事的根因正是跨组协调的缺口，等于绕回了跨组话题。另外那件事的完整时间线还没定（同页「还没定的」），HM 一追问细节就可能牵出离职。

6. 没用过 AWS 怎么办

My production cloud experience is Azure — I stood up the full environment for two services, from internal test through worldwide production to US government cloud. The AWS services themselves would be new, but Kubernetes carries over directly, and the core concepts — queues, serverless functions, managed storage, infrastructure as code — map closely.

说完就停，因为这几样她没有生产经验，多说一句就把话题引到答不深的地方。Kubernetes 那半句以 AKS 那条确认属实为前提，确认不了就删掉。后半句只说概念对得上，不等于在 Azure 上用过队列或无服务器函数（简历（文字版） 和 简历项目的 STAR 素材 里都没有）；被问用的是哪个队列，就照实说没用过。

经理追问「打算怎么补」时，说具体做法【推断】：从组里一个现有服务的 Terraform 代码读起，找出它用的 Lambda 函数、SQS 队列和 DynamoDB 表怎么连起来，因为读正在跑的配置比从教程学起更快对上组里的实际用法；再在测试环境改一处、走一遍发布。DynamoDB 要多花时间，因为它不能随意联表查询（join），主键要按查询方式提前设计，和她用过的 PostgreSQL 不同。

I'd start from one of the team's existing services: find its Lambda functions, queues and tables in the Terraform code and trace how they connect, then make a small change and take it through the release process in a test environment. DynamoDB is where I'd spend the most time, since modeling around access patterns is quite different from the PostgreSQL work I've done.

7. 为什么离开微软

照 被问到为什么离开微软怎么答 定稿的三层口径答：默认只说九月离开了微软；被问离开的性质，才说是按绩效离开（performance-based separation）；被问之前有没有沟通，才说离开前有过绩效谈话、但没有正式的改进计划。问到哪层答哪层，不主动往下说。

10/8 她对同一位招聘方说的是过去一年组里有重组和换组，招聘方追问是不是有重组，她答了 yes。所以这次先接住「有过重组」，再过渡到九月那一轮按绩效的裁减，接法和英文原句在 职位调研（Data Engineering）「2026-10-08 recruiter 面里说过的话」。最要紧的一条：被直接问 were you laid off 时不答 yes，因为定稿说的是按绩效离开，答 yes 就对不上了。

追问「那你擅长什么」时，research 那一节有现成的英文：讲分布式后端服务和给大批网络设备下发策略的经历，落到这个岗位更接近她最擅长的事。

8. 你在工作里怎么用 AI 工具

JD 要求会用 AI 辅助开发工具，2026-09 Cisco San Jose 也有一位候选人被问到（工作中怎么用 AI 工具）。要分清两件事：简历上的 Copilot（微软的 AI 助手）集成是她给 PowerPoint 做的 AI 功能，不是她自己写代码时怎么用 AI。前者可以顺带一提，主体要讲她自己真实的用法，这在 简历（文字版） 和 简历项目的 STAR 素材 里都没有记录，待她自己准备。

回答按 工作中怎么用 AI 工具「思路」组织：用在哪、哪些事不让 AI 直接决定、怎么验证、一个具体例子，因为面试官想听的是判断力，不是工具清单。常见追问是「怎么确定 AI 写的代码是对的」（那道题记录的 Amazon 面经里至少三次），照她真实的把关方式答，比如是否和自己写的代码一样过代码审查（code review）和测试。

按 JD 建议练的题

有面经依据的题已经放进公司题库，汇总见 面试概览（2026-10-15 找的）。下面是按 JD 挑的站内已有题，给 10/29 的 System Design 轮练习用，只作练习，不进 Cisco 的题库：

• 设计 YouTube：视频上传、搜索、观看的通用设计。Verkada（也做云管理摄像头的公司）的电话面试常考这题。
• 设计流媒体处理系统：流媒体处理的两种做法，流式（数据一边到达一边处理）和异步（先提交任务、处理完再通知）。
• 设计异步任务 API 与 webhook：视频导出这种长任务的异步接口和回调（webhook，任务完成后服务端主动通知调用方）。
• 设备心跳：判活型：大批设备的在线状态监控。这是 Verkada 的题，场景和 Meraki 摄像头很像。

反问

面试最后经理会留时间给她提问。每个问题既问出她关心的事，也让经理看到她想过这个组的活：

1. 视频流、导出、存储三块里，这个岗位主要负责哪一块？现在最大的技术难题是什么（成本、延迟、可靠性）？答案直接决定她入职后做什么，也能接上第 4 条的设计思路。
2. 边缘存储（录像存在摄像头本地）和云端存储怎么分工，视频什么情况下才上云？录像放在哪，决定了云端要存多少、传多少视频，是这类系统的关键架构选择【推断】；网上的说法没核实，正好当面问。
3. 后端主要用 Go 还是 Ruby？和 Meraki Dashboard 的代码怎么协作？JD 两门语言都提了，答案决定她先补哪一门。
4. On-call（轮流在下班时间响应线上告警）怎么排，一个工程师大概多久轮一次？JD 要求 24×7 可用，值班负担就是实际的工作量。
5. 团队成员分布在哪些城市，远程的人怎么协作？JD 写的是美国境内可远程，要知道远程在这个组是不是常态。

工作许可

JD 没有签证条款；她不需要任何 sponsorship（雇主为工作签证提供的担保），不受影响。

来源

• 官方职位页（careers.cisco.com，转载站给的链接）
• zapply 转载
• freehire 转载