逐日AI

面试题库

共 328 题,当前筛选 3 题。

标签
还有 136 个标签
#api-design6#operations6#sse6#deployment5#message-bus5#tool-calling5#agent-loop4#behavioral4#error-handling4#evaluation4#framework-design4#mcp4#routing4#concurrency3#context-engineering3#langgraph3#llm-basics3#model-routing3#orchestration3#prompt-injection3#protocol3#redis-streams3#scalability3#scheduling3#agent-design2#auth2#checkpointing2#communication2#cost-control2#database2#debugging2#interview-process2#latency2#long-term-memory2#memory2#ordering2#prompt-engineering2#rate-limiting2#react2#resume2#retrieval2#sharding2#state-machine2#state-management2#tool-design2#tool-permissions2#trade-offs2#ux2#agent-basics1#agent-quality1#async1#atomicity1#cancellation1#capacity-planning1#career1#chunking1#compression1#configuration1#consistent-hashing1#context1#context-compression1#context-management1#correctness1#customer-support1#data-modeling1#deliberate-practice1#docker1#documentation1#engineering-tradeoffs1#escalation1#event-driven1#fallback1#fan-out1#fencing-token1#forking1#framework-selection1#frontend1#global-market1#hybrid-search1#interrupt-merge1#isolation1#json-parsing1#jwt1#knowledge-organization1#lease1#least-privilege1#llm-as-judge1#loop-guard1#mobile1#multi-tenancy1#nodejs1#performance1#persistence1#pgvector1#portfolio1#prioritization1#proactive-messaging1#product-engineering1#project-storytelling1#prompt1#provider-abstraction1#quiet-hours1#ranking1#recall1#reconnect1#redis1#reflection1#replay1#reporting1#rerank1#retrieval-quality1#retry1#retry-semantics1#rrf1#sampling1#sandboxing1#schema-design1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#service-architecture1#session-management1#split-brain1#star1#stateless1#storytelling1#structured-output1#system-prompt1#testing1#timezone1#tool-execution1#tools1#tracing1#transport1#vector-database1

30 天从前端工程师到 Agent 工程师

D7 封装成服务:Fastify + SSE + Docker(dg P07);W1 复盘

  • 自我介绍时,怎么在两分钟里讲清楚一个 Agent 项目的价值?In a two-minute self-introduction, how do you convey the value of an agent project?
    国内高频海外高频基础#interview-prep#communication

    分析过程 · 先想清楚再作答

    1. 这题没有标准答案,但有明确的失败模式:从技术栈开始报菜名(我用了 Fastify、SSE、Docker、向量库……)。面试官记不住工具清单,他记得住的是问题和数字。
    2. 用一条固定结构去组织,两分钟正好够:一句话说你是谁和转型方向,一句话说项目解决的业务问题(谁在什么场景下受什么苦),三到四句说你的关键技术决定和它换来了什么,最后一句给可验证的结果。
    3. 关键技术决定要挑「有取舍的」讲,不要讲「有实现的」。比如「流式用 SSE 而不是 WebSocket,因为上行只有一次,这样鉴权限流日志这套现成设施全部照用」——这种句子同时展示了你知道有别的选项、也知道选它的代价,比列出十个工具有效得多。
    4. 结果要尽量带数字,哪怕是自测数据:首字延迟从几秒降到几百毫秒、分层路由把日成本从 300 元降到 125 元、多 provider 冗余让可用性不再取决于单家厂商。没有生产数据就诚实说明是自测环境,编数字是最危险的做法,追问两句就穿帮。
    5. 常见误区是把学习项目说成生产项目。正确姿势是主动定位:这是我为了搞懂生产级 Agent 架构而完整实现的一套系统,规模是自测级,但每个决定都对着真实约束做过取舍——面试官对诚实的自评远比对夸大的描述宽容。
    6. 可以预期的追问:这个项目最难的地方是什么?提前准备一个具体的、有过程的答案(比如流式接口推流之后没法用状态码报错,最后改成流内 error 事件加上把校验全部前置),比任何形容词都有说服力。

    How to reason about it · think before answering

    1. There is no model answer, but there is a clear failure mode: opening with a tool list. Interviewers do not remember stacks; they remember problems and numbers.
    2. Use a fixed structure that fits two minutes: one line on who you are and where you are heading, one line on the business problem (who suffers, in what situation), three or four lines on your key technical decisions and what each bought you, and one closing line with a verifiable result.
    3. Choose decisions that involved a trade-off, not decisions that merely involved implementation. 'We stream over SSE rather than WebSocket because upstream traffic is a single request, which lets us keep existing auth, rate limiting and logging' shows you knew the alternative and priced it — far stronger than naming ten tools.
    4. Attach numbers wherever you can, even self-measured ones: time-to-first-token dropping from seconds to a few hundred milliseconds, tiered routing cutting daily spend by more than half, multi-provider fallback removing a single vendor from your availability ceiling. If the numbers are from a test environment, say so; inventing them collapses after two follow-ups.
    5. A common mistake is presenting a learning project as production. Position it yourself: a complete system built to understand production agent architecture, at self-test scale, where every decision was made against real constraints. Interviewers forgive honest scoping far more readily than inflated claims.
    6. Expect: what was the hardest part? Prepare one concrete story with a process — for example, discovering that a streaming endpoint cannot report errors by status code once it has started pushing, and redesigning around an in-stream error event plus front-loaded validation.

    答题要点

    • 结构固定:定位一句、业务问题一句、三到四个有取舍的技术决定、一句可验证的结果
    • 不要报菜名:面试官记不住工具清单,记得住问题、取舍和数字
    • 技术决定要讲取舍而不是讲实现,说清楚备选方案是什么、为什么没选它
    • 结果尽量带数字,自测数据也可以,但必须标明来源,绝不编造
    • 主动定位项目规模:为搞懂生产架构而完整实现、自测级规模,诚实自评比夸大更容易通过

    Key points

    • Keep a fixed structure: positioning, the business problem, three or four traded-off decisions, and one verifiable result
    • Do not recite a stack — interviewers retain problems, trade-offs and numbers, not tool lists
    • Frame decisions as trade-offs, naming the alternative and why it lost
    • Attach numbers even from self-testing, but label their source and never invent them
    • Scope the project honestly as a complete build at self-test scale; honest framing survives follow-ups better than inflation

