Interview Bank
328 questions total; 2 shown with current filters.
CourseAllFrom Frontend Engineer to Agent Engineer in 30 DaysPrompt Engineering From Scratch in 5 DaysMastering Claude: From Conversation to Claude Code in 5 DaysMastering Codex and the OpenAI Agents SDK in 5 DaysMCP in 7 Days: Wire Tools Into Any AgentAgent Skills in 7 Days: Turn Experience Into Reusable CapabilityContext Engineering in 5 DaysRAG in 14 Days: From Retrieval to Trustworthy AnswersBuild an AI Short-Drama Production Pipeline With Agents in 14 Days
Tag
All#context-rot2#evaluation30#cost29#reliability24#architecture22#agent-skills21#security18#observability15#streaming12#error-handling11#idempotency10#system-design10
362 more tagsShow fewer tags
#api-design9#coding-agent9#distributed-systems8#multi-agent8#rag8#chunking7#debugging7#pipeline-design7#structured-output7#agent-loop6#mcp6#operations6#prompt-injection6#sse6#tool-calling6#tool-design6#context5#context-engineering5#deployment5#embeddings5#hybrid-search5#message-bus5#scheduling5#system-prompt5#agentic-rag4#behavioral4#client4#concurrency4#consistency4#framework-design4#ingestion4#prompt-engineering4#rate-limiting4#retrieval4#routing4#trade-offs4#abstention3#agents-sdk3#caching3#communication3#context-window3#cost-control3#data-quality3#failure-modes3#image-generation3#interview-prep3#langgraph3#latency3#llm-as-judge3#llm-basics3#long-context3#model-migration3#model-routing3#orchestration3#ordering3#progressive-disclosure3#prompt-basics3#prompt-caching3#protocol3#provider-abstraction3#ranking3#recall3#redis-streams3#responses-api3#resume3#retry3#runtime3#scalability3#skills3#state-management3#statelessness3#subagents3#timeline3#versioning3#workflow-engine3#access-control2#agent-design2#async-task2#auth2#checkpointing2#citation-verification2#citations2#claude-md2#code-review2#compaction2#contextual-retrieval2#cost-tradeoff2#data-modeling2#database2#distribution2#fallback2#ffmpeg2#golden-set2#grounding2#interview-process2#long-term-memory2#media-pipeline2#memory2#multi-hop2#multi-tenancy2#oauth2#prioritization2#project-storytelling2#prompt-techniques2#query-rewriting2#react2#refusal2#reproducibility2#rerank2#retrieval-quality2#retrospective2#scripts2#sharding2#state-machine2#tool-permissions2#tooling2#tools2#tracing2#transport2#tts2#ux2#vector-database2#verification2#workflow2#agent-basics1#agent-quality1#agent-sdk1#agents-md1#altitude1#analytics1#approvals1#architecture-review1#async1#atomicity1#attention-budget1#av-sync1#backoff1#bi-encoder1#bm251#budget-control1#build-vs-buy1#cancellation1#candidate-selection1#capacity-planning1#career1#chain-of-thought1#ci1#circuit-breaker1#claude-code1#cli-design1#client-integration1#cloud1#compliance1#compression1#configuration1#confused-deputy1#consistent-hashing1#content-hash1#content-safety1#context-assembly1#context-compression1#context-management1#copyright1#coreference1#correctness1#cost-accounting1#cost-analysis1#cost-optimization1#cross-encoder1#cross-model1#customer-support1#dag1#decision-making1#decomposition1#degradation1#deliberate-practice1#design1#diagnostics1#dimensions1#docker1#documentation1#embedding-migration1#encoding1#engineering-judgement1#engineering-tradeoffs1#error-propagation1#escalation1#eval1#event-driven1#evidence1#failure-analysis1#fairness1#faithfulness1#fan-out1#feedback-loop1#fencing-token1#few-shot1#filter-pushdown1#filtering1#fine-tuning1#forking1#four-elements1#framework-selection1#frontend1#global-market1#graph-rag1#guardrails1#hallucination1#handoff1#handoffs1#headless1#hnsw1#hooks1#human-in-the-loop1#hybrid1#hyde1#incremental-recompute1#incremental-sync1#index-maintenance1#index-routing1#indexing1#information-retrieval1#instruction-hierarchy1#integration1#intent-routing1#interrupt-merge1#invalidation1#isolation1#iterative-scan1#ivfflat1#json-parsing1#json-schema1#just-in-time1#jwt1#knowledge-organization1#labeling1#latency-budget1#lease1#least-privilege1#llm-output-quality1#long-session1#loop-guard1#maintenance1#mcp-basics1#mental-model1#messages-api1#metadata1#methodology1#metrics1#migration1#mobile1#model-selection1#moderation1#modularity1#multi-turn1#multimodal1#nodejs1#normalisation1#notifications1#ocr1#offline-testing1#openai1#overlap1#pagination1#parent-child1#pdf-parsing1#performance1#permissions1#persistence1#pgvector1#pipeline-reliability1#portfolio1#primitives1#priority-queue1#proactive-messaging1#product-engineering1#production-readiness1#prompt1#prompt-assembly1#prompt-bloat1#prompt-design1#prompt-limits1#prompt-surface1#prompt-template1#prompt-versioning1#prompting1#protocol-versions1#quality1#quality-check1#quantization1#query-transformation1#quiet-hours1#rag-basics1#rank-fusion1#reasoning1#reconnect1#redis1#reflection1#replay1#reporting1#retrieval-failure1#retrieval-metrics1#retry-semantics1#retry-strategy1#review1#risk-assessment1#rollback1#rollout1#rrf1#safety1#sampling1#sandbox1#sandboxing1#scaling1#schema-design1#schema-validation1#scoping1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#self-reflection1#server-design1#service-architecture1#session-management1#sessions1#similarity1#skill-authoring1#skill-description1#skill-design1#spec1#split-brain1#stakeholder-communication1#star1#state-persistence1#stateless1#stdio-transport1#stopping-criteria1#storytelling1#subagent1#subscriptions1#subtitles1#task-graph1#team-governance1#test-set1#test-strategy1#testing1#thresholds1#timezone1#token-accounting1#token-budget1#tool-budget1#tool-execution1#tool-naming1#tool-schema1#trust-boundary1#tuning1#validation1#vector-index1#workflow-design1#xml-tags1#zero-downtime1
Context Engineering in 5 Days
D1 Context Is the Scarcest Resource: the Window, Attention Decay, and Cost — From Prompt Engineering to Context Engineering
Context windows keep growing. Why not just put everything potentially relevant into the prompt?窗口越来越大了,为什么不能把所有可能有用的资料都塞进去?
Common in ChinaCommon overseasIntermediate#context-rot#attention-budget#costHow to reason about it · think before answering
- The hinge is whether you treat the window as capacity or attention as a budget. Answering only with cost reads as inexperience, since cost is the easiest and least dangerous of the three bills.
- Split into capability and cost. On capability, name context rot: recall accuracy degrades as context grows, rooted in the n-squared pairwise relationships a transformer maintains over n tokens, plus the fact that long-range parameters are underrepresented in training.
- Stress that this is a gradient, not a cliff. No specific length breaks; every thousand irrelevant tokens shaves a little accuracy. That phrasing distinguishes people who read primary sources.
- On cost, give three bills: money (the model is stateless, so every turn resends everything and the total is cumulative, not the last call), latency (slower time to first token), and accuracy (irrelevant content dilutes attention). The third is worst because it never raises an error, it just returns a plausible answer that violates a stated constraint.
- Expect the follow-up: how do you decide whether a given chunk earns its place? Give an operational test: if you cannot name the specific decision it changes, it does not go in.
分析过程 · 先想清楚再作答
- 这题的题眼是「你知不知道窗口是容量、注意力是预算」。只回答「太贵了」的人会被判成没做过工程,因为成本是三笔账里最容易想到、也最不致命的一笔。
- 怎么拆:分成能力和代价两条线。能力这条线要点出上下文腐烂——随着上下文变长,模型准确回忆其中信息的能力会下降,根源在于 Transformer 里 n 个 token 有 n 平方级别的两两关系,注意力被摊薄;而且训练语料里长序列本来就少,处理长距离依赖的参数不够多。
- 关键是要强调它是一条缓坡不是一道悬崖:没有哪个长度会突然崩掉,每多塞一千个不相干的 token,正确率就低一点点。这个措辞能立刻区分读过一手材料的人。
- 代价这条线给三笔账:钱(模型无状态,每轮全量重发,总输入是累加值不是最后那次的值)、延迟(首字返回变慢)、正确率(无关内容稀释注意力)。第三笔最贵,因为它不会报错,只会给出看起来合理但违反了约束的回答。
- 可预期的追问:那你怎么判断某段内容该不该加?给一条可执行的判据——说不出它会改变模型哪一个具体决定,就不该加。
Key points
- The window is capacity; attention is the budget. Fitting is not the same as being used well.
- Context rot: recall degrades as context grows, as a gradient rather than a hard cliff.
- Three bills: money (stateless models resend everything each turn, so cost is cumulative), latency, and accuracy.
- Accuracy is the dangerous one because it fails silently with plausible answers that break stated constraints.
- Test: if you cannot name the specific decision a chunk changes, leave it out.
答题要点
- 窗口是容量,注意力是预算;容量够不代表模型用得好。
- 上下文腐烂:上下文越长,准确回忆的能力越差,是渐进的性能梯度而不是一道悬崖。
- 三笔账:钱(每轮全量重发,成本是累加值)、延迟、正确率。
- 正确率那一笔最危险,因为它不报错,只会给出看似合理却违反约束的回答。
- 判据:说不出这段内容会改变哪一个具体决定,就不该放进去。
D4 Long-Running Sessions: Compression, Notes and Memory Files, Subagent Isolation and Handoff Summaries
When should you compact the context, and when should you just move to a larger context window?什么时候该压缩上下文,什么时候该直接换一个更大的窗口?
Common in ChinaCommon overseasIntermediate#compaction#context-rotHow to reason about it · think before answering
- This checks whether you treat the window as capacity and attention as a budget. Answering only that you compact when it does not fit misses half the cases, since plenty of sessions should be compacted while the window is still mostly empty.
- Separate the two problems. Not fitting is capacity, and a bigger window fixes it. But a bigger window does not fix context rot: recall degrades as context grows, on a gradient, so a large nominal window is not a promise of stable behavior at that length. Fitting and being used well are different.
- Give the test: watch two signals, not one. High window occupancy means compact for capacity. Low occupancy with a low share of actually-useful tokens also means compact, for attention. The second is the one people miss because nothing looks urgent.
- Then order the tactics. Compaction is not the first move. Clear stale tool results first, since that needs no model call, is deterministic, and is reversible. Only then summarize history. Doing it the other way costs an extra call and risks losing information while usually treating the smaller bucket.
- Expect the follow-up: when is compaction itself not enough? When the state is an accumulating ledger rather than a summarizable conclusion, such as exact tallies, maps, or a long-term plan. Those belong in files outside the window.
分析过程 · 先想清楚再作答
- 这题在考你有没有把窗口当容量、把注意力当预算。只回答「窗口不够就压缩」的人漏掉了一半——很多时候窗口还很空,但已经该压了。
- 怎么拆:先把两个问题分开。窗口不够是容量问题,换大窗口确实能解决;但换大窗口解决不了上下文腐烂——上下文越长模型准确回忆的能力越差,这是一条缓坡,标称窗口大不等于在那个长度上表现稳定。所以「装得下」和「用得好」是两件事。
- 给判据:看两个指标而不是一个。窗口占用率高就该压(容量问题);占用率不高但有效信息占比很低,也该压(注意力问题)——后者最容易被忽略,因为看起来毫无压力。
- 再给顺序上的结论:压缩不是第一手段。先清掉旧的工具结果(不用调模型、确定、可逆),不够再摘要历史。反过来做的人很多,因为摘要听起来更高级,但摘要要多花一次调用、要承担丢信息的风险,而它治的往往不是大头。
- 可预期的追问:那什么时候压缩也不够?当状态是渐进积累的账本而不是可总结的结论时——比如精确计数、地图、长期计划。这类东西要写到窗口外面的文件里,不能靠摘要保住。
Key points
- Not fitting is capacity and a larger window solves it; context rot is attention and a larger window does not.
- Two triggers: high window occupancy, or low occupancy with a low share of useful tokens.
- Clear stale tool results first (no model call, deterministic, reversible), then summarize history.
- If the state is an accumulating ledger such as tallies, maps, or a plan, use external files instead of compaction.
答题要点
- 窗口不够是容量问题,换大窗口能解决;上下文腐烂是注意力问题,换大窗口解决不了。
- 两个触发信号:窗口占用率高,或占用率不高但有效信息占比很低。
- 顺序上先清旧工具结果(不调模型、确定、可逆),不够再摘要历史。
- 如果状态是渐进积累的账本(计数、地图、长期计划),压缩救不了,要写到窗口外的文件里。