Глава 11. Техническое интервью на английском

Введение

Техническое интервью на английском — стресс-тест для языка. Всё, что на обычном созвоне сглаживают контекст и знакомые лица, здесь играет против тебя: собеседник чужой, ставка высокая, время идёт, и параллельно с языком надо ещё решать задачу. Поэтому интервью регулярно проваливают инженеры, которые технически сильнее половины нанимающей команды.

Суть проблемы вот в чём: оценивают не правильность английского, а понятность твоего мышления вслух. Интервьюер не умеет читать мысли, у него есть только твоя речь. Молчаливый гений, решивший задачу за три минуты и не сказавший ни слова, получит отказ. Человек, который вслух перебрал три подхода, объяснил выбор и сам назвал слабое место решения, получит оффер — даже с недописанным кодом.

Пройдём весь процесс, от скрининга до разговора про деньги, с конструкциями на каждом этапе. Отдельно займёмся двумя вещами, которые чаще всего решают исход: рассказом о себе и техникой thinking aloud.

Формат интервью в международной компании

Типовой процесс — четыре-пять этапов, у каждого свои правила игры. Понимать, на каком ты сейчас, стоит хотя бы потому, что одна и та же реплика на одном этапе попадает в цель, а на другом топит.

Термины из писем: screen (отсеивающий звонок, а не «показ экрана»), onsite (финальный блок интервью, часто уже удалённый), loop (серия интервью подряд), take-home assignment (задача на дом), hiring manager (потенциальный руководитель), debrief (внутренняя встреча, где решают твою судьбу).

Отсюда практический вывод. На скрининге с рекрутером не углубляйся в технику: человек напротив оценивает связность речи и мотивацию, а не твоё мнение про eventual consistency. На system design, наоборот, не лезь писать код. Несовпадение формата и поведения отправляет в отказ не реже, чем слабый ответ.

«Tell me about yourself»: структура present — past — future

С этого вопроса начинаются девять интервью из десяти, и он же чаще всего проваливается. Типичная ошибка — пересказ резюме от первой работы в хронологическом порядке. Резюме интервьюер уже читал; на второй минуте он открывает почту.

Работает другая структура: три блока по 30–40 секунд, всего полторы-две минуты. Present — кто ты сейчас и чем занимаешься. Past — только тот кусок прошлого, который объясняет, почему ты подходишь именно на эту роль. Future — что ищешь. Последний блок недооценивают чаще всего, а он единственный связывает тебя с конкретной вакансией.

I'm a backend engineer with about six years of experience, mostly
in Python and Go. Right now I'm at a fintech company where I own
the payments service — it handles around two thousand transactions
per minute, and I'm the person on call for it.

Before that I spent three years at a smaller product company. That's
where I got into distributed systems, mostly the hard way: we had a
nasty data consistency issue that took me two months to properly
fix. That project is the reason I care so much about idempotency and
observability now.

What I'm looking for next is a place where I can work on
infrastructure at a larger scale. Your job posting mentioned moving
from a monolith to event-driven services — that's exactly the
problem I've been living with for the past year, and I'd like to do
it once more with the lessons I've already paid for.

Что здесь работает. I own the payments service — глагол own в рабочем контексте про ответственность, а не про собственность; сильное слово, сразу показывающее уровень. Число two thousand transactions per minute задаёт масштаб: без чисел все рассказы о себе звучат одинаково, и «я делал платежи» в стартапе на трёх пользователей не отличить от того же в банке. The hard way — «научился на собственных шишках». А финальный блок прямым текстом цитирует вакансию — видно, что ты её открывал. Связки для каждого блока:

Рассказ о проекте: STAR и числа

На вопросы вида Tell me about a project you worked on отвечай по схеме STAR: Situation, Task, Action, Result. Придумали её для behavioral-интервью, но и на технических рассказах она держит форму: слушателю даёт каркас, тебе не даёт расползтись на десять минут про то, какой в проекте был легаси.

Сильный STAR от слабого отличают два правила.

Первое: «я», а не «мы». Русскоязычные инженеры по привычке говорят we did — скромность, вбитая с институтских времён. Интервьюер в итоге не понимает, что из перечисленного сделал ты, и на всякий случай не засчитывает ничего. Баланс такой: контекст на we, действия на I. We decided to move to a queue, and I was the one who designed the retry semantics. Это не хвастовство, а ответ на заданный вопрос.

