You ask an AI to help you prepare for an interview. You get back twenty generic questions you could have found on any blog.
You ask again. This time you mention that you are an entry-level developer, that you know the MERN stack, and that you want the answers in a table. Suddenly it is useful.
Same model. Same knowledge. Different prompt.
That gap, between the generic answer and the useful one, is what prompt engineering is about.
AI has been with us far longer than most people realise. Ever wondered how your mobile keyboard suggests the next word while you are typing? That is AI too, just a very narrow use case of it.
Compare that with today's AI, which can answer our day-to-day questions, help with our tasks, generate articles, taglines and summaries, and even produce images and video, all from a simple text instruction.
That instruction is known as a prompt.
Now take a child as an example. When they are young, they speak gibberish which is hard to understand. But as they grow up, they communicate better, and it becomes easier to understand what they want.
A similar idea applies to Generative AI. If our instructions are unclear, the AI may misunderstand our requirement and produce a result that is off-target, irrelevant, or incomplete.
So how do we communicate with AI more effectively?
That is where prompt engineering comes in.
Prompt engineering is a method of writing prompts in a structured manner so that we provide the AI with the required information, relevant context, examples, and clear instructions.
This helps the AI generate a result that is closer to our expectations.
We can also use prompt chaining, where we break a big task into steps and feed the output of one prompt into the next.
Although there isn't one specific rule for creating the perfect prompt, a structure taught in Google's prompting course that may be useful is TCREI:
T — Task
C — Context
R — References
E — Evaluate
I — Iterate
Let's understand each of them.
This is where we specify the task we want the AI to perform.
It can be:
The task is the main instruction, the one thing you want the AI to do.
It can also have two additional parts.
Here we associate a role or personality with the AI, so that it approaches the task from that perspective.
For example: Assume you are a software developer with 15 years of experience.
Or:
Assume you are a store manager with 10 years of experience.
A persona reliably changes how the answer is written: the vocabulary, the depth, and what the model assumes you already know. "Explain this as a senior developer would" and "explain this as a teacher would" produce genuinely different answers.
What a persona does not do is make the model know more. "You are an expert cardiologist" does not add medical knowledge it did not already have. Use a persona to shape the framing, not to buy accuracy.
It is also a good idea to specify the format in which we want the result.
Give me a table with five points.
Provide the answer in three paragraphs.
Format the output as CSV with the columns: Question, Topic, Difficulty, Answer.
This helps us get an output that is more useful and closer to what we actually need.
Context is important for AI because it helps create the background related to the task.
It is just like the background we provide before narrating a story to someone.
Imagine this prompt:
Analyze the given data and generate a profit and loss summary.
Good. But it only tells the AI what to do. It doesn't tell it much about the situation.
Now consider this:
Here is a company's sales data for the last year, including revenue, purchases, salaries, and other operating expenses. Analyze it and give me a profit and loss summary as a table.
Here we have also provided a background related to the task. This makes the requirement more specific and gives the AI additional information it can use.
Prompt 2 gives the AI something to work with. Prompt 1 makes it guess.
"References" actually covers two different things, and they are worth separating.
One is examples, where we show the pattern we want. The other is source material, where we paste in the actual document, spec, or data the answer should come from.
The second one is powerful. The model cannot make up an answer if you hand it the real one.
Let's look at examples first, since that is where most of the technique lives.
Instead of simply saying:
Explain React.
We can provide an example of the expected format:
Define React → Answer
How React works → Answer
What is ES6 → Answer
Now the AI has a reference for how we want the output to look.
There are different variants of prompting based on how many examples we provide.
In this approach, we don't provide any example. The AI has to rely on its pre-trained knowledge and the instruction we gave it.
Explain what React is in simple terms.
There is no example here.
Zero-shot works well for simple, direct questions and everyday tasks. When the output isn't coming back in the shape you want, that is the signal to start adding examples.
In this approach, we provide one example in the prompt. The example acts as a blueprint for the desired output.
Convert the following sentence into a professional tone.
Example:
"Hey, send me the report ASAP." → "Please share the report at your earliest convenience."
Now convert:
"Hey, fix this issue quickly."
Here the AI can understand the expected transformation from the single example.
In this case we provide multiple examples so that the AI can identify the pattern and generate the expected output.
React → Frontend Library
Express → Backend Framework
MongoDB → Database
Node.js → ?
The AI picks up the pattern and answers "JavaScript Runtime".
Though watch out for something here. My three examples were all library, framework and database, so a model following that pattern too literally might answer "Backend Framework", which is wrong. Node.js is a runtime.
That is the real risk with few-shot: examples don't just show the format, they bias the answer. Choose examples that cover the range of answers you actually expect.
One more thing on quantity. Providing irrelevant or contradictory information hurts, because the model has no way to know which parts to trust. But good examples generally don't. The old advice was "two to five examples, no more", and that was reasonable when context windows were small. With today's much larger context windows, more consistent examples usually help rather than hurt.
So the goal is not fewer examples, and not more examples. It is consistent, relevant examples.
By this point we have the output generated by the AI.
Now our task is to evaluate whether it meets our requirements and follows the instructions in the prompt.
This is a crucial stage. We should check things like:
Did the AI perform the correct task?
Did it follow the requested format?
Is the information relevant?
Is anything missing?
And the one that matters most:
Is it actually correct?
A well-formatted, on-topic, confident answer can still be wrong. If the output contains facts, figures, version numbers, or API details you are going to rely on, check them somewhere else.
This evaluation becomes especially important when we continue the conversation using the generated result as context. If we don't identify problems early, we end up building on an incorrect result.
Now we have evaluated our result. If the result is what we wanted, we are done.
But if something went wrong, this is where we correct the AI. We tell it what went wrong and what we want instead.
The format is correct, but you included unnecessary technical details. Keep the explanation beginner-friendly and limit it to five points.
This also gives us an opportunity to improve our own prompt, because sometimes the problem is not with the AI. Sometimes we simply didn't provide enough information, context, or clear instructions in the first place.
So prompt engineering is also an iterative process.
Let's put everything together.
Suppose I am preparing for a frontend interview. I could give the AI a prompt like this:
You are a senior software developer with 10 years of experience.
I want you to help me prepare for my upcoming frontend interview. I am an entry-level developer with MERN stack experience and basic AWS knowledge.
List the questions I am most likely to be asked based on current frontend interview trends.
Format the output as CSV with the columns: Question, Topic, Difficulty, Answer.
Use the following examples to understand the type of questions I am looking for: Define React → Answer
How does React work? → Answer
What is ES6? → Answer
Now look at what we have included:
Persona: Senior software developer with 10 years of experience.
Task: Help with frontend interview preparation.
Context: Entry-level, MERN expertise, basic AWS knowledge.
Format: CSV with specific columns.
References: Examples of the expected questions.
Now notice one weak spot in my own prompt. I asked for "current trends". Unless the tool I am using has web search turned on, the model has no idea what is current. It will produce something plausible from its training data and present it confidently.
This is exactly the EVALUATE step doing real work. I should either turn on web search, paste in a few recent job descriptions as source material, or drop the word "current" and accept that I am getting general fundamentals.
That is the whole idea.
The TCREI structure covers the bulk of it, but a few smaller habits make a noticeable difference.
Separate your instructions from your data. If you are pasting in a long document, wrap it so the model knows where your instruction ends and the content begins:
Summarize the document below in five bullet points.
--- DOCUMENT ---
(paste here)
--- END DOCUMENT ---
Without a separator, the model can read your pasted content as part of the instruction.
Say what you want, not what you don't. "Don't use jargon" performs worse than "use plain language a first-year student would understand." Positive framing consistently beats negative framing.
"Think step by step" is no longer a universal trick. It used to be the single most-cited prompting tip. On today's reasoning models, which already work through problems internally, it is often redundant and can occasionally make things worse by forcing a rigid structure. Try the prompt without it first.
Prompt engineering is not about writing extremely complicated prompts.
It is about communicating clearly with AI.
The more clearly we communicate our task, context, references, expectations, and desired format, the easier it becomes for the AI to produce a useful result.
TCREI is one framework that can help us structure that communication:
Task → Context → References → Evaluate → Iterate
And whatever the prompt, always verify the parts you are going to rely on.
This is a small guide on prompt engineering. I hope you found it helpful.
Until next time.
Peace ✌️