You've been sent
a link. Here's what
it actually is.
No trick questions, no proctoring software, no reversing a binary tree while someone watches your face. You get a real codebase, a real editor and terminal, and an AI assistant — and you are expected to use it.
// what happens when you click
No account, no install
The link opens a workspace in your browser. There's no signup, no password, no download, and nothing running on your machine.
Read the brief, then start
The task is in the first tab and stays there. The clock only starts when you say you're ready — take a minute to read it properly first.
Build, then submit
Work the way you normally would. When you're done, hit submit — or let the clock run out, which submits whatever you have.
Everything you'd normally reach for
- A real editor with your usual shortcuts, and a real file tree
- A terminal — run the tests, install a package, start the server
- An AI assistant that can read, edit and run code alongside you
- A visible clock, so nothing sneaks up on you
- A budget bar for the assistant, so you can see how much runway is left
It writes. You check.
Ask it in plain language. It'll read the code, change files and run things. Its edits land in your files straight away, and Source Control shows everything that changed since the start. Before it runs a command, it shows you the command and waits for Allow or Deny.
You can leave a change, fix it yourself, ask for a different one, or undo it. Undoing something is not a black mark. Noticing that something needed undoing is one of the better things you can do in this format.
You can also ask for a plan first. In plan mode the assistant reads the code and writes a plan, and changes nothing until you approve it. Reject the plan with a note and it writes a new one.
Not on typing speed
What helps
- Reading the diff before you accept it
- Saying what you're trying to achieve, not just what to type
- Testing the thing you changed
- Noticing when the assistant is confidently wrong
- Making a call under ambiguity and saying why
- Leaving the codebase better than you found it
What doesn't
- Accepting every suggestion to save time
- Rewriting files the task never asked you to touch
- Refusing to use the assistant to prove a point
- Leaving it broken but finishing early
- Guessing at the brief instead of making your assumption explicit
Preparing for an AI-enabled coding interview
A growing number of large engineering organisations have moved their coding rounds to this shape: a real codebase, an assistant beside you, and a task closer to a ticket than to a puzzle. If you have only sat the older kind, the instinct most people bring is the one that costs them.
Do not avoid the assistant to look strong
This is the most common mistake and it reads badly, because nobody works that way any more. Declining the main tool of the job does not demonstrate ability; it demonstrates unfamiliarity with how the team you are joining actually works.
Practise reading, not prompting
Prompt wording is the smallest part of this. Take some code an assistant wrote for you last week and go find what is wrong with it. Reading generated code sceptically is the skill being observed, and most people have never practised it on purpose.
Say what you are doing
"I am not going to use this bit because it would break on empty input" is worth more than the fix itself. Reasoning stated while you work is checkable against the session. Reasoning offered afterwards is a story about the work, and everyone can tell the difference.
Expect something to be subtly wrong
Tasks in this format are usually written so the obvious answer has a problem in it somewhere. That is not a trick — it is the only way the round separates anyone, now that a working solution is available to everybody. Slow down where it looks easy.
None of this is specific to us. It applies to any interview where the assistant is allowed, and it is what the people assessing you are looking at whichever platform they use — the four behaviours are set out in what AI fluency actually means.
You should know this before you start
An interview is a recorded event, and you deserve to know the shape of the recording rather than discover it afterwards.
What is captured
- The code you submit
- Your conversation with the assistant, and what it did
- Which plans you approved or rejected, and which commands you allowed or denied
What is not
- No camera. No microphone. No screen recording.
- No keystroke logging
- We never read your clipboard. Text you paste into a file or into a message to the assistant is stored like anything else you type there
- Nothing outside the interview tab
// nobody is auto-rejected by a machine. A scorecard goes to the hiring team, who read it, can override any part of it, and make the decision themselves.
My wifi dropped. Did I lose everything?+
Am I allowed to just let the AI do it?+
What if I don't finish?+
Can I use a different model?+
Can I see the assistant's plan before it changes anything?+
Does the timer include reading the task?+
Who sees my session?+
How should I prepare for an AI-assisted coding interview?+
Will I score lower if I use the assistant a lot?+
Good luck. Read the diffs.
If something in the workspace breaks in a way that isn't your fault, say so in your submission notes. A grading run that couldn't complete is reported as a grading failure, not as your failure.