Coding rounds with an AI assistant

An AI-assisted coding round is an interview in which you solve the problem with an AI assistant at hand, and part of what is judged is how you use it. Such rounds are described in public. Meta’s hiring page says that select roles now have an assistant built into the interview environment and that candidates are expected to use it; Canva’s engineering blog describes rounds in which candidates use AI tools of their own choice. The assistant changes who types, not what the interviewer needs to see: your plan, which parts you hand over, whether you read what comes back and how you test it. This lesson sets out what the public sources say, which assistant you may use where, a routine for working with one, a complete round in which a test catches the assistant’s bug, and the rules that keep your use of AI open and permitted.

What hiring teams and platforms say in public

Few companies describe these rounds in their own words, and the ones that do differ on the details that matter on the day: whose assistant you use, which tools are allowed and who can see the conversation. Here is what four public sources say.

An assistant inside the interview environment

Meta’s hiring page covers the change in a note on technical interviews and in several answers of its FAQ:

• For select roles, technical interviews now come with an authorised AI assistant built into CoderPad. The FAQ adds that many interviews have one and that candidates are expected to use it.
• During the interview you can pick which of several models the assistant runs on. Outside AI tools are not allowed: the only assistance you may use is what the interview platform itself supplies.
• The FAQ explains the change as bringing interviews closer to the job, and names problem solving, coding, debugging and collaboration as the skills they assess.
• To prepare, it points to a practice session in the same tool, and recommends practising with AI coding tools and getting comfortable with code that already exists: reading it, debugging it and building on it.
• The page calls the round the AI-native coding interview and lists nine languages for it: Python, Java, TypeScript, C++, C#, Kotlin, Swift, Rust and Go. JavaScript is not on the list, so check your language before the day.

Your own tools, on harder problems

Canva’s engineering blog explains why it changed one of its technical interviews:

• Candidates for backend, machine-learning and front-end roles are expected to work with AI assistants in its technical interviews, using whichever tools they like, and they are told so before the interview.
• Its own tests found that assistants solved its traditional interview questions easily, often in seconds, so those questions no longer showed how a candidate would work in the job.
• The new problems are larger, more ambiguous and closer to product work, so that a single prompt cannot solve them. Its example asks for a system that controls take-offs and landings at a busy airport.
• Interviewers look at when and how a candidate uses AI, how they break unclear requirements into parts, how sound their technical decisions are, and whether they find and fix problems in generated code.
• Computer-science fundamentals are still assessed, inside the new round. In the pilot, candidates with little experience of AI tools often struggled, not because they could not code but because they could not steer the assistant, or tell when its suggestion was a poor one.

What the interview platforms show

The platforms that host these rounds document how their assistants behave:

• CoderPad’s guide for candidates says that its AI panel appears only if the interviewer turns it on, tells you to ask the interviewer what use of it is acceptable, and notes that its practice sandbox has no AI panel.
• HackerRank’s help for candidates says that its AI Assistant is there only if the hiring company switches it on. On coding questions it runs in a guarded mode that helps with syntax, errors and concepts but does not give complete solutions; on questions set in a code repository it can also plan, write and edit code. The interviewer can follow your conversation with it as it happens, and the interview report includes your prompts and its replies.
• HackerRank’s Proctor Mode, which a company can switch on for a test, is the opposite case. Before the test starts, candidates agree to a list of banned actions, among them changing tabs and using outside tools; pasting text in is turned off; and screenshots are checked for AI assistants that are not part of HackerRank’s own editor.

Put side by side, the sources describe three settings, and the company decides which one you are in:

• A built-in assistant (Meta’s AI-native coding interview, and HackerRank or CoderPad pads with AI switched on). You may use only the assistant that the platform provides. On HackerRank the interviewer sees your prompts, live and in the report.
• Your own tools (Canva’s AI-assisted coding interview). You may use the tools you prefer, as the company’s notice says. Who sees your prompts is not stated, so say what you ask as you ask it.
• No AI at all (classic live rounds and proctored online assessments). No AI help of any kind is allowed, and proctoring looks for outside AI tools in screenshots.