Второе: числа. Без них любой результат звучит как «стало лучше». Впечатляющими они быть не обязаны, обязаны быть конкретными: the build went from 18 minutes to 6, it saved the support team about ten hours a week. Точной цифры не помнишь — выручает честное roughly. Врать не надо, никого ещё не поймали на округлении, зато на выдуманных миллионах RPS ловят регулярно.

Thinking aloud: главный навык не-носителя

На live coding оценивают процесс мышления, а не только итоговый код. Для не-носителя это разом и трудность, и подарок: думать вслух можно короткими простыми фразами, и весь их набор — штук пятнадцать. Выучил — закрыл большую часть разговорной нагрузки интервью.

Разложим сессию на этапы, с формулами на каждый.

1. Убедиться, что понял задачу. Не бросайся кодить. Первые тридцать секунд — пересказ условия своими словами.

Let me make sure I understand the problem. We're given a list of
intervals, and we need to merge the ones that overlap and return
the result sorted by start time. Is that right?

2. Задать уточняющие вопросы. Про них отдельный раздел ниже. Пока запомни главное: вопросы — часть решения, а не признание в незнании.

3. Проговорить первую идею и её обоснование. Обязательно с because.

My first thought is a hash map, because we need constant-time
lookups and the order doesn't matter here.

The brute force approach would be two nested loops, which is O(n²).
Let me start with that just to have something working, and then
we can optimize.

Ход «сначала грубое решение, потом оптимизация» ценится высоко: он показывает, что ты двигаешься итеративно, а не зависаешь на двадцать минут в поисках красивого. На реальной работе это ровно то же поведение, и интервьюер это считывает.

4. Комментировать по ходу. Молчание дольше десяти секунд — тревожный сигнал для того, кто на тебя смотрит. Думаешь — скажи, что думаешь.

Let me think about the edge cases for a second.

I'm going to name this variable "seen" — it'll hold the elements
we've already processed.

I'll skip the input validation for now and come back to it if we
have time.

5. Признать и исправить ошибку. Возможно, самый сильный момент интервью. Инженер, который сам поймал свой баг вслух, выглядит лучше инженера, который его не сделал: второму просто повезло, а первый показал рабочий механизм самопроверки.

Actually, that won't work for duplicates — let me adjust.

Hold on, I'm overcomplicating this. There's a simpler way: we can
just sort by start time first.

Wait — this breaks if the list is empty. Let me add a guard.

6. Оценить сложность. Проговаривай в конце всегда, даже если не спросили. Не спросили — значит, собирались спросить через минуту.

The time complexity here is O(n log n) — the sort dominates, the
merge pass is linear. Space is O(n) for the output, or O(1) extra
if we're allowed to modify the input in place.

7. Проверить на примере. Прогони решение вслух по маленькому входу: Let me trace through a quick example: input is one-three, two-six, eight-ten... Половина найденных на интервью багов находится именно здесь.

Все эти фразы короткие и грамматически примитивные. Отрепетируй их вслух до автоматизма — вслух, не глазами. Тогда на интервью мозг займётся задачей, а рот сам выдаст нужный комментарий, и тебе не придётся делать две трудные вещи одновременно.

Уточняющие вопросы и как они спасают

Задачи на интервью недоопределены намеренно. Интервьюер ждёт вопросов, это часть оценки. Кандидат, который бросился кодить по первому прочтению условия, в реальной работе точно так же бросится реализовывать недописанный тикет — и вот эту аналогию проводит любой нанимающий.

Базовый набор, подходящий почти к любой задаче:

Should I handle empty input?
Can I assume the input is sorted?
How large can the input get? Are we talking thousands or billions?
Can the values be negative? Can they be duplicated?
Is it okay if I modify the input array in place?
What should happen on invalid input — return null, or throw?
Are we optimizing for read or write?
Do we care more about memory or speed here?

Отдельно про Are we optimizing for read or write? Один этот вопрос переводит задачу из абстрактной в инженерную и часто меняет ответ целиком. То же с масштабом: решение на тысячу элементов и решение на миллиард — разные решения, и произнести это вслух дороже, чем написать правильный код.

Ещё ход: если спрашивать неловко или момент упущен, проговори допущение. I'm going to assume the input fits in memory. If that's not the case, we'd need a streaming approach — happy to talk about that after. Границу обозначил, широту взгляда показал, время не потратил.

Лексика system design

