Поговори с ней о сексе - она хочет знать все, или все что вы знаете об интервью программистов

Пожалуй, интервьюирование специалистов в ойти - это одна из тем, которая, наряду с хохлосрачем, freebsd vs linux и java vs c++ - вызывает наиболее обильные и продолжительные шитсторма в интернетах. По правильному прохождению интервью написаны сотни книг (некоторые даже в бумаге и продаются на амазонах, я сам это видел), тысячи мегабайт текстов на хабре, лоре и прочих рсдн или там скл.ру. Все эти материалы разной степени упоротости, с акцентами на как и что говорить про себя, какой правильный ответ на “кем вы видите себя через пять лет” и зачем люки круглые.

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

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

Из этого следует, что интервью предназначено только для понимания вашей пригодности для работы в конкретной команде над конкретным проектом. А пригодностей здесь ровно несколько видов

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

Я расположил вот это все в порядке убывания приоритетов. Попробую вкратце описать, кто есть ху в данном списке.

Коммуникация.

Под коммуникацией тут я понимаю достаточно широкий спектр вещей, которые не столько связаны с известным выражением “пиздеть - не мешки ворочать”. Здесь скорее

  • умение слушать других
  • умение внятно и четко формулировать свое мнение
  • умение отстаивать свою точку зрения (но при этом см. пункт 1)
  • умение договариваться
  • способность принимать правила игры, которые устанавливает команда, тимлид или заказчик

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

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

Общая техническая грамотность.