Practise in the setting you will meet: in the platform’s practice space when it includes the assistant, with your own assistant on tasks too big for a single prompt, or in a plain editor, tracing and testing by hand.

What the interviewer still needs from you

An assistant can produce a correct function in seconds, so a correct function on its own tells an interviewer little. What it cannot show is why that function is the right one and how you know it works. Those are what the interviewer listens for, and you supply them by explaining as you go.

The lesson on coding-round formats grouped interviewer feedback into four areas. Each one still applies, with new evidence behind it:

• Problem solving. You choose the approach and say why before the first prompt. If you adopt an idea that the assistant suggests, be ready to defend it as if it were your own.
• Communication. Your prompts are now part of what you say, and on HackerRank the interviewer can read them as you send them. A request that states exactly what you need shows that you understand the task; “solve this” shows only that you have an assistant.
• Technical competency. You read generated code critically: you can say what each line does, point to the line that decides a boundary, and notice a library call whose behaviour you should check.
• Testing. You choose the checks for code you did not write. Finding and fixing problems in generated code is one of the things Canva’s interviewers assess.

Canva’s post also describes what its strongest pilot candidates did. They asked good questions about the product requirements, gave the assistant small, clearly defined pieces of work while keeping the overall design in their own hands, reviewed what it produced and improved it, and debugged it when it went wrong. HackerRank’s advice to candidates points the same way: understand a suggestion before you adopt it, and keep explaining your reasoning while you use the assistant. That is a routine, and the next section writes it down as steps.

A routine for each piece of work

1. Clarify and plan before the first prompt. Ask about sizes, edge cases and conventions, then say your approach and what it costs. The plan is the part of the round that is plainly yours, and it tells you what to ask for.
2. Keep the core; hand over routine pieces. The core is the idea that the problem is testing: the data structure, the invariant, the order of the work. Routine pieces are code you could write without hard thinking but would spend minutes on: parsing the input, a small class, formatting the output, generating test inputs, or a brute force to stress-test against.
3. Ask for one piece, with its contract. Name the function, its inputs and its output, the conventions (is a range inclusive? is the result sorted? are repeats removed?) and the edge cases, such as an empty input. A contract turns “looks fine” into claims you can check.
4. Read every line before you run it. Say what each line does. Mark the lines that decide a boundary: ranges and slices, comparisons, where loops start and stop, empty input, and any change to an argument. Those are the lines where a mistake survives a small example, in generated code and hand-written code alike.
5. Test what you marked. Run the example from the statement, then add one small case for each marked line, with its answer worked out by hand first. Keep every check in the pad, so that each later change runs against all of them.
6. Fix, then explain. Fix a bug yourself when it is one line you understand; otherwise ask again and give the assistant the failing case. Then say what you kept, what you changed and why.

Steps 3 and 5 take a minute or two each. That is little next to the cost of building the rest of a round on a helper that is wrong.

A worked round: shifts, a helper and an off-by-one

The round below is made up, but every line of code in it runs, and the output on this page is what it printed.

1. You: “Two checks before I start. Is a range inclusive, so 1-3 is three shifts? And if a volunteer names the same shift twice, do they count twice?”

   Interviewer: “Inclusive, yes. A volunteer counts once for each shift, however they write it. There may be spaces after the commas, and an empty reply means no shifts.”

2. You: “Then the plan: turn each reply into a set of shifts, count the volunteers for each shift in a list of n + 1 counters, and return the shifts below k. That is at most 200 × 1,000 = 200,000 additions, which is quick. The counting is the heart of the task and it is three lines, so I’ll write it myself. Parsing the text is routine but fiddly, so I’ll ask the assistant for it, with a precise contract.”

3. You, to the assistant, in the pad’s AI panel, where the interviewer can see it:

A few seconds later the draft comes back, and it goes into the pad unchanged:

