Своим опытом поделился Франческо Коно.
За время моей работы были случаи, когда меня просили помочь в процессе найма и побыть техническим экспертом. Это не основная моя работа (я разработчик, в конце концов), но кто может оценить разработчика лучше, чем другой разработчик? Я делал это плюс-минус 50 раз, поэтому хотел бы поделиться своими замечаниями по этой теме. Я надеюсь помочь вам лучше подготовиться к техническому интервью и приобрести большую уверенность в своих способностях. Имейте в виду мою точку зрения: люди все разные, а значит и интервью тоже не будут одинаковыми, даже если компании стараются их стандартизирвать.
Также я буду говорить об интервьюере в мужском роде, так как я мужчина и это для меня привычнее. Это не говорит о том, что интервьюером обязательно должен быть мужчина. Пол здесь не имеет значения.
Правило 1: не вешайте лапшу на уши
Встретившись с техническим интервьюером, сначала спросите его, чем он сам занимается. Если он активно работает с технологией, вы должны прийти к выводу, что он знает ответ на вопрос, который задает вам. Крайне маловероятно, что у него просто где-то записан ответ.
Если вы попытаетесь угадывать, вам может посчастливиться, и вы сможете убедить его, что знаете предмет. Но шансы на это ничтожно малы, особенно если ответ более сложный, чем «да» и «нет». Таким образом вы можете моментально утратить весь кредит доверия. Никто не захочет работать с человеком, предоставляющим неправдивую информацию. А вы бы хотели основывать свою работу на случайных допущениях? Если они окажутся ложными, вы можете потерять недели работы. Лично я, если уловлю, что вы угадываете, даже если угадываете правильно, буду забрасывать вас дополнительными вопросами. И рано или поздно поймаю на лжи. Поэтому, если вы не знаете ответа, скажите об этом прямо. Потом вы можете начать размышлять, может, даже обсуждать с интервьюером. Так вы покажете не только свою честность, но и навыки мышления.
Что касается личностных качеств, мне нравятся люди, способные признать свою неправоту и не претендующие на знание всего на свете. Это превращает их в прекрасных партнеров по работе.
Правило 2: поясняйте ваше резюме
Ваше CV может быть раздуто в надежде произвести впечатление на HR. Я могу это понять. Но не врите, когда профессионал задает вам вопрос, действительно ли вы мастер в этой технологии. Это очень близко к первому правилу про лапшу на ушах. Скорее всего я смогу разобраться, мастер вы или нет. Например, не представляйтесь гуру блокчейна, если вы не знаете, что такое дерево хешей. Я спрошу вас об этом и обнаружу вашу ложь. Просто скажите что-то вроде «Я знаю, я написал, что я гуру, но я имел в виду, что с точки зрения конечного пользователя, а не разработчика». Это расставляет все по своим местам. Тут я могу еще спросить, знаете ли вы, что означает «consensus». Но точно не буду спрашивать о дереве хэшей.
Это справедливо даже для элементарных познаний. Знание основ даже легче проверить. Но об этом больше в следующем разделе.
Правило 3: знать основы
Я сказал, что вы должны четко заявить, если чего-то не знаете. Но оосновы знать необходимо. Невозможно претендовать на техническую позицию без знания основ своего дела.
Например, если вы подаете резюме на должность администратора баз данных, вы должны знать, что такое индекс. Мне безразлично, знаете ли вы синтаксис, который используется для создания индекса. Мне нужно чтобы вы знали, что такое индексы и зачем они нужны. Это истина, не зависящая от старшинства должности.
Другие примеры из моего опыта:
- Если вы хотите быть С-программистом, вы должны знать разницу между stack и heap.
- Если вы хотите быть разработчиком SQL-серверов, вы должны знать, что такое INNER JOIN и LEFT JOIN.
- Если вы хотите быть программистом на С#, вы должны знать, что такое статический метод.
- Если вы хотите быть Rust-программистом, вы должны знать, что такое mutability.
Суть вы уловили. Синтаксис и детали не так важны. Вы всегда можете найти их с помощью поисковика. Но если вы не знаете, о чем говорите, то вы даже не знаете, что искать.
Итог: если вы профан по технической части, лучше сказать об этом с самого начала. В этом нет стыда. Но не ожидайте, что вас наймут на позицию старшего разработчика C#, если вы не можете объяснить, что такое наследование.
Правило 0: будьте собой
Это не касается технологий, но думаю, что тоже стоит упомянуть. Будьте собой. Правда. Техническому интервьюеру все равно, забавны ли вы и улыбаетесь ли. Он проверяет, что вы знаете и умеете. Если вы тратите энергию, пытаясь выглядеть кем-то другим, а не собой, вы зря тратите ресурсы. Напрасная трата ресурсов это плохо, даже если ваш мозг и не банк памяти.
Вы умник? Мне все равно. Вы интроверт? Мне все равно. Вы из какого-нибудь меньшинства? Мне все равно. Вы прибыли с другой планеты и у вас аллергия на криптонит? Мне все равно. Я должен давать оценку исключительно с технической точки зрения. Если вы скажете что-то очень, очень неправильное (например: «лучшая сборка мусора та, что используется в С»), никакое количество улыбок не изменит моего мнения.
Лично я работал со многими разными людьми. Компетентность важнее всего остального. Я предпочту сотрудничать с кем-то, кто умеет работать с gdb, даже если он мудак, а не с очень классным, умным, но бесполезным парнем. Конечно, я ужасен в том, что касается отладки, поэтому я могу быть предвзятым:).
Правило 4: задавайте вопросы
Работая над проектом, вы можете задавать вопросы. Возможно, что-то не до конца понятно. Может, вы думаете, что другой подход будет более продуктивным. Дело в том, что рабочее взаимодействие это ключевой момент. Поэтому я ожидаю, что вы будете задавать вопросы в ходе интервью. Например, я могу попросить вас набросать дерево. Вы можете спросить, зачем. Это даст вам контекст. Это разумный вопрос. Конечно, вы можете набросать двоичное дерево. Это хорошо. Но в реальном мире никто не создает двоичное дерево без причины.
Если на ваш вопрос я скажу «дерево, использующееся для ускорения поиска», вы можете переспросить «почему бы не использовать hash set вместо него?»
Это просто пример, но он дает невероятное количество информации интервьюеру: вы знаете, что такое деревья, что такое hashset и где они применяются. Это много информации в нескольких предложениях. А в нашем деле концентрированная информация это плюс!
Правило 5: приготовьте экземпляры ваших работ
Ничто не расскажет разработчику больше, чем код. Так что, пожалуйста, принесите с собой какой-нибудь код. Даже если вы совершенный новичок, люди ожидают увидеть ваш профайл на GitHub. И нет, простые форки классных проектов не считаются. Вы должны иметь что-то, созданное самостоятельно. Это может быть простая математическая библиотека или служебная программа. Таким образом вы можете показать две вещи:
- Вы что-то сделали. Мы, разработчики, знаем, что создать нечто работающее действительно сложно. Идеи недостаточно. Вам придется сражаться с каждой строчкой, чтобы заставить код работать. Вам придется читать документацию. Вам нужно будет составить тесты. Вам нужно будет сделать отладку. И каждый шаг будет труден. Но вы это сделали, даже если результат – всего 20 строчек кода. Количество строк в этом смысле неважно.
- Вы знаете основы (ource control, ssh и т. д.).
Пожалуйста, не говорите о гипотетическом проекте. Мне безразлично, планируете ли вы создать классный «Raspberry Pi»-проект. Мне интересно, создали ли вы его. Также не давайте мне скучные проекты из универа, вроде программы, реализующей сортировку слияния. Если у вас нет идей, автоматизация – хороший старт. Вы ловили себя на ручной сортировке своих фотографий? Постройте скрипт, который делал бы это. Это намного информативнее, чем энный бесполезный учебный проект.
Последнее правило: гордитесь
Где-то это уже упоминалось (сейчас не найду ссылку, простите). Пожалуйста, пожалуйста, гордитесь тем, что вы делаете. Вы программируете только на BASIC? Гордитесь этим. Вы не знаете CUDA? Не бойтесь. С точки зрения технического интервьюера способность что-то делать означает что вы умеете учиться. Но если вы говорите «Я знаю немного BASIC, но не хорошо, и я ничего не предпринимаю по этому поводу», вы принижаете свои навыки и свою любовь к разработке программ. В конечном итоге, для разработчика парень, проводящий свою жизнь в написании кода, уже звезда.
***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
