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#project-storytelling2#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#context-rot2#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#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
From Frontend Engineer to Agent Engineer in 30 Days
D27 Resume and Project Packaging: STAR, README, Architecture Diagrams, a Demo Video, an English Resume
Tell me about the most challenging project you have worked on. What made it hard?讲讲你做过的最有挑战的一个项目,难在哪里?
Common in ChinaCommon overseasDeep dive#behavioral#project-storytellingHow to reason about it · think before answering
- The hinge is the word 'challenging', and almost everyone falls into the same trap: treating 'a lot of work' as a challenge. Three months of overtime proves stamina, not judgment. The interviewer wants to see how you decide under incomplete information.
- Pick the story first, because it caps everything after it: choose the project where you can name what you gave up. Hard test — if your answer is only 'I did A and it worked', with no 'I chose A over B and paid C for it', pick a different project.
- Order the answer as difficulty, decision, cost, outcome — not chronologically. Chronology drags the listener through a diary; leading with the difficulty pins their attention on the first sentence. 'With three replicas consuming in parallel, one user's messages arrived out of order' beats 'the project started in March'.
- When describing the difficulty, explain why it could not be solved by reading the docs. Real challenges carry conflicting constraints: parallel replicas for throughput versus strict per-user ordering. Surfacing that conflict is what makes the difficulty credible.
- Do not end on pure success. Volunteer one sentence on what you would change today — this is the highest-signal line available on this question, because it shows you kept thinking after shipping.
- Expect: 'did you consider alternatives?' It is nearly guaranteed, so prepare the option you rejected and an engineering reason for rejecting it — latency, cost, operational load — never 'it just felt wrong'.
分析过程 · 先想清楚再作答
- 这题的题眼在「挑战」这两个字上,而它有一个几乎所有人都会踩的陷阱:把「工作量大」当成挑战。加了三个月班、写了两万行代码,这些证明的是耐力,不是判断力。面试官想看的是你在信息不足的情况下怎么做决定。
- 先做选题,这一步决定了后面的天花板:选那个**你能说出「我放弃了什么」**的项目。判据很硬——如果你的答案里只有「我做了 A,效果很好」,没有「我在 A 和 B 之间选了 A,代价是 C」,那这个项目就不适合回答这道题,换一个。
- 组织顺序建议用「困难 → 我的判断 → 代价 → 结果」,而不是时间顺序。时间顺序会把听众拖进流水账;从困难切入,第一句话就把对方的注意力钉住了。比如「三个副本同时消费的时候,同一个用户的消息顺序会乱」,比「这个项目是三月份开始的」有效得多。
- 描述困难时要给出「为什么这不是查一下文档就能解决的」。真正的挑战都带着约束冲突:既要多副本并行提高吞吐,又要同一用户严格保序——这两个诉求天然打架,所以才需要设计而不是查资料。把这层冲突讲出来,难度就立住了。
- 结果那部分不要只报成功。**主动说一句「现在回头看,我会改哪里」**,这是这道题上区分度最大的一句话。它表明你在项目结束之后还继续想过这件事,而不是交付完就翻篇了。
- 可以预期的追问:「当时有没有考虑过别的方案?」这几乎是必问。所以准备答案时要备好那个被你放弃的方案,以及放弃它的具体理由——理由要是工程性的(延迟、成本、运维复杂度),不能是「感觉那样不好」。
Key points
- Challenge means judgment, not volume — overtime and lines of code are not difficulty
- Pick a story where you can say 'I chose A over B and paid C for it'
- Structure it as difficulty, decision, cost, outcome — never as a chronological diary
- Name the conflicting constraints (parallel replicas versus strict per-user ordering) to make the difficulty real
- Close with what you would change today, and have the rejected alternative plus an engineering reason ready
答题要点
- 挑战 = 判断力,不是工作量;别拿加班和代码行数当难度
- 选题判据:这个项目你能说出「我在 A 和 B 之间选了 A,代价是 C」
- 按「困难 → 判断 → 代价 → 结果」组织,不要按时间顺序讲流水账
- 把约束冲突讲出来(比如既要多副本并行、又要同一用户保序),难度才立得住
- 结尾主动说「现在回头看我会改哪里」,并备好那个被放弃的方案和工程性的理由
Build an AI Short-Drama Production Pipeline With Agents in 14 Days
D14 A Five-Episode Season: Batch Production, Portfolio Packaging, and a Short-Drama Pipeline Interview Deep Dive
Walk me through the AI content pipeline you built. What was the hardest part?介绍一下你做的这条 AI 内容生产线,它最难的地方在哪?
Common in ChinaCommon overseasBasic#project-storytelling#system-designHow to reason about it · think before answering
- This is an open question that tests convergence. Narrating two weeks of work chronologically loses the interviewer in three minutes; delivering one through-line in thirty seconds is what counts as telling a project well.
- Open with positioning and scale: an automated pipeline from a one-line premise to publish-ready vertical episodes, one run producing a five-episode season, with humans stepping in only where judgement is required. Numbers first, detail second.
- Then answer hardest. That word should not be spent on debugging pain; spend it on a judgement that generates every downstream decision: video generation is the most expensive, slowest and most failure-prone stage at over ninety percent of per-episode cost, so the whole design revolves around issuing one fewer video call.
- Attach the chain of consequences in one sentence: idempotency and caching avoid duplicate calls, reference-image reuse reduces retries, the draft tier makes experimentation cheap, and the budget breaker stops a runaway. The chain proves your choices are derived rather than collected.
- Leave a deliberate hook for follow-up, such as saying the async task client turned out far harder than expected. That steers the interviewer toward your strongest material instead of a corner you never considered.
- Expect the follow-up: do you have real numbers? Keep four from every run: wall time, spend, failure rate and manual interventions. If spend is estimated, say so, rather than letting them assume you pasted a real invoice.
分析过程 · 先想清楚再作答
- 这是一道开放题,考的是收敛能力。把十四天的东西按时间顺序流水账讲一遍,面试官三分钟后就走神了;能在三十秒内给出一条主线,才算会讲项目。
- 开头两句要立住定位与规模:从一句话选题到多平台可发布成片的自动化流水线,一次运行产出一季五集,人只在需要判断的地方介入。数字先给,细节后给。
- 然后回答「最难」。这个词不该答成「调试很麻烦」,要答成一条能推出后续所有设计的判断:这条线上最贵、最慢、最容易失败的是视频生成,占单集成本九成以上,所以整套工程都是围着「怎么少调一次视频接口」转的。
- 接着一句话挂上推论链:幂等与缓存是为了不重复调,参考图复用是为了少试几次,草稿档路由是为了试错时用便宜规格,预算熔断是为了失控时能停住。这条链子证明你的技术选择不是攒来的最佳实践。
- 最后主动留一个可被追问的钩子,比如「异步任务的客户端比我预想的复杂得多」——把面试官引到你准备最充分的地方去,而不是等他随机挑一个你没想过的角落。
- 可预期的追问是「有真实数据吗」。所以复盘时必须留下四个数字:耗时、花费、失败率、人工介入次数。花费是估算的就要主动说明是估算,别让人以为你贴了张真实账单。
Key points
- Position first: from a one-line premise to multi-platform episodes, one run per five-episode season
- Frame the hardest part as a judgement: video dominates cost and is the slowest, most failure-prone stage
- Show the derivation chain: idempotency and caching, reference reuse, draft tier, budget breaker
- Bring four numbers: wall time, spend, failure rate, manual interventions, flagging estimates as estimates
- Plant a follow-up hook that steers the conversation to your strongest area
答题要点
- 先定位再展开:从一句话到多平台成片,一次运行产出一季五集
- 把最难点答成一条判断:视频占单集成本九成以上且最慢最易失败
- 用推论链证明设计是导出来的:幂等缓存、参考图复用、草稿档、预算熔断
- 带上四个数字:耗时、花费、失败率、人工介入次数,估算值要主动标注
- 主动留一个追问钩子,把话题引向准备最充分的部分