// for candidates

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.

Using AI is not cheating here. It's the exercise. What we're interested in is what you do with what it gives you.

// what happens when you click

01

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.

02

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.

03

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.

// what 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
// how the assistant works

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.

// how you're assessed

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
// if this format is new to you

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.

01 —

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.

02 —

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.

03 —

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.

04 —

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.

// what's recorded, plainly

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.

// straight answers
My wifi dropped. Did I lose everything?+
No. Open the same link again and you're back in the same session, with your files as you left them. Your remaining time is the time that was actually left.
Am I allowed to just let the AI do it?+
You're allowed to. It rarely goes well. The tasks are written so that the obvious answer is subtly wrong somewhere, and accepting everything without reading it is exactly the behaviour that walks into it.
What if I don't finish?+
Submit what you have. A partial solution with clear reasoning and honest notes about what's left reads far better than a complete one nobody can follow. Say what you'd do next.
Can I use a different model?+
If the team offering the interview enabled more than one, yes — there's a picker in the assistant panel. Everyone sitting the same interview sees the same options.
Can I see the assistant's plan before it changes anything?+
Yes. Switch the conversation to plan mode and the assistant reads the code and writes a plan without editing files or running commands. It starts the work when you approve the plan. If you reject it, you can say what to change and it writes a new plan.
Does the timer include reading the task?+
No. You see the brief before you start, and the clock begins when you choose to begin. Read it twice.
Who sees my session?+
The team that invited you. Your work is scoped to their account and is not visible to any other company using codesolara.
How should I prepare for an AI-assisted coding interview?+
Practise reading generated code critically rather than practising prompts. Take something an assistant wrote for you recently and find what is wrong with it. That is the skill the format is built to observe, and it is the one most people have never deliberately practised.
Will I score lower if I use the assistant a lot?+
No. Volume of use is not a signal in either direction. Someone who asked twice and got it right is not scored below someone who asked thirty times. What is read is what you asked for, what you kept, and what you rejected.

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.