Большую часть последнего года своей жизни я провел, обучая разработке под iOS на курсах для начинающих по программированию. У меня была уникальная привилегия наблюдать за кучей разработчиков, усердно искать свою первую инженерную работу, подвергать себя бесконечным фиктивным интервью и изучать Cracking the Coding Interview с такой тщательностью, которая заставила бы посторонних поверить в то, что оно содержит секреты вечного жизнь.

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

Моя гипотеза

Я собираюсь выдвинуть здесь простую, но, возможно, радикальную гипотезу: большинство инженеров не устраивают интервью, потому что им не хватает технических знаний. Большинство инженеров бомбят собеседования, потому что они невероятно плохо передают эти технические знания. На самом деле, я вполне уверен, что могу сократить это предложение до «Большинство инженеров бомбят‹ #fill in the blank # ›, потому что они невероятно плохо общаются» (точка).

Вы можете подумать о своей квалификации на техническом собеседовании в двух плоскостях. Во-первых, это ваш технический опыт. Во-вторых, ваша способность поделиться своим опытом. В совокупности эти два элемента по сути определят вашу способность перейти от неудобного собеседования к удобной инженерной должности. Однако это не простое уравнение: Эффективность = Знания + Общение

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

Ваша производительность никогда не превзойдет ваш уровень общения

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

Эффективность = (20% * знания) + (80% * общение)

Улучшение общения

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

  1. Научите того, кто знает предмет меньше, чем вы

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

В этот момент вам, вероятно, пришла в голову эта мысль. «Мне некого учить» или «Я недостаточно сообразителен, чтобы читать кому-то лекцию по этой теме». По отношению к обоим вы категорически неправы. В мире, где проживает более 7,54 миллиарда человек, математически очевидно, что, по крайней мере, для 7 539 999 999 человек найдется кто-то хуже их в любой задаче. Если вы не готовы признать, что вы самый крупный лемминг на планете, выбросьте, пожалуйста, это оправдание из головы.

Лучше спросить: «Где мне найти кого-нибудь, чтобы научить?» Если вы заканчиваете какой-либо учебный курс по программированию, скорее всего, за вами будет группа студентов на 6 недель и другая группа на 6 недель, которые отчаянно жаждут большего количества инструкций. Спросите любого из них, с чем они борются, и сядьте вместе с ними, чтобы объяснить эту тему. Еще лучше, предложите прочитать лекцию на общую тему интервью, например. Управление памятью. Если вы выходите из университетского опыта CS, где учебная среда более жесткая и структурированная, поговорите с профессором о том, чтобы предлагать свои волонтерские услуги для сессий TA. Если они откажутся, найдите местный учебный курс по программированию и предложите свои услуги. Помните, что изучение технических концепций и передача этих концепций - это совершенно разные навыки. Дальнейшее изучение не улучшит вашу способность передавать уже известную информацию.

2. Демо стоит 1000 описаний

Раньше я проводил всех своих студентов через имитационные собеседования в последние недели нашего учебного лагеря для iOS. На этом этапе у каждого студента обычно было заполнено 2 заявки. Я бы попросил их: «Расскажите мне об интересной или сложной функции, которую вы недавно создали». В обязательном порядке каждый из них погрузился бы в однообразное описание своих приложений. Я видел и участвовал в планировании большинства этих приложений, и обычно к концу их 5-минутного объяснения того, что делает их приложение, я чувствовал, что у меня меньше представления о том, что это за проекты и почему они имел значение. Между тем их iPhone все время лежал в их кармане, собирая пыль.

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

3. По возможности используйте истории, аналогии и метафоры.