System design — разговор почти без кода и с очень плотной терминологией. Без неё мысль не выразить, даже если архитектуру ты понимаешь лучше интервьюера. Минимальный словарь ниже нужно не узнавать при встрече, а произносить самому.

Самая ценная фраза раздела — it depends on the load profile. Это не увиливание, а профессионально корректный ответ: архитектура действительно зависит от характера нагрузки. Только произносить её надо целиком: It depends on the load profile. If reads dominate by a factor of a hundred, I'd go with denormalized views. If it's write-heavy, that becomes too expensive and I'd keep it normalized. Ты не ушёл от ответа — ты дал два ответа с условиями. Вот этого и ждут. Оборванное it depends без продолжения, наоборот, звучит как попытка спрятаться.

Ещё три оборота для компромиссов: This trades X for Y (this trades write latency for read simplicity), The downside is..., That would work, but it doesn't scale past a single region.

Behavioral: «Tell me about a time when...»

Поведенческие вопросы начинаются одинаково: Tell me about a time when... — а дальше конфликт, провал, дедлайн, спор с руководителем. Готовят к ним не ответы, а истории: три-четыре штуки, каждая по STAR, потом подгоняются под вопрос почти любой формулировки.

Классический набор тем: конфликт с коллегой, крупная собственная ошибка, невыполнимый дедлайн, случай, когда пришлось убеждать команду, работа без внятной постановки.