Это опять же целый набор характеристик, которые отличают быдлопохапешника от хаскелештангиста инженера от обезъяны с клавиатурой. Здесь у каждого свои пункты, но мне наиболее общими видятся (в порядке убывания важности):

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

  • понимание основ CS, все вот эти array, hashtable, bst и прочие очереди. Ключевое слово тут - понимание, а не зазубривание наизусть характеристик типа “вставка в голову очереди занимает O(1) по времени”. Если вот это зазубрено - то поциент не сможет пояснить, почему такая вот вставка может занимать и O(N) в некоторых условиях. Список всего этого опять же может варьироваться - кому-то архиважно, чтобы было понимание кучи Фибоначчи или вон тех finger-trees.

  • знание матчасти. Это в первую очередь относится к умению представить, как вообще работает железяка (или виртуальная машина), что такое память и как она расходуется, размер основных типов данных и понимание представления этих самых данных в памяти, базовые операции над значениями, может быть - IO, ну такое. Или там как в браузере интерпретируется жабоскрипт и почему всем похер на многопоточность внутри GWT. Чтобы для товарища не было сюрпризом переполнение или там выпадения по stackoverflow.

  • знание основного инструмента на достаточном уровне. Под основным инструментом понимается выбранный язык программирования (или несколько), или платформа разработки, да тот же линупс. Достаточный уровень определяется здравым смыслом - если это Java, то можно не понимать специфику JMM (но лучше надо), но знать зачем нужен final. Вообще чтение спецификаций языков должно быть возведено в культ.

  • знание основных библиотек под этот инструмент, чтобы не изобретать велосипеды на каждый чих (я как-то видел изобретенный Stack просто потому что товарищ не был в курсе про java.util.Stack. Это само по себе ничего плохого не значит - но лучше все ж применять туалетную бумагу вместо топора и карты леса.

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

Техническая экспертиза.

Этот пункт означает лишь то, что человек знаком с тонкостями и разными неочевидностями выбранных инструментов разработки или предметной области. При этом он также обладает неким багажом шрамов на лбу от хождения по граблям, чтобы уберечь от этого остальных. Не более и не менее - просто know your tool.

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

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

Почему интервью - это НЕ экзамен? Да потому что экзамен - это завершение какого-то цикла обучения и просто контроль усвоенных знаний и навыков, а интервью - это оценка того, как вы будете приобретать эти знания и навыки и какой фундамент у вас есть. То есть разница колоссальная - экзамен суть окончание, а интервью суть начало процесса.

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

А теперь плавно перейдем к главному - процессу интервьюирования и что же могут оценивать в кандидате интервьюеры. Здесь все зависит от того, какая задача поставлена перед интервьюером. Их может быть великое множество, но тем не менее основными мне видятся:

  • найти нужного человека В этом случае скорее всего все будет правильно. Интервьюер будет заинтересован в том, чтобы найти человека, который может выполнять свою работу - и будет выдвигать соответствующие требования. Если вы чего-то не знаете, но у вас все ок с мозгами (см. техническая грамотность) - то никто не будет заебывать деталями реализации RB-tree в штатной библиотеке Java. Это будет диалог на равных, и вы тоже можете задавать технические вопросы для понимания - а кто вас вообще собеседует и что он знает. Ну и тут тоже играет роль наличия присутствия в интернетах - например, аккаунт на гитхабе с контрибутом в scalaz - скажет о вас больше, чем два часа интервью. Да его скорее всего и не будет, если компания плотно работает со scalaz. Также никто не будет вас заебывать вопросами из смежных областей - в частности, если вы пишете WEB приложение, то никому неинтересно спрашивать вас о прошлом опыте с IDA Pro и WinDASM. Об этом можно поговорить в частной беседе и найти какие-то общие интересы, например.

  • закрыть вакансию Этот момент скорее всего будет представлен в ярких красках в бодишопах (ну там дешевые универсалы, всего почучуть). Как правило, у интервьюера будет какой-то листок бумажки с чеклистом на тему “знает-не знает”, вопросы будут обо всем, вот буквально обо всем. Это связано с тем, что скорее всего там есть пачка проектов, на которые надо именно что закрыть вакансию и отчитаться о достигнутом, и людям нужно быстро понять куда вы лучше подходите. Ну и про через 5 лет конечно же - это прощупывается путь вашего роста - или в погонщики, или в носителей сакрального и ненужного за пределами этой конторы знания. Посчитать галочки, если короче.

  • почесать свое ЧСВ Это практикуется как правило в известных компаниях, в куда типа высокий порог вхождения. Здесь очень широкий простор для изучения перенесенных в детстве травм и унижений, комплексов, и все остальное. Именно для этого есть замечательное выражение “на интервью спрашивают то, что вчера прочитали в книжке”. Здесь могут быть реально вопросы из сферы “как реализован вот этот флаг в GCC”, или например какое исключение бросается какой-то библиотекой в каком-то там случае. То есть техническая экспертиза поставится во главу угла, и ебать будут по всем фронтам. Причем чем лучше вы будете отвечать - тем больше будут ебать.

Вообще говоря, крайне сложно со стороны понять, а что же происходит. Например если вам ебут мозг про оптимизацию хвостовой рекурсии в ассемблерном коде - то это может быть как потому, что контора занимается написанием компиляторов, так и потому то интервьюирующий - тупой еблан, у которого единственная заслуга в жизни - получение работы в этой конторе (еще и неясным способом). То есть в принципе с какой-то долей вероятности (глядя на вакансию и требования) можно предположить что именно происходит (ну, если вы идете на программиста WEB и перекладывания ввода пользователя из формы в базу, и назад - то клиника заболевания сразу будет ясна). Также если перед вами сидит человек с чеклистом - это вовсе не значит, что там 100 проектов и неясно куда вас девать - интервью может быть многоходовое, из нескольких фаз. Чтобы отсеять явных дебилов).

Какие ж из этого всего следуют выводы? Они опять же, просты, написаны везде и понятны даже из здравого смысла

  • поймите что требуется в вакансии, и пришлите адаптированное резюме. Ведь реально читать про работу забойщиком скота и потом менеджера по продаже туалетной бумаги перед устройством джуниор ПХП-сбегайзаводкой в фирму рога и копыта - весело, но не в плюс кандидату.
  • не надо врать. Ни в резюме, ни на интервью. Не надо выкручиваться. Лучше просто сказать “я не знаю”.
  • если вам не нравится интервьюер - заканчивайте интервью как можно скорее. Вы бы хотели работать с чуваком, которому хочется уебать в щщи с вертушки?
  • оценивайте себя адекватно. Это означает, что в 20 лет вы скорее всего не будете Senior Java Developer, даже если эти буквы вам написали на прошлой работе взамен повышения зряплаты. Но это также и значит, что если у вас нет диплома программиста - это не значит, что вы хуже чем сосед с красным дипломом Национальной Академии Говна и Торфа.
  • не нужно знать все. Все знать сложно. Лучше написать три вещи в резюме и знать их до мелочей, чем написать 33 баззворда и усраться на вопросе про второй из них. Это автоматически поставит под сомнение все остальное, что у вас там написано.

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

В общем, ходите больше на интервью, и будет счастье. Главное, как всегда - не ссать и хуярить