Technical interview prompts for candidates and interviewers

Good technical interview prompts make the AI act like a real interviewer: one problem at a time, hints only when you ask, and honest feedback at the end. Below are 14 technical interview prompts for ChatGPT, Claude and Codex, split into practice for candidates (coding, system design, behavioral) and tools for interviewers (questions, rubrics and fair debriefs).

How to use these prompts

Copy a prompt and replace the blanks in double braces, or keep the default after the colon: {{language:Python}} means Python unless you change it.

For practice, the rule that matters most is this: make the model hold back answers. If it solves the problem for you, you learn to recognize solutions, not to produce them. Each candidate prompt below tells the model to wait, give small hints and only reveal a solution when you ask.

Some tools have a built-in mode for this. In Claude Code, the Learning output style "explains its choices and leaves small pieces of code for you to write yourself," which suits practice on real projects. For interview drills in a chat window, the prompts below set the same rules by hand.

Two more habits:

• Practice out loud. Interviews test how you explain your thinking. Type or say your reasoning as you go, then ask for feedback on it.
• Keep a log. After each session, save the feedback and the patterns you missed. Repeat weak topics a few days later.

How do you practice coding interviews with AI?

1. Mock coding interview

The core practice prompt. It sets the rules a real interviewer would follow.

Act as a technical interviewer at {{company_type:a mid-size product company}} interviewing me for a {{level:mid-level}} {{role:backend engineer}} role.

Rules:
- Give me one {{difficulty:medium}} coding problem in the style of {{topic:arrays and hash maps}}. State it the way an interviewer would, with one example.
- Answer clarifying questions briefly, like a real interviewer.
- Do not give hints unless I ask. When I ask, give the smallest useful hint.
- Never show a solution unless I type "show solution".
- I'll write in {{language:Python}}. When I say "done", review my code.

Feedback at the end, scored 1 to 4 each: problem solving, correctness, complexity analysis, code quality, testing, communication. Give one specific thing to improve for each.

2. Review my solution like an interviewer would

Use it after you solve a problem on your own.

Here is a coding problem and my solution in {{language:Python}}.

Problem:
{{problem}}

My solution:
{{code}}

Review it as a strict interviewer:
1. Is it correct? Give a failing input if not.
2. Time and space complexity, with reasoning. Did I get them right? My claim: {{my_complexity}}
3. Edge cases I missed (empty input, duplicates, negatives, very large input).
4. One cleaner or faster approach, described in words only. Don't write the code unless I ask.

3. Pattern recognition drill

Most interview problems fall into a few patterns. This drill trains spotting them fast.

Give me {{count:5}} short coding problem statements, one at a time. For each, I'll reply with the pattern I'd use (for example two pointers, sliding window, BFS, DFS, binary search, heap, dynamic programming, union find) and one sentence on why.

After each answer, tell me if I'm right. If I'm wrong, explain the clue in the problem statement I should have noticed. Don't solve the problems. Focus on {{focus:patterns I tend to miss: dynamic programming and graphs}}.

4. Pick the right data structure

Knowing your language's standard library saves time in an interview. In Python, for example, heapq is a min-heap where heap[0] is always the smallest item, and functools.cache memoizes a recursive function in one line.

I'm preparing for interviews in {{language:Python}}. Quiz me on choosing data structures.

Give me a scenario (for example, "keep the top 10 scores from a stream"). I'll say which structure I'd use from the standard library and the complexity of the key operations. Then tell me if there's a better choice and why, and show the one or two standard library calls that matter.

Do {{count:6}} rounds. Mix in at least one question on memoizing a recursive function and one on a priority queue.

How do you practice system design interviews?

5. Mock system design round

Run a {{minutes:45}}-minute system design interview for a {{level:senior}} engineer.

Start with a short, vague prompt like "{{system:design a URL shortener}}". Then:
- Answer my clarifying questions with concrete numbers (users, requests per second, data size, latency targets). Invent realistic numbers if I ask.
- Let me drive. Don't suggest components unless I'm stuck for a while and ask.
- After I sketch the high-level design, push on two or three weak spots: a bottleneck, a failure mode, a consistency question.
- Tell me when we're at the halfway point and when time is up.

Then score me on requirements gathering, high-level design, deep dive, trade-off discussion and communication, with the single most important gap to fix.

6. Critique my design

Here is my design for {{system:a notification service that sends email, SMS and push}}.

Requirements I assumed: {{requirements}}

My design:
{{design}}

Critique it like a senior interviewer. What breaks first at 10x load? Where is data lost if a component fails? Which trade-offs did I make without saying so? What would a strong candidate have discussed that I didn't? Keep it to the five most important points, ordered by impact.