Самая скользкая — про собственную ошибку. Тут легко либо утопить себя (I deployed to production on Friday and took the site down for four hours — и точка), либо соврать (I can't really think of any mistakes, после чего интервьюер мысленно ставит крестик). Работает другое: короткое честное признание, минимум оправданий, максимум про то, что ты сделал дальше и что изменил в системе.

A couple of years ago I ran a database migration that dropped a
column we still needed. It was on a staging clone first, but I got
the environment variable wrong and it hit production. About twenty
minutes of degraded checkout.

I noticed it in the metrics, rolled back from the backup, and told
the team in the incident channel right away rather than trying to
quietly fix it.

Afterwards I wrote the postmortem, and the two things that came out
of it stuck: we made destructive migrations require a second
approver, and we added a loud confirmation prompt that prints the
target environment. Nobody has repeated that particular mistake
since.

Разберём, что здесь сделано правильно. Ошибка названа прямо, без тумана. Масштаб последствий честный и конкретный: двадцать минут, а не «катастрофа» и не «небольшой сбой». Отдельно подчёркнута немедленная коммуникация — rather than trying to quietly fix it. Нанимающие ценят это выше технической части ответа, потому что тихое замалчивание инцидента дороже самого инцидента. И финал не про самобичевание, а про системное изменение: из ошибки выросли два правила, которые теперь работают без участия автора.

Конструкции для behavioral-ответов:

Как правильно сказать «не знаю»

Тебя обязательно спросят о том, чего ты не знаешь. Так устроено интервью: хороший интервьюер копает вглубь, пока не упрётся в границу твоих знаний, — иначе он не поймёт, где эта граница проходит. Дойти до неё нормально. Провал — не незнание, а два поведения вокруг него: блеф и капитуляция.

Блеф вычисляется мгновенно, обычно вторым уточняющим вопросом, и заодно обесценивает всё, что ты успел сказать до этого. Капитуляция — I don't know и тишина — закрывает тему и не оставляет интервьюеру материала для оценки.

Работает формула из трёх частей: честная граница плюс то, что ты знаешь рядом, плюс рассуждение по аналогии.

I haven't worked with Kafka directly, but based on what I know
about queues in general, I'd expect the consumer group to keep an
offset per partition, and rebalancing to happen when a consumer
drops out. Is that roughly how it works?

I don't know the exact syntax off the top of my head, but the idea
would be a window function partitioned by user and ordered by
date — I'd look up the exact form.

That's outside what I've done. My guess would be that it's a
trade-off between index size and lookup speed, but I'd want to
measure rather than guess.

Обрати внимание на концовку первого примера: Is that roughly how it works? Слабая зона превратилась в диалог, и ты заодно узнал ответ. Интервьюеры объясняют охотно — это их любимая тема, и после такого ты запоминаешься как любопытный и обучаемый, а не как человек с дырой в знаниях.

Ещё три оборота на каждый день: off the top of my head (навскидку, по памяти), I'd have to look that up (посмотрел бы в документации), I've read about it but never used it in production — честная граница между теорией и практикой, которую собеседник обычно оценит.

Вопросы работодателю и разговор про деньги

В конце каждого этапа прозвучит Do you have any questions for us? Ответ No, everything is clear — упущенная возможность и тихий минус в заметках: читается как «мне всё равно, где работать». Держи наготове три-четыре вопроса, желательно разного типа.

What does a typical week look like for someone in this role?

How do changes get from a developer's laptop to production? How
long does that usually take?

What's the on-call rotation like?

What's the biggest technical challenge the team is facing right now?

How is technical debt handled here — is there dedicated time for it?

What would a successful first three months look like for me?

Последний вопрос особенно хорош: показывает ориентацию на результат и вытаскивает наружу реальные ожидания от роли. Иногда ответ на него — единственная причина отказаться от оффера.

Про деньги. Тема кажется неловкой ровно до первого разговора: в англоязычной практике найма обсуждать вилку на раннем этапе нормально и экономит время обеим сторонам. Главный приём — сделать так, чтобы диапазон первым назвал работодатель.

Is there any flexibility on...? — стандартная и совсем не агрессивная формула торга. Она ничего не требует и ни на что не давит, а спрашивает о возможности. Ответ no на неё тоже нормален и ничего не портит: спросить и услышать «нет» дешевле, чем год работать за меньшее.

Кейс из реального проекта: «Tell me about a challenging bug you fixed»

Возьмём один из самых частых вопросов интервью и два ответа на него — от одного и того же человека, про один и тот же баг. Технически он в обоих случаях одинаково компетентен. Разница в языке и структуре, и она решает исход.

Слабая версия:

Yes, we had a very difficult bug. It was in production and it was
very hard. The system sometimes worked incorrectly and users
complained. We looked at logs for a long time, it was really
painful. Then we found the problem, it was a race condition in the
code. We fixed it and everything was fine. It was a good
experience.

Что не так — по пунктам. Нет контекста: что за система, какой масштаб, что именно ломалось. Нет ролей: сплошное we, и вклад кандидата не отделить от вклада команды. Нет метода — «долго смотрели логи» ничего не говорит о том, как человек диагностирует проблемы, а спрашивали ровно об этом. Нет чисел. Нет вывода. И лексика уровня A2: very difficult, very hard, really painful, everything was fine — прилагательные там, где нужны факты. Венчает всё It was a good experience, фраза-пустышка.

Полминуты речи, ноль информации. Интервьюеру нечего записать в форму оценки, а он обязан что-то записать.

Сильная версия:

Sure. The one that comes to mind is a race condition in our order
service.

The symptom was odd: roughly one order in ten thousand ended up
charged twice. Support saw maybe two or three cases a week, so it
was easy to dismiss as a payment provider glitch — but the money
was real, so I picked it up.

I couldn't reproduce it locally, so I started from the data. I
pulled the affected orders and looked for anything they had in
common. All of them had two payment attempts less than 200
milliseconds apart, which pointed at double submission rather
than a provider issue.

From there I traced it to our retry logic. The client retried on
timeout, and our handler wasn't idempotent — we generated the
payment ID inside the handler instead of taking it from the
request. So two requests that were logically the same became two
different payments.

The fix itself was small: we moved to a client-provided
idempotency key and added a unique constraint in the database, so
even if the application logic fails, the database refuses the
duplicate. I also added a metric for duplicate-key rejections so
we'd see it immediately if it came back.

After that we went from about ten duplicate charges a week to
zero, and the constraint has caught two other bugs since.

The bigger lesson for me was that "can't reproduce" usually means
"look at the data instead of the code". I now start with the
affected rows rather than the stack trace.

Почему этот ответ сильный.

STAR виден невооружённым глазом. Situation — симптом с числом (one order in ten thousand). Task — почему он вообще взялся. Action — три шага диагностики. Result — числа до и после. Плюс вывод сверху.

Метод показан, а не назван. Вместо «мы долго искали» — цепочка: локально не воспроизводится, значит идём в данные; нашёл общую черту у пострадавших заказов; черта дала гипотезу; гипотеза подтвердилась в коде ретраев. Интервьюер видит, как кандидат думает. Ради этого вопрос и задавали.

«Я» и «мы» расставлены правильно. I picked it up, I traced it, I also added a metric — личный вклад ясен. We moved to a client-provided idempotency key — командное решение обозначено честно.

Защита в глубину показана явно. Кандидат не просто починил логику, а добавил constraint на уровне БД — so even if the application logic fails, the database refuses the duplicate. Это сигнал зрелости: он не доверяет одному слою.

Наблюдаемость. Метрика на отказы по уникальному ключу отличает инженера, который закрывает тикет, от инженера, который закрывает проблему. Стоила она пять строк кода, а весит в ответе больше самого фикса.

Результат измерим и продолжается. The constraint has caught two other bugs since — одна фраза, и видно, что решение работает до сих пор.

Лексика тоже заслуживает внимания: the symptom was odd, easy to dismiss as, pointed at, traced it to, the fix itself was small. Грамматика простая до неприличия. Но каждое слово несёт факт, а не эмоцию, — вот и вся разница между двумя версиями.

Типичные ошибки

Заученный монолог. Мой личный провал, за который до сих пор неловко. Я вызубрил ответ на Tell me about yourself дословно, отчитал полторы минуты без единой запинки и почти успел собой погордиться. Потом интервьюер спросил: You mentioned the payments service — what was the hardest part of owning it? И всё. Текст кончился, а говорить своими словами я в тот момент разучился, потому что полторы минуты работал магнитофоном. Секунд десять я честно молчал. Готовь структуру и ключевые числа, но не текст: проговори рассказ вслух пять раз разными словами, и он станет гибким.

«My English is not very good» в начале. Эта фраза не защищает, а вредит. Ты своими руками вешаешь на разговор дисклеймер, и дальше каждую твою паузу интервьюер списывает на язык, а не на обдумывание. Если разговор вообще состоялся, значит, с языком достаточно нормально. Извиняться не за что.

Односложные ответы. Have you worked with Docker? — Yes. Тишина. Интервьюер тянет из тебя клещами деталь за деталью и к двадцатой минуте выдыхается. Правило: закрытый вопрос отвечай как открытый. Yes — I've been writing our Dockerfiles and the compose setup for local dev for about three years. The trickiest part was getting the build cache to actually work for a Python project. Два предложения сверх yes — и допрос превратился в разговор.

Молчание во время размышления. Кандидат замолкает на две минуты и думает. С той стороны экрана видно застывшего человека и больше ничего: тупик у тебя или финишная прямая, интервьюер не угадает. Озвучивай: I'm weighing two options here, Let me think about the edge cases for a second. Даже I'm stuck on how to handle the empty case лучше тишины — это разрешает собеседнику подсказать, а подсказки в сценарии интервью обычно предусмотрены.

Отрицание любых слабостей. Ответ на What's your weakness? в жанре I work too hard или I can't think of any читается как отсутствие саморефлексии. Схема рабочая: настоящая, но не смертельная слабость плюс то, что ты с ней делаешь. I tend to go too deep into refactoring when I should be shipping. What helps is time-boxing: I give myself a fixed slot for cleanup and open a separate ticket for the rest.

Критика прошлого работодателя. «Там был ужасный код, бестолковый менеджер и легаси-помойка» бьёт по тебе, а не по ним: интервьюер молча примеряет эту речь на свою компанию через год. Переформулируй через собственные цели: The codebase was quite old, which taught me a lot about working with legacy — but there wasn't much room to work on scale, and that's what I'm looking for next.

Итог

Интервью на английском проверяет не богатство языка, а способность внятно показать мышление. Отсюда всё остальное. Рассказ о себе — present, past, future, а не пересказ резюме. Истории о проектах и о поведении — STAR, с числами и честным разделением «я» и «мы». На кодинге — думать вслух: пересказать задачу, задать вопросы, объяснить выбор через because, поймать собственную ошибку, оценить сложность. На system design — активный словарь компромиссов и it depends on the load profile обязательно с продолжением.

Отдельно держи в голове правильное «не знаю»: граница плюс рассуждение по аналогии плюс встречный вопрос. Это не спасательный круг, а нормальный инженерный ответ, и он сильнее блефа и капитуляции вместе взятых.

И последнее. Интервью — отдельный навык, он тренируется не за клавиатурой. Проговори три свои истории вслух и запиши на диктофон. Первое прослушивание будет мучительным, я предупредил. Зато ты услышишь настоящие проблемы — паузы, «эээ», отсутствие чисел, — и починишь их до того, как их услышит интервьюер.

Дальше — навык, который нужен уже после найма и отличает сильного инженера от просто хорошего: умение объяснять сложное. Демо, доклады, design docs. И итог всего курса.