Guide

How to guide the AI in a coding interview

Coding interviews now give you an AI helper. The interviewer cares less about the code it writes than about you: did you decide what to build, did you catch its mistakes, can you explain what you shipped. We read hundreds of practice sessions on Nyrion, and we built the helper that sits in them. This is what good sessions look like. The examples are from real sessions, with spelling fixed and names removed.

Last updated October 18, 2026. By the Nyrion team.

What the interviewer is scoring

Five things. Did you drive the solution, or ask the AI to figure it out? When a test failed, did you find the cause, or hand the failure over? Did you work on your own, or lean on hints? Could you explain your work? And is the final code any good? These are the five parts of the Nyrion interview report, and they are what this guide is about.

One rule covers most of it: at every moment, you should know what is true about the code. The AI is fast and does what you say. Your job is to always know what it did and why.

1. Drive the solution: say what to build and how

"Fix it", "solve it" and "implement the solution" say nothing about what to build. "Implement the cache eviction" could mean ten different designs. The AI picks one, and you end up with a design you did not choose and cannot explain.

Say what and how:

A few issues in list_issues: status should not have a default. If no status is passed, show all issues. Sort by id, newest first. Fix those two, nothing else.

The AI can build exactly that, and you can stand behind it when the interviewer asks why.

On Nyrion, if you say "solve it", the helper asks you once which way you want to go. If you tell it to pick, it builds the simplest thing that passes the stage, says which one it chose, and that line stays in your record: the AI designed that part, not you. Nobody stops you from doing this in a real interview either. The interviewer just sees it, and later asks you to explain code you did not design.

One exception. "Fix it" is fine right after the AI told you what is wrong and you agreed. The what is already on the screen. "Fix it" just points at it.

2. Find the problem before you ask for the fix

"Find the bugs and fix them" is one prompt that asks for two things. The AI finds something, changes something, and you are left reading a pile of changes without knowing what it found. If it went after the wrong bug, a red test tells you ten minutes later.

Split it. Say what you think is wrong first, then ask. Here is a candidate on a buggy issue tracker, where creating an issue fails:

I suspect the reason we can't create issues is that there is no actual Issue class yet. Is that right?

The helper answered:

No. Issue is already defined in models.py. The problem is in issues.py: it reads summary where the request sends title, it returns the new issue without saving it, and it returns 200 where the contract requires 201.

The guess was wrong, and that is fine. The candidate now has three things the AI thinks are true. They picked one, checked it themselves, and only then asked for a change:

Is line 19 correct? From what I see it uses .get("summary") when it should be "title". Or am I wrong?

Two prompts, and at every point they know what the AI is doing and why. In the report this reads as "found the problems", even though the first guess missed.

3. Asking is free. Checking is the skill.

"What do you see in this code?" "Walk me through add_movie." "Is the bug in get, because it never updates recency?" "Double check my thinking here."

All good prompts. This is how you work with a strong partner on real code: you ask what they see, then you decide. On Nyrion these get a straight answer. They are not hints, they are not counted, and the harder the problem, the more you should use them.

What the report looks at is your next move. Ask "what's wrong?", then say "fix it" without checking anything, and it looks like you handed the problem over. Ask, check one claim against the code or a test, then say what to change, and it looks like you are driving.

Checking matters because the AI is sometimes wrong. In the sessions we read, it has named a bug that was not in the file, and it has said a change was missing when it was only waiting to be accepted. A candidate who runs the test after every change catches this in a minute. One who accepts and moves on finds out at the end.

4. Hints cost you. Use them after you tried.

A hint is different from a question. A question asks the AI what it sees. A hint asks it what to do: "any ideas?", "where do I start?", "give me a hint". On Nyrion a hint comes from the platform, not from the helper, and it is counted.

Hints come in three levels: where to look, what is wrong, and how to fix it. Each stage gives a few. On a problem with several stages, the last stage gives none. The report counts them: a "how to fix it" hint, or three hints on one problem, marks "worked independently" as weak. So try first, ask the AI what it sees, and take a hint only when you are stuck.

One more thing the report counts: files that end up exactly as the AI proposed them. Accepting the AI's code is normal. Edit it, or type part of it yourself, and the file is yours.

5. Answer the interviewer

After each stage passes, the interviewer asks you a question or two about the code: what a function does, why you chose this structure, what breaks if the input grows. This is the part of the interview where you show you understand what you shipped.

Answer with specifics. "Not sure" is a weak answer, and a skipped question counts as unanswered. If you let the AI write a function, read it before you continue, so you can explain it when asked.

6. If the fix is one or two lines, just type it

The AI found that intervals_collide uses < where touching intervals need <=. Don't write a prompt for that. Click into the file, change the sign, run the test. A prompt takes longer than the edit, and the interviewer would rather see you make a small change yourself than read it out to the AI.

Same for a wrong default value, a missing return, an off-by-one in a range. Say what you changed, then move on. The report knows which files you wrote by hand.

The short version

  • Say what to build and how. No "solve it".
  • Say what you think is wrong before you ask for the fix.
  • Ask the AI what it sees as often as you like. Then check one thing it said.
  • Take a hint only after you tried. The last stage has none.
  • Answer the interviewer's questions with specifics. Don't skip them.
  • Two-line fix: your hands, not a prompt.

You can practice all of this on Nyrion. The helper there works the way this guide describes, and the interview report at the end scores the same five things, with quotes from your own session.