23 April 2017

Improve your algorithmic skills

Мне всегда поражала методика, по которой IT гиганты типа Microsoft, Google или там Facebook набирают себе в штат новый программистов.
Если кто не в курсе, в двух словах объясню. Людей ищут не на конкретный проект и с конкретными техническими скиллами, востребованными на этом проекте, а ищут взагали, без всякой оглядки на боевой опыт соискателя. При этом практически единственным критерием отбора кандидатов являются навыки оных в области решения хардкорных алгоритмических задачек. Под секундомер. Написал без ошибок и быстрее на 20 секунд, чем другие участники забега, процедуру балансировки черно-красного дерева -- welcome aboard! А какие ты при этом технологии знаешь, какой у тебя практический опыт и на чем ты этот алгоритм реализовывал -- дело совершенно десятое.


Меня весь этот цирк удивлял по многим причинам. Например, отсутствием элементарной связи между заданиями на интервью и теми задачи, которые люди должны решать на своих рабочих местах. Если кто не в курсе, в Microsoft или Google пишут точно такие же программы, как в других IT компаниях, и, соответственно, попавшие туда люди, в большинстве своем, точно так же лепят формочки для Android приложений или отдают браузеру страницу, построенную на SQL запросе к базе данных. Знать при решении этих задач 20 разновидностей алгоритма сортировки совершенно не нужно и знания эти, если и бывают когда востребованы, то исключительно в случаях, когда тебя подключают к процессу отбора желающих работать с тобой в одной компании.
Некоторые товарищи, умудрившиеся окончательно поехать крышей на алгоритмах и структурах данных, после успешного трудоустройства (которое далось им многочасовыми бдениями над скучными формулами, теоремами и псевдокодом) оказываются ужасно разочарованы -- как минимум от того, что навыки, которые так востребованы при трудоустройстве в крутые компании, день ото дня не совершенствуются при решении рабочего круга задач. Очевидно, просто потому, что связь между практическими проблемами, которые решаются с помощью программирования, и математическим алгоритмическим задротством примерно такая же, как между возможностью говорить и пониманием физиологических процессов в коре головного мозга, связанных с речью.

Так вот, в очередной раз удивляясь несуразности всех этих интервью с кандидатами, я понял, почему процесс устроен именно так. Просто потому, что использование знаний в области алгоритмов выступает более-менее прозрачным и объективным  критерием, дающим достаточно большое рассеиванием оценок, при отборе огромного количества желающий трудоустроиться в компанию с громким именем. Невозможно использовать индивидуальный подход, когда у тебя 150 желающих на одно место. Поэтому и взяли эти алгоритмы за метрику, как некий стандарт в индустрии. Знания в этой области в вышеназванных компаниях имеют все поголовно (потому что они уже были по ней "стандартизированы" при трудоустройстве). Ее несложно оценить. И она имеет ну хоть какое-то отношение к программированию. В смысле, что точно так же в качестве стандартного решета для всех желающих можно было бы использовать, к примеру, латынь, но к программированию это имело бы еще меньшее отношение, чем злополучные алгоритмы... А так, было бы очень даже не плохо. Хочешь попасть в Google -- зубри латынь. Днем и ночью. И неважно, что на работе она тебе на хрен не будет нужна, важно, что ты так хотел получить это место, что обошел в своем усердии всех своих конкурентов. И понятно, что собеседующие тебя тоже все будут гуру латыни...

Другая странность такого рекрутинга -- тотальное игнорирование практических навыков кандидата и исповедование подхода "да ты у нас где угодно освоишься, раз всю эту муть про алгоритмы и структуры данных осилил".
Вообще, современное IT в плане количества различных областей знаний, технологий, библиотек и фреймворков реально кажется бесконечным (ибо одним только фреймворкам для JavaScript нет счета). Поэтому глубокая специализация человека, концентрация его практических знаний в каких-то конкретных вещах, это данность, которую просто глупо отрицать. И история о некоем сферическом универсале с шильдиком "software engeneer" на лбу в моих глазах такая же глупость, как попытка протезировать зубы у опытного гинеколога, руководствуясь соображениями, что "он же тоже врач". Ну в самом деле, какая польза будет на плюсовом embedded проекте от чувака, который последний 10 лет писал исключительно на PHP четвертой версии? Вне зависимости от того, какое количество алгоритмов сортировки он знает.

А потом я объяснил для себя и эту загадку. Тут все, на самом деле, очень просто.
Гении большим корпорациям не нужны, им нужны стандартные дешевые взаимозаменяемые детали. Вернее как сказать -- не нужны, нужны, но этих людей ничтожно малое количество на фоне остальных работяг. И работают эти крутые парни на совершенно другом, стратегическом уровне, когда тебе, по большому счету, плевать, кто твои гениальные идеи будет отливать в метал, чувак с богатым бекграундом в питоне или, например, в джава, и получится ли это у него в сто строчек или в сто пятьдесят. Главное, чтобы написано это было максимально просто и в лоб, чтобы когда на место одного болтика в этой гигантской машине вкрутят болтик другой, он мог подхватить написанное, имея минимальный опыт не только в проекте, но и в используемых технологиях. А навороты не нужны, так как сильно надежнее и проще полагаться на взаимозаменяемые болванки, которые, к тому же, теоретически до бесконечности масштабируются старым-добрым экстенсивным подходом, просто путем увеличения поголовья скота.
Я даже обнаружил ряд косвенных аргументов, подтверждающих эту теорию. Например, придуманный под крышей Google язык Go. Очевидно же, что никто в XXI веке в здравом уме и твердой памяти не станет предлагать миру статически типизированный язык без инструментов для обобщенного программирования. Ну просто потому, что это как пытаться вооружать свою армию копьями и щитами в эпоху ядерного оружия. Однако если вспомнить о том, что код внутри Google должны писать люди, которые только вчера увидели этот ваш Go, а завтра вслед за ними на поддержку придут точно такие же "спецы", то все становится на свои места. Чем проще, тем лучше. Даже если написано немножко по дебильному и копи-паста составляет добрую половину кода. Главное ведь что? Что алгоритмы то везде будут давать O(1). Ну в крайнем случае O(log N).

Ну и следующий из всего этого очевидный вывод: на индивидуальных сверхспособностях в этом мире строятся только некоторые, относительно небольшие проекты. Выжимать из используемых технологий 200% очень важно, когда задействовано пять, ну или там десять человек. А когда тебе нужно масштабироваться на сотни и даже тысячи человек, пишущие код гении не только не нужны, они, очевидно, даже вредны...
Keep it simple, stupid!!

зы. Заголовк заметки взят из этого прекрасного материала

No comments:

Post a Comment