Build a project that survives a technical round

A project's job in a placement interview is to give you something to be interviewed about. It does not need to be novel, deployed, or impressive. It needs to be yours, small enough to understand completely, and honest about its limits.

The project

Ask My Notes — a question-answering system over your own semester notes and question papers.

Why this one:

• The documents are yours, so no dataset hunting.
• You know the correct answers, so you can tell when it is wrong. Almost no student project has this, and it is what produces the numbers in the next section.
• It is genuinely useful to you during exams.
• Every concept from lessons 3 and 4 appears in it, so the fundamentals questions land on ground you have actually walked.

Scope it deliberately

Finish a small thing. A half-built ambitious thing interviews badly, because every interesting question lands on a part you did not get to.

In scope: one subject's notes (~30-60 pages), text only, a command-line or single-page interface, answers with citations, and a refusal when the documents do not cover the question.

Out of scope, on purpose: multi-turn conversation, images and diagrams, authentication, deployment, a fine-tuned model, an agent framework.

Being able to say "I deliberately left conversation memory out because I wanted retrieval quality to be the only variable" is a better answer than a half-working chat history.

Build order

1. Load and chunk. Extract text, split into ~300-500 token chunks with a small overlap. Store each chunk's text, its source document and its page number — the page number is what makes a citation useful.
2. Embed and store. Embed each chunk. For this size, a local index or even a plain array with cosine similarity in a loop is completely adequate. Reach for a vector database only if you can say why you needed one — "50 documents didn't need an index, so I computed similarity directly" is a genuinely good answer that most candidates cannot give.
3. Retrieve. Embed the question, score against every chunk, take the top k (start with 4). Print the scores while developing — you will learn more from watching them than from any tutorial.
4. Generate. Assemble: instruction, then the numbered chunks, then the question. Instruct it to answer only from the provided context, to cite the chunk numbers it used, and to reply NOT_FOUND if the context is insufficient.
5. Add the threshold. If the top score is below a cut-off you pick by experiment, do not call the model at all — return "not in your notes". This is the single highest-value hour of the project.

Then measure it — this is the part that wins

Write down twenty questions with the answers you know to be correct. Include five whose answers are genuinely not in your notes.

Run all twenty and record, for each: did retrieval bring back the right passage, and was the final answer right. You now have something almost no fresher brings to an interview:

"On twenty test questions, retrieval found the right passage 17 times and the final answer was correct 15 times. Of the five questions not covered by my notes, the similarity threshold correctly refused four — the fifth was phrased similarly enough to a covered topic that it slipped through and got a confidently wrong answer."

Every number there is a door into a technical conversation you are prepared for. And that last sentence — a specific, honestly-reported failure — does more for you than a claim of perfection ever will.

The four follow-ups it will attract

Prepare these. They are close to certain.

"Why not just paste the notes into the model?" Because the context window is finite and cost scales with tokens. For 40 pages you might get away with it; for 400 you cannot. Retrieval is what makes it independent of corpus size. Good extra credit: "for a single small subject, pasting genuinely would have worked — I built retrieval because I wanted it to still work when I added the other five subjects."

"How do you know the answer is actually from the notes?" Citations. Each answer names the chunks it used, and I can open the page and check. Without that, there is no way to distinguish a grounded answer from the model's training data.

"What was your chunk size and why?" Give your real number, then the trade-off from lesson 3, then how you would tune it: retrieval accuracy on the twenty test questions. Never invent a justification for a default you accepted.

"What would you do next?" Have one specific, sized answer. "Re-ranking, because my main failure was the right passage being retrieved at rank four while a plausible wrong one was at rank one — a cross-encoder re-ranker over the top ten would reorder them." Naming a real remaining problem and a matching fix is the strongest close available to you.

The mistake to avoid

Do not add a framework to your description that you did not need. Interviewers ask "why LangChain?" and a shrug undoes several minutes of good answers. Use whatever you like while building — but describe your system in terms of the mechanism, not the library. The mechanism is what you are being tested on, and it is the thing that transfers to the next job.

Next: the free practice set for this course — fifteen screening-style questions on everything above, marked instantly, no account needed.