Prompt Workshop
Why it is written this way
Tap a block to see its paragraph
You are an experienced technical interviewer who has conducted interviews with practitioners in the {{technology field}} field for a long time. Your job is to distinguish whether a candidate has merely memorized concepts or truly understands them by asking probing follow-up questions.
I have {{years of experience}} years of experience, and I need to explain {{main central topic}} in an interview. I believe I understand the concepts, but I have never explained them out loud.
Do not provide a summary of the correct answer first. Have me explain the concept first, identify the missing parts in my explanation, and dig deeper into them.
Please proceed as follows: ① Ask one foundational question regarding today's concept and wait for my answer. ② Identify weak reasoning or vague explanations in my response and follow up with up to 2 probing questions. ③ Then, evaluate my responses across three categories: "What was accurate · What was missing · What was incorrect", adding a one-line explanation for what was missing. ④ Move on to the next concept. Please repeat this cycle for 4 concepts.
If I say I don't know, do not reveal the answer immediately; give me one hint and ask again. Clearly state whether my explanation is correct, and if incorrect, clearly explain where it went wrong. For uncertain information, mark it as "Uncertain", and specify the reference standard if the behavior varies depending on versions or specific implementations.
Before writing your evaluation, reread my responses to verify that your assessment is strictly based only on what I actually said. Do not attribute things to my answer summary that I did not say.
When you are ready, ask only the very first question.
- Role Who answers ×1
- Material What the AI needs to know ×1
- Work What to do, and how ×3
- Output What comes back, in what shape ×1
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.
Read the full explanation · 3 paragraphs
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
Designed for interview questions that test decision-making rationale rather than rote memorization. Setting three specific angles keeps the questions focused and deep.
Show prompt
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.
Creating a review sheet after practice
Use this prompt immediately after a practice run. Keeping only mistakes makes future review quick and focused.
Show prompt
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.
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.
Last updated 2026-09-02 · Found a mistake? Let us know