Dayward AI

Interview Bank

328 questions total; 2 shown with current filters.

Tag
362 more 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-storytelling

    How to reason about it · think before answering

    1. 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.
    2. 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.
    3. 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'.
    4. 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.
    5. 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.
    6. 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'.

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

    1. 这题的题眼在「挑战」这两个字上,而它有一个几乎所有人都会踩的陷阱:把「工作量大」当成挑战。加了三个月班、写了两万行代码,这些证明的是耐力,不是判断力。面试官想看的是你在信息不足的情况下怎么做决定。
    2. 先做选题,这一步决定了后面的天花板:选那个**你能说出「我放弃了什么」**的项目。判据很硬——如果你的答案里只有「我做了 A,效果很好」,没有「我在 A 和 B 之间选了 A,代价是 C」,那这个项目就不适合回答这道题,换一个。
    3. 组织顺序建议用「困难 → 我的判断 → 代价 → 结果」,而不是时间顺序。时间顺序会把听众拖进流水账;从困难切入,第一句话就把对方的注意力钉住了。比如「三个副本同时消费的时候,同一个用户的消息顺序会乱」,比「这个项目是三月份开始的」有效得多。
    4. 描述困难时要给出「为什么这不是查一下文档就能解决的」。真正的挑战都带着约束冲突:既要多副本并行提高吞吐,又要同一用户严格保序——这两个诉求天然打架,所以才需要设计而不是查资料。把这层冲突讲出来,难度就立住了。
    5. 结果那部分不要只报成功。**主动说一句「现在回头看,我会改哪里」**,这是这道题上区分度最大的一句话。它表明你在项目结束之后还继续想过这件事,而不是交付完就翻篇了。
    6. 可以预期的追问:「当时有没有考虑过别的方案?」这几乎是必问。所以准备答案时要备好那个被你放弃的方案,以及放弃它的具体理由——理由要是工程性的(延迟、成本、运维复杂度),不能是「感觉那样不好」。

    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-design

    How to reason about it · think before answering

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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.

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

    1. 这是一道开放题,考的是收敛能力。把十四天的东西按时间顺序流水账讲一遍,面试官三分钟后就走神了;能在三十秒内给出一条主线,才算会讲项目。
    2. 开头两句要立住定位与规模:从一句话选题到多平台可发布成片的自动化流水线,一次运行产出一季五集,人只在需要判断的地方介入。数字先给,细节后给。
    3. 然后回答「最难」。这个词不该答成「调试很麻烦」,要答成一条能推出后续所有设计的判断:这条线上最贵、最慢、最容易失败的是视频生成,占单集成本九成以上,所以整套工程都是围着「怎么少调一次视频接口」转的。
    4. 接着一句话挂上推论链:幂等与缓存是为了不重复调,参考图复用是为了少试几次,草稿档路由是为了试错时用便宜规格,预算熔断是为了失控时能停住。这条链子证明你的技术选择不是攒来的最佳实践。
    5. 最后主动留一个可被追问的钩子,比如「异步任务的客户端比我预想的复杂得多」——把面试官引到你准备最充分的地方去,而不是等他随机挑一个你没想过的角落。
    6. 可预期的追问是「有真实数据吗」。所以复盘时必须留下四个数字:耗时、花费、失败率、人工介入次数。花费是估算的就要主动说明是估算,别让人以为你贴了张真实账单。

    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

    答题要点

    • 先定位再展开:从一句话到多平台成片,一次运行产出一季五集
    • 把最难点答成一条判断:视频占单集成本九成以上且最慢最易失败
    • 用推论链证明设计是导出来的:幂等缓存、参考图复用、草稿档、预算熔断
    • 带上四个数字:耗时、花费、失败率、人工介入次数,估算值要主动标注
    • 主动留一个追问钩子,把话题引向准备最充分的部分