На live coding интервью вы решаете задачу в присутствии интервьюера: объясняете предположения, пишете код, проверяете результат и обсуждаете ограничения. Итоговая функция важна, но ход рассуждений тоже даёт информацию о вашей работе. По нему видно, замечаете ли вы неоднозначность требований, умеете ли подобрать пример и можете ли найти ошибку без случайных правок. Ниже — воспроизводимый разбор проверки скобок на Python 3.12 и способ организовать решение в ограниченное время.
Уточните формат до начала решения
Сначала выясните, что разрешено: запускать тесты, пользоваться документацией, выбирать язык, делать заметки или обращаться к внешним инструментам. Не предполагайте, что правила одинаковы у всех компаний. Если хотите использовать ИИ, согласуйте это заранее. Для самостоятельной подготовки полезно сначала пройти задачу без подсказок, затем сравнить своё объяснение с альтернативой и повторить решение на изменённом условии.
Проверьте редактор, раскладку и способ запуска кода до встречи. На интервью достаточно коротко сказать, какой язык и версию вы используете. Если среда ограничена, договоритесь, как будете проверять результат: исполняемыми тестами или ручным проходом. Техническая проблема в редакторе не должна незаметно съесть всё время задачи. Сообщите о ней, предложите доступный способ продолжить и сохраните написанный фрагмент.
Превратите условие в проверяемый контракт
Уточняющие вопросы должны менять реализацию или проверки. Для скобочной последовательности существенны набор допустимых символов, смысл пустой строки и реакция на посторонний текст. Для числовой задачи это могут быть отрицательные значения, дубликаты, диапазон чисел и наличие ответа. Не стоит спрашивать обо всём подряд: назовите неоднозначность и предложите разумное правило, которое интервьюер может подтвердить или изменить.
- Что получает функция и что возвращает?
- Какие ограничения установлены для размера входа?
- Встречаются ли некорректные данные и как на них реагировать?
- Нужно ли изменять входной объект или сохранить его?
- Что считать успешным результатом на граничных случаях?
Для нашего примера договоримся: вход — строка из символов (), [] и {}. Пустая строка корректна. Любой другой символ делает строку некорректной. Функция возвращает bool и не бросает исключение из-за неправильного порядка скобок. Проверка типа аргумента остаётся за вызывающей стороной: мы не превращаем учебную функцию в универсальный валидатор произвольных объектов.
Начните с понятного решения и оцените его стоимость
Простой подход — удалять из строки пары (), [] и {}, пока что-нибудь меняется. После остановки пустая строка означает успех. Это помогает понять условие: в корректной вложенной последовательности обязательно найдётся внутренняя соседняя пара. Однако повторные проходы и создание новых строк увеличивают затраты. На глубоко вложенном входе можно получить квадратичное время. Этого достаточно, чтобы мотивировать улучшение, не тратя половину интервью на реализацию промежуточного варианта.
Подход со стеком хранит только ещё не закрытые открывающие скобки. Новую открывающую скобку кладём наверх. Закрывающая обязана соответствовать последней незакрытой. Это правило одновременно проверяет тип и порядок вложенности. Простого счётчика недостаточно: строка ([)] содержит одинаковое количество открывающих и закрывающих символов каждого вида, но нарушает порядок.
Разбор проверки скобок на Python 3.12
Инвариант цикла: стек содержит открывающие скобки из уже прочитанного префикса, для которых пока не встретилась соответствующая закрывающая, в порядке их появления. Если очередная закрывающая скобка не подходит к вершине, ни один будущий символ не исправит уже нарушенный порядок. Поэтому можно сразу вернуть False. После полного прохода оставшийся стек означает незакрытые скобки.
def valid_brackets(text: str) -> bool:
pairs = {')': '(', ']': '[', '}': '{'}
openings = set(pairs.values())
stack = []
for char in text:
if char in openings:
stack.append(char)
elif char in pairs:
if not stack or stack.pop() != pairs[char]:
return False
else:
return False
return not stack
def test_valid_brackets():
cases = [
('', True),
('()[]{}', True),
('{[()]}', True),
('(', False),
(')', False),
('([)]', False),
('(()', False),
('(a)', False),
]
for text, expected in cases:
assert valid_brackets(text) is expected, (text, expected)
test_valid_brackets()Решение можно скопировать в файл brackets.py и запустить командой python brackets.py. При успешных проверках программа ничего не печатает; ошибка приводит к AssertionError с входом и ожидаемым ответом. Код и встроенные проверки рассчитаны на CPython 3.12. Список используется как стек: append добавляет элемент в конец, pop без индекса снимает последний. Этот способ описан в официальной документации Python.
Пройдите один пример вручную
Для строки {[()]} стек последовательно принимает состояния {, {[, {[(. Символ ) снимает (, символ ] снимает [, а } снимает {. Строка закончилась, стек пуст. Для ([)] после двух символов на вершине находится [, поэтому ) сразу обнаруживает несовпадение. Покажите именно такой отрицательный пример: он отличает решение со стеком от недостаточного подсчёта количества символов.
Объясните сложность без заученной формулы
Пусть n — число символов. Каждый символ обрабатывается один раз; каждая открывающая скобка добавляется и удаляется не больше одного раза. Размер словаря пар фиксирован. С учётом амортизированной стоимости добавления в конец списка время составляет O(n), дополнительная память — O(n) в худшем случае, когда все символы открывающие. Для пустой строки память остаётся постоянной, но оценку худшего случая это не меняет.
Подбирайте тесты по причинам возможной ошибки
Хороший тест отвечает на конкретный риск. Пустая строка проверяет согласованный контракт. Один открывающий символ ловит забытый финальный контроль стека. Один закрывающий выявляет попытку вызвать pop у пустого списка. Неправильная вложенность отличает проверку порядка от подсчёта. Посторонний символ проверяет, не игнорирует ли реализация вход вопреки условию. Несколько соседних пар показывают, что функция поддерживает не только одну вложенную цепочку.
Вход | Результат | Что проверяем |
|---|---|---|
пустая строка | True | Базовый случай |
{[()]} | True | Вложенность разных типов |
([)] | False | Порядок закрытия |
(() | False | Оставшаяся открывающая скобка |
(a) | False | Посторонний символ |
После исправления ошибки повторно выполните весь небольшой набор. Иначе можно незаметно починить один пример и сломать другой. Если интервьюер меняет правило и разрешает игнорировать буквы, проговорите изменение контракта, исправьте соответствующую ветку и обновите отрицательный тест. Не выдавайте новую версию за эквивалентную прежней: она решает немного другую задачу.
Комментируйте решения, а не каждое нажатие клавиши
Полезный комментарий объясняет выбор: «Проверяю пустой стек до pop, потому что строка может начинаться закрывающей скобкой». Пересказ «сейчас пишу if, теперь return» мешает понимать общий ход. Если нужна пауза, обозначьте её и сформулируйте, что проверяете. Если ошиблись, назовите предположение, которое оказалось неверным, и найдите минимальный контрпример. Это делает исправление понятным собеседнику.
В финале коротко повторите контракт, идею, сложность и оставшиеся ограничения. Не добавляйте новые абстракции только ради впечатления. Для трёх видов скобок отдельная иерархия классов не даёт преимущества. Если времени осталось мало, работающее решение с ясными проверками полезнее незавершённой универсальной конструкции.
Как повторить тренировку самостоятельно
- Решите задачу с таймером и запишите объяснение вслух.
- Проверьте, были ли озвучены контракт и инвариант до написания кода.
- Закройте решение и воспроизведите его на следующий день.
- Измените условие: разрешите обычный текст или возвращайте позицию первой ошибки.
- Сравните набор тестов до и после изменения, объяснив причину каждого нового случая.
Для следующего занятия выберите задачу на другую структуру данных: словарь, очередь или множество. Цель подготовки — научиться связывать ограничения с решением, а не узнавать только знакомую формулировку. Сохраните короткую заметку: где задержались, какой тест забыли и какое объяснение было непонятным. На следующей тренировке проверяйте именно эти пункты.