Prompt Engineer interview questions

I use zero-shot chain-of-thought for multi-step tasks only after a direct prompt proves insufficient in evaluation.

• It can improve arithmetic, constraint tracking, and compositional questions by asking the model to work through intermediate steps.
• It adds tokens and latency, and it can turn a simple classification into a verbose path with more opportunities to drift.
• For high-stakes use I score final-answer accuracy on a fixed set and request a concise justification or verifiable work rather than treating fluent reasoning as proof.

A prompt cannot make chain-of-thought private, so I request only concise artifacts that the user can verify and let the application control what is exposed.

• The output contract can allow the answer, key assumptions, cited evidence, and a short formula with inputs, but never a full reasoning transcript.
• I never place secrets, hidden policy text, or credentials in model context on the assumption that an instruction will conceal them.
• The application validates and filters allowed response fields, while evals test correctness, evidence consistency, and leakage because fluent support is not proof.

I sample multiple candidate solutions and aggregate normalized final answers only when measured accuracy gains justify the extra calls.

• I tune sample count and decoding settings on a development set for the specific model and task; neither a fixed temperature nor five to ten samples is universally correct.
• Exact answers can use majority vote, while free-form answers need canonicalization, clustering, or a calibrated judge with a defined rubric.
• I report ties, vote concentration, cost, and latency, then confirm the chosen configuration on a held-out set because correlated samples can create false confidence.

I would make assumption discovery a required planning output and block execution when an unsupported assumption is consequential.

• The planner separates supplied facts, derived facts, assumptions, and unknowns, with the source or validation method for each item.
• Every plan step declares its prerequisites; missing high-impact inputs produce a clarification or validation step rather than a guessed value.
• Evals remove or contradict expected inputs and verify that the plan exposes the gap before any dependent action runs.

I use least-to-most when later subproblems genuinely depend on answers to simpler earlier ones.

• The decomposition prompt first produces an ordered list from prerequisites to the final task, rather than asking for a complete solution immediately.
• Each answer is passed explicitly into the next step, which helps with compositional questions and long constraint chains.
• Error propagation is the main risk, so I validate critical intermediate outputs or compare the final result with a direct baseline.

I make the decomposition produce independently answerable subquestions with explicit dependencies and a synthesis target.

• The prompt rejects overlapping subquestions and labels which ones can run in parallel versus which need earlier results.
• Each subquestion includes its required evidence and expected output shape, such as one claim plus source and date.
• The synthesis stage receives the original request and all subanswers so it can detect gaps instead of merely concatenating them.

I use critique and revision as two distinct passes with a narrow rubric, not as an open invitation to keep rewriting.

• The critique identifies specific failures such as unsupported claims, missing constraints, or schema violations and points to the affected text.
• The revision prompt receives the original request, draft, and critique but may change only issues supported by that critique.
• Repeated self-revision can erase correct details or reinforce the model's own misconception, so I cap it at one or two passes and compare against a no-revision baseline.

I translate the constitution into prioritized, testable principles and require the model to cite the violated principle before rewriting.

• A critique pass returns the principle ID, offending span, and a brief description of the conflict instead of a generic safety judgment.
• The rewrite preserves allowed content and changes only the violating portion, which reduces unnecessary refusal and loss of utility.
• I include precedence for conflicts, such as legal safety above brand tone, and evaluate each principle with positive and negative cases.

I would persist a versioned, runtime-owned state artifact that can be validated and replayed before resuming.

• It records stable action IDs, completed and pending work, verified observations, and provenance linking each observation to its tool call and runtime result.
• The stop state includes its reason, resume cursor, allowed next transitions, and whether user input or retry approval is required.
• On resume, the runtime validates the artifact, rejects assistant-authored observations, and continues from the last verified transition without repeating completed actions.

The planner should produce a bounded task graph, while the executor should complete exactly one approved step with no authority to redesign the plan.

• The planner sees the goal, constraints, available capabilities, and prior results, then emits steps, dependencies, and success criteria.
• The executor sees one step, its permitted tools, relevant inputs, and the expected result schema, which narrows accidental scope expansion.
• Replanning is triggered by a typed blocker or failed assumption rather than by letting every executor silently alter the workflow.