def parse_shifts(text):
    """Turn text such as "1-3, 5" into a sorted list of distinct shifts."""
    shifts = set()
    for part in text.split(","):
        part = part.strip()
        if not part:
            continue
        if "-" in part:
            start, end = part.split("-")
            shifts.update(range(int(start), int(end)))
        else:
            shifts.add(int(part))
    return sorted(shifts)

4. You, reading the draft aloud before running it: “It strips each part and skips empty ones, so the spaces and the empty reply are handled. It collects the shifts in a set, so a repeat counts once, as you said. The range line is the one I’m least sure of, because a range is where inclusive and exclusive ends get mixed up. So after the example from the statement, my next checks are ranges whose last shift matters.”

Under the draft go the counting function and the checks that this reading suggests:

# The candidate's own code, written under the assistant's draft: the counting,
# then the checks that reading the draft suggested. parse_shifts.py is the draft
# exactly as it came back.
from parse_shifts import parse_shifts


def short_shifts(n, k, replies):
    """The shifts 1..n with fewer than k volunteers, in increasing order."""
    counts = [0] * (n + 1)
    for reply in replies:
        for shift in parse_shifts(reply):
            counts[shift] += 1
    return [shift for shift in range(1, n + 1) if counts[shift] < k]


def check(function, args, expected):
    """Call function(*args) and print ok, or WRONG with what was expected."""
    call = f"{function.__name__}({', '.join(map(repr, args))})"
    got = function(*args)
    if got == expected:
        print(f"ok     {call} -> {got}")
    else:
        print(f"WRONG  {call} -> {got}, expected {expected}")


print("The example in the statement:")
check(short_shifts, (5, 1, ["1-3", "3-5", "5"]), [])

print("The draft on the cases its range line decides:")
check(parse_shifts, ("7",), [7])
check(parse_shifts, ("1-3",), [1, 2, 3])
check(parse_shifts, ("4-4",), [4])
check(parse_shifts, (" 2, 9-10 ",), [2, 9, 10])
check(parse_shifts, ("",), [])

The example in the statement:
ok     short_shifts(5, 1, ['1-3', '3-5', '5']) -> []
The draft on the cases its range line decides:
ok     parse_shifts('7') -> [7]
WRONG  parse_shifts('1-3') -> [1, 2], expected [1, 2, 3]
WRONG  parse_shifts('4-4') -> [], expected [4]
WRONG  parse_shifts(' 2, 9-10 ') -> [2, 9], expected [2, 9, 10]
ok     parse_shifts('') -> []

5. You: “The example passes, but the helper is wrong. Python’s range stops before its end, so 1-3 gives 1 and 2, and 4-4 gives nothing at all. The example hid it: the 3 that 1-3 drops is covered by 3-5, and the 5 that 3-5 drops is covered by the reply 5.”

   Python’s documentation defines a range by its start and a stop that it never reaches, which is the half-open convention. The task’s notation is inclusive, and a helper that mixes the two drops the last shift of every range. The lesson on interval conventions covers the same choice for intervals.

6. You: “It is one line and I understand it, so I’ll fix it myself, with + 1 on the end of the range. The checks stay in the pad.”

   Interviewer: “A new requirement: some volunteers write a range backwards, like 5-3.”

   You: “Then I sort the two ends before making the range, add 5-3 to the checks and run all of them again. I’ll also add the statement’s replies with k = 2, where the counting itself shows, and a reply that names a shift twice.”

# The same pad at minute 30: the range line fixed, the interviewer's extension
# added (a range may be written backwards, "5-3"), and every check kept, so each
# later change is tested against all of them.


def parse_shifts(text):
    """Turn text such as "1-3, 5" into a sorted list of distinct shifts."""
    shifts = set()
    for part in text.split(","):
        part = part.strip()
        if not part:
            continue
        if "-" in part:
            start, end = part.split("-")
            # The extension: "5-3" means 3, 4 and 5.
            low, high = sorted((int(start), int(end)))
            # range() stops before its end, so + 1 keeps the last shift.
            shifts.update(range(low, high + 1))
        else:
            shifts.add(int(part))
    return sorted(shifts)


