What this section is
Live coding is a format rather than a separate stage of the funnel, and it turns up in several places at once: inside the language and platform section, where it takes an hour to an hour and a half; inside the technical screen as a short task; and occasionally in the final round with the team. It differs from the algorithms section in its subject. There, candidates solve a problem they have not seen before; here, they show that they can write normal, working code in their own language.
The environment is the key variable
The conditions a candidate works in determine which skill is really being tested. When the code cannot be run anywhere, the interviewer is testing the ability to spot bugs by reading: the usual “write a bit more and run the tests” loop does not work in such an environment, and debugging has to happen in one’s head. When the environment is a working one, a typo costs close to nothing, but a wrong algorithm is immediately visible to both candidate and interviewer, and the bar for the result is higher.
How far the conditions diverge is shown by Yandex (in Russian), where the environment depends even on the language. In the C++ and Go sections code is written in the company’s online editor, and for C++ it is stated separately that the interview takes place “without a compiler or autocomplete.” In Java and Python the candidate works in their own IDE. The language is chosen in advance, at the screening stage, together with the recruiter.
What is allowed
Rules on access to the outside world vary more than anything else in this section, and they vary even within a single company. In Yandex’s backend sections searching the web is allowed. In the frontend section at the same Yandex (in Russian) it is not: “you may not search for the problem statement online or receive outside help” — even though code there is in fact run and debugged in the browser’s developer tools.
When the rules have not been stated, a principle formulated by VK’s head of backend development applies: “whatever is not forbidden is allowed” (in Russian) — if the interviewer forgot to mention a restriction, they are not entitled to object to the use of a search engine. The rule describes who bears responsibility for an unstated ban. It does not suggest quietly opening a browser: a minute spent clarifying the rules at the start of the section settles the question entirely.
The range within which these rules sit is wide. Avito bans library functions: you may write even in a pseudo-language, but the sort has to be implemented yourself. T-Bank asks for notice: “If you need to look something up online, tell us.” Mindbox does not even ask candidates to turn on their camera or share their screen. Sber asks for consent to the live coding itself and does not run it at all for some roles.
Formats by company
| Company | Environment | What is allowed | What they give |
|---|---|---|---|
| Yandex, C++ and Go | The company’s online editor. For C++, officially — no compiler and no autocomplete | Web search allowed. AI assistants banned by name | An applied task: a site map built by crawling links, then parallelizing the crawl across N threads |
| Yandex, Java and Python | The candidate’s IDE | Documentation and search allowed. AI assistants must be disabled — the company provides instructions for eight environments | Python: write autotests with pytest, implement a product feature, fix bugs in code |
| Yandex, frontend | Online editor; code is run and debugged in browser devtools, with the browser window shared | Web search forbidden | Review a snippet of inefficient, buggy code and write a working solution |
| T-Bank, Go | In-house live coding platform. Per a candidate report — an editor with no hints or autocomplete | “When a candidate uses neural networks or a search engine, it’s noticeable. If you need to look something up — tell us” | 90 minutes: code review with modification for a business task, troubleshooting, concurrency, language primitives |
| Avito | Tools provided by the company; the technical interview runs 2–3 hours | Library functions banned; pseudo-language allowed | Programming, turning a problem into an algorithm, understanding code complexity |
| Sber | — | Consent to live coding is requested; not held for some roles | A short 15–30 minute task, “the time is generous” |
| Ozon | A ready-made application template, two interviewers | — | A large two-hour section: a case with parallel reads from cache and database, SQL, a code review fragment |
| VK | Working environment: the solution is exercised with HTTP requests | — | A news service with an in-memory top by rating, three endpoints, database forbidden |
| Mindbox | No camera or screen sharing requested at all | Searching, debugging and neural networks all allowed | Basic tree traversal, one hour |
| 2GIS | No code is written | — | A fully conversational section of about two hours: language, databases, architecture, algorithms |
What the tasks look like
The tasks are applied and resemble real work. Almost every one has a complication built in towards the end — it is part of the section’s script from the outset, and a candidate who moves quickly gets it too.
In a candidate report from February 2026, Yandex’s Go task looked like this: write a program that builds a site map — parse the links, traverse them depth-first or breadth-first, filtering out external ones by host. Then the crawl had to be parallelized across N threads, with a correct way to detect when it had finished. At VK in the same period the task was a news service with an in-memory top by rating: three endpoints, millions of news items, a top of a thousand, no database allowed. The solution was actually run there and checked with HTTP requests. Yandex’s official Python examples are of the same kind: write autotests with pytest, implement a product feature, fix bugs in code.
Reviewing someone else’s code
Writing code from scratch is gradually giving way to working through someone else’s. Existing code cannot be fixed without understanding it, and a hint helps little here: the code has to be understood first. From a rarity, this format has become an official block of the section.
T-Bank puts code review first in its Go section and phrases it as “review the code and modify it for a business task.” Next to it is an analysis of a simulated failure — the company calls it troubleshooting. At Yandex, review makes up the entire frontend section: candidates get a snippet of written code, inefficient and with functional bugs, and are asked to review it and write a working solution. At Ozon, candidates describe a code review fragment at the end of the large section. VK’s head of backend recommends the same approach to colleagues: if a team needs someone who will refactor a system, it makes sense to give them badly written code and ask them to rewrite it.
What gets assessed
Yandex publishes its coding section criteria openly: command of the language and its standard library, design of class and function interfaces, choice of data structures, clear and working code, unit test coverage of the solution — and how the candidate reasons about the solution and explains their steps. The same page dispels a common fear: “we don’t assess knowledge of the specification; if you’ve forgotten a standard function, the interviewer or the online editor will prompt you.”
The interviewer assesses the line of reasoning separately from the result: Yandex says so directly — they look both at the solution and at how the candidate arrived at it. This does not mean silence is forbidden. VK’s internal methodology, on the contrary, teaches interviewers to give the candidate the first few minutes to think in peace and not to take a pause as a call for help. What turns into a failure is something else: a solution the candidate found but did not explain — there is simply nothing to assess it by.
Edge cases get a line of their own in Yandex’s official tips for candidates: “account for the main edge cases, use test cases.” Sber adds to the list what it assesses on a par with the code: openness, the ability to ask clarifying questions and a willingness to reason about the solution out loud.
Preparation has a flip side too. The same head of backend at VK describes how a pre-solved task is recognized: the candidate “sidestepped all the typical problems or immediately produced a perfect solution that accounts for every pitfall.” This does not end in rejection — the task gets harder: the candidate may be asked to solve the same one, for example, without recursion.
AI in the section
Positions range from a ban naming specific tools to full permission, and Russian companies occupy both ends.
Yandex bans them and does not stop at a declaration: AI assistants are listed by name — Copilot, ChatGPT, Cursor — and the site publishes step-by-step instructions for disabling them in eight environments, including creating an empty .noai file in the project root, the Cursor Tab: Disable command in Cursor and the disable_ai key in Zed. Ordinary code autocomplete is explicitly allowed. The same page warns that the meeting may be recorded and transcribed with AI tools — “so that the section can be scored quickly and well.”
At the other end is Mindbox, where neural networks are allowed and the camera and screen sharing are not requested at all. The company’s frontend lead explains it this way (in Russian): “You can google, you can debug — no programming on a sheet of paper,” and camera and screen are not required “so as not to add stress.” The logic is that in real work a developer has both search and neural networks at hand, and it makes sense to test them under the same conditions. T-Bank sits in the middle: there is no outright ban, only a warning that using a neural network is noticeable.
For all the differences, none of these companies has dropped the format itself. Finished code no longer proves anything, and the live section remains the only place where it is visible how the candidate arrived at it.
A separate question is what the interviewer can actually see of what is happening on the candidate’s screen while sharing is on. An explanation of the mechanics and their limits: what is visible during screen sharing.
FAQ
Is the code actually run during the section?
It depends on the company, and at Yandex even on the language. In the C++ and Go sections candidates work in the company’s online editor, and for C++ it is stated explicitly: “no compiler and no autocomplete.” In Java and Python the candidate writes in their own IDE. At VK the environment is a working one — the solution is actually exercised with HTTP requests. These are two different skills: in the first case debugging happens while reading the code; in the second a mistake costs almost nothing, but a wrong algorithm shows up immediately.
Can I read documentation and search the web?
The range is enormous, and asking about it in advance is normal. In Yandex’s backend sections searching the web is allowed; in the frontend section at the same Yandex it is not. T-Bank asks candidates to give notice: “If you need to look something up online, tell us.” Avito bans library functions — you may write even in pseudocode, but you will have to implement the sort yourself. Mindbox allows both search and neural networks.
What if the interviewer doesn’t state the rules?
Ask. VK’s head of backend development puts the principle plainly: if restrictions have not been stated, “such disputed points fall under the rule ‘whatever is not forbidden is allowed’,” and there can be no complaints about using a search engine. But relying on this silently is risky: it is simpler to spend a minute at the start and settle the question.
Do I need to write tests?
At Yandex, covering the solution with unit tests is explicitly on the list of assessment criteria for the coding section. The same page lists among its official tips for candidates: “account for the main edge cases, use test cases.” At a minimum, it is worth talking through the checks out loud: empty input, a single element, duplicates, nil, a cancelled context.
How long does the section last?
A language section usually runs 60–90 minutes. Yandex allots an hour to an hour and a half: an hour for the task and half an hour for logistics. T-Bank gives 90 minutes for its Go section. Live coding inside a technical screen is shorter: at Sber the practical task takes 15–30 minutes, and “the time is generous, so that a candidate who starts down the wrong path can correct their mistakes.”
Can I use AI during live coding?
At Yandex, no, and the ban names tools: Copilot, ChatGPT, Cursor. The company publishes instructions for disabling them in eight environments, including creating an empty .noai file in the project root. Ordinary code autocomplete is explicitly allowed. T-Bank limits itself to a warning that using a neural network is noticeable. Mindbox, by contrast, allows it — their argument is that in real work a developer has both search and neural networks at hand.
Sources
- T-Bank: the Go interview (in Russian) — structure of the section: code review, troubleshooting, concurrency, primitives; timings and the stance on neural networks.
- Avito’s hiring playbook (in Russian) — the programming section: ban on library functions, pseudocode, criteria.
- Sber: how technical interviews work (in Russian) — 15–30 minute live coding, candidate consent, interviewer criteria.
- Interviews at Yandex and VK, backend, February 2026 (in Russian) — a candidate’s diary: section tasks and differences between environments.
- A report on interviews at Ozon, T-Bank, Mindbox and 2GIS (in Russian) — July 2025: section formats, including permitted neural networks at Mindbox and the conversational section at 2GIS.
The other stages of the funnel are covered in the overview of developer interview stages. The neighboring sections have their own write-ups: algorithms and system design.