Эта статья для тех, кто готовится искать работу и, возможно, тревожится о том, что в топовые компании без диплома Стэнфордского университета по информатике не пробьешься. Вам наверняка говорили, что вас никто не возьмет в Facebook или Microsoft. Но я хочу вам сказать, что это вполне возможно. Вот моя история о том, как мне удалось получить работу своей мечты в Twitter.
Что вы найдете в этой статье:
Я не оканчивал университетов из Лиги плюща. Два года я проучился в общественном колледже в Айдахо, затем перевелся в маленький католический университет и там закончил обучение по специальности «Информатика».
Программированием я стал заниматься на первом курсе, просто потому, что мне показалось, что это будет занятно. Весь мой опыт с компьютерами до того момента исчерпывался китайской подделкой под приставку Nintendo, да и та сдыхала, стоило только вставить в нее картридж.
Чтобы себя обеспечивать, пока не получу образование, я брал по несколько подработок сразу — мыл полы, продавал еду в кинотеатрах. После выпуска у меня не было никакой работы на примете. Я разослал резюме по всем крупным IT-компаниям, каким только мог, и даже, по везению, получил несколько приглашений на телефонные интервью.
На тот момент я даже примерно себе не представлял, что это вообще такое — собеседование на техническую должность, и уж тем более, как к нему нужно готовиться. Я приходил на интервью с мыслью, что меня будут спрашивать о том, что такое связный список или двоичное дерево.
Естественно, на всех этих собеседованиях меня отсеяли.
Тогда я не слишком задумывался о том, хороший ли у меня уровень. Я знал, что быстро схватываю. Все, что мне было нужно — это возможность себя проявить.
Как говорит народная мудрость, сеть нужно забрасывать подальше и пошире. Так я и поступил.
За то, что я сделал на следующем этапе, я испытываю особую гордость. Я написал простенький скрипт на Python, который собирал вакансии с Craigslist, отбирая должности с определенными ключевыми словами, и вносил указанные там электронные адреса в таблицу. Не самое гениальное решение, но люди, которые размещают вакансии на Craigslist, на удивление точно называют должности.
На Craigslist, однако, не слишком любят, когда кто-то пытается выгрузить их данные. Чтобы обойти ограничения, я запускал скрипт через VPN и установил таймер, который приостанавливал процесс каждые несколько минут. Не идеально, но такая схема работала.
В конечном счете, я собрал около 500 адресов организаций, расположенных в Сан-Франциско, Портленде, Споконе и Сиэтле. Я отфильтровал результаты по релевантности и дате и продолжал оптимизировать выдачу, добавляя все больше и больше параметров.
Как выяснилось, на рынке уже было несколько ботов, которые собирали данные с Craigslist и автоматически рассылали письма. По большей части, это были офшорные компании, пытающиеся пробиться на рынок в США.
Одна из хитростей, к которым я прибегнул, состояла в следующем: я составлял текст писем так, чтобы тема содержала соответствующие ключевые слова. Затем я добавил еще кое-какие детали с опорой на текст вакансии, чтобы предложение выглядело заточенным под конкретные требования. Судя по быстрому A/B тесту, который я провел, процент откликов после этого значительно возрос — с 2-3% до 10%.
На мои разосланные 500 писем пришло порядка 50 ответов; с небольшим процентом от этих 50 мне удалось договориться об интервью по телефону. Я остановился на 500, потому что время поджимало — мне нужно было уже куда-то устроиться. Приоритетом на тот момент был результат, а не широта охвата.
По счастливой случайности, я получил работу в стартапе из Сиэтла, на позиции разработчика-джуниора. Их офис тогда располагался в Киркланде, так что мне пришлось 45 минут ехать на автобусе, чтобы успеть на собеседование.
Там я проработал следующие три с половиной года и многому научился: Amazon AWS, EC2, DynamoDB, SQS и Docker. За это время я сильно вырос как программист. Я научился писать модулярный, простой для поддержки код, правильно рассуждать о дизайне и решать проблемы при работе с людьми.
Я работал бок о бок с группой знающих людей, которые пришли к нам из Microsoft, Amazon и LinkedIn, и старался играть среди них роль «губки». Я впитывал абсолютно все, что они мне давали. Убежден, что это оказалось огромное влияние на мою карьеру.
В стартапе я за редкими исключениями работал только над бэкендом с редкими вылазками в DevOps. Сначала я писал функции для дополнения или модификации возможностей, обычно не слишком масштабных. Но это было отличной возможностью ознакомиться с кодовой базой и пройти процедуру проверки кода.
Через год мне стали доверять целые фрагменты кодовой базы, а потом поручили сделать из набора функций сервис. Стартап как раз начинал переходить на сервис-ориентированную архитектуру. Мы стали превращать разные компоненты сайта в сервисы и между делом я много узнал о RESTful, аутентификации, AWS, шаблоне издатель-подписчик, распределенных системах и так далее.
Что самое интересное: я не учился ничему этому по книгам или в ходе университетского курса. Просто нужно было реализовать какие-то функции или устранить какие-то узкие места. И я такой: ну что ж, давайте разбираться!
Не раз и не два я впадал в аналитический паралич — состояние, когда излишне детальный анализ препятствовал прогрессу в разрешении проблемы. Именно в эти тяжелые моменты возникало больше всего возможностей для развития. Я совершенствовался в определении области действия функций, переговорах, мониторинге, настройке оповещений и составлении документации. На каждом шаге этого процесса обнаруживались новые концепты, которые мне нужно было освоить. За эти два-три года я как никогда вырос и с точки зрения навыков программирования, и в плане человеческих качеств.
После своих мучений при первом раунде поиск работы я пообещал себе, что в следующий раз как следует подготовлюсь к собеседованиям.
Подготовку я начал с того, что расписал, в чем я силен, в чем слаб, а что хорошо бы подтянуть. Все навыки я разбил по трем категориям: структуры данных, алгоритмы и дизайн систем.
В профессиональной сфере я работал в основном на PHP, а в колледже писал на C++, поэтому для собеседования решил подобрать что-нибудь попроще, не такое массивное.
Исходя из этих критериев, я остановил свой выбор на Python. Это отличный вариант для изучения: легко усваивается, поддерживает много структур данных по умолчанию и позволяет быстро прописать код на доске. Я освоил Python по туториалам на Youtube, вроде такого, и документации. Мне лично больше нравится Python 2.x, но вы можете выбирать между Python 2.x и Python 3.
Кстати, одна из причин, по которой я отдал предпочтение Python, состоит в том, что он очень прост для чтения и компактен при записи. Вот простой пример, чтобы сравнить C++ и Python.
Программа для сортировки в нисходящем порядке на С++:
Сравните с той же программой на Python:
Я слышал от специалистов, проводящих собеседования, что при прочих равных лучше склоняться к лаконичности при выборе языка. Чем больше времени из отведенных вам 45 минут вы сможете потратить собственно на решение задания, тем лучше.
Совет: выбирайте не слишком громоздкие языки, чтобы быстрее писать код на доске.
Где-то с неделю я прорешивал несложные задания на LeetCode, HackerRank и Project Euler, чтобы познакомиться с интерфейсами этих сайтов и привыкнуть писать на Python. За это время я смог лучше оценить свой уровень в некоторых языках программирования. Еще неделю я отвел на задания по дизайну, стараясь при этом охватывать как можно более широкий спектр и погружаться как можно глубже.
Это было очень увлекательно: часто я просто брал iOS приложения и смотрел, как они сделаны. Скажем, как создать Instagram с нуля (именно такой вопрос мне задали в Facebook)?
У меня в портфолио работа над API и сервис-ориентированной архитектурой. Поэтому я охотно воспользовался этой возможностью рассказать, как бы спроектировал свою версию Instagram. Благодаря сайд-проектам у меня также есть некоторый опыт разработки на iOS, так что заодно я ввернул словцо о callback-а, технологиях pull и длинных опросах.
Начал я с того, что перечислил функционал, который хотел бы видеть в собственной версии Instagram: лайки, загрузка фото и простая лента. Определение круга функций позволило мне выстроить очень добротный API, так как все эти сценарии хорошо мне знакомы.
Затем я нарисовал несколько схем высокого уровня, показывающих, как пользователь будет взаимодействовать с бэкендом и как там будут храниться данные. Я двигался от самого минимума, постепенно добавляя компоненты по мере надобности, и активно искал узкие места. Я делал обоснованные предположения (подчеркиваю: обоснованные) о том, какими будут требования, и как туда впишется та или иная технология. А также, что не менее важно, какие технологии не впишутся никак.
Например: почему для хранения определенного типа данных стоит использовать Cassandra, а не MySQL (подсказка: масштаб, скорость разработки, schema reviews), чем OAuth лучше простой аутентификации, Redis против Memcached при кэшировании данных, стриминг или пакетная обработка и так далее.
Тут можно исследовать разные области, обычно на все часовой сессии не хватает. Чтобы хорошо отвечать на такие вопросы, нужно досконально изучить проблему компромиссов, плюсы и минусы различных технологий в индустрии. Для этого я рекомендую сайты типа HighScalability.
Относитесь к этому, как к обычному мозговому штурму с коллегой, и стремитесь к максимально широкому подходу и глубокой проработке.
Крайне важно осознавать, что эти сессии по дизайну предназначены для того, чтобы выявить, что вы знаете и насколько хорошо — и что это ваша возможность показать себя в выгодном свете. Я посмотрел вот это видео от бывшего дизайнера Facebook о том, как подходить к заданиям по дизайну; его рекомендации очень помогли мне на собеседованиях. Две основных мысли, которые я из него вынес, звучат так: задавайте направление разговору о дизайне сами и покажите, что умеете.
Итак, я расписал свои навыки в том, что касается структур данных (связные списки, hash map, двоичные деревья, двоичные деревья поиска, кучи, массивы), алгоритмов (бинарный поиск, хэширование, динамическое программирование, сортировка) и синтаксиса и библиотек конкретных языков (lambda-функции для Python, append, index). Затем я выбрал область, в которой дела обстояли хуже всего, и стал работать над ней. Это оказались алгоритмы.
Алгоритмы никогда не были моей сильной стороной. С колледжа утекло уже много воды, а по работе мне не часто приходилось плотно заниматься двоичным поиском. Я имел общее представление о том, как работает каждый алгоритм и в каких сценариях их использовать. Но я не на сто процентов был уверен в своей способности прописать двоичный поиск меньше чем за десять минут. На доске. В присутствии человека, проводящего собеседование.
Заодно я прикупил целую кучу маркеров с Amazon — они прекрасно пишут. Не знаю, может, это только у меня так, но маркеры в офисах почему-то всегда выдохшиеся. Я обычно две-три минуты только и делаю, что перебираю маркеры в поисках нормального, а это не та ситуация, когда можно вот так разбрасываться временем. И еще: если брать тонкие маркеры, можно уместить на стандартную доску на 5-8 строк кода больше по сравнению с обычными.
Совет: обзаведитесь собственным набором маркеров.
Я купил в Costco доску за 50 $, набрал книг на Amazon (они перечислены в разделе с рекомендациями в конце статьи) и начал практиковаться. Я старался особенно нажимать на двоичный поиск, рекурсию, динамическое программирование, поиск в ширину и в глубину. Многие вопросы на собеседованиях касаются именно рекурсии и двоичного поиска или какой-то его вариации.
У самых лучших заданий, которые мне встречались, много разных решений, это обстоятельство тоже стоит учитывать в процессе подготовки.
Один вопрос, который мне задали в Google, касался каталогов файловой системы и того, как проводить их траверс (подсказка: рекурсия). Я довольно быстро представил решение, и проводящий собеседование спросил, как определить, что в папке не хватает файла. Это был вопрос посложнее, но я справился. После этого мы перешли к разговору о том, как перекомпоновать, сериализовать или десериализовать каталог и долгое время обсуждали, как работают каталоги под капотом. Я получил от этой сессии огромное удовольствие.
Опыт, мягко говоря, волнительный. Те еще американские горки.
Я распределил свое время так: 20% на резюме, 20% на ознакомление с компаниями, 60% на подготовку к собеседованию.
20% времени я потратил на обновление информации в резюме, которое не трогал три с лишним года. Я внимательно просмотрел все, чем занимался в прошлом, и отобрал те проекты, которые вел от начала до конца, независимо от уровня сложности.
На то у меня было две причины. Во-первых, способность довести проект до конца предполагает дисциплинированность и лидерские качества — то есть именно те черты, с которыми мне хотелось бы ассоциироваться у работодателей.
Во-вторых, подобная степень задействованности в проекте означает, что я могу рассказать о нем очень подробно и содержательно. Это обстоятельство оказалось критически важным на моем собеседовании в Twitter, где меня с пристрастием допрашивали не только о разных аспектах дизайна, но и о том, почему их решили реализовать именно так.
Еще 20% ушли на поиск информации. Под этим я подразумеваю то, что уделил должное внимание компаниям и разослал запросы на рекомендации. Рекомендации сильно повышают вероятность того, что вам перезвонят.
По собственному опыту: я разослал около 20 «холодных» писем стартапам и бизнесам средней величины, и ответили мне всего несколько из них. А вот из тех компаний, где за меня замолвил слово один из сотрудников, подавляющее большинство списались со мной в течение недели. Это, конечно, только один конкретный случай, но все-таки он о чем-то да говорит.
Я не отличаюсь общительностью и людей, способных меня порекомендовать компаниям, в которых я был заинтересован, знал не так уж много. Чтобы решить эту проблему, я направился на LinkedIn. С помощью их поискового механизма я нашел свои связи первого и второго уровней. Связи второго круга — это те люди, которые всего на шаг отстоят от вашего круга общения. Иными словами, у вас есть общие друзья, которые могут им за вас поручиться.
Это крайне важно, потому что пробиться на собеседование «холодным» способом очень и очень непросто, особенно в реалиях современного рынка. Люди в таких случаях предпочитают проявить осторожность. LinkedIn оказался очень полезен для стадии сбора информации.
Оглядываясь назад, вот мои впечатления о тех компаниях, в которых я проходил собеседования:
Я бы сказал, что собеседоваться у Twitter во многих отношениях сложно. Но при этом данный опыт был более индивидуальным и интересным, чем мои встречи с остальными компаниями.
Первый этап собеседования — телефонный разговор для знакомства с техническим руководителем. Затем следует одно или два технических интервью по телефону, количество зависит от ваших результатов. Если все в порядке, они пригласят вас прилететь в тот офис, на вакансию которого вы откликнулись, в моем случае это был офис в Сиэтле. Там вы пройдете три сессии продолжительностью в один час пятнадцать минут, на каждой присутствует по два сотрудника.
Два телефонных интервью проходят по обычной для технических должностей схеме: вы решаете задания в режиме совместного редактирования кода.
Сессии в офисе, однако, проходят куда менее формально и далеко не так пугают. Вас будут досконально расспрашивать о предыдущих проектах и обо всем, чем вы занимались до сих пор. Если вы заявляете, что участвовали в том или ином проекте, будьте готовы подробно о нем рассказать. Использование их как источника решений или для обкатки идей только поощряется.
Я ни разу не ощутил, что на меня давят, заставляя волшебным образом создать готовое, рабочее решение; наоборот, складывалось впечатление, что сотрудники настроены очень лояльно.
По сравнению с Twitter собеседования Facebook и Google показались мне более механическими. Они состояли из одного-двух телефонных интервью и пяти-шести сессий в офисе. На каждой сессии нужно было прописывать код на доске, причем требовалось практически идеальное решение, впрочем, и времени давали достаточно.
У Facebook было две сессии по программированию, одна по дизайну и одна для оценки личных качеств. В конце дня я прошел еще дополнительную «теневую» сессию, но на общий балл ее результаты не повлияли.
У Google было пять сессий, все по программированию. По дизайну не было вообще ничего и никто ни разу не заговорил о моих прошлых проектах. Я не говорю, что это однозначно плохо. Но мне кажется, что такой подход оставляет чувство конвейера и не дает разработчику в должной мере показать, на что он способен. Некоторым такой формат подходит — это как со студентами и экзаменами.
Собеседование в Pinterest мне не понравилось. Сам продукт кажется интересным, и команда, по всей видимости, работает над очень занятными задачами. Но мой опыт как соискателя был однозначно негативным.
Pinterest проводит три сессии по программированию, одну по дизайну. Из этих четырех меня разочаровала последняя. И вот почему.
Сотрудник, который проводит интервью, пришел с опозданием и первые несколько минут просто читал мое резюме. Затем он нарисовал на доске API, вкратце описал, что он должен делать, и спросил, как бы я это реализовал. Мы обговорили функционал и я стал прописывать на доске решение. Минут через пять я обернулся и увидел, что он задремал!
Не круто.
Я написал об этом в опроснике после собеседования, но со мной больше никто не связывался.
Не буду вдаваться в подробности о том, какие именно вопросы мне задавали на собеседованиях. Вместо этого перечислю некоторые полезные выводы и рекомендации, к которым пришел в процессе подготовки.
Технические интервью отличаются высокой сложностью, их исход иногда оказывается сложно предсказать. Однако наилучшие возможности выпадают тем, кто приходит подготовленным.
Мои заметки
На продуманную подготовку к собеседованиям у меня ушло около двух месяцев. Я занимался по 20 часов в неделю, то есть 80 часов в месяц, вдобавок к основной работе.
На то, чтобы составить хорошее резюме, у меня ушло три с половиной года упорной, продуманной работы. Я специально выскакивал себе работу посложнее и понеприятнее, чтобы учиться быстрее, чем все остальные. Пусть у меня за плечами не было диплома звездного университета или работы в топовой IT-компании, я компенсировал это ясным, доскональным пониманием проектов, над которыми работал. А добиться такого понимания мне помогла моя привычка записывать все, что я узнал, и упорядочивать информацию согласно определенной системе.
Помните: выживает сильнейший, преуспевает самый выносливый.
Если обобщить: не сдавайтесь, ищите возможности, больше практикуйтесь и не теряйте надежды. Сосредоточьтесь на процессе и выработайте к нему продуманный, дисциплинированный подход.
Elements of Programming Interviews — хороший источник с заданиями высокого уровня сложности
Cracking The Coding Interview — полезные материалы для освоения базового CS
OneNote — его я использую для хранения фрагментов кода
Evernote — а его — для всего остального
CodeRunner — отличная программа для Mac! Я часто ей пользовался для работы со специфическими скриптами/функциями на Python, работает просто отлично.
Jobscan — компания моего друга. Я слышал о них много хорошего, так что обращайтесь к ним за разбором резюме.
Refdash — инициатива нескольких бывших сотрудников Google. Их пробные собеседования — просто огонь по качеству. Сотрудник, который проводил со мной интервью, раньше работал в Google и рассказал мне очень много полезного о том, чему нужно уделить особое внимание и как бы меня оценили в Google. Очень рекомендую эту компанию.
CodePath — некоммерческая организация, которая помогает людям построить карьеру в IT-сфере. Нейтан и Тим — прекрасные люди, я многому у них научился. Сообщество очень отзывчивое, любой готов чем-нибудь помочь.
Вот эти тонкие маркеры — отлично пишут, очень рекомендую.
Если выбирать между двумя книгами, Cracking The Coding Interview лучше годится для того, чтобы отработать основы: как устроен связный список или hash map, как с ними работать и так далее. Elements of Programming Interviews подходит для тех, кому нужны задания посложнее. Я бы сделал так: две-три недели потратил на то, чтобы вдумчиво, от главы к главе, изучить Cracking The Coding Interview и освоиться со всеми библиотеками нужного вам языка. Все остальное время я бы посвятил Elements of Programming Interviews и представленным там заданиям — полное понимание базовых структур данных помогло бы мне в их решении.
Что вы найдете в этой статье:
- Кое-что из моей биографии
- Рассказ о том, как меня пригласили на собеседования топовые IT компании мира: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat и другие
- Рассказ о том, как я получил несколько предложений о работе на должности программиста
- Уроки, которые я вынес из этого опыта
Биографическая справка
Я не оканчивал университетов из Лиги плюща. Два года я проучился в общественном колледже в Айдахо, затем перевелся в маленький католический университет и там закончил обучение по специальности «Информатика».
Программированием я стал заниматься на первом курсе, просто потому, что мне показалось, что это будет занятно. Весь мой опыт с компьютерами до того момента исчерпывался китайской подделкой под приставку Nintendo, да и та сдыхала, стоило только вставить в нее картридж.
Чтобы себя обеспечивать, пока не получу образование, я брал по несколько подработок сразу — мыл полы, продавал еду в кинотеатрах. После выпуска у меня не было никакой работы на примете. Я разослал резюме по всем крупным IT-компаниям, каким только мог, и даже, по везению, получил несколько приглашений на телефонные интервью.
На тот момент я даже примерно себе не представлял, что это вообще такое — собеседование на техническую должность, и уж тем более, как к нему нужно готовиться. Я приходил на интервью с мыслью, что меня будут спрашивать о том, что такое связный список или двоичное дерево.
Естественно, на всех этих собеседованиях меня отсеяли.
Следующий шаг
Тогда я не слишком задумывался о том, хороший ли у меня уровень. Я знал, что быстро схватываю. Все, что мне было нужно — это возможность себя проявить.
Как говорит народная мудрость, сеть нужно забрасывать подальше и пошире. Так я и поступил.
За то, что я сделал на следующем этапе, я испытываю особую гордость. Я написал простенький скрипт на Python, который собирал вакансии с Craigslist, отбирая должности с определенными ключевыми словами, и вносил указанные там электронные адреса в таблицу. Не самое гениальное решение, но люди, которые размещают вакансии на Craigslist, на удивление точно называют должности.
На Craigslist, однако, не слишком любят, когда кто-то пытается выгрузить их данные. Чтобы обойти ограничения, я запускал скрипт через VPN и установил таймер, который приостанавливал процесс каждые несколько минут. Не идеально, но такая схема работала.
В конечном счете, я собрал около 500 адресов организаций, расположенных в Сан-Франциско, Портленде, Споконе и Сиэтле. Я отфильтровал результаты по релевантности и дате и продолжал оптимизировать выдачу, добавляя все больше и больше параметров.
Как выяснилось, на рынке уже было несколько ботов, которые собирали данные с Craigslist и автоматически рассылали письма. По большей части, это были офшорные компании, пытающиеся пробиться на рынок в США.
Одна из хитростей, к которым я прибегнул, состояла в следующем: я составлял текст писем так, чтобы тема содержала соответствующие ключевые слова. Затем я добавил еще кое-какие детали с опорой на текст вакансии, чтобы предложение выглядело заточенным под конкретные требования. Судя по быстрому A/B тесту, который я провел, процент откликов после этого значительно возрос — с 2-3% до 10%.
На мои разосланные 500 писем пришло порядка 50 ответов; с небольшим процентом от этих 50 мне удалось договориться об интервью по телефону. Я остановился на 500, потому что время поджимало — мне нужно было уже куда-то устроиться. Приоритетом на тот момент был результат, а не широта охвата.
По счастливой случайности, я получил работу в стартапе из Сиэтла, на позиции разработчика-джуниора. Их офис тогда располагался в Киркланде, так что мне пришлось 45 минут ехать на автобусе, чтобы успеть на собеседование.
Там я проработал следующие три с половиной года и многому научился: Amazon AWS, EC2, DynamoDB, SQS и Docker. За это время я сильно вырос как программист. Я научился писать модулярный, простой для поддержки код, правильно рассуждать о дизайне и решать проблемы при работе с людьми.
Я работал бок о бок с группой знающих людей, которые пришли к нам из Microsoft, Amazon и LinkedIn, и старался играть среди них роль «губки». Я впитывал абсолютно все, что они мне давали. Убежден, что это оказалось огромное влияние на мою карьеру.
Работа в стартапе
В стартапе я за редкими исключениями работал только над бэкендом с редкими вылазками в DevOps. Сначала я писал функции для дополнения или модификации возможностей, обычно не слишком масштабных. Но это было отличной возможностью ознакомиться с кодовой базой и пройти процедуру проверки кода.
Через год мне стали доверять целые фрагменты кодовой базы, а потом поручили сделать из набора функций сервис. Стартап как раз начинал переходить на сервис-ориентированную архитектуру. Мы стали превращать разные компоненты сайта в сервисы и между делом я много узнал о RESTful, аутентификации, AWS, шаблоне издатель-подписчик, распределенных системах и так далее.
Что самое интересное: я не учился ничему этому по книгам или в ходе университетского курса. Просто нужно было реализовать какие-то функции или устранить какие-то узкие места. И я такой: ну что ж, давайте разбираться!
Не раз и не два я впадал в аналитический паралич — состояние, когда излишне детальный анализ препятствовал прогрессу в разрешении проблемы. Именно в эти тяжелые моменты возникало больше всего возможностей для развития. Я совершенствовался в определении области действия функций, переговорах, мониторинге, настройке оповещений и составлении документации. На каждом шаге этого процесса обнаруживались новые концепты, которые мне нужно было освоить. За эти два-три года я как никогда вырос и с точки зрения навыков программирования, и в плане человеческих качеств.
Как я готовился к собеседованиям
После своих мучений при первом раунде поиск работы я пообещал себе, что в следующий раз как следует подготовлюсь к собеседованиям.
Подготовку я начал с того, что расписал, в чем я силен, в чем слаб, а что хорошо бы подтянуть. Все навыки я разбил по трем категориям: структуры данных, алгоритмы и дизайн систем.
В профессиональной сфере я работал в основном на PHP, а в колледже писал на C++, поэтому для собеседования решил подобрать что-нибудь попроще, не такое массивное.
Исходя из этих критериев, я остановил свой выбор на Python. Это отличный вариант для изучения: легко усваивается, поддерживает много структур данных по умолчанию и позволяет быстро прописать код на доске. Я освоил Python по туториалам на Youtube, вроде такого, и документации. Мне лично больше нравится Python 2.x, но вы можете выбирать между Python 2.x и Python 3.
Кстати, одна из причин, по которой я отдал предпочтение Python, состоит в том, что он очень прост для чтения и компактен при записи. Вот простой пример, чтобы сравнить C++ и Python.
Программа для сортировки в нисходящем порядке на С++:
#include <bits/stdc++.h>
using namespace std;
int main()
{
int arr[] = {1,10,0,4,5}
int n = size(arr)/sizeof(arr[0]);
sort(arr, arr + n, greater<int>());
for (int i = 0; i < n; i++) {
cout << arr[i] << " ";
}
return 0;
}Сравните с той же программой на Python:
a = [1,2,4,5,1000]
a.sort(reverse=True)
print aЯ слышал от специалистов, проводящих собеседования, что при прочих равных лучше склоняться к лаконичности при выборе языка. Чем больше времени из отведенных вам 45 минут вы сможете потратить собственно на решение задания, тем лучше.
Совет: выбирайте не слишком громоздкие языки, чтобы быстрее писать код на доске.
В модусе подготовки
Где-то с неделю я прорешивал несложные задания на LeetCode, HackerRank и Project Euler, чтобы познакомиться с интерфейсами этих сайтов и привыкнуть писать на Python. За это время я смог лучше оценить свой уровень в некоторых языках программирования. Еще неделю я отвел на задания по дизайну, стараясь при этом охватывать как можно более широкий спектр и погружаться как можно глубже.
Это было очень увлекательно: часто я просто брал iOS приложения и смотрел, как они сделаны. Скажем, как создать Instagram с нуля (именно такой вопрос мне задали в Facebook)?
У меня в портфолио работа над API и сервис-ориентированной архитектурой. Поэтому я охотно воспользовался этой возможностью рассказать, как бы спроектировал свою версию Instagram. Благодаря сайд-проектам у меня также есть некоторый опыт разработки на iOS, так что заодно я ввернул словцо о callback-а, технологиях pull и длинных опросах.
Начал я с того, что перечислил функционал, который хотел бы видеть в собственной версии Instagram: лайки, загрузка фото и простая лента. Определение круга функций позволило мне выстроить очень добротный API, так как все эти сценарии хорошо мне знакомы.
Затем я нарисовал несколько схем высокого уровня, показывающих, как пользователь будет взаимодействовать с бэкендом и как там будут храниться данные. Я двигался от самого минимума, постепенно добавляя компоненты по мере надобности, и активно искал узкие места. Я делал обоснованные предположения (подчеркиваю: обоснованные) о том, какими будут требования, и как туда впишется та или иная технология. А также, что не менее важно, какие технологии не впишутся никак.
Например: почему для хранения определенного типа данных стоит использовать Cassandra, а не MySQL (подсказка: масштаб, скорость разработки, schema reviews), чем OAuth лучше простой аутентификации, Redis против Memcached при кэшировании данных, стриминг или пакетная обработка и так далее.
Тут можно исследовать разные области, обычно на все часовой сессии не хватает. Чтобы хорошо отвечать на такие вопросы, нужно досконально изучить проблему компромиссов, плюсы и минусы различных технологий в индустрии. Для этого я рекомендую сайты типа HighScalability.
Относитесь к этому, как к обычному мозговому штурму с коллегой, и стремитесь к максимально широкому подходу и глубокой проработке.
Крайне важно осознавать, что эти сессии по дизайну предназначены для того, чтобы выявить, что вы знаете и насколько хорошо — и что это ваша возможность показать себя в выгодном свете. Я посмотрел вот это видео от бывшего дизайнера Facebook о том, как подходить к заданиям по дизайну; его рекомендации очень помогли мне на собеседованиях. Две основных мысли, которые я из него вынес, звучат так: задавайте направление разговору о дизайне сами и покажите, что умеете.
Итак, я расписал свои навыки в том, что касается структур данных (связные списки, hash map, двоичные деревья, двоичные деревья поиска, кучи, массивы), алгоритмов (бинарный поиск, хэширование, динамическое программирование, сортировка) и синтаксиса и библиотек конкретных языков (lambda-функции для Python, append, index). Затем я выбрал область, в которой дела обстояли хуже всего, и стал работать над ней. Это оказались алгоритмы.
Алгоритмы никогда не были моей сильной стороной. С колледжа утекло уже много воды, а по работе мне не часто приходилось плотно заниматься двоичным поиском. Я имел общее представление о том, как работает каждый алгоритм и в каких сценариях их использовать. Но я не на сто процентов был уверен в своей способности прописать двоичный поиск меньше чем за десять минут. На доске. В присутствии человека, проводящего собеседование.
Заодно я прикупил целую кучу маркеров с Amazon — они прекрасно пишут. Не знаю, может, это только у меня так, но маркеры в офисах почему-то всегда выдохшиеся. Я обычно две-три минуты только и делаю, что перебираю маркеры в поисках нормального, а это не та ситуация, когда можно вот так разбрасываться временем. И еще: если брать тонкие маркеры, можно уместить на стандартную доску на 5-8 строк кода больше по сравнению с обычными.
Совет: обзаведитесь собственным набором маркеров.
Я купил в Costco доску за 50 $, набрал книг на Amazon (они перечислены в разделе с рекомендациями в конце статьи) и начал практиковаться. Я старался особенно нажимать на двоичный поиск, рекурсию, динамическое программирование, поиск в ширину и в глубину. Многие вопросы на собеседованиях касаются именно рекурсии и двоичного поиска или какой-то его вариации.
У самых лучших заданий, которые мне встречались, много разных решений, это обстоятельство тоже стоит учитывать в процессе подготовки.
Один вопрос, который мне задали в Google, касался каталогов файловой системы и того, как проводить их траверс (подсказка: рекурсия). Я довольно быстро представил решение, и проводящий собеседование спросил, как определить, что в папке не хватает файла. Это был вопрос посложнее, но я справился. После этого мы перешли к разговору о том, как перекомпоновать, сериализовать или десериализовать каталог и долгое время обсуждали, как работают каталоги под капотом. Я получил от этой сессии огромное удовольствие.
Собеседования в топовых компаниях
Опыт, мягко говоря, волнительный. Те еще американские горки.
Я распределил свое время так: 20% на резюме, 20% на ознакомление с компаниями, 60% на подготовку к собеседованию.
20% времени я потратил на обновление информации в резюме, которое не трогал три с лишним года. Я внимательно просмотрел все, чем занимался в прошлом, и отобрал те проекты, которые вел от начала до конца, независимо от уровня сложности.
На то у меня было две причины. Во-первых, способность довести проект до конца предполагает дисциплинированность и лидерские качества — то есть именно те черты, с которыми мне хотелось бы ассоциироваться у работодателей.
Во-вторых, подобная степень задействованности в проекте означает, что я могу рассказать о нем очень подробно и содержательно. Это обстоятельство оказалось критически важным на моем собеседовании в Twitter, где меня с пристрастием допрашивали не только о разных аспектах дизайна, но и о том, почему их решили реализовать именно так.
Еще 20% ушли на поиск информации. Под этим я подразумеваю то, что уделил должное внимание компаниям и разослал запросы на рекомендации. Рекомендации сильно повышают вероятность того, что вам перезвонят.
По собственному опыту: я разослал около 20 «холодных» писем стартапам и бизнесам средней величины, и ответили мне всего несколько из них. А вот из тех компаний, где за меня замолвил слово один из сотрудников, подавляющее большинство списались со мной в течение недели. Это, конечно, только один конкретный случай, но все-таки он о чем-то да говорит.
Я не отличаюсь общительностью и людей, способных меня порекомендовать компаниям, в которых я был заинтересован, знал не так уж много. Чтобы решить эту проблему, я направился на LinkedIn. С помощью их поискового механизма я нашел свои связи первого и второго уровней. Связи второго круга — это те люди, которые всего на шаг отстоят от вашего круга общения. Иными словами, у вас есть общие друзья, которые могут им за вас поручиться.
Это крайне важно, потому что пробиться на собеседование «холодным» способом очень и очень непросто, особенно в реалиях современного рынка. Люди в таких случаях предпочитают проявить осторожность. LinkedIn оказался очень полезен для стадии сбора информации.
Оглядываясь назад, вот мои впечатления о тех компаниях, в которых я проходил собеседования:
- Facebook/Google — все очень механически. Собеседования проходили по шаблону, и я не ощутил никакой личной связи.
- Pinterest — не лучший опыт в плане собеседования, но сам продукт и компания классные.
- Microsoft — мне очень понравилась команда, особенно менеджер и ее руководитель. Вопросы были стандартные, но подход очень личный. Серьезный конкурент на позицию моего фаворита. У вас, впрочем, может сложиться другое впечатление: каждая команда в Microsoft проводит интервью по-своему.
- Amazon — все стандартно. Половине соискателей такой подход нравится, остальным — нет.
- Twitter — очень увлекательно и персонализировано. Собеседование прошло отлично, много внимания было уделено моему предыдущему опыту и человеческим качествам.
- Snapchat — шикарный офис в Лос-Анджелесе и большая компания людей, которые решили присоединиться к стартапу. Чувство было такое, будто на всем завеса секретности.
- Lyft — недалеко от моего дома, симпатичный офис, собеседование по стандартной схеме. Не оставили сильного впечатления.
Сначала о моем фаворите
Я бы сказал, что собеседоваться у Twitter во многих отношениях сложно. Но при этом данный опыт был более индивидуальным и интересным, чем мои встречи с остальными компаниями.
Первый этап собеседования — телефонный разговор для знакомства с техническим руководителем. Затем следует одно или два технических интервью по телефону, количество зависит от ваших результатов. Если все в порядке, они пригласят вас прилететь в тот офис, на вакансию которого вы откликнулись, в моем случае это был офис в Сиэтле. Там вы пройдете три сессии продолжительностью в один час пятнадцать минут, на каждой присутствует по два сотрудника.
Два телефонных интервью проходят по обычной для технических должностей схеме: вы решаете задания в режиме совместного редактирования кода.
Сессии в офисе, однако, проходят куда менее формально и далеко не так пугают. Вас будут досконально расспрашивать о предыдущих проектах и обо всем, чем вы занимались до сих пор. Если вы заявляете, что участвовали в том или ином проекте, будьте готовы подробно о нем рассказать. Использование их как источника решений или для обкатки идей только поощряется.
Я ни разу не ощутил, что на меня давят, заставляя волшебным образом создать готовое, рабочее решение; наоборот, складывалось впечатление, что сотрудники настроены очень лояльно.
А теперь обо всех остальных
По сравнению с Twitter собеседования Facebook и Google показались мне более механическими. Они состояли из одного-двух телефонных интервью и пяти-шести сессий в офисе. На каждой сессии нужно было прописывать код на доске, причем требовалось практически идеальное решение, впрочем, и времени давали достаточно.
У Facebook было две сессии по программированию, одна по дизайну и одна для оценки личных качеств. В конце дня я прошел еще дополнительную «теневую» сессию, но на общий балл ее результаты не повлияли.
У Google было пять сессий, все по программированию. По дизайну не было вообще ничего и никто ни разу не заговорил о моих прошлых проектах. Я не говорю, что это однозначно плохо. Но мне кажется, что такой подход оставляет чувство конвейера и не дает разработчику в должной мере показать, на что он способен. Некоторым такой формат подходит — это как со студентами и экзаменами.
Собеседование в Pinterest мне не понравилось. Сам продукт кажется интересным, и команда, по всей видимости, работает над очень занятными задачами. Но мой опыт как соискателя был однозначно негативным.
Pinterest проводит три сессии по программированию, одну по дизайну. Из этих четырех меня разочаровала последняя. И вот почему.
Сотрудник, который проводит интервью, пришел с опозданием и первые несколько минут просто читал мое резюме. Затем он нарисовал на доске API, вкратце описал, что он должен делать, и спросил, как бы я это реализовал. Мы обговорили функционал и я стал прописывать на доске решение. Минут через пять я обернулся и увидел, что он задремал!
Не круто.
Я написал об этом в опроснике после собеседования, но со мной больше никто не связывался.
Не буду вдаваться в подробности о том, какие именно вопросы мне задавали на собеседованиях. Вместо этого перечислю некоторые полезные выводы и рекомендации, к которым пришел в процессе подготовки.
Чему я научился
- Будьте честным при составлении резюме. Большинство компаний будет задавать вопросы о том, что там написано, и сразу поймет, если вы начнете выдумывать. Лучше знать один проект на 100%, чем располагать 10% информации о десяти разных проектах.
- Одностраничные резюме предпочтительнее. Для IT-сферы это особенно актуально. По негласному правилу, на две страницы могут претендовать те, у кого есть ученая степень и много публикаций, либо те, кто был по-настоящему глубоко вовлечен в большое количество проектов. Кстати, один из моих друзей основал компанию под названием Jobscan, которая анализирует резюме и предлагает конкретные действия по их улучшению. Отличный сервис, можете попробовать.
- Общайтесь, заводите связи. Конкуренция среди программистов очень высока, топовые IT-компании обрабатывают тысячи резюме в день. Рекомендация сотрудника поможет вам привлечь к себе внимание.
- Умейте себя продать. Любая компания, заинтересованная в вас, хочет знать, почему вы заинтересованы в ней. «Мне нужна работа, надо же на что-то жить» — плохой ответ. «Я искал варианты в Интернете и увидел ваш сайт» — получше, но все равно не очень. Хороший ответ звучит как-то так: «Я слышал, что у вас есть интересные проекты по X, которые могут способствовать Y. В ходе работы над прошлыми проектами я освоил A, B, C, которые можно применить в Х. Я испытываю живой интерес к Y, потому что бла-бла-бла». (Только не используйте это как шаблон. Тут нужно прост уловить паттерн: соберите информацию о компании, обратитесь к своей биографии и покажите, почему вы друг другу подходите.)
И еще несколько советов
Технические интервью отличаются высокой сложностью, их исход иногда оказывается сложно предсказать. Однако наилучшие возможности выпадают тем, кто приходит подготовленным.
- Начинайте готовиться заранее и как следует. О том, что нужно готовиться к собеседованиям, знают все, но не все знают, как делать это правильно. Как и с любым другим стоящим навыком, чтобы достичь хорошего результата, нужно практиковаться по продуманной схеме. А продуманная схема требует какой-то системы.
- Создайте систему для совершенствования технических навыков. Я начал с того, что оценил свои умения в разных областях по десятибалльной шкале и стал подтягивать те, которые получили самые низкие оценки. Я тратил на каждый тип задания по несколько дней, пока не отрабатывал каждый концепт как следует. Каждый день я делал заметки в Evernote. У меня был особый блокнот, отведенный под записи на тему программирования. Туда я заносил советы и хитрости, распространенные ошибки и заблуждения, алгоритмы решения заданий разных типов и многое другое.
- Ведите записи о том, чему научились. Я использовал для этой цели как Evernote, так и OneNote. OneNote предназначался для строго технических вещей и кода, мне нравилось, что там можно форматировать записи как угодно. Evernote я использовал для рассуждений и идей. Выше вы можете видеть мои заметки об архитектуре и дизайне систем.
- Фиксируйте все, что можно, даже если вам кажется, что это вряд ли пригодится. Я очень забывчивый, поэтому записываю все, что выучил, включая команды для командной строки. Также я часто читаю блоги программистов, и если попадется что-то интересное, тут же заношу это в Evernote. В конце каждой недели или каждого месяца я просматриваю записи и привожу их в порядок. Эта привычка оказалась очень полезной для моей карьеры.
- Устраивайте репетиции. Это очень ценный опыт, который я рекомендую всем. Я просил друзей разыграть со мной «собеседование» и старался устраивать такие тренировки как можно чаще. Если вам не к кому обратиться, могу посоветовать Refdash, которые оказывают услуги по организации пробных интервью. У них работают специалисты из крупных IT-компаний вроде Google, Facebook и Microsoft. Эти сотрудники проведут оценку ваших навыков программирования и дизайна и, что самое главное, представят итоговый балл и конкретные рекомендации о том, над чем нужно поработать.
- В неудачах нет ничего страшного. В процессе поиска работы я завалил массу собеседований. Иногда бывает такое, что просто день не ваш. Даже если все кончилось провалом, это еще не конец света. Компании вообще больше склонны говорить «нет», чем «да» — меньше риска. В долгосрочной перспективе недооценить кандидата не так убыточно, как переоценить. Первые несколько отказов определенно были самыми болезненными. При первых попытках устроиться на работу меня отсеивали еще на этапе телефонных интервью, и это подорвало мою веру в себя. Я стал сомневаться в своих способностях и бояться, что мои навыки не востребованы на современном рынке труда. Но я придумал для себя такую формулу: если потерпел неудачу 10 раз, сделай еще 10 попыток. Достаточно достичь успеха всего один раз. Такой образ мышления придал мне уверенности в себе и сил, чтобы продолжать попытки. Когда я наконец получил первое предложение о работе, все пошло гораздо проще.
Мои заметки
На продуманную подготовку к собеседованиям у меня ушло около двух месяцев. Я занимался по 20 часов в неделю, то есть 80 часов в месяц, вдобавок к основной работе.
На то, чтобы составить хорошее резюме, у меня ушло три с половиной года упорной, продуманной работы. Я специально выскакивал себе работу посложнее и понеприятнее, чтобы учиться быстрее, чем все остальные. Пусть у меня за плечами не было диплома звездного университета или работы в топовой IT-компании, я компенсировал это ясным, доскональным пониманием проектов, над которыми работал. А добиться такого понимания мне помогла моя привычка записывать все, что я узнал, и упорядочивать информацию согласно определенной системе.
Помните: выживает сильнейший, преуспевает самый выносливый.
Если обобщить: не сдавайтесь, ищите возможности, больше практикуйтесь и не теряйте надежды. Сосредоточьтесь на процессе и выработайте к нему продуманный, дисциплинированный подход.
Рекомендуемые инструменты
Elements of Programming Interviews — хороший источник с заданиями высокого уровня сложности
Cracking The Coding Interview — полезные материалы для освоения базового CS
OneNote — его я использую для хранения фрагментов кода
Evernote — а его — для всего остального
CodeRunner — отличная программа для Mac! Я часто ей пользовался для работы со специфическими скриптами/функциями на Python, работает просто отлично.
Jobscan — компания моего друга. Я слышал о них много хорошего, так что обращайтесь к ним за разбором резюме.
Refdash — инициатива нескольких бывших сотрудников Google. Их пробные собеседования — просто огонь по качеству. Сотрудник, который проводил со мной интервью, раньше работал в Google и рассказал мне очень много полезного о том, чему нужно уделить особое внимание и как бы меня оценили в Google. Очень рекомендую эту компанию.
CodePath — некоммерческая организация, которая помогает людям построить карьеру в IT-сфере. Нейтан и Тим — прекрасные люди, я многому у них научился. Сообщество очень отзывчивое, любой готов чем-нибудь помочь.
Вот эти тонкие маркеры — отлично пишут, очень рекомендую.
Если выбирать между двумя книгами, Cracking The Coding Interview лучше годится для того, чтобы отработать основы: как устроен связный список или hash map, как с ними работать и так далее. Elements of Programming Interviews подходит для тех, кому нужны задания посложнее. Я бы сделал так: две-три недели потратил на то, чтобы вдумчиво, от главы к главе, изучить Cracking The Coding Interview и освоиться со всеми библиотеками нужного вам языка. Все остальное время я бы посвятил Elements of Programming Interviews и представленным там заданиям — полное понимание базовых структур данных помогло бы мне в их решении.
Комментарии (12)
php7
13.04.2018 21:18А зачем туда попадать? :)
ganqqwerty
13.04.2018 22:02+1В Америке — не знаю, может быть, кому-то и прикольно. Если подразделение в Европе, то не так уж и плохо, есть вероятность что культуры торчания на работе по 12 часов не будет, отпуск точно будет, до работы добираться будет проще, ну и денег много дают.
zenkz
13.04.2018 21:23Могу сказать, что одностраничное резюме не всегда лучше двухстраничного. Намного важнее, чтобы резюме было чётко разделено на секции и тогда читающий может пропустить то, что ему не нужно. У меня, к примеру, 2 страницы, но из них 1 страница — это краткое описание проектов и технологий, которые на них использовал (хронологически, по датам). Если это не интересно работодателю, то он можео пропустить эту часть, но если заинтересовался, то это может быть хорошей основой для тем интервью.
Собеседование с Амазоном я был немного разочарован (к другим гигантам не подавался) — очень уж формальный подход. Задачку дали не сложную, но она скорее хороша для выпускников колледжей, а не для тех кто приходит уже с большим опытом. Я бы на их месте лучше поговорил о прошлых проектам и больше поспрашивал про дизайн и архитектуру, а также про структуры данных. Ну да посмотрим… Моя эпопея с ними только началась…
Dywar
13.04.2018 23:06Тоже делаю заметки, в моем случае это OneNote для всего. Пишу в него все интересное что нахожу в книгах, блогах или самостоятельно.
Сложнее всего заставить себя перечитать свои заметки по конкретной теме, что бы лучше запомнилось.
mbait
15.04.2018 05:04+2Как попасть в Microsoft, Amazon или Twitter без диплома престижного колледжа... и там говнокодить на С++.
#include <bits/stdc++.h> using namespace std; int main() { array<int,5> arr = { 1, 10, 0, 4, 5 }; sort(arr.begin(), arr.end(), greater<int>()); copy(arr.begin(), arr.end(), ostream_iterator<int>(cout, " ")) ; // return 0 не требуется по стандарту }
Stas911
Интересная статья, но если исписать на собеседовании всю доску перманентными маркерами (а именно на них стоит линк) — то, боюсь, могут и побить.
Про одностраничные резюме — такое правда в ходу в ИТ в США?
khim
Ну вы можете и на 20 страниц расписаться, но прочитают одну в лучшем случае.
Areso
Имхо, 1 страница подходит лишь для молодых людей, или людей работавших долго на одной позиции в одной компании. Остальным ну очень сложно будет уложить 20-30 лет опыта в 1 страничку. Тем более, что нынче рекомендуют писать не только где и когда работал, но еще что делал (использовал) и чего добился.
khim
Как я уже сказал: вы можете написать хоть 20 старниц (у меня самого 5). Но читать будут первую в лучшем случае — и это надо понимать.
VenomBlood
1 страница подходит в подавляющем большинстве случаев. Зачем расписывать 20-30 лет опыта, когда смотреть будут на последние лет 5 в лучшем случае? Ваши должностные обязанности 10 летней давности все равно не релеватны, если вы последние лет 5 этим не занимались. А если занимались — они будут в последних 5 годах. Просто не нужно раздувать резюме бесполезной информацией. Фото, адрес, пол, возраст, 10 методов контакта, языки, на которых говорите (кроме случая когда этот набор неочевиден и является важным для работы, что очень редко в IT), адреса работодателей, самоочевидные навыки (windows, word, outlook), тривиальные навыки (git, visual studio, Eclipse, Idea, Resharper), навыки не относящиеся к делу и вещи которые вы просто тыкали палочкой (перечисление 10 языков программирования, учитывая что в 8 из этих 10 вы не знаете стандартную библиотеку на сколько нибудь комфортном уровне, и 8 из 10 вообще не важны для вакансии) и подобное — выкинуть.
Остается имя, телефон, email, objective с перечислением основных скиллов, релевантных для данной вакансии и 2-4 последних места работы с кратким общим описанием достижений и области ответственности, если недавний выпускник — можно указать университет. Все. Все это без проблем поместится на 1 странице с форматированием и без ужимания размера шрифта.