Why it is written this way
When you ask an AI, "Explain what an index is," it generates a well-organized answer. The problem is falling into the illusion that reading it means knowing it. In an interview, you must explain that same concept in your own words, and memorized scripts crumble at the first follow-up question.
This is why the Role in the first paragraph is defined as "an interviewer who uses follow-up questions to distinguish memorization from real understanding." Assigning a tutor role prompts it to explain everything kindly first, but an interviewer role waits for your explanation. Adding "Do not provide a summary of the correct answer first" ensures strict execution.
Pinning down the process in four Steps prevents the session structure from falling apart: Foundational question → My answer → Max 2 follow-ups → Grading. This flow guarantees clear visibility into what you missed after each concept. Capping follow-up questions prevents the practice from turning into an endless interrogation.
The instruction to self-verify "based strictly on what I actually said" before grading is remarkably effective. Without it, the AI tends to hallucinate points in its summary of your answer and grade too leniently. The Constraints regarding marking uncertain points and clarifying specific versions are vital in technical interviews, as asserting version-dependent behavior incorrectly will cost you points in real interviews.
Unfamiliar terms? See Aha AI: role-prompting, hallucination
Compared with a bad example
Summarize backend technical interview questions and answers for me.
This produces a clean list of anticipated questions. Reading them makes you feel prepared, but because you haven't verbalized the answers, a simple "Why is that?" in the interview will freeze you up. Your preparation ends without discovering your real blind spots.
Variations
When evaluating architectural and design choices
You are a technical interviewer in {{technology field}}. I will explain the architecture I designed regarding {{main central topic}}. Once I finish my explanation, ask probing follow-up questions across three angles: "What were the alternatives to this choice?", "Where would the system break first if traffic scaled 10x?", and "What is the riskiest assumption in the current architecture?". Do not reveal the answers before hearing my response, and ask only one question at a time.
Designed for interview questions that test decision-making rationale rather than rote memorization. Setting three specific angles keeps the questions focused and deep.
Creating a review sheet after practice
Please summarize the Q&A session we just completed on {{main central topic}}. Extract only the points I got wrong or missed, and format them into a table with columns: "Question · What I Said · Actual Concept · Keywords to Review". Do not include concepts I answered correctly, and do not attribute points to my answer that I did not state. Sort the table in order of foundational importance for an interview at the {{years of experience}}-year experience level.
Use this prompt immediately after a practice run. Keeping only mistakes makes future review quick and focused.
Model notes
Grading becomes more lenient as the context gets longer. It is better to start a new chat session every two or three concepts.
The model may assert version-specific behaviors without validation, so double-check version-sensitive grading against official documentation. If sharing code for review, input only one function at a time; pasting long code blocks causes the model to abandon the interviewer role and start doing a code review instead.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know