Как отсутствие технического экрана помогло мне вырасти как разработчику

Как инженер-программист, выходящий на рынок труда, у меня была возможность поговорить с десятками компаний, от стартапов из двух человек до гигантских компаний, включая Facebook и Amazon.

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

Я многому научился за время этого процесса.

Одно из моих последних собеседований касалось часового разговора по телефону с инженером Amazon. В дополнение к поведенческому компоненту (там два совета: метод STAR и принципы лидерства), мы потратили чуть больше половины времени, работая над вопросом кодирования на цифровой доске, разговаривая по телефону. Я не прошел через этот этап (иначе я потерпел неудачу - попытался привыкнуть к тому, чтобы сказать это вслух), но я многому научился.

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

Мой интервьюер дал мне два замечательных совета, которые уже помогли мне на последующих технических экранах:

1. Напишите код, как если бы вы здесь работали

Я понял это так, что на собеседовании вы должны писать код так, как будто вы работаете в компании и в команде. Это может показаться очевидным, но когда вы практикуетесь с LeetCode, легко сосредоточиться только на том, чтобы ваша программа прошла все тесты и написала алгоритм с наименьшей пространственной и временной сложностью. Точность, скорость и эффективность важны, но то, что ваш код работает, а алгоритм работает быстро, не обязательно означает, что компания будет рассматривать вас как актив. Другим инженерам необходимо иметь возможность взглянуть на вашу программу и очень быстро понять, что она делает. Они должны уметь быстро вносить изменения. Ваша программа должна масштабироваться. Использование правильных имен переменных, добавление комментариев и, как правило, использование наименее подробных функций и синтаксиса позволит вам выделиться. Более ясная и лаконичная логика может быть даже предпочтительнее чего-то более быстрого, но менее ясного.

2. Структуры данных - ваш друг

У меня был вопрос, который требовал, чтобы я отслеживал, видели ли числа раньше. В итоге я добился этого с помощью массива. В JavaScript есть структура данных, аналогичная массиву, но автоматически не позволяющая добавлять дубликаты. Наборы! Конечно. Я был знаком со структурой данных, но знал, что моя программа все равно не добавит дубликатов в массив, поэтому я выбрал массивы. Это было ошибкой. Хорошей стратегией перед выбором структуры данных было бы составить быстрый список того, что мне нужно было достичь (без дубликатов, произвольный доступ не нужен), а затем список возможных структур данных (массив, объект / хеш-таблица, набор). Этот быстрый процесс привел бы меня к набору, превосходной структуре данных для этого варианта использования не потому, что он был быстрее, а потому, что он был бы более понятным для моих сотрудников. Другой способ следовать первому совету «Пишите код, как если бы вы здесь работали» - это выбрать структуру данных, которая предлагает другим разработчикам очень очевидные сигналы о том, что делает программа.

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