Canva AI-assisted coding interviews: questions, expectations, and practice

What to expect from Canva’s AI-assisted interview

Canva expects AI use from backend, frontend, and machine learning candidates; its published screening pilot covers backend and frontend. Canva’s engineering announcement.

Confirm the structure of your own loop with the recruiter, especially if you are applying for a specialist role. Then choose the language and development environment in which you can read, run, and change code comfortably. You want your attention on the product behavior, rather than on finding a terminal command or learning an editor shortcut during the interview.

A good preparation session includes both implementation and explanation. Ask someone to give you a broad request, interrupt with a clarification, and ask why you made a particular choice. That practice makes it easier to keep the human conversation moving while an assistant is producing code.

What the interviewer wants to learn about you

Canva’s October 20, 2025 interviewer guide describes three evaluation areas: engineering problem solving, technical depth and ownership, and effective AI collaboration. It recommends preparing your development environment and basic project structure. It also tells candidates to answer an interviewer’s question with their own thinking before consulting AI. Canva’s interviewer guide.

Rehearse moving between those activities. Turn a product question into a concrete rule, compare a generated patch with an independent example, and use a failing test to guide a focused repair. Getting stuck between activities can consume more time than typing the implementation.

After each rehearsal, record one assumption you discovered late and one decision you made without assistance. That log gives you specific weaknesses to work on instead of an unhelpful impression that the session went well or badly.

Canva’s published example: an airport control system

Canva’s illustrative prompt asks candidates to manage aircraft takeoffs and landings at a busy airport. It is an official example, not a promised interview question. Read Canva’s example.

To practice with that broad prompt, start by asking what must be controlled. Is there one runway or several? Are aircraft queued in arrival order, assigned time slots, or ranked by priority? What happens when a request is cancelled? These are your clarification questions, not additional requirements supplied by Canva.

Choose a manageable version before generating code. For example, model a single runway with pending requests and an explicit rule for which request becomes active next. Write down what prevents two requests from owning the runway at once. Then demonstrate a complete request, selection, and completion sequence before adding scheduling policies.

For a focused exercise in exclusive ownership, try Stop Double Claims in the Job Scheduler. It concerns workers and expiring leases rather than aircraft, but it gives you practice checking who may claim work and what happens when ownership expires. It is useful preparation for resource coordination without pretending to reproduce Canva’s airport question.

Build your own practice project: shared studio bookings

For an original nrml exercise, build a small application where teams reserve recording studios. Start with the request: let someone choose a room and reserve a time. Before opening the assistant, list the decisions hidden inside that sentence. Are adjacent reservations allowed? Can a cancelled booking still block availability? What identifies a booking?

For this exercise, choose explicit constraints. Each booking has an ID, room ID, start, end, and cancellation status. Use integer minutes on one fictional day, with start strictly less than end. Reservations are half-open intervals: a booking ending at minute 60 does not conflict with one starting at 60. Ignore time zones and recurring bookings.

Reject overlapping active reservations for the same room. Different rooms may overlap. Cancellation releases the time, and cancelling an already cancelled booking leaves state unchanged. Keep persistence in memory for the first version. The goal of this practice project is to make a few important rules observable before extending the application.

Build one complete path before extending the product

Choose a narrow first outcome: submit a valid booking and list it. A backend rehearsal can expose functions or a small API. A frontend rehearsal can use a local store and a simple form. Pick the surface relevant to your role while preserving the same reservation rules.

Write the acceptance examples yourself. Room A from 30 to 60 followed by Room A from 60 to 90 succeeds. Room A from 45 to 75 conflicts. The same interval in Room B succeeds. A reversed interval fails before state changes. These examples make the contract inspectable.

Postpone login, invitations, calendar integration, and styling polish. In this practice session, a complete reserve-and-cancel flow teaches more than several disconnected screens. Keep a short list of deferred work so that reducing scope remains a deliberate decision.

Give the assistant a bounded implementation task

Ask for the booking rules before requesting a full application. Point the assistant toward existing types and tests when practicing in a repository. Require it to preserve the public interface. If it proposes a dependency, make it explain which requirement needs it.

Read the resulting patch before running the next prompt. Check whether validation happens before mutation and whether the conflict check filters by room. An elegant interval comparison is still wrong if it rejects a booking in an unrelated studio. Accepting one small change at a time keeps the explanation manageable.

Implement reserveBooking using the existing booking type.
Use integer-minute, half-open intervals on one fictional day.
Reject start >= end and active overlaps in the same room.
Cancelled bookings must not block availability.
Do not add persistence, authentication, or dependencies.
Explain the conflict condition and show the smallest patch.

Use counterexamples to inspect generated code

For two intervals, overlap requires each start to precede the other interval’s end. Trace that rule yourself with adjacent, nested, and identical reservations. A generated solution may handle partial overlap while missing a booking that completely contains another.

Inspect cancellation separately. If the implementation deletes a booking, can you still distinguish a repeated cancellation from an unknown ID? Either representation can work, but it must fit the chosen contract. Ask for a focused adjustment instead of a broad rewrite that changes several behaviors at once.

For a frontend version, clear stale conflict messages when the user changes the room or time. Test the state behind the display as well as the visible result. A green success banner is not proof that a rejected reservation left the store untouched.

Keep test expectations independent of the implementation

Use the examples you wrote before generation as the starting test set. Then add one case for each branch that could corrupt state. Assert the returned result and the resulting bookings. A rejected operation should preserve the previous state exactly.

Change the implementation deliberately during practice: replace a strict comparison with an inclusive comparison, or remove the room filter. Your tests should fail for a clear reason. This small experiment distinguishes useful coverage from tests that merely execute code.

• Adjacent reservations succeed; identical and nested active reservations conflict.

• Different rooms can reserve the same interval without interfering.

• Cancelling a booking releases its slot; repeating cancellation changes nothing.

• Invalid input and conflict rejection leave all existing bookings unchanged.

Introduce one difficult change after the core works

Now add rescheduling. A booking should keep its ID while changing its interval, and a failed move should preserve the original reservation. This exposes two common mistakes: detecting a conflict with the booking itself and deleting the old reservation before validating the new one.

Sketch the state transition before generating code. Check availability while excluding the current ID, validate the proposed interval, then update once. Write a regression test where the destination conflicts and verify that the original time remains reserved. Explain which assumption makes this sufficient: the practice program processes operations sequentially. Real concurrent requests would require additional coordination.

Another useful follow-up is a repeated booking request. Should a retry create a second reservation or return the original result? To practice that distinction in a separate domain, use Make Payment Webhooks Idempotent, which centers on retries, validation, and conflicting identities. The transferable habit is defining the identity of an operation before allowing it to change state twice.

Rehearse a clear handoff

Finish a practice session by demonstrating one success, one rejected conflict, and one cancellation. Then explain the overlap rule without reading the assistant’s response. Identify the generated change you corrected and the test that demonstrates the correction.

Reserve part of each rehearsal for that handoff. State what works, what you checked, and what remains simplified. For this exercise, the limits include in-memory storage, sequential operations, one fictional day, and no access control. If a test did not run, say so directly. Then choose one weakness to practice again, such as explaining the overlap rule or catching a mutation before it reaches the interface.