7. Back-of-the-envelope estimates

Give me {{count:3}} estimation questions of the kind asked in system design interviews (for example storage for a photo app over five years, or peak requests per second for a chat app).

For each, wait for my estimate and my working. Then show your own working step by step, compare it with mine, and point out any assumption I made that was off by more than 10x. Use round numbers, as you would on a whiteboard.

How do you prepare for behavioral interviews?

8. Turn my experience into STAR stories

Help me turn these notes about my work into interview stories using the STAR format (Situation, Task, Action, Result).

My notes:
{{notes}}

Target role: {{role:senior frontend engineer}}

Write {{count:3}} stories, each under 200 words when spoken. Keep my words where you can and don't invent results; where a number is missing, mark it [ADD NUMBER]. For each story, list the interview questions it answers (for example conflict, failure, leadership, tight deadline).

9. Mock behavioral round with follow-ups

The follow-up questions are where weak stories fall apart, so practice those.

Act as a hiring manager running a behavioral interview for a {{role:staff engineer}} role.

Ask me one question at a time from these areas: {{areas:conflict, ownership, failure, influence without authority}}. After each answer, ask one or two follow-ups that probe for specifics: what did I personally do, what was the measurable result, what would I do differently.

After {{count:4}} questions, give feedback on each answer: was it specific, did it show my own actions, was it the right length, and what to cut or add.

10. Questions to ask the interviewer

I'm interviewing for {{role:a backend engineer role}} at {{company:a 200-person fintech startup}}. Interviewer: {{interviewer:the engineering manager}}.

Suggest 8 questions I can ask that help me decide if I want the job: on how the team works, how decisions get made, on-call and incidents, growth, and what success looks like in the first six months. Avoid questions I could answer from their website. Mark the two I should ask if time is short.

How can interviewers use AI to run better interviews?

11. Write a coding question with a rubric

Solve the question yourself before you use it.

Write a {{minutes:45}}-minute coding interview question for a {{level:mid-level}} {{role:backend engineer}}.

It should test {{skills:working with hash maps, handling edge cases and writing clean code}}, relate to {{domain:real backend work like rate limiting or log processing}}, and not be a well-known puzzle that candidates can memorize.

Include: the problem statement as I'd say it, two examples, a reference solution in {{language:Python}}, a rubric (strong, acceptable, weak) for each skill, two follow-up extensions for fast candidates, and hints I can give at three levels without giving it away.

12. Build a structured scorecard

Structured scorecards with defined levels make interviews more consistent across interviewers.

Create an interview scorecard for a {{role:senior software engineer}} loop with these rounds: {{rounds:coding, system design, behavioral}}.

For each round: the 3 to 4 competencies it measures, a definition of each, and what a 1, 2, 3 and 4 look like in observable behavior (things the candidate says or does, not impressions). Add a short list of signals interviewers should not score, such as accent, school or confidence that isn't backed by substance.

13. Write a fair debrief from my notes

Turn my raw interview notes into a debrief write-up.

Round: {{round:system design}}
Scorecard competencies: {{competencies}}
My notes:
{{notes}}

For each competency: the score I'd give, and the specific evidence from my notes that supports it. Flag any judgment in my notes that has no evidence behind it, and any wording that describes the person instead of their work. End with a hire or no-hire recommendation and the main reason. Don't add anything that isn't in my notes.

14. Calibrate a question across levels

Here is a coding interview question I use:
{{question}}

Show me what a {{levels:junior, mid-level and senior}} candidate's answer typically looks like, as a short description of approach, code quality and how they handle follow-ups. Then tell me whether this question separates those levels well, and how to adjust it if it doesn't.

What makes AI interview practice actually work?

Practice that feels easy usually isn't working. A few rules keep it honest:

A simple weekly plan works for most people: two or three mock coding rounds, one system design round, one behavioral round, and a short review of the week's feedback log. Before an on-site, shift toward full mock rounds under time pressure instead of single drills.

Interviewers get the most from AI on the prep work: question drafts, rubrics, calibration and clean write-ups. Keep the judgment calls, and check every generated question by solving it yourself. Never paste a candidate's personal details or code into a tool your company hasn't approved.

Save your practice prompts

If you use the mock interview prompt every day, turn it into a skill with the SKILL.md generator. For a skill that interviews you about a plan instead of a coding problem, see grill-me.

Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks such as {{language:Python}} and {{level:mid-level}} stay fillable, so switching from a Python drill to a Go drill is one edit, and ⌘K finds any prompt.