Dayward AI

Interview Bank

328 questions total; 1 shown with current filters.

Tag
361 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#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#llm-basics2#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#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#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

Mastering Codex and the OpenAI Agents SDK in 5 Days

D2 Codex, Level Up: Cloud Tasks, Code Review, MCP Integration, Custom Instructions, IDE Integration

  • A cloud coding agent can run many tasks in parallel with nobody around to approve steps. Where should its approval boundary sit?云端 coding agent 能同时跑很多任务,但没有人在旁边点头。它的审批边界应该画在哪里?
    Common in ChinaCommon overseasIntermediate#coding-agent#cloud#approvals

    How to reason about it · think before answering

    1. This checks whether you noticed the approval model changed: local means step-by-step approval, cloud means authorize upfront and review afterwards.
    2. Split the boundary across three moments: before the task (environment config decides network, variables, dependencies), during (container isolation), after (a human reviews the diff before any PR).
    3. Conclude that the cloud boundary is two gates, environment config plus pre-PR human review, with nobody in between; hence no production secrets, network off by default, merge rights stay human.
    4. Add the engineering angle: draw boundaries between parallel tasks too; tasks that touch the same files should not run concurrently.
    5. Expect the follow-up: can it auto-merge? Only in low-risk repos for fully green PRs, with rollback in place, and treat enabling auto-merge as a change that itself needs approval.

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

    1. 这题考的是你有没有意识到「审批模型变了」:本地是逐步审批,云端只能事先授权、事后审阅。答成「跟本地一样弹窗」说明没用过。
    2. 拆法是把边界分成三个时间点:任务开始前(环境配置决定能联网什么、有哪些变量、装什么依赖)、任务执行中(容器隔离,改动只在容器里)、任务结束后(人审 diff 再决定开不开 PR)。
    3. 结论是:云端的审批边界就是「环境配置 + PR 前人工审阅」这两道门,中间不再有人;所以生产密钥不能进环境、公网默认关、合并权限保留在人手里。
    4. 补一条工程视角:并行任务之间的边界也要画——互相会改同一批文件的任务不要同时派,否则合并成本吃掉并行收益。
    5. 可预期的追问:能不能让它自动合并?可以在低风险仓库对通过全部测试的 PR 这么做,但要保留回滚手段,并且把「自动合并」本身当成一个需要审批的配置变更。

    Key points

    • No step-wise approval in the cloud; the boundary becomes upfront environment config plus post-hoc human review
    • Keep production secrets out, network off by default, merge rights with humans
    • Draw boundaries between parallel tasks: never run file-overlapping tasks concurrently
    • Auto-merge only for low-risk repos with fully green PRs, with rollback ready

    答题要点

    • 云端没有逐步审批,边界变成事前的环境配置与事后的人工审阅两道门
    • 环境里不放生产密钥、公网默认关、合并权限保留给人
    • 并行任务之间也要画边界:会改同一批文件的任务不同时派
    • 自动合并只适用于低风险仓库且全绿的 PR,并保留回滚