D30 总复盘 + 投递启动:题库全量过一遍、知识地图、第二个月投递节奏、网站公开上线

  • 如果只剩最后一周准备面试,你会怎么安排复盘节奏?With only one week left before your interviews, how would you plan your review?
    国内高频海外高频基础#interview-prep#prioritization

    分析过程 · 先想清楚再作答

    1. 这题看着像闲聊,其实在考「你会不会做优先级」。面试官想听的不是勤奋,是判断:一周时间是固定的,你怎么决定把它花在哪。答「每天复习八小时,从头过一遍」就是没有判断。
    2. 先给一条可复用的推导:复习的边际收益取决于「这一块你现在离能讲清有多远」,所以任何计划的第一步都必须是**测量**,而不是学习。没测量就排计划,等于闭着眼睛分配预算。
    3. 落到具体做法:第一天只做分诊——把所有题目出声过一遍,按「能讲清 / 看一眼能讲 / 讲不出」标三种颜色,看到不会的立刻跳过。这一遍的产出是一张分布图,不是知识。第二、三天只碰后两类,第四天只碰仍然讲不出的,最后两三天留给模拟和表达。
    4. 要主动说出「只标记不纠结」这条纪律和它的失败模式:碰到第一道不会的题当场去补,一道题吃掉半小时,做到第 20 道今天就没了,剩下的题连颜色都没有。这个细节最能证明你真的这样练过。
    5. 再补一个判据:判断「会」的标准必须可证伪——出声、限时 90 秒、不看提纲。默读产生的流畅感是题库给的,不是你的。
    6. 可预期的追问:如果分诊发现红题集中在同一块怎么办?答案是先补那一块的**上游**概念,而不是逐题补——同一块里的题往往共用一个没吃透的前置,补上游一道题能带亮五道。

    How to reason about it · think before answering

    1. This sounds casual but it tests prioritization. The interviewer wants judgment, not diligence: the week is fixed, so how do you decide where it goes? 'Eight hours a day, start from the top' shows no judgment at all.
    2. Offer a reusable rule: the marginal value of reviewing a topic depends on how far you currently are from being able to explain it, so step one of any plan is measurement, not study. Planning without measuring is allocating a budget blindfolded.
    3. Concretely: day one is triage only — say every answer out loud and tag it green (can explain unaided), yellow (can explain with a glance at notes), or red (cannot). Skip reds immediately. The output of that pass is a distribution, not knowledge. Days two and three hit yellow and red, day four hits what is still red, and the last days go to mock interviews and delivery.
    4. Name the discipline and its failure mode: fixing the first red question on the spot burns thirty minutes, so by question twenty the day is gone and most of the set was never assessed. That detail is what proves you have actually done this.
    5. Add a falsifiable bar for 'I know it': out loud, ninety seconds, no notes. The fluency you feel while reading silently belongs to the author, not to you.
    6. Expect the follow-up: what if the reds cluster in one area? Fix the upstream concept first rather than the individual questions — clustered reds usually share one missing prerequisite, and repairing it lights up five questions at once.

    答题要点

    • 第一步是测量不是学习:先出声过一遍全部题目,只做三色标记,不当场补漏
    • 三遍递减:第一遍全量标记,第二遍只刷黄和红,第三遍只刷仍然红的,最后留时间给表达与模拟
    • 「会」的判据必须可证伪:出声讲、90 秒内讲完、不看提纲,默读不算
    • 分诊的产出是一张分布图,它决定后面几天该补技术还是补表达
    • 红题扎堆时先补共同的上游概念,比逐题补效率高得多

    Key points

    • Start by measuring, not studying: one spoken pass over everything, tagging only, no on-the-spot fixes
    • Three shrinking passes: tag everything, then only yellow and red, then only what is still red, leaving the tail for delivery practice
    • Make 'I know it' falsifiable: spoken, under ninety seconds, no notes — silent reading does not count
    • The triage pass produces a distribution that tells you whether the remaining days go to technique or to delivery
    • When reds cluster, repair the shared upstream concept rather than each question
  • 怎么把零散的知识点组织成一张便于复习的知识地图?How do you turn scattered knowledge into a map that is actually useful for review?
    国内高频海外高频进阶#knowledge-organization#interview-prep

    分析过程 · 先想清楚再作答

    1. 题眼在「便于复习」四个字。绝大多数人答成「按模块分类、画个思维导图」,那产出的是目录不是地图——目录任何一本书的前几页都有,它不能告诉你先补哪里。区分度就在这儿。
    2. 怎么拆:一张图有两种元素,节点和边。分层(节点怎么分组)是廉价的、几乎人人做得对;真正的信息量在边上。所以先问自己一个问题——我这张图上有几条边,每条边的含义是什么?答不上来就说明画的是目录。
    3. 给一条可操作的连边判据:只有当「不懂 A 就学不懂 B」时才连 A 指向 B。「A 和 B 都属于消息队列」不算,那是同层并列;「不理解上下文窗口就理解不了为什么要压缩」算。课程的先后顺序也不算——那是日历,不是依赖。
    4. 结论:地图的用法是把你的弱点涂上去。某个节点讲不清,先看它的上游是不是也红——是的话补上游,一次带亮一串。这就是地图相对清单的唯一优势:清单说哪里错了,地图说该从哪儿开始。
    5. 生产视角:这套东西在工作里同样有用。排查一个线上问题时,你脑子里那张「谁依赖谁」的图决定了你先看哪个服务的日志;没有这张图的人只能一个个试。面试时把这个类比说出来,会显得你不是为了背题才画图。
    6. 可预期的追问:那张图应该多大?答案是能在白板上 5 分钟画完——超过这个规模你会开始维护它而不是使用它,节点合并成主题,细节留在题库里。

    How to reason about it · think before answering

    1. The load-bearing phrase is 'useful for review'. Most answers become 'group things by module and draw a mind map', which produces a table of contents, not a map — a contents page cannot tell you what to fix first. That is where candidates separate.
    2. Break it down: a graph has nodes and edges. Grouping nodes is cheap and almost everyone does it correctly; the information lives in the edges. So ask yourself how many edges your diagram has and what each one means. No answer means you drew a contents page.
    3. Give an operational rule for edges: draw A to B only when not understanding A blocks understanding B. 'Both are about message queues' does not qualify — that is sibling grouping. 'You cannot understand context compression without the context window' does. Course order does not qualify either; that is a calendar, not a dependency.
    4. Conclusion: use the map by painting your weak spots onto it. If a node is shaky, check whether its upstream is shaky too — repair upstream and several downstream nodes light up at once. That is the map's one advantage over a checklist: a checklist says what is broken, a map says where to start.
    5. Production angle: the same habit pays off at work. When debugging an incident, the dependency graph in your head decides whose logs you open first; without it you probe services one by one. Saying this shows the map is a working tool, not an exam prop.
    6. Expect the follow-up: how big should it be? Small enough to redraw on a whiteboard in five minutes. Past that you start maintaining the map instead of using it — merge nodes into themes and leave the detail in your question bank.

    答题要点

    • 分层只是分组,任何目录都做得到;地图的信息量全部在边上
    • 连边的判据只有一条:不懂 A 就学不懂 B 才连边,同类并列和课程顺序都不算
    • 把弱项涂到节点上,红点扎堆时优先补上游节点,一次带亮一串下游
    • 跨层的长边最值钱,面试时顺着长边讲能体现体系,孤立节点只能给出零碎答案
    • 规模控制在白板 5 分钟能画完,再细的内容留在题库里而不是图上

    Key points

    • Grouping into layers is what any table of contents does; a map's information is in its edges
    • One rule for edges: draw one only when A is a genuine prerequisite for B — sibling topics and course order do not count
    • Paint your weak spots on the nodes and fix upstream first when reds cluster; one fix lights up several downstream nodes
    • Long cross-layer edges are the valuable ones — following them in an interview shows a system, isolated nodes only produce fragments
    • Keep it redrawable on a whiteboard in five minutes; finer detail belongs in the question bank, not the map