def short_shifts(n, k, replies):
    """The shifts 1..n with fewer than k volunteers, in increasing order."""
    counts = [0] * (n + 1)
    for reply in replies:
        for shift in parse_shifts(reply):
            counts[shift] += 1
    return [shift for shift in range(1, n + 1) if counts[shift] < k]


def check(function, args, expected):
    """Call function(*args) and print ok, or WRONG with what was expected."""
    call = f"{function.__name__}({', '.join(map(repr, args))})"
    got = function(*args)
    if got == expected:
        print(f"ok     {call} -> {got}")
    else:
        print(f"WRONG  {call} -> {got}, expected {expected}")


print("The example in the statement, and the same replies with k = 2:")
check(short_shifts, (5, 1, ["1-3", "3-5", "5"]), [])
check(short_shifts, (5, 2, ["1-3", "3-5", "5"]), [1, 2, 4])

print("The helper on the cases its range line decides:")
check(parse_shifts, ("7",), [7])
check(parse_shifts, ("1-3",), [1, 2, 3])
check(parse_shifts, ("4-4",), [4])
check(parse_shifts, (" 2, 9-10 ",), [2, 9, 10])
check(parse_shifts, ("",), [])

print("The interviewer's extension, and a repeat that must count once:")
check(parse_shifts, ("5-3",), [3, 4, 5])
check(short_shifts, (3, 2, ["1-2, 2", "3"]), [1, 2, 3])

The example in the statement, and the same replies with k = 2:
ok     short_shifts(5, 1, ['1-3', '3-5', '5']) -> []
ok     short_shifts(5, 2, ['1-3', '3-5', '5']) -> [1, 2, 4]
The helper on the cases its range line decides:
ok     parse_shifts('7') -> [7]
ok     parse_shifts('1-3') -> [1, 2, 3]
ok     parse_shifts('4-4') -> [4]
ok     parse_shifts(' 2, 9-10 ') -> [2, 9, 10]
ok     parse_shifts('') -> []
The interviewer's extension, and a repeat that must count once:
ok     parse_shifts('5-3') -> [3, 4, 5]
ok     short_shifts(3, 2, ['1-2, 2', '3']) -> [1, 2, 3]

7. Interviewer: “Why not ask the assistant for the whole solution?”

   You: “I could have, but then you would only have seen that I can paste. The counting is the part I had to get right and explain. The parser I could check against a contract, and checking it found a real bug before anything was built on it.”

Look at what the interviewer could note in those minutes: two conventions settled before any code, a plan with its cost, a request with a contract, reading that pointed at the risky line before a check proved it, a one-line fix with its reason, and checks that were still in place when the requirement changed. None of it depends on who typed the parser. And notice which checks found the bug. The example from the statement passed with the bug in place, because one example is evidence about one input; the checks that failed came from asking which line decides each boundary.

Rules: permitted tools and what stays private

Everything above assumes that the round allows the assistant you use. In a round that forbids outside help, using an AI tool anyway is cheating, however it is done. This lesson teaches only open use that the round permits.

• Use only what the round authorises. Meta’s FAQ authorises only the tools that its interview platform provides. In a classic round, or an online assessment without an AI feature, assume that no AI is allowed unless the company tells you otherwise.
• Ask early. Before the day, ask the recruiter which assistant is allowed, whether your language is supported in the AI round, and whether any part must be done without AI. At the start, ask the interviewer how they want you to use the assistant; CoderPad’s guide gives candidates the same advice.
• Assume you are seen. On HackerRank your prompts and the replies reach the interviewer live and in the report, and under Proctor Mode screenshots are checked for outside AI tools. Write every prompt as if you were saying it aloud, because in effect you are.
• Keep the task inside the environment. Do not paste the problem, the company’s code or its data into a tool outside the interview environment, during the round or after it. OWASP’s list of the main risks of applications built on large language models warns that sensitive data a user enters can later surface in what the model outputs. If a company asks you to keep its questions confidential, that includes chatbots.

