AI & Prompt Engineering for Freshers

Week 1 — the mental model, including the limits. Everything in the rest of the course depends on this honesty.

1. Next-token prediction, in plain words

   The model predicts a likely next piece of text from everything before it. It has no database it looks facts up in and no way to know, by itself, that it has invented something.

   Example That single sentence explains why the same question can get two different answers, why it will confidently name a book that does not exist, and why asking it to cite sources is not the same as asking it to be right.

   Practice Ask the same factual question three times, note the differences, then verify each answer against a source you trust and write down which was wrong.

2. What they are good at and where they confidently fail

   Strong at shaping, summarising, rewriting, translating, generating examples and explaining a concept six ways. Weak at recent facts, exact numbers, citations, private information and anything requiring accountability.

   Example Using it to turn your bullet points into a professional summary is a good use. Asking it for the current cutoff date of an exam, or a company's exact hiring process, is how a wrong answer ends up on a resume.

   Practice Write two lists from your own life: five tasks you will now hand to an AI assistant, and five you will never hand over without a human check.

3. Privacy: what you may never paste in

   A chat window is a third party. Customer names, phone numbers, financial data, source code you do not own and anything covered by an NDA stay out — no matter how convenient the rewrite would be.

   Example Removing a name and rephrasing is not anonymising when the details still identify one person. The professional habit is to paste the structure and none of the specifics.

   Practice Take a real document, remove everything identifying, and write down exactly what you removed and why — that note is what you repeat when a colleague pastes something they should not.

Weeks 2–3 — how to get a usable answer the first time, and a repeatable one the second time.

1. Context, constraints and the output shape

   Three parts turn a wish into an instruction: who the answer is for and why, the limits it must respect, and the exact format you want back. "Write a cover letter" has none of them.

   Example "You are helping a fresher with no experience apply for a support role. Maximum 150 words, no clichés about passion, end with one sentence about the night-shift availability the ad mentions. Output as three paragraphs" is a prompt. The constraints are most of the work.

   Practice Take a vague prompt you have used before and rewrite it with all three parts. Compare the two outputs and note exactly what changed.

2. Few-shot examples and role framing

   Showing two examples of what you want is often worth more than a paragraph describing it. Role framing works the same way: it sets the register and the level of detail before the question arrives.

   Example Pasting two of your own good answer sheets and asking for a third in that style gives output in your voice. Asking the same question cold gives output in everyone else's.

   Practice Give the model two examples of a bug report you wrote and have it produce a third, then edit the result yourself and compare how much editing was needed.

3. Iterating: the second prompt is the real one

   The first answer is a draft, not a verdict. Saying what is wrong with it — too long, too generic, missing the number — is a specific skill, and it is where most people give up and decide the tool is bad.

   Example "Shorter, remove the phrase passionate about, and add the specific project I mentioned" produces a usable second draft. "No, try again" produces a third draft of the same thing.

   Practice Take one output through five rounds of specific feedback and save both the prompt chain and the final result.

Week 4 — a small, honest tool of your own. This is the week that turns the course into evidence.

1. A study assistant for your own syllabus

   A useful assistant answers from YOUR notes rather than from general memory. That is what "grounding" means, and it is the difference between a toy and a study tool.

   Example Pasting a unit of your own notes and asking for ten questions with answers, in your syllabus's wording, gives revision material you can actually use the night before. Asking generally gets questions from a different syllabus.

   Practice Build the question set for one full unit of your course, use it once, and note which questions were useless and why.

2. Grounding answers in your own documents

   When the answer must be traceable, you supply the text and ask the model to answer only from it — and to say "not in the document" when it is not there. That instruction is what stops the invention.

   Example "Answer only from the text below. If the answer is not there, reply NOT FOUND and nothing else." One sentence, and a summariser becomes something you can rely on for a client document.

   Practice Try it on a document with a question whose answer is deliberately absent, and confirm the NOT FOUND reply.

3. Publishing the tool and writing it up

   A short write-up — what it does, the prompt that powers it, what it gets wrong — is what makes this a portfolio item rather than a personal trick.

   Example Naming the failure cases is the part that impresses: it shows you tested the tool instead of admiring it. That habit is what separates prompt engineering from prompt collecting.

   Practice Write 300 words on your assistant, publish it, and add the link to your resume under Projects.

Structured output, comparison and the judgement to know which answer is better.

1. Getting structured output you can use

   Ask for the answer in a fixed shape - a table, JSON, a list with named fields - and you can paste it straight into a document or a script instead of rewriting it by hand.

   Example Ask for JSON with the keys skill, why_it_matters and example, and the answer becomes data rather than prose you must reformat.

   Practice Ask for the same information twice, once as prose and once as a JSON list, and note which one you could actually use.

2. Comparing two answers instead of trusting one

   Ask for two versions of the same thing and the reasons they differ, then choose. Seeing the trade-off is how you learn to judge output instead of accepting the first fluent paragraph.

   Example Ask for the same answer at two levels - for a beginner and for a busy interviewer - and the second is usually the one you actually send.

   Practice Take any request and ask for two versions with a one-line note on when each is better. Pick one and say why.

3. Long context without losing the thread

   With a long document or a big syllabus, give the model a structure to fill rather than one open question. It keeps the answer organised and keeps you from reading a wall of text.

   Example Ask for one line per section, then a short "what to do first" list, and the summary maps to the document instead of floating free.

   Practice Feed one long document and ask for a section-by-section one-liner plus a three-item action list.

Put a prompt inside a real script, handle the edges, and write it up honestly.

1. Putting a prompt inside a script

   A prompt in a script can process a hundred rows the way a prompt in a chat processes one. The API call is a function: send the prompt, get text back, use the text.

   Example A loop that sends each row to the model and writes the cleaned result to a new column turns an hour of copy-paste into a minute of waiting.

   Practice Write a small script that sends one fixed prompt to a model with two different inputs and prints both answers.

2. Cost, limits and safety in a real tool

   A tool that costs money and takes user input needs three things: a cap on how much it can spend, a limit on how often it can be called, and a check on what it sends back.

   Example Log the tokens used per request and refuse once a daily budget is crossed, so a loop with a bug cannot drain an account overnight.

   Practice Add a request counter and a per-day cap to your script, and log the tokens each call uses.

3. Documenting and publishing honestly

   A short README that says what the tool does, how to run it, what it costs and where it fails is what turns a hobby script into a portfolio piece someone can trust.

   Example Four sections - what, run, cost, limits - and a screenshot is enough; the limits section is the one that gets you the interview conversation.

   Practice Write the README for your tool with a real limits section, and publish the repository.