Человеческий разум, даже разум инженера, запрограммирован на сочинение хорошей истории. Недавние нейробиологические исследования даже показали, что при прослушивании рассказа, метафоры или аллегории задействуются совершенно разные области вашего мозга по сравнению со списком зазубренных фактов. Когда я говорю о шаблоне делегирования в iOS, я меньше сосредотачиваюсь на полиморфизме и разделении через протоколы и больше на истории беспомощного работника, который не знает, как реагировать на определенные события в течение своего дня, как принтер. загорается, или клиент угрожает подать в суд. Рабочий не обладает достаточной квалификацией и специализацией, чтобы иметь дело с пожарными или юридическими проблемами, поэтому он решает эту проблему, наблюдая и сообщая о пожаре и юридических угрозах своему боссу (читай метафорическому представителю) и снимая с себя любую дальнейшую ответственность. Гораздо легче представить себе принимающий объект и его делегата после того, как вы олицетворяете их как работника и начальника. Это может показаться нетехническим или неинженерным, но все мы люди, и даже инженеры не могут устоять перед хорошей историей.

Еще более полезно, чем рассказы, использовать метафоры или аллегории. Давайте попробуем вместе:

Интервьюер: «Не могли бы вы рассказать мне, что такое протокол (интерфейс в Java) и для чего он может использоваться?»

Вы: «Да, протоколы - это форма абстракции в коде, которая определяет список требований, которым может соответствовать класс».

(Может быть полезно начать с быстрого определения, но это совершенно не вдохновляет, переходите к аллегории как можно скорее)

«Я думаю о протоколах так же, как о посуде. Посуда действительно описывает любой инструмент, которым я могу есть. Вилки, ножи, ложки можно использовать для еды, и поэтому все они могут рассматриваться или упоминаться как посуда. КАК вы едите вилкой, ножом и ложкой, будет разным для каждого, но протокол определяет только, ЧТО должен делать объект, а не КАК это делать. В программе мы могли бы сказать, что все конкретные классы Fork, Knife и Spoon соответствуют протоколу Utensil, потому что все они имеют функцию под названием «eat», которая возвращает экземпляр пользовательского класса Food ».

4. Говорите просто и используйте конкретику

Прекратите использовать «foo» и «bar», это стало чрезмерно используемым кодовым эквивалентом «Lorem Ispum», который наш мозг инстинктивно замалчивает. Говорите о реальных примерах, а еще лучше - о реальных примерах того, что вы кодировали лично. Абстракция - роскошь эксперта и одно из худших средств обмена технической информацией. Будьте конкретны. Давайте продолжим с того места, где мы остановились в вашем последнем интервью.

Интервьюер: «Хорошо, хорошо. Так почему протоколы сильны? Что они позволяют вам делать? »

Вы: «В этом приложении для iOS, которое я написал под названием Spilt.Coffee - (вернитесь к шагу 2 назад и вытащите свой телефон) - я определил протокол под названием« FirestoreFetchable », который каждый класс, который можно получить и декодировать из базы данных Firestore, соответствует. Это позволяет мне использовать одну и ту же сетевую функцию для получения всех этих разных классов, даже если логика декодирования каждого из них различается. Короче говоря, это позволяет мне относиться к продуктам, статьям и рецептам, хранящимся на сервере, как к одному типу в зависимости от их общих возможностей, хотя то, КАК каждый класс достигает этих возможностей, может отличаться ».

Прекратите использовать такие фразы, как «объект A» и «объект B», и говорите о реальных вещах, которые вы сделали. Примените словесную абстракцию в качестве запоздалой мысли, если необходимо, чтобы продемонстрировать, что вы понимаете, что обсуждаемые принципы применимы за пределами этого конкретного случая.

Небольшое примечание по поводу жаргона: я знаю, что вы думаете, что это заставляет вас казаться умным, и что ваши интервьюеры будут просто предполагать, что, даже если они не понимают, о чем вы говорите, что вы делаете. Поверьте мне, они этого не сделают. Даже хороший младший инженер почувствует это за версту. Вы не собираетесь проложить себе путь через это. Да, жаргон может быть важен, чтобы показать, что вы понимаете, о чем говорите, но позвольте ему течь естественным образом. Если вы не знаете, как что-то называется, будьте честны и опишите, что вы имеете в виду. Хорошие интервьюеры будут в первую очередь сосредоточиться на вашей логике и намерениях. Они хотят увидеть, сможете ли вы решить проблему, а не воспроизвести семантику курса алгоритмов на втором курсе.

5. Выразите словами свои мысли и предположения. Выходи из своей головы, интервьюера там нет.

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

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

Заворачивать

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