Chapter 106 — GenAI Interview: Self-Introduction & Project Questions
📖 Why This Chapter Comes First
GenAI interviews almost always begin with "Tell me about yourself" and "Explain a GenAI project you've built". Interviewers use your answer to judge whether you've built real systems (data, evaluation, cost, security) or only tried demos. Prepare these answers carefully with real numbers.
1. "Tell me about yourself." (GenAI developer)
"I'm [Your Name], a full-stack developer with 3 years of experience — mainly MERN with TypeScript — and for the last year I've focused on Generative AI features. I built a document question-answering assistant for an insurance client using RAG: ingestion of 5,000 policy PDFs, hybrid search over MongoDB Atlas Vector Search, reranking, and answers with citations, served through a Node.js API with streaming to a React UI. I also built an invoice-extraction pipeline using structured outputs that cut manual data entry by about 70%. I'm comfortable with prompt engineering, RAG, tool calling, evaluation and deploying LLM features to production with cost and security controls."
Tips
- Say which models/providers you used (OpenAI, Anthropic Claude, Azure OpenAI, Bedrock, Gemini, open-source models).
- Mention evaluation and production — this separates you from demo builders.
- Don't claim "trained an LLM" if you used an API — say "integrated" or "fine-tuned with LoRA" only if true.
2. "Explain your GenAI project end to end."
| Part | What to say |
|---|---|
| Problem | Who had what pain, and the cost of the old way |
| Solution type | RAG chatbot / extraction / summarisation / agent / classification |
| Data | Sources, size, formats, how often it changes |
| Architecture | Ingestion → storage → retrieval → LLM → output → UI |
| Model choice | Which model and why (quality, cost, latency, data residency) |
| Quality | How you measured accuracy, hallucinations |
| Production | Security, cost control, monitoring, feedback |
| Result | Numbers |
Model answer (RAG assistant):
"Problem: the client's support team spent 6–8 minutes per ticket searching policy documents.
Data: about 5,000 PDFs and 800 FAQ pages, updated weekly, plus permission groups — some documents are only for senior agents.
Ingestion: a Node.js job extracts text with a PDF parser, splits by headings into chunks of ~500 tokens with overlap, adds the document title and section as a header to each chunk, creates embeddings and stores them in MongoDB Atlas with metadata — document ID, section, version, and allowed groups.
Query: the agent's question is rewritten into a standalone query using chat history, then we run hybrid search — vector plus keyword — filtered by the agent's permission groups, rerank the top 30 to the best 6, and send them to the LLM with instructions to answer only from the context and cite sources. If the answer isn't in the context, it says so. The response is streamed to the React UI with clickable citations.
Evaluation: with two senior agents we built a 200-question test set. We measured retrieval hit rate in the top 6 and answer correctness/faithfulness with a judge prompt plus manual review. Adding hybrid search and chunk headers raised the retrieval hit rate from 71% to 92%.
Production: prompt caching for the system prompt, a smaller model for query rewriting, rate limits per user, PII masking in logs, and thumbs-up/down feedback.
Result: average handling time dropped by about 35%, at roughly ₹1.5 per question."
3. "Why did you choose this model?"
"We compared two models on our 200-question test set. The larger model was 4% more accurate on complex questions, but 5× more expensive and slower. We used the larger model for final answers because accuracy mattered for policies, and a small, fast model for query rewriting and classification. The client required data to stay in India, so we used the provider's India-region deployment through our cloud account."
Key factors: quality on your eval set, latency, cost, context window, data privacy/residency, tool-calling and structured-output support.
4. "What was the hardest problem?"
Good examples:
- Tables and scanned PDFs giving wrong answers → better parsing/OCR, tables kept as markdown.
- Model answering from general knowledge instead of documents → stricter prompt + citations + "I don't know" behaviour + faithfulness check.
- Wrong document versions → version metadata, filter latest only.
- Cost spikes → caching, routing, shorter context.
Use STAR:
Situation: "Agents complained answers mixed up two similar insurance products." Task: "Fix wrong-product answers." Action: "Logs showed chunks like 'The waiting period is 30 days' with no product name. I added the product and section name to every chunk before embedding, and extracted the product name from the question as a metadata filter." Result: "Wrong-product answers dropped from about 12% to under 2% on the test set."
5. "What was your exact role?"
"I owned the backend: ingestion pipeline, retrieval API, prompt design and the evaluation scripts. A frontend developer built the chat UI with my streaming API; a data engineer helped with SharePoint connectors. I worked with the client's subject-matter experts to build the test set."
6. "How did you make sure the AI doesn't give wrong answers?"
- Grounding: answer only from retrieved context, with citations.
- Allow "I don't know" when context doesn't contain the answer.
- Low temperature for factual answers.
- Evaluation set before each release; faithfulness checks.
- Human review for high-risk outputs; user feedback loop.
- Clear UI messaging that the answer is AI-generated with sources to verify.
7. "How did you handle sensitive data?"
"We masked PII (names, phone numbers, policy numbers) in logs, used the provider's enterprise settings so data isn't used for training, kept the deployment in the client's cloud region, enforced document permissions in retrieval (not in the prompt), and restricted who can see conversation logs."
8. "What frameworks have you used? LangChain, LlamaIndex?"
Answer honestly:
"I've used LangChain for prototyping chains and document loaders, and LangGraph for an agent with a review step. For the production RAG API I used the provider SDK directly with my own small retrieval layer, because it was easier to debug, test and control prompts and costs. I'd choose a framework when it saves real effort — like loaders, or graph-based agent workflows."
9. "What would you improve if you continued the project?"
- Add an automated evaluation step in CI for every prompt change.
- Add a reranker or tune chunking for tables.
- Add tool calling for live data (policy status from the core system).
- Better analytics on unanswered questions to improve documents.
- Semantic caching for repeated questions.
10. Questions you can ask the interviewer
- "Is the GenAI work more RAG/chatbot, document processing, or agents?"
- "Which models and cloud platform does the project use?"
- "How do you currently evaluate quality — is there a test set?"
- "Is this a new build or an existing system that needs improvement?"
⚠️ Mistakes to Avoid
| Mistake | Better |
|---|---|
| "I built a chatbot with ChatGPT" | Explain the architecture, data, evaluation and results |
| No evaluation numbers | "Retrieval hit rate 92% on 200 questions" |
| Ignoring cost and security | Mention token cost per request, PII handling, permissions |
| Claiming "100% accurate" | Explain how you measured and reduced errors |
| Buzzwords without depth | Fewer terms, each explained clearly |
← Senior Rapid-Fire Q&A | Index | Next: LLM & Prompt Engineering Questions →