Хабрахабр

[Перевод] Как попасть в 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 <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 и представленным там заданиям — полное понимание базовых структур данных помогло бы мне в их решении.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»