Як вести технічні розмови англійською мовою

Початок нової інженерної роботи є однією з найбільш лінгвістично вкрай складних ситуацій для носіїв англійської мови, для яких англійська не є рідною. Ви засвоюєте нові технічні поняття, новий словниковий запас і нову командну динаміку - все на другій мові, часто через відео дзвінки. Знання правильних фраз для початку розмови робить справжню різницю: це допомагає вам ставити кращі запитання, будувати відносини з вашим другом і встановити себе як розважливого інженера з першого дня.

Ключовий словник

Система друзей Зазвичай, структура впровадження, де новий найманий працівник поєднується з досвідченим членом команди (їх «друг» або «друг впровадження»), який керує ними протягом перших тижнів. Відрізняється від офіційного наставника - більш неформальний і щоденний.

• Приклад: « Мене поєднано з Сарою як моїм другом з розгортання — вона веде мене через процес розгортання. »*

Передача знань Процес передачі інформації від однієї особи або команди до іншої, часто, коли хтось вступає, залишає або коли змінюються обов’ язки.

• Приклад: « У нас є двотижневий період передачі знань перед тим, як початковий автор перейде до іншої команди. » *

** Проходження кодової бази ** Прогулянка кодом — пояснення основних компонентів, як вони поєднуються, де знайти речі, і які є основні шаблони.

• Приклад: « Чи можете ви зробити для мене перегляд коду? Я читав документацію, але я не впевнений, як послуги з’єднуються. ”*

Командні норми Неписані (або письмові) угоди про те, як працює команда — стиль коду, етикет перегляду PR, культура зустрічей, переваги спілкування.

• Приклад: «Які норми команди для перегляду коду? Чи очікуєте ви, що коментарі будуть розглянуті перед об’єднанням, або просто підтверджені?»*

Время подъема Період між початком нової ролі і повним призначенням. Це нормально і очікувано - хороші команди планують на це. Приклад: “Я приблизно три тижні в моєму підйомі. Я відчуваю себе комфортно в фронтенді зараз, але я все ще знайомлюся з бекенд-сервісами. ”

** Допомога з налаштуванням ** Допомога з налаштуванням середовища розробки, встановленням інструментів, отримання доступу до систем і запуском програм локально у перший раз.

• Приклад: « Мені може знадобитися допомога з налаштуванням — я отримую помилку розпізнавання під час спроби запустити локальне середовище. » *

Парковка Список питань або тем, до яких слід повертатися пізніше, щоб вони не зірвали поточну розмову. Дуже часто трапляється під час сеансів запуску, коли просте питання відкриває велику тему.

• Приклад: “Чудове питання — давайте покладемо це на парковку і повернемося до нього після того, як ми закінчимо огляд архітектури.” *

Фрази і фразеологізми

Я покажу вам код Стандартна фраза для запрошення на екскурсію кодом. Запам’ятай це - ти почуєш це і будеш говорити це постійно.

• Приклад: « Дозвольте мені запланувати годину, щоб провести вас через базу коду. Ми розпочнемо з шару даних і працюватимемо до API.”*

“Можете показать мне…?” Ввічливий спосіб запитати, де щось знаходиться — документація, файл, канал Slack, runbook.

• Приклад: « Чи можете ви відправити мене до документації щодо служби розпізнавання? » Я не зміг знайти його в Confluence.”*

“Только чтобы убедиться, что я правильно понял…” Професійний спосіб перефразувати те, що ви чули і підтвердити своє розуміння - не звучачи так, ніби ви не звертали уваги.

• Приклад: « Тільки щоб переконатися, що я правильно розумію — API-шлюз обробляє автентифікацію, а окремі служби довіряють токену без повторної перевірки? »*

“Что здесь за обычай…?” Запитує про норми команди або встановлені шаблони, не припускаючи, що ви їх знаєте. *Приклад: « Яка тут угоди щодо назв гілок? Я бачив і feature/, і feat/ в історії сховища.» *

“Я сначала пройдусь, а потом проверю у тебя” Професійний спосіб сказати, що ви спочатку спробуєте самостійно, а потім попросите про відгук, демонструючи ініціативу, не боячись просити про допомогу.

• Приклад: « Я спочатку налаштую локальне середовище за допомогою README, а потім перевірю з вами, якщо щось не вийде. » *

“Чи є хтось, з ким можна поговорити про…” Перенаправляє вас до відповідного експерта з даної теми, не змушуючи вашого друга відчувати себе відповідальним за все.

• Приклад: « Чи є хороша людина, з якою можна поговорити про конвеєр даних? » Я не хочу забирати занадто багато вашого часу на теми, що не належать до вашої сфери»

Практичні рекомендації