Practise with the exercise

The exercise hands you a draft like the one in the round: a seat-list helper that an assistant wrote against a contract, with three bugs in it. Work it the way the round went. Read the draft against each clause of the contract and mark the line that decides it, predict what each sample test expects before you run it, and then fix each bug with the smallest change you can explain in a sentence.

parse_seats("A1-A4, b7")    # ['A1', 'A2', 'A3', 'A4', 'B7']
parse_seats("A2, A1-A3")    # ['A2', 'A1', 'A3']: the second A2 is a repeat
parse_seats("")             # []

def parse_seats(text):
    """Turn a seat list such as "B7, C3" into seat labels: ['B7', 'C3']."""
    seats = []
    for part in text.split(","):
        part = part.strip()
        if not part:
            continue
        if "-" in part:
            first, last = part.split("-")
            row = first[0]
            for number in range(int(first[1:]), int(last[1:])):
                seats.append(f"{row}{number}")
        else:
            seats.append(part)
    return seats

from seats import parse_seats


def test_docstring_example():
    """the draft's own example: two single seats"""
    assert parse_seats("B7, C3") == ["B7", "C3"]


def test_range_includes_both_ends():
    """a range includes its last seat: A1-A4 is four seats"""
    assert parse_seats("A1-A4") == ["A1", "A2", "A3", "A4"]


def test_range_of_one_seat():
    """a range whose ends are equal is one seat"""
    assert parse_seats("D5-D5") == ["D5"]


def test_two_digit_numbers():
    """a range that crosses from one digit to two"""
    assert parse_seats("C9-C11") == ["C9", "C10", "C11"]


def test_lower_case_rows():
    """rows in lower case come back in upper case, for single seats and ranges"""
    assert parse_seats("b7, c1-c2") == ["B7", "C1", "C2"]


def test_spaces_and_empty_parts():
    """spaces around parts and an empty part between two commas"""
    assert parse_seats(" A1 ,, A3 ") == ["A1", "A3"]


def test_empty_text():
    """an empty text gives an empty list"""
    assert parse_seats("") == []


def test_repeat_kept_in_first_place():
    """a seat listed twice appears once, where it first appears"""
    assert parse_seats("A2, A1-A3") == ["A2", "A1", "A3"]


def test_order_of_the_text():
    """labels keep the order of the text, not alphabetical order"""
    assert parse_seats("Z1, A1") == ["Z1", "A1"]


def test_prompt_example():
    """the first example of the prompt: a range and a lower-case seat"""
    assert parse_seats("A1-A4, b7") == ["A1", "A2", "A3", "A4", "B7"]

Interview questions

Fresher to mid-level · How would you use an AI assistant in this round?

I would keep the approach and the core logic myself and say them out loud before any prompt. Then I would give the assistant routine pieces, one at a time, each with a precise contract: parsing the input, boilerplate, test inputs or a brute force to compare with. I would read every line it returns before running it, mark the lines that decide boundaries, and test those with small cases whose answers I work out by hand, keeping the tests in the pad. When a test fails, I fix the line myself if I understand it, or ask again with the failing case. I would tell you what I am asking as I ask it, because my prompts are part of my reasoning, and I would use only the assistant that this environment provides.

Key takeaways

• AI-assisted rounds are described in public: Meta’s interviews may include an assistant inside the environment that you are expected to use, Canva asks candidates to bring their own tools, and on interview platforms the company decides whether the assistant is switched on.
• The assistant changes who types, not what is assessed. Your plan, your choice of what to hand over, your reading of its code and your checks are the evidence.
• Ask for one routine piece at a time, with a contract; read every line; test the lines that decide boundaries; keep every check.
• A passing example is weak evidence. In the worked round, the statement’s example passed with an off-by-one in the helper, and the first range check caught it.
• Use only the tools the round authorises, assume your prompts are seen, and keep the task out of outside tools.