Вопросы асинхронного технического интервью, которые действительно выявляют навык

Проблема асинхронного вопроса

В 2026, почти любая классическая головоломка алгоритма, которую кандидат видит в асинхронном take-home, решается языковой моделью в секунды. Так же большинство LeetCode. Так же каноничные "реализовать кэш" и "построить URL shortener" вопросы.

Если ваш асинхронный stage всё ещё использует вопросы из 2020 interview-prep канона, вы не скринируете инженерский навык — вы скринируете доступ ChatGPT. Этот пост собирает четыре вопрос форматы, которые сопротивляются тривиальному AI завершению и производят реальный сигнал в асинхронном setting.

Формат 1: Read-this-codebase вопросы

Кандидату дан небольшой repository (50–500 линий) и просят сделать что-либо с ним: найти баг, добавить функцию, рефакторить класс, написать отсутствующий тест.

Пример для backend роли:

"Приложен небольшой Express API с users endpoint. Есть баг, который заставляет endpoint возвращать stale данные после обновления профиля пользователя. (1) Найди и исправь баг. (2) Добавь тест, который бы его поймал. (3) Напиши 2–3 предложения, объясняющие основную причину."

Почему это работает:

• Кандидат должен читать код, а не просто писать его. AI может писать; кандидат всё ещё должен понимать.
• "Объясни причину" deliverable короткий, но выявляет глубину. AI-generated объяснения могут быть обобщённые; реальные инженеры указывают на специфичную линию.
• Live follow-up вопрос ("проведи меня через то, как ты нашёл баг") коллапсирует любую AI-only submission.

Формат 2: Tradeoff-design вопросы

Вместо "реализуй X", спроси "спроектируй X и напиши вниз что ты рассматривал."

Пример для senior инженера:

"Спроектируй простой rate limiter для внутреннего API, обслуживающего 50 RPS в пик. Реализуй рабочую версию (любой язык) и 1-страничный README объясняющий: (1) алгоритм, который ты выбрал и по меньшей мере одна альтернатива, которую ты отклонил, (2) что ты бы изменил если трафик вырос до 5000 RPS, (3) что ты не обрабатываешь и почему."

Почему это работает:

• Код это небольшая часть. README это сигнал.
• "Что ты не обрабатываешь" это killer вопрос. AI плохо с признанием лимитов; senior инженеры делают это естественно.
• Deliverable короткий для чтения (≤15 мин для рецензента), в отличие от 4-часового проекта.

Формат 3: Debug-this-failure вопросы

Дай кандидату passing тест, failing тест и код under test. Спроси их сделать failing тест pass без разрушения passing одного.

Этот формат сложно геймифицировать с AI, потому что AI склоняется к over-rewrite. Кандидат, который рассуждает о минимальных изменениях, будет превосходить кандидата, который вставляет переведённый файл.

Пример:

"Приложена date-parsing утилита. Функция правильно обрабатывает ISO 8601 даты (тест 1 passes). Она не обрабатывает даты с mixed-case месячными аббревиатурами как 12-Mar-2025 (тест 2 fails). Сделай тест 2 pass без разрушения теста 1. Отправь наименьший patch, который можешь."

Фраза "наименьший patch" делает работу. Рецензенты могут прочитать 3-line diff в 30 секунд.

Формат 4: Code-review-style вопросы

Дай кандидату кусок кода с 3–5 проблемами разной серьёзности и спроси их подать code review.

Пример для mid-level роли:

"Приложен pull request, добавляющий новый /checkout endpoint в наш e-commerce API. Рецензируй его как если бы коллега его отправил. Перечисли проблемы, на которых ты бы заблокировал, проблемы, которые ты бы предложил и по меньшей мере одно, что автор сделал хорошо. Упорядочи их по серьёзности."

Почему это работает:

• Инженерия это в основном чтение чужого кода, не написание greenfield кода. Этот вопрос тестирует реальную работу.
• Это выявляет суждение ("ты бы заблокировал или просто предложил?"), какой это senior-vs-mid сигнал.
• Это сложно outsource: AI может flag очевидные проблемы, но ранжирует их плохо и редко ловит subtle проблемы.

Чего избегать в асинхронных вопросах

• Pure algorithm головоломки. "Реализуй sliding window для X" — решено AI в секунды, слабо предсказывает производительность работы даже до AI.
• Что-либо над 2 часами. Top кандидаты пропускают эти. Смотрите drop-off данные на бюджет времени.
• Generic CRUD приложения. "Построй список дел с Postgres" — каждый кандидат производит near-identical submission.
• Вопросы с одним правильным ответом. Асинхронный формат лучше всего на выявлении суждения, что требует множество валидных ответов.

Following up live

Каждое асинхронное кодирующее упражнение должно быть спарено с 20-минутным live follow-up, где кандидат проходит свою собственную submission. Этот единственный step делает больше для целостности чем любой AI-detection инструмент. В ClarityHire, live room загружает submitted кандидат код автоматически, поэтому интервьюер прибывает подготовленный.

Pairing вопросов с rubrics

Отличный вопрос без rubric всё ещё производит inconsistent результаты. Для каждого вопрос формата выше, pre-write a скоринг rubric с по меньшей мере 3 anchored уровнями (1 = below bar, 3 = at bar, 5 = above bar) перед первой submission приземлением. Смотрите наш best-practices guide для полного асинхронного найма playbook.