[Перевод] Как попасть в Microsoft, Amazon или Twitter без диплома престижного колледжа
Эта статья для тех, кто готовится искать работу и, возможно, тревожится о том, что в топовые компании без диплома Стэнфордского университета по информатике не пробьешься. Вам наверняка говорили, что вас никто не возьмет в Facebook или Microsoft. Но я хочу вам сказать, что это вполне возможно. Вот моя история о том, как мне удалось получить работу своей мечты в Twitter.
Что вы найдете в этой статье:
- Кое-что из моей биографии
- Рассказ о том, как меня пригласили на собеседования топовые 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
using namespace std;
int main()
{
int arr[] = {1,10,0,4,5}
int n = size(arr)/sizeof(arr[0]);
sort(arr, arr + n, greater());
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 и представленным там заданиям — полное понимание базовых структур данных помогло бы мне в их решении.