Advanced Prompting Techniques

prompt-engineering covers the fundamentals: the system/user split, few-shot examples, a first pass at chain-of-thought, structured outputs, and prompt versioning. That subject stops at "ask the model to think step by step and give it a few examples of the target format." This subject picks up exactly where it leaves off — the wider set of techniques that exist because "think step by step" is a blunt instrument, and a senior AI engineer is expected to know the sharper ones, what each one actually buys mechanically, and — just as important — when reaching for it is a waste of tokens and latency for no measured gain.

The pattern across every technique below is the same one prompt-engineering establishes for basic CoT: none of these are free, none of them are magic, and all of them trade some combination of tokens, latency, and engineering complexity for a shot at higher accuracy on a specific class of task. Decomposition and self-consistency spend more inference-time compute on tasks that genuinely benefit from more computation. ReAct spends turns interleaving reasoning with real actions instead of trying to reason a whole answer in one shot. Tree- and graph-of-thought spend an order of magnitude more compute doing something close to search. Persona prompting and meta-prompting spend engineering time instead of tokens, and are far more often folklore than mechanism. And the newest wave — reasoning models with extended, budgeted thinking — spends a provider-controlled compute budget in place of the CoT instructions you used to have to write by hand, which changes what "prompting well" even means for those models.

Interviewers probe this layer specifically because it's where candidates start reciting technique names without being able to say what each one costs or when it's the wrong call. "I'd use tree-of-thought" is not an answer; "this task has a large, mostly-invalid search space where wrong intermediate steps are cheap to detect and backtrack from, so paying 10–20x the tokens of a single chain for exploration is worth it here, but it would not be worth it on a task with a single correct chain of reasoning" is. That is the register this subject is written in throughout — mechanism first, cost stated in real terms (tokens, calls, latency), and an explicit answer to "when would you not use this."

Three things a strong answer keeps separate for every technique below:

• What it mechanically does — more tokens, more calls, more search, or a different conditioning signal, stated in terms of the underlying model, not the technique's marketing name.
• What it costs — in tokens, calls, and latency, ideally as an actual multiplier against a single-shot baseline, not "it's more expensive."
• The task shape that earns the cost — the concrete property of a task (verifiable answer, real dependency chain, genuine search space, need for live information) that determines whether the technique's cost is worth paying at all.