1. “Чи можемо ми запланувати проходження кодової бази на цей тиждень? Я прочитав архітектуру документації, але я б хотів побачити це пояснено в контексті. ”
2. Які норми команди щодо розміру PR? Я робив менші затвердження, але я не впевнений, чи це очікується тут»
3. «Тільки щоб переконатися, що я правильно розумію — ми розгортаємо стадіювання автоматично при злитті, але виробничі розгортання вимагають вручну схвалення?»
4. «Я додам це до парковки — я хочу зрозуміти основи перш ніж я занурюся в логіку повторних спроб»
5. “Можете показать мне справочник по дежурству? Я б хотів прочитати його перед моєю першою ротацією»

Необхідно уникати помилок

** Притворяясь, что понимаешь, когда ты не понимаешь** При вступі на службу, очікується, що ти нічого не знаєш. Сказав “так, я розумію”, щоб не виглядати збентеженим, насправді сповільнює твій підйом.

• Замість мовчазного запитання або відповіді « так »: скажіть « Чи можете ви пояснити, що ви маєте на увазі під [терміном]? Я хочу переконатися, що я не роблю припущень.»*

Задавать слишком много вопросов сразу Задавання п’ яти питань в одному повідомленні або на одній зустрічі може перевантажити вашого друга. Пакетні пов’ язані питання і пріоритетні питання, які вас блокують.

• Замість переліку десяти питань: скажіть « У мене є декілька питань щодо потоку розгортання — чи можу я їх обговорити з вами? » Найважливіша з них — це…»*

** Не продовжувати після проходження ** Передача знань залишається тільки якщо ти переглядаєш її. Професійне повідомлення про подальші дії показує ініціативу.

• Приклад: « Дякую за вчорашній огляд. Я зробив кілька записок — чи не завадило б вам переглянути їх, щоб перевірити, чи я правильно зрозумів ключові моменти?»*

Summary

Технічні розмови мають свій власний словник і етикет. Незалежно від того, чи ви новий працівник, що навчається, чи досвідчений інженер, який керує новачком, такі фрази, як «Я провожу вас кодовою базою», «Яка тут конвенція» і «Просто щоб переконатися, що я правильно розумію» є будівельними блоками ефективної передачі знань. Мета впровадження - не вразити - це ефективно навчатися, будуючи довіру з вашою новою командою.

Використовується для визначення точності мовлення

Багато розробників, які переходять до міжнародних команд, знаходять початкові розмови про вступ - особливо ті, що включають технічні обговорення - неймовірно пригнічуючими. Це не просто про передачу ваших ідей; це про те, щоб зробити це чітко і впевнено в рамках певної професійної англійської мови. Для не-рідних носіїв, це може бути приголомшливо, особливо коли стикаються з нюансами або складними поясненнями. Ключовим елементом, який часто ігнорується, є намірність фрази. Просто сказати, що вам потрібно, не завжди достатньо. Навчання сформулювати свої вимоги і зрозуміти точки зору інших через ретельно обрані слова значно зменшує непорозуміння і сприяє зміцненню відносин.

Розглянемо звичайний сценарій: отримання коментаря перегляду коду на запит на витягування. Проста відповідь на зразок «Гаразд, я виправлю це» може бути ввічливою, але не має важливого контексту. Замість цього, намагайтеся дати більш докладні описи. « Дякую за відгук! Я понимаю вашу обеспокоенность по поводу потенциальных последствий такого подхода для производительности. Я збираюся переробити код, щоб використовувати [спеціальну техніку] — чи можете ви пояснити, чому це було запропоновано більш докладно? Я хочу переконатися, що я ефективно вирішую кореневу причину. “Зауважте, як розширена відповідь демонструє активне слухання, визнає експертизу рецензента і шукає пояснення * перед * впровадженням рішення. Цей активний підхід зменшує шанси на переробку і демонструє вашу прихильність до якості.

Іншою часто зустрічається ситуацією є пояснення вашої роботи на каналі Slack або під час короткого огляду. Уникайте нечітких тверджень на зразок « Я працюю над цією можливістю. » Замість цього спробуйте « Зараз я реалізую кінцеву точку API для автентифікації користувача, зосереджуючись на безпечному гешуванні паролів за допомогою [назва алгоритму] і інтеграції з нашим існуючим потоком OAuth. Я розгорну цю інформацію у середовищі тестування до кінця дня. » Цей рівень деталізації надає вам можливість негайно побачити контекст і дозволить членам вашої команди швидко зрозуміти ваш прогрес і всі потенційні перешкоди. Це демонструє, що ви не просто щось робите, а активно повідомляєте про його мету і деталі реалізації.

Наконец, помни, что задавать проясняющие вопросы - это признак силы, а не слабости. Не вагайтеся сказати «Чи можете ви розібратися, що ви маєте на увазі під «зменшити затримку» в цьому контексті?» або «Чи можете ви надати приклад того, як ця інтеграція повинна обробляти крайові випадки?». Використання фраз на кшталт «Щоб переконатися, що я правильно розумію…» перед перефразуванням чиєїсь пояснення є особливо корисною технікою, яка показує справжні зусилля і дозволяє негайно виправити, якщо це потрібно. Сфокусування на точності вашої мови створює довіру і сприяє плавнішій співпраці у команді.