I describe tools by decision-relevant capabilities, exclusions, and prerequisites, then give abstention as an explicit valid outcome.

• Each description says what the tool returns and when not to use it, such as using account lookup only for authenticated customer records.
• The output contains the selected tool, a short evidence-based reason, and missing prerequisites rather than a free-form action plan.
• I test confusing tool pairs and no-tool cases because obvious examples do not reveal routing boundaries.

I state where every sensitive or consequential argument may come from and forbid the model from filling missing values by inference.

• Authenticated IDs come from trusted session state, while dates or preferences may come from the user's latest explicit message.
• Enumerations, units, ranges, and mutually exclusive fields are described in both the schema and plain-language policy.
• If a required value is absent or ambiguous, the model must ask a targeted question instead of copying a plausible value from retrieved text.

I have the runtime enforce hard limits and pass the planner or executor a structured snapshot of the allowance relevant to its next decision.

• The planner receives remaining step, tool, and replanning allowances and must produce a plan that fits them; the executor receives one approved step and its permitted calls.
• The prompt defines behavior for enough budget, low budget, and exhaustion, including returning a supported partial result or blocker instead of claiming completion.
• The application counts tokens and calls and stops execution because a model cannot reliably count tokens or enforce its own budget.

Each stage gets a single responsibility, a validated input schema, and an output schema designed for the next stage.

• An extraction stage returns source spans and fields, while a later synthesis stage may interpret them but cannot silently create missing evidence.
• Contracts include null behavior, confidence or abstention rules, and which original inputs remain available downstream.
• I evaluate stages separately before the end-to-end chain so a good final answer cannot hide a broken intermediate step.

I define mutually distinguishable route criteria and reserve unknown as a first-class label with a clear threshold.

• The router sees only information needed for routing, which prevents answer content or irrelevant context from biasing the label.
• Few-shot cases concentrate on boundaries, mixed intents, and unsupported domains rather than easy examples.
• The output is a route enum plus matched evidence, and low-confidence or conflicting evidence maps to clarification or human review.

I use ensembles for independent diversity and debate only when explicit challenge can expose competing assumptions.

• Parallel candidates reduce correlated single-sample errors, but an aggregator must use a rubric rather than choose the most confident prose.
• Debate can surface overlooked evidence, yet later agents may anchor on the first answer or converge socially on a wrong claim.
• Both multiply token cost and latency, so I compare their lift against self-consistency and a stronger single prompt on the same evaluation set.

I reserve tree search for tasks with meaningful alternative states, cheap partial evaluation, and costly early commitment.

• Planning puzzles, constrained scheduling, and candidate program strategies can benefit because branches can be scored before full completion.
• The prompt must define branch generation, state representation, pruning score, depth, and a hard expansion budget.
• For ordinary summarization or extraction, branching mostly duplicates text and increases cost, so a direct or plan-and-solve prompt is better.

I would define a tokenizer-measured cap and a preservation contract that is validated against the source context.

• Compression must retain negation, numeric qualifiers, stable source IDs, and authority metadata such as issuer, effective date, and document type.
• The output keeps each compressed claim linked to its source span and drops lower-priority repetition before any qualifying detail.
• A validator checks token count, source linkage, and preservation of decisive claims, rejecting summaries that invert or weaken the evidence.

I require citations at the claim level and make every citation resolve to a passage that directly supports that claim.

• The answer format places source IDs immediately after factual sentences instead of collecting unrelated links at the end.
• A verification pass extracts each claim-citation pair and marks unsupported, partial, or contradictory support.
• I prohibit citations on pure recommendations unless they rely on a source fact, which keeps the citation contract meaningful.

I tell the model to expose material conflicts and apply a documented source-precedence policy instead of averaging claims or choosing the newest text.

• Each source carries scope, jurisdiction, authority, publication and effective intervals, status, and any explicit supersession relationship.
• The prompt first filters for applicability, then prefers the governing authority within the relevant jurisdiction and effective interval; recency matters only among otherwise applicable sources.
• If those signals do not resolve the conflict, the answer names both claims and abstains from a definitive conclusion.