Verified against ChatGPT · 2026-08-08
Prep for a technical interview by working through your actual weak spots, not a generic problem set
Builds a technical interview prep plan around your stated weak areas and the specific role's likely technical bar, then walks through practice problems with real-time reasoning checks instead of just handing you answers.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Help me prepare for a technical interview. I don't want a generic problem set — I want prep focused on where I'm actually weak, calibrated to the technical bar this specific role and stage is likely to test. ROLE AND TECHNICAL AREA Backend engineer role, technical screen focused on data structures/algorithms and SQL query design. INTERVIEW FORMAT 45-minute live coding round on a shared editor, no whiteboard, interviewer can see me type in real time. MY CURRENT LEVEL AND SPECIFIC WEAK SPOTS I'm solid on basic data structures but freeze up on anything involving graph traversal, and I tend to jump to coding before fully explaining my approach out loud. TIME AVAILABLE TO PREP 3 days, about 90 minutes per day. STEP 1 — CALIBRATE THE BAR Given the role, level, and interview format, tell me what technical bar is actually being tested here — not the theoretical maximum depth this topic could go to, but what a candidate at this level in this format is realistically expected to demonstrate in the time given. Being calibrated wrong in either direction wastes prep time: overshooting means I over-prepare topics unlikely to come up, undershooting means I walk in underprepared. STEP 2 — PLAN AROUND MY ACTUAL WEAK SPOTS Given my stated weak spots and the time I have, tell me which weak spots are worth closing before this interview versus which ones I should accept the risk on and focus my limited time elsewhere, and why. STEP 3 — WORK THROUGH ONE PROBLEM LIVE, WITH ME REASONING OUT LOUD Give me one practice problem calibrated to Step 1's bar and targeted at a weak spot from Step 2. Do not give me the answer or a hint yet — wait for me to attempt it and explain my reasoning first. Once I respond, do not just tell me if I'm right or wrong: ask me a targeted question about the specific part of my reasoning that's weakest, the way an interviewer probing for understanding rather than just a correct final answer would, before confirming or correcting anything. WHAT NOT TO DO Do not hand me a fully worked solution before I've attempted the problem myself — the value of live practice is in the struggle and the follow-up questions, not in reading a clean answer. Do not pick a problem more advanced than Step 1's calibrated bar just because it's more interesting to discuss. After I've worked through the problem with your follow-ups, give me a short honest assessment of what specifically I should keep practicing before the real interview.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The most common failure in AI-assisted technical interview prep is miscalibration in either direction — a model asked to help prep for a technical interview will often default to either generic textbook-difficulty problems that don't reflect what a 45-minute live-coding screen actually tests, or occasionally the opposite, showing off with an unnecessarily advanced problem that wastes the candidate's limited prep time on depth the actual interview will never probe. Forcing an explicit Step 1 calibration — reasoning about what this specific format and level realistically test, separate from the theoretical depth of the topic — makes the model's assumption about difficulty visible and correctable before any practice time is spent, rather than silently baking in a miscalibrated assumption. The instruction to withhold the answer until the candidate attempts the problem and explains their reasoning first is the mechanism that actually produces useful practice rather than passive reading: a model's default behavior when given a problem to "help with" is to be maximally helpful immediately, which for interview prep specifically defeats the purpose, since the actual skill being tested in a live technical interview is producing reasoning under time pressure without help, not recognizing a correct answer once shown one. The instruction to probe the weakest part of the candidate's stated reasoning, rather than a binary right/wrong judgment, mirrors how a real technical interviewer actually operates — most technical interviews are explicitly scored on process and communication, not just a correct final answer, so a mock session that only confirms correctness misses the exact skill (reasoning out loud, handling being questioned mid-thought) that determines the real outcome.
What you get back
Step 1: for a 45-minute live-coding screen at this level, expect one medium-difficulty graph or tree problem with follow-up variations, not a hard-difficulty multi-part problem — the format doesn't have time for that depth. Problem: given a list of flight routes, determine if you can reach a destination within k stops. [Candidate attempts] Follow-up: "You said you'd use BFS — walk me through why BFS and not DFS matters specifically for the 'within k stops' constraint."
Verified against
ChatGPT GPT-5.1 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
