What the section usually looks like
Formats vary, so read the instructions for yours. A typical AI-assisted assessment gives you a small repository of a few files, a task such as a failing test, a bug report or a small feature, an editor with an assistant panel, and a time limit. Some versions ask for a short written explanation at the end. Some record the conversation with the assistant.
Which parts of an AI-assisted assessment are marked automatically and which a person reads depends on the employer. You will not always be told. The safe assumption is that the final code, the test results and anything you write in explanation can all be looked at.
This is one of the newer online assessment formats, and it rewards the same habits as an engineer debugging someone else's code. The full method for a bug in an unfamiliar codebase is in the failing business rule in an unfamiliar repository. This page is the entry-level, assessment version of it.
Understanding before patching
Start by running the tests, before you open the assistant. The output tells you what is broken and gives you an expected and an actual value. Then read the failing test, because it states the rule the code is supposed to follow.
Only then ask the assistant, and ask it things you can check in seconds. The difference between a weak and a strong request is visible to anyone reading the transcript.
| Weak request | Strong request |
|---|
| "Fix the bug." | "Which function computes the late fee, and in which file?" |
| "Make the tests pass." | "What does late_fee return for a book returned on its due date?" |
| "Rewrite this to be better." | "Where else is late_fee called?" |
Each strong request returns a pointer you can confirm by opening the file. If the assistant names a function that is not there, you have learned something about how far to trust it for the rest of the section. An AI-assisted assessment rewards noticing that, not ignoring it.
Verifying every change
Assistant output can look right and be wrong, and an online assessment gives you no colleague to catch it. A suggested fix might pass the one failing test and break a case nobody tested, or it might change behaviour you were not asked to touch. So every change gets the same treatment: make it, run the failing test, then run the whole suite.
If you can, add or point to a test that fails without your change and passes with it. Put the old line back for a moment and confirm the test goes red again. That proves the test is checking your fix rather than something incidental. It takes a minute and is the clearest evidence you can leave behind.
Explaining what you changed
Whether the explanation is written or spoken, keep it to cause, change, evidence and limits. Here is a note for a late-fee bug where returning a book on its due date was wrongly charged.
Cause: late_fee() treated the due date itself as late (>= where > was meant).
Change: one comparison in fees.py, >= to >.
Evidence: test_return_on_due_date_is_free failed before, passes now;
full suite passes.
Not done: weekend due dates look inconsistent but have no test, so I left them.
The last line matters. Saying what you noticed but deliberately did not change shows you stayed inside the task, which is exactly the restraint a reviewer is looking for.
Why prompt cleverness is not what is scored
Many candidates assume the section is testing how well they can instruct an assistant, and spend their time crafting long prompts that ask it to solve the whole task. The usual result is a large diff touching several files for what was a one-line bug. A reviewer looking at that diff sees someone who accepted changes they could not explain.
The strong answer is the opposite shape: a small change, reached by reading, confirmed by tests, and described in a few plain sentences. The assistant was used throughout, but as a fast way to find and explain code, never as the decision-maker. The same split between what you write and what you delegate is covered for longer rounds in machine coding with an AI assistant.
One rule sits underneath all of this. Use only the tools the section allows. If the online assessment provides an assistant, that is the one you use; pasting the task into another tool when the rules forbid it is a breach, not a strategy.
The assistant can find and explain code for you. Understanding it, proving the fix and explaining the change are the parts being scored.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).