Около месяца назад я обнаружил себя разговаривающим по видеосвязи с Joel Spolsky (автор известного блога «Joel on Software», со-основатель Stack Overflow — прим. перев.). Даже сейчас кажется абсурдным писать подобное. Долгое время, на протяжении всей своей карьеры, я регулярно читал Joel Spolsky, и во многом сходился с ним во взглядах на разработку. И вдруг общаюсь лицом к лицу.
Добиться этого разговора было далеко не просто. Процесс занял несколько недель, и, честно говоря, было затруднительно найти время на прохождение стольких интервью. Скольких, спросите вы?
До Joel'a я говорил с 5 или 6 других удивительных людей (в их числе Marc Gravell и Nicholas Larsen). Каким-то образом мне удалось произвести на каждого из них достаточное впечатление, чтобы добраться до финального босса. Разговор длился около часа, а для меня пролетел за 5 минут – вероятно, из-за волнения. Мы обсуждали плюсы и минусы различных методологий разработки ПО, свои прошлые карьерные ошибки, некоторые из проблем Dache (мой кэш с открытым исходным кодом), и пару других тем. Затем Joel сказал нечто удивительное: «Присоединяйтесь к нам в Stack Exchange!» В тот момент я ощутил такой сильный выплеск адреналина, что мог бы поднять машину голыми руками.
Несколько дней спустя я официально приступил к работе. Я рад подобной возможности и считаю, что мне очень повезло. До сего момента, Stack Exchange зарекомендовала себя как невероятно квалифицированная и профессиональная организация, которая относится к сотрудникам как к людям, а не как к расходным ресурсам, и я уже успел полюбить здешние обычаи общения с коллегами.
ВАЖНО: Прежде всего, излагаемая позиция — исключительно моя, а не компании Stack Exchange, либо третьих лиц. В статье приводятся размышления касательно процесса интервью, а также той специфики моих знаний и профессионального пути, которые помогли получить эту работу. Это не «срыв покровов», и не облегчающая путь подсказка. Если вы хотите работать здесь, вам придется пройти те же испытания (детали которых я не буду раскрывать), что прошел и я.
С этой оговоркой, вот мои мысли о том, как я получил работу в Stack Exchange, и о том, как это можете проделать вы:
Эго — убийца разума, так что убейте эго. Большинство разработчиков (в том числе, и я — прежний) обладают массивным «Я». Их эго настолько велико, что едва помещается в комнате. Это естественно, учитывая то, что мы целыми днями создаем приносящие солидный доход вещи божественного качества буквально из ничего. Мы начинаем чувствовать себя очень могущественными. Досконально изучив технологический стек компании, мы делаем вывод, что знаем всё о любом ПО и «железе».
Думать, что знаешь всё — самый простой способ облажаться как программист. Веря в подобное, вы больше не изучаете новинок (вы же их уже знаете). Пока вы мастерски освоили ASP.NET MVC 3 на текущем месте работы, вышли 4-я, а затем 5-я версии фреймворка… вот только ваша компания не сделает апгрейд, потому что это слишком рискованно, и поэтому вы никогда не изучите новую версию. Спустя пару лет, вы окажетесь так далеко позади современных технологий, что не сможете их увидеть даже в бинокль. Кстати, я упомянул те штуковины — Ruby и PHP, или даже Java, на которых вы так и не написали ни одной строчки? А как насчет MongoDB, Couchbase, Azure, EC2, и тысяч других платформ и языков программирования? Надеюсь, теперь вы поняли, что ваши знания о языках и аппаратных конфигурациях — это капля в море… возможно 0,1% от всех знаний о разработке. Столько же знаю я, и это нормально.
Не будьте рок-звездой. Этим я занимался в течение нескольких лет, что только повредило моей карьере. Многие компании умышленно подкармливают эго своих сотрудников, чтобы те чувствовали себя ценными (часто без соответствующей оплаты). Быть рок-звездой — звучит здорово, но на самом деле это рискованная стратегия, которая может взрастить невероятно взрывоопасную атмосферу в коллективе. Компании разыскивают и нанимают рок-звезд, и рок-звезды воспринимают это, как должное. Они раздувают свои «Я» и напыщенно спорят на собраниях, перебивая и расталкивая других. Рассуждают в духе «я прав, потому что вы не правы, потому что я прав». Рок-звезда убеждён: остальные существуют, чтобы потакать его прихотям… в то время, как остальные ненавидят работать с таким человеком.
Дело в том, что вы на самом деле можете быть тем самым, одним на миллион великим разработчиком, «рок-звездой» — но всем на это плевать. Слова ничего не стоят, и люди скажут почти всё что угодно, чтобы произвести на человека нужное им впечатление. Даже если вы действительно хороши – говорить с людьми только об этом, и ни о чем другом — заставит их презирать вас. Хорошему разработчику не нужно хвастаться, его результаты скажут сами за себя красноречивее любых слов. Естественно, что окружающие оценят подобного человека. Досужие разговоры на тему «вау, он очень умный» или «она справилась за час, а мы-то думали — это займет несколько дней» будут крепнуть, что не плохо. Пусть люди говорят о вас все, что им вздумается, но сохраните скромность и чувство реализма. Вы можете быть лучшим разработчиком в команде или даже компании, но вы всё еще человек, и вы всё еще на работе. Никого здесь не нанимали обслуживать ваше эго (даже тех, чьи повседневные обязанности — работа на вас). То, что вы хороший разработчик — не делает вас лучше, как личность; это просто делает успешнее вашу карьеру. Никогда не забывайте, что тысячи других разработчиков точно также блистают на своих рабочих местах. Из их общего ряда — сможет выделиться отличный и скромный разработчик. Это очень редкое сочетание по моему опыту, и предел мечтаний для найма во многих компаниях. Даже если вы самый-самый (что клёво!) из всех, перестаньте хвастаться окружающим. Им все равно, как и вам должно быть.
Знайте, что вы знаете достаточно для понимания ограниченности ваших знаний (оригинал know that you know enough to know that you don’t know enough – прим. перев.). Осознавайте, что вы знаете, а что нет. Никогда не бойтесь сказать: «я не знаю», когда это правда. Разработчик, который не робеет произнести: «я не знаю» перед полной людей комнатой — редкость. Будучи честным, вы создаете доверие и авторитет. Вы также развиваете позитивные отношения с коллегами и компанией. Если вы никогда не слышали о Angular.js или Couchbase — никто этого не станет запоминать, но люди всегда будут благодарны, если вы не стали тратить их время и деньги.
Знайте свои структуры данных и алгоритмы. Языки программирования высокого уровня, такие как C#, настолько абстрактны, что многие из нас не имеют ни малейшего понятия о том, что же на самом деле происходит «под капотом» при выполнении программы. Это здорово — повсюду использовать LINQ, но знаете ли вы вычислительную сложность того, что написали? Вы знаете, что такое хэш-таблицы, и зачем они нужны? Можете ли вы отсортировать массив наиболее эффективным путем? А придумать сценарий, где наилучшим вариантом является использование стека? Обратите внимание — вам не нужно запоминать вещи вроде алгоритмов сортировки (черт, да я не смог бы, даже если бы попытался), но очень ценным является знание структур данных: деревья, хэш, списки, очередь, стек; в сочетании с рудиментарными понятиями о сортировке, поиске и кэшировании. Вот различие между хорошим и превосходным программистами. Каждый может писать на C#, но только понимающий низкоуровневую «подноготную» каждого вызванного метода напишет хороший, чистый, эффективный код. Вам необходимо фундаментальное понимание того, как работают структуры данных, такие как стек и куча, как работает адресация по значению и по ссылке. Эти основные принципы применимы ко ВСЕМ языкам программирования. Слишком многие разработчики игнорируют сложность алгоритмов и просто вызывают готовые методы, не понимая последствий. Изучите структуры данных и алгоритмы, и внезапно вы окажетесь впереди стаи.
Знайте, почему ваш код работает и почему ваш код не работает. Вы видели это изображение с Reddit и ему подобных сайтов?
Пусть эта картинка и смешная, но ее популярность меня бесит. Она заявляет, что суть программирования — не врубаться, почему ваш код работает или не работает. Как по мне, так это недопустимо. Превосходный разработчик стремится узнать ПОЧЕМУ вещи работают так или иначе, а не только КАК это исправить. Код не компилируется? ПОЧЕМУ? Race condition? ПОЧЕМУ? Задавая вопросы «почему» вы расширите свой кругозор и набор навыков по сравнению с прагматичным «как», что позволит вам стать лучшим программистом. Большинство великих программистов не повторяют одни и те же ошибки снова и снова, хотя они, конечно, ошибаются… Они просто делают новые и интересные ошибки!
Я помню дни написания дрянного кода, и последующего копирования строк из Stack Overflow и ему подобных сайтов — до тех пор, пока код не начинал вроде работать (хотя я не был уверен, как и почему это случилось). Эти дни остались далеко позади. Когда мой код не компилируется, в 99% случаев я сразу знаю, как решить проблему. Когда в моем коде баг, как правило, я знаю, как отследить и исправить его, и при этом учусь избегать подобных ситуаций в будущем. Не иметь ни малейшего понятия, почему ваш код работает — все равно, что быть адвокатом, не имеющим ни малейшего понятия, почему клиент не виноват: бесполезное, дорогое и забавное зрелище одновременно. Убедитесь, что осознаете, почему ваш код работает… или не работает. На мой взгляд, это основное качество профессионального разработчика. Создать баг или сделать ошибку — ОК, но повторить ту же ошибку несколько раз — не ОК!
Вот я и описал вам свой набор навыков и ключевых компетенций — то, что показал команде Stack Exchange на интервью. Не на все технические вопросы я смог дать точный (или оптимальный) ответ, но я вел себя скромно и никогда не боялся попросить помощи или сказать «я не знаю», когда в чем-то затруднялся. В моих ответах были эффективные структуры данных и алгоритмы, и я был в состоянии объяснить, почему вот эта конкретная структура — лучший выбор для решения проблемы. Сделав ошибку, в большинстве случаев я был в состоянии это определить и указать пути исправления. Показав свою компетентность и состоятельность как разработчик, я в итоге получил работу мечты.
Автор: chumakov-ilya
