Як говорити через Take-Home Coding Challenge Submission англійською мовою

Розмова про виклик кодування, який потрібно взяти додому, часто важча, ніж сам виклик — ви повинні захищати рішення, які прийняли кілька днів тому, визнати, що ви зробили б по-іншому, і робити все це в реальному часі без записів. Цей підручник містить інформацію англійською мовою, яка вам потрібна для того, щоб ясно і впевнено проаналізувати ваші повідомлення.

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

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

• “Дозвольте мені спочатку проаналізувати рішення на високому рівні: я розділив задачу на шар аналізу, шар перевірки і основну логіку відповідності, і я проаналізую кожен з них.” *

** Обґрунтування рішення щодо дизайну ** — пояснення причин конкретного вибору, який ви зробили, особливо того, який очевидно не є єдиним варіантом, щоб інтерв’ юер розумів, що це було навмисне.

• “Я хочу обґрунтувати одне рішення щодо дизайну: я обрав перевірку вводу на межі API, а не глибоко у службі, тому що я хотів, щоб неправильні дані зазнавали невдачі швидко і гучно, а не поширювалися.” *

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

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

** « Якщо б у мене було більше часу, я б… » ** — стандартне визначення для опису поліпшень, яких ви не зробили, що свідчить про розуміння розриву між кодом, який ви можете взяти додому, і кодом, який можна використовувати у виробництві.

• “З більшим часом, я б додав інтеграційні тести навколо потоку платежу, оскільки це частина з найвищим ризиком, якщо вона зламалася.” *

Звичайні фрази

• «Ядро ідеї за моїм підходом є [X], тому що [розуміння]»
• «Я зробив тут компроміс: я віддав перевагу [читабельності/швидкості/простоті] над [альтернативою]»
• «Ця частина навмисно проста — давши більше часу, я б розширив її, щоб обробляти [країнний випадок]»
• «Я розглядав [альтернативний підхід], але пішов з цим замість того, щоб [причина]»
• «Якби це йшло в виробництво, перше, що я б додав, це [моніторинг/тестування/обробка помилок]»

Приклади висловлювань

Відкриття огляду:

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

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

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

Назва відомого обмеження:

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

Професійні поради

• Починайте з проходу високого рівня перед деталями коду — співбесідник часто втрачає нитку, якщо ви перескочите прямо в пояснення рядок за рядком.
• ** Обґрунтовуйте рішення** проактивно, особливо нестандартні — мовчання закликає інтерв’юера припустити, що ви не думали про це.
• ** Підтверджуйте скорочення ** самостійно, перш ніж вас про це запитати; це демонструє здатність до оцінки виробництва навіть у вправі з обмеженим часом виконання.
• Підготуйте два або три справжніх «з більшим часом, я б…» пункти заздалегідь — нечіткі відповіді на кшталт «Я б полірував його більше» читаються як не підготовлені.
• Коли викликають на рішення, відповідайте з допитливістю, а не обороною - “це справедливий момент” є сильним відкриттям, навіть якщо ви все ще вірите в свій початковий вибір.

Практичні вправи

1. Напишіть коротке резюме проекту, який ви створили, у вигляді двох речень, так, ніби ви відкриваєте огляд проекту.
2. Наведіть список трьох скорочень, які ви використовували у реальному проекті, і напишіть одне речення, у якому згадаєте про кожне з них.
3. Створити три чернетки « з більшим часом, я б … » для недавнього коду, який ви написали.

Національний інститут стандартизації: Англійська мова для професійного використання

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

Однією з найчастіших проблем є формування зворотнього зв’ язку, навіть якщо ви не погоджуєтесь з коментарем рецензента. Замість того, щоб відразу ж сказати «Це неправильно!», що негайно створює оборонну стіну, спробуйте такі фрази, як: «Я ціную пропозицію про використання бібліотеки X тут. Я спочатку розглядав це, але я вибрав Y через [особливу причину, пов’ язану з продуктивністю, підтримкою або стандартами команди]. Це те, що я буду пам’ятати про майбутні проекти.” Зауважте використання “Я ціную”, яке пом’якшує початкове твердження і визнає внесок рецензента. Іншою корисною фразою є «З моєї точки зору…» — це дозволяє вам представити свої міркування без прямого суперечення інтерв’юеру. Не менш важливо визнати потенційні недоліки; сказати: «Хоча цей підхід був би простішим в цьому конкретному випадку, я передбачаю потенційні проблеми масштабування з більшими наборами даних», демонструє передбачення і розуміння ширших наслідків.

Крім того, при описі ваших варіантів розробки у описі запиту на звантаження, уникайте надмірно технічного жаргону, якщо це не є абсолютно необхідним. Замість того, щоб сказати « Я реалізував алгоритм рекурсивного пошуку з першою глибиною », спробуйте сказати « Я використав рекурсивний підхід для дослідження структури даних, який надав ефективне рішення цієї проблеми ». Ця фраза є більш доступною і показує, що ви розумієте, * чому * ви обрала цей метод. Також, будьте готові пояснити ваші компроміси - це цілком прийнятно (і часто очікується) сказати щось на зразок “Я поставив на перше місце швидкість реалізації тут, щоб врахувати термін, приймаючи трохи менш оптимальне рішення для довгострокового підтримання.” Прозорість про пріоритети є ключем. І нарешті, не соромтеся задати прояснюючі питання. Якщо ви справді не розумієте коментар рецензента, ввічливо запитайте про подальші пояснення: « Чи могли б ви розібратися у аспектах мого коду, які вас хвилюють? » Це демонструє вашу зацікавленість і бажання вчитися.