×

Мой путь в западные продуктовые компании: от отказа Twitter до оффера Facebook

Всем привет. Последние полгода я провел собеседуясь в компании из Кремниевой долины и хотел бы поделиться с вами историей своих проб и ошибок на пути к офферу. Из этой статьи вы узнаете о процессах найма в разных компаниях и поймете, на что важно обратить внимание во время собеседований.

Начало пути и DataStax

Моя дорога к работе мечты началась с обычного чтения ленты в Твиттере. Я увидел твит от Alex Petrov, в котором он искал инженеров для работы над Cassandra в DataStax.

В описании вакансии я увидел все, что подходило под описание идеальной работы для меня: отсутствие офиса, распределенная команда, highload база данных, которая используется во всем мире, и самые интересные технические вызовы в контексте распределенных систем. На тот момент я и мечтать не мог о том, что хотя бы попаду на собеседование. Я написал Алексу в личные сообщения и через пару дней получил письмо с приглашением начать общение и первым заданием. Ну что же, let the fun begin.

Собеседование в DataStax состоит из трех частей (спойлер: я зафейлился на второй): открытые теоретические вопросы, практическое задание и общение с командой. Получив теоретические вопросы, я был приятно удивлен тем, что они так или иначе связаны с реальными проблемами, которые решает Cassandra. Это не был очередной набор задач из Cracking the Coding Interview, взятых для галочки. В итоге, отправив решения, я на следующий день получил письмо с пропуском на второй этап.

На втором этапе вместо написания какого-то очередного бесполезного сервиса или имплементации алгоритма, мне прислали спеку для нового CQL оператора. За время, ограниченное здравым смыслом (дедлайн не указывали), мне нужно было разобраться с исходниками базы данных и имплементировать спеку. Ничего сложного, не правда ли? :)

Решив, что нужно все сделать как можно быстрее, я не стал тратить время на whitepapers, которые мне порекомендовали прочитать перед выполнением задачи. Две недели я получал удовольствие от постепенного понимания того, как работает база данных изнутри. В итоге я начал приближаться к решению задачи. Решив, что тянуть больше нельзя и потратив вечер на оформление решения, я отправил патч на проверку. Оказалось, что мое решение работало не корректно, а для исправления пришлось бы переписать половину. Этого можно было бы избежать, если бы я понял, что интервьюеры осознавали его сложность и не ожидали, что я справлюсь с ним быстро. Раз уж на то пошло, то они почти прямым текстом об этом писали в описании задания.

Я получил фидбэк о решении задачи, множество опыта, связанного со строением баз данных, и заразился идеей того, что работу мечты найти легче, чем может казаться.

Прорваться на собеседование в Elastic

Следующей компанией, которую я для себя выделил, была Elastic. На самом деле со стороны она очень похожа на DataStax в плане работы. Те же распределенные команды и highload база данных, но здесь занимаются полнотекстовым поиском.

С этой компанией я начал делать все неправильно с самого начала. Самая большая ошибка, которую вы можете совершить, — это открыть страницу вакансий и подать резюме через нее. Проблема в том, что вы стучитесь в те же двери, что и остальные, и, скорее всего, ваше резюме будет отброшено в долгий ящик.

Подождав пару недель и увидев шаблонное письмо с отказом, я начал искать сотрудников компании. Написал одному из разработчиков в Core team, пообщался с ним и получил реферал. Но так как я уже был отмечен в системе, то получил отказ без объяснения причины. В это время я узнал, что в Elastic разрабатывают не только базу данных, но и разный тулинг вокруг нее. Подав резюме в одну из таких команд, я попал на интервью. Я планировал пообщаться с рекрутерами и другими членами команды и узнать, можно ли потом перейти в Core team, которая была мне интересна.

Я прошел два этапа собеседований. Первый был с одним из разработчиков Elastic Cloud, на котором мы обсуждали мой предыдущий опыт и провели небольшое system design interview. О нем я расскажу больше в контексте собеседования в Facebook. Следующее собеседование было с тимлидом команды. Мы больше говорили о том, что мне интересно, а также я отвечал на базовые вопросы из курса Computer Science. Я был «слегка» удивлен, когда через час после собеседования получил отказ. До этого я не относился к мотивационным интервью серьезно, но, как оказалось, для продуктовых компаний это один из самых важных этапов. Интервьюер сказал, что мне вряд ли будет интересно работать у них в команде и лучше бы мне пойти на собеседование в Core team. Учитывая, что HR’ы из этой команды не хотели даже говорить со мной, я попал в ситуацию, когда все двери оказались закрыты.

Молчаливый рекрутинг Твиттера

После провала с предыдущими двумя позициями пришло время постучаться в двери компаний из более привычного списка. Я разослал около двадцати шаблонных писем работникам Twitter в LinkedIn — просил зарефералить меня на вакансию, связанную с разработкой инфраструктуры для machine learning департамента. Один из контактов ответил мне, и так началось общение с рекрутером. После короткого разговора мы определились с позицией, и начался процесс интервью.

Само собеседование было коротким — небольшой разговор с лидом команды, тестовое задание и... 4 недели тишины. Последние две недели я пытался разными способами узнать у HR, что происходит, и слышал лишь пустоту. Рекрутер не отвечал на мои письма, звонки и SMS. Мне повезло получить телефонный номер лида во время собеседования. Когда я позвонил ему и объяснил ситуацию, он пообещал помочь. Через два дня позвонил HR и объяснил, что позиция на которую меня собеседовали, была закрыта кем-то изнутри компании и мое решение задачи даже не смотрели. Взамен мне предложили другие вакансии, и мы остановились на infrastructure team, где инженеры строят базы данных специально для Твиттера. Этот вариант был даже лучше прошлого, и мы начали процесс заново.

В этот раз собеседование разительно отличалось от предыдущего. Один за другим пришли приглашения на мотивационное, кодинг и system design интервью. Особенность команды в том, что она распределена между разными офисами компании, поэтому можно было не лететь в Лондон ради интервью. Первое собеседование было с engineering manager’ом команды, на котором мы обсудили причины моего ухода из тех или иных компаний и мотивацию заниматься программированием вместо чего либо еще. Это было одно из самых лучших мотивационных интервью по моему опыту, так как оно проходило в абсолютно непринужденной обстановке и выглядело просто как общение двух знакомых. Остальные этапы интервью провела другая команда. Сейчас я понимаю, что не уделил достаточно внимания подготовке к system design интервью и не смог хорошо справиться с ним. Неожиданно, но нужно было спроектировать распределенную базу данных.

Через три дня после собеседования меня ждало шаблонное письмо с отказом на почтовом ящике. Я потратил так много усилий на весь процесс, поэтому хотел получить больше объяснений, но HR, как обычно, не отвечал. Я написал engineering manager’у напрямую и был приятно удивлен подробным фидбэком. Я получил пищу для размышлений и до сих пор благодарен интервьюеру за его открытость.

Причиной отказа послужило вовсе не так себе пройденное system design интервью, а личные мотивации. В компании опасались, что через пару лет мне станет скучно и я со всеми накопленными опытом и знаниями уйду ради более интересных задач/большей зарплаты. Fair enough, разделяя эту точку зрения, я отправился на поиски дальше, ведь в этот раз я просто выбрал двери не той компании.

Окей, Google

Однажды из разговора со своим бывшим лидом Pavlo Voznenko (кстати, если вы интересуетесь переездом в Германию, у него есть отличная статья об этом) я узнал о его знакомых инженерах в Google и Facebook. Воспользовавшись знакомствами, я быстро получил рефералы и приглашения на собеседования в обе компании. Первым меня ждало общение с Google.

Еще до разговора с Пашей, используя фидбэк после собеседования в Твиттер, я начал закрывать пробелы в своих знаниях. В ход шли whitepapers, которые присылал DataStax, курсы Седжвика на Coursera и разные статьи в интернете, которые объясняли непонятные мне термины и конструкции. Сам процесс разбора занял около месяца и закончился как раз к началу собеседований в обеих компаниях.

Собеседование в Google состоит из трех этапов: общения с рекрутером, онлайн- и оффлайн-этапов. Во время общения с рекрутером вы узнаете о процессе интервью и пройдете небольшой тест, по результатам которого вам могут порекомендовать почитать подготовительные материалы и взять паузу перед онлайн-этапом. Сам тест представляет собой около десяти вопросов на разные темы, начиная от базовых структур данных, заканчивая задачами, связанными с языками программирования и задачей на логику. Забавно, но это было первое собеседование за долгое время, на котором меня спросили про основные принципы ООП. В своем большинстве мой опыт был связан с функциональным программированием, поэтому пришлось быстро вспоминать заветные четыре слова :)

Перед интервью я взял небольшую паузу, чтобы закончить разбор материалов. Само интервью проходило через Hangouts, в качестве доски предложили использовать Google Docs. Забегая вперед, скажу, что это не лучшее место для написания кода. Приходилось все время мучиться с отступами и недостаточной максимальной длиной строки.

Сама задача совмещала в себе логическую часть и понимание алгоритмов поиска пути. Решение нужно было написать на «произвольном» языке. Вариант использовать JavaScript или Scala не сильно обрадовал моего интервьюера, поэтому пришлось писать на смеси Java и C++, что получалось у меня не так хорошо. После решения задачи я спросил собеседующего, стоит ли мне писать тесты и рефакторить код. Не получив утвердительного ответа, я сдал задание и ушел заниматься своими делами. Не удивительно, что меня ждал отказ.

Пообщавшись с другими разработчиками, я узнал, что интервьюеры ожидали написание хорошего кода изначально, а тесты должны быть обязательной частью такого решения. В фидбэке я получил хорошие баллы за коммуникацию, но комиссия не смогла разобраться в моем коде, поэтому мне предложили попробовать свои силы опять через год. Я не опускал нос, потому что уже получил приглашение на собеседование в Лондон, и отправился готовиться к оффлайн-этапу интервью в Facebook.

Оффер от Facebook

Почти все написанное про собеседование в Google относится и к Facebook. Собеседуясь в обе компании параллельно, я смог почувствовать разницу в их культурах. Весомым отличием Facebook для меня стало отношение на интервью. Во время всех этапов меня не покидало чувство, что интервьюеры — это мои хорошие знакомые, которым понадобилась помощь с задачей, и мы вместе ищем для нее решение.

Онлайн-этап собеседования проходил в том же формате, что и в Google. Но был более удобный онлайн-редактор и большее количество языков на выбор, что позволяло не отвлекаться на вспоминание С-подобных конструкций. Через день после собеседования HR дал мне обширный фидбэк и пригласил на следующий этап в Лондоне.

Оффлайн-этап состоит из пяти собеседований подряд: трех coding challenge, благодаря чему комиссия может получить наиболее объективное мнение о соискателе, мотивационное и system design интервью. Как по мне, самое сложное из них — system design интервью. На нем необходимо спроектировать решение определенной открытой задачи. Сама задача состоит из одного предложения, описывающего общую идею. Все остальные детали вы должны узнать у интервьюера или спрогнозировать сами. Для меня это было очень похоже на начало разработки нового продукта, когда разработчикам нужно узнать все требования к проекту и на их основе составить высокоуровневую архитектуру приложения. Для подготовки к этому интервью я купил доступ к курсу Grokking the System Design Interview, что, безусловно, было лучшими вложением 79 долларов. Благодаря этому блогу я получил множество новых идей, как можно строить приложения, и научился задавать правильные вопросы самому себе во время проектирования.

Перед интервью я весь вечер повторял свои конспекты и разбирал задачи, которые другие соискатели публиковали на Glassdoor. Многие советуют прорешать «Cracking the coding interview», но, как по мне, это трата времени. Эта книга достаточно поверхностно описывает алгоритмы и структуры данных. Вместо того, чтобы учиться понимать идеи и принципы, заложенные изначально, с помощью книги вы просто научитесь решать конкретные задачи. В итоге собеседование превращается в бросание монетки: если вам повезет, то задача будет похожа на ту, которую вы прошли в этой книге. Мне куда больше пользы принесли курсы от Robert Sedgewick на Coursera (первая и вторая части). В них объясняются идеи, которые стояли за той или иной структурой данных и алгоритмом. Да и вряд ли кто-то может лучше объяснить красно-черные деревья, чем тот, кто их придумал :) И я бы не сказал, что на проработку задач из книги нужно меньше времени, чем на просмотр обоих курсов Седжвика.

В офисе мне сделали небольшую экскурсию и провели в переговорную, где ожидал первый интервьюер. За следующие пять часов меня познакомили с множеством интересных людей, занимающихся разными проектами. Во время личного общения после интервью я узнал о рекламных сетях, компиляторах и распознании лиц напрямую от тех, кто работает над ними из дня в день.

Даже если бы я не получил оффер, это все равно был бы невероятно интересный опыт. Компания хотела не только проверить меня, но и показать себя с лучшей стороны. Как мне сказали во время обеда: «Till now you tried to sell yourself, now we will try to sell the company to you». Выходя из офиса, я чувствовал себя абсолютно опустошенным. Голос пропал, и следующие полчаса я перебирал мысли в голове. Несмотря на это, я был счастлив, так как чувствовал, что выложился на полную.

Выводы

Собеседования в продуктовые компании оказались очень похожи друг на друга. Все компании искали сотрудника, соответствующего внутренним ценностям компании, умеющего решать нестандартные задачи и выбирать правильные решения. Именно ценности компании определяли образ идеального соискателя. На этот раз мои мотивации совпали с тем, что искала компания, а технические скилы позволили получить долгожданный оффер.

Несколько советов:

  • Лучший способ получить оффер — попасть на собеседование, а лучший способ попасть на собеседование — это найти человека внутри компании, который мог бы порекомендовать вас.
  • Очень важно ознакомиться с core values компаний, чтобы понимать, подойдете ли вы друг другу. Но в то же время не нужно пытаться подобрать ответы под них. Вряд ли вам хочется сменить работу на ту, где вы не сможете быть собой.
  • Если вы чувствуете, что ваши знания в computer science не так сильны, то уделите пару месяцев для подготовки и обучения. Я могу посоветовать вам этот курс (часть1, часть 2).
  • Во время подготовки обращайте внимание на общие концепции и идеи вместо частных решений. Куда легче разобраться с парой десятков идеи, чем подготовиться к тысячам производных задач.
  • Используйте все возможные ресурсы для подготовки, даже если вам придется заплатить за них. Скорее всего, цена на них вполне оправдана. Для меня очень важным шагом стала покупка этого курса.

Я желаю вам удачи в поисках, а сам собираю вещи на самолет «Мюнхен  —  Лондон» и улетаю в новое приключение. Буду рад ответить на ваши вопросы, а также подписывайтесь на мой Twitter и Instagram.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




78 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Поздравляю с оффером! «Welcome to Facebook. This is your company now» :)
Уже прошел буткемп? Какую команду выбрал/думаешь выбрать?

Спасибо! :) Первая неделя буткемпа только прошла, так что все еще впереди. Присматриваюсь к тому чем можно заниматься в лондонском офисе.

А, круто. Have fun in bootcamp :)
Не очень знаком с лондонскими командами, но слышал что Workplace хорошая, вменяемый менеджмент и хорошая организация. И наоборот, имел опыт работы с Catalog team (Marketplace) — туда лучше не идти, там бардак.

О, клево, спасибо за овервью :)

І якщо ти все ж хочеш працювати з функціональщиною — майже всі команди з CI активно використовують Хаскель

Было интересно читать. В итоге когда уже устроились чувство было что вы на равне с остальными или нужно учиться?

Всегда есть чему учиться :)

не ну реально интересно были ли персонажи при знакомстве с которым возникал вопрос как он туда попал?

Очень интересная и вдохновляющая статья! Спасибо, что поделились опытом.

вот интересно, все эти конторы требующие ниипических знаний компьютер сайенс и алгоритмов, реально эти знания используют? или там сидят такие умные перцы и 90% времени правят xml/json ? жду статью «Я устроился в Google/Facebook/Twitter. Реальность vs ожидания», но вряд ли кто-то напишет, ибо NDA

Нынче это чаще встречается в конторах поменьше

при таких объемах данных нет-нет, да и может понадобиться знание CS. У меня, например, такое иногда бывает.

Я тоже с удивлением все больше и больше обнаруживаю, что знания пригождаются. Хотя я далеко не в fang.

Спасибо за интересную статью. На мой взгляд, прекрасно показывает важность такого качества, как настойчивость.

Elastic — это в каком городе было?

У Эластика нет обязательных офисов и они нанимают всех на удаленку

в какой угодно стране?

то-то у них глюкавые продукты. небось их пишут из амстердамского кофешопа :-)))

Через півроку прийду сюди та поцікавлюсь, чи реально в роботі потрібні ті знання, наявність яких перевіряли на співбесідах, чи там, як і усюди, клепають круди з гівна і палок.

Думаецца, что алгоритмические задачки — это ключик от двери, за которой платять больше денег.

хм. из «работа с указателями тренирует навыки абстрагирования» и «а ща про указатели не рассказывают» рождается «значит, теперь хуже готовят». нормально так поворчал.

самая большая опасность обучения Java — она прививает любить деньги. We’re only in it for the money :-))

тяжелее значит лучше, тяжелее значит надеждее ©

Ну да, в Google/Amazon/etc. собеседовать вообще не умеют, спрашивают всякую ненужную фигню, набирают одних олимпиадников неумеющих решать реальные бизнес задачи...
Брать должны только за знание А/В/С фреймворков и на слово верить байкам о прошлом опыте...
Правда у них как то получаются продукты и сервисы, которыми пол планеты пользуется, но это просто недоразумение...

которыми пол планеты пользуется

вот это ваще не коррелирует со скиллами разработчиков, к"мон

То есть нагрузка, надежность и кол-во информации генерируемое таким кол-вом пользователей — не в счет? Как по мне это существенно повышает сложность разрабатываемых систем и скиллы разработчиков для этого необходимы куда выше среднего.
Или другой пример поприземленнее — 2 недели назад была конфа Devoxx, там был очень классный доклад от Grammarly на тему алгоритмов в их продукте. Они прямо принесли учебник и ткнули пальцем — «вот из этой главы мы взяли идею для решения нашей проблемы», а так же привели пример использования базовой структуры данных для другой проблемы.

То есть нагрузка, надежность и кол-во информации генерируемое таким кол-вом пользователей — не в счет?

в счет, но где-то в конце влияющих факторов.

в счет, но где-то в конце влияющих факторов.

Amazon’s calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Google has calculated that by slowing its search results by just four tenths of a second they could lose 8 million searches per day—meaning they’d serve up many millions fewer online adverts.

действительно...

Виглядає як підрахунок Майкрософтом недоотриманого через піратів прибутку.

вот это ваще не коррелирует со скиллами разработчиков, к"мон

Вы ошибаетесь. Иначе весь мир бы нанимал массово дешевых джунов, и парочку средненьких мидлов (они являлись бы тим лидами) и работали бы себе отлично. Но дурные руководители почему то огромные деньги тратят на поиск лучших

в чем ошибаюсь?
т.е. сложная система автоматически становится популярной?
т.е. наличие в команде гения делает продукт успешным?
т.е. успешной не может стать простая система?
серьёзно?

Дайте примеры простых, успешных систем, которыми пользуются миллионы пользователей ежедневно.
Я молчу про то, какова «цена ошибки» в таких системах, «цена часа неработоспособности», да вообще, цена дополнительной половине секунды к загрузке страницы (к примеру веб приложения) — даже для простых систем.
Да и какая простота приложения и инфраструктуры в целом в случае сильного хайлоада?

Дайте примеры простых, успешных систем, которыми пользуются миллионы пользователей ежедневно.

goo.gl
какой-нить форумоподобный ресурс типа реддита

могу также дать примеры систем, которые валились от нагрузки(т.е. не были готовы), но популярности которых это не помешало

Да и какая простота приложения и инфраструктуры в целом в случае сильного хайлоада?

кстати, да, каким боком простота приложения к хайлоаду?

как-то вы в одну корзину складываете сложность продукта и сложность инфраструктуры.
типа, если я лабораторную работу закину в безусловно сложную облачную инфраструктуру, она и сама станет сложнее.

кстати, да, каким боком простота приложения к хайлоаду?

как только ваш продукт становится популярнее, увеличивается нагрузка, сразу начинаются телодвижения в сторону разбиения приложения на сервисы, переписывания определенных сервисов на других ЯП и так далее и до бесконечности. С увеличением популярности простота улетучивается, это обыденность. У того же реддита вы лично знаете что под капотом? всего-лишь масштабирование серверов или все намного сложнее? А защита данных? Это часть вашего продукта, чем продукт популярней — тем критичней этот вопрос.
Поэтому да — от популярности (считайте нагрузки, в случае веб-а) прямо зависит сложность продукта, по другому может быть только в исключительных случаях, какой нибудь маленький, законченный, продукт, с узко заточенным функционалом, возможно работающий вне web. Но речь шла о google etc.

могу также дать примеры систем, которые валились от нагрузки(т.е. не были готовы), но популярности которых это не помешало

Возможно и популярность у них относительная?

Дайте примеры простых, успешных систем, которыми пользуются миллионы пользователей ежедневно.

интернет? #trollface

Да и какая простота приложения и инфраструктуры в целом в случае сильного хайлоада?

интернет? #trollface

И интернет, конечно, сделали мидлы-генералисты, краем уха слышавшые о CS )

нет его успели сделать до того как они появились ))

и хорошо, «вот в наше время» умели делать )
а то сейчас http протокол со скоростью js-фреймворков начал меняться.

разве «интернет» — простая система?

дык чего уж проще!? ))

Днс сервер корневой возьми, куда уж популярнее)

Сложная система не значит популярная, но популярная система практически всегда становится сложной

продукты и сервисы, которыми пол планеты пользуется

так ведь других нет!? (к) (тм)

И сраная почта, которая теперь грузится 2 секунды.

продукты в основном заслуга продакт-менеджеров. программисты пишут то что им скажет продакт менеджер. а глюков и багов хватает и в продуктах которыми пол-планеты пользуется. причем одна очень известная компания не очень то любит их фиксить. тикеты висят по полгода. но продажи то идут! (опять заслуга менеджеров)

могу со своего опыта сказать — у нас надо все, что спрашивали (графы, деревья, и еще куча всякого), хоть и не фб

Меньше раза в полтора

у нас надо все, что спрашивали

dms.licdn.com/...​8rjS3XNdTEsp1AHt51kmhutEE

Ты не любишь медвежонков? ))

какое это имеет отношение к интервью?)

Та так само клепають, навіть гірше ніж я могла уявити. Все ж на ПХП написано) а щодо питань на спібесідах — так їм просто нема що питати. Те, з чим вам доведеться працювати у компанії-гіганті ви з 90% ймовірністю ніколи в житті не бачили. Їм плювати на знання фреймворків — їх в компанії не використовують. Не дарма перші 5 місяців триває процес ознайомлення з цим місцевим зоопарком. І от якщо кандидату вистачило розуму і наснаги розібратися з задачками — то і з місцевими системами розбереться. А так надзвичайні знання CS на перших 2-3 рівнях не треба (звісно є вийнятки)

лучший способ попасть на собеседование — это найти человека внутри компании, который мог бы порекомендовать вас

Ergo, рекрутери і HR не потрібні, бгагага!

Парень молодец и вообще красавчик! Такие истории всегда радуют

Отличный опыт и позитивная статья ! Самых лучших успехов и дальше !

Хотелось бы узнать сколько времени до этого вы работали от самого нуля и с каких технологий начинали)

Это не настолько важно, ни на одном собеседовании меня не спрашивали о конкретных технологиях или языках. Так-же как и годы опыта интересовали только HR, итоговый грейд зависит от того как прошли собеседования. То что действительно важно, это соответствие ценностям компании, знания в computer science и понимание как построить с нуля то в чем вы работали на протяжении своей карьеры. Насчет количества опыта и его качества, по результатам собеседования вам могут предложить оффер на более низкий грейд, чем у вас сеичас, и это нормально, так как стандарты в компаниях отличаются.

Было стыдно читать за рекрутёров Твиттера.Я думала,что только у нас такая негативная практика возможна.
А так-успехов Вам и хороших впечатлений от работы в ФБ)

там, просто, магического слова sovok не знают, а так все то же :)

Сколько всего времени ушло со времени начала поиска работы до оффера?

Около четырех месяцев

Рад за людей, которые достигают своих позитивный целей. Успехов на новом месте!

Отличная статья! Хоть тема мне не интересна.

Зайшов просто почитати коменти)))

И все сидят и грустно ждут, пока кто-то набросит, чтобы можно было почитать комменты.
cs9.pikabu.ru/...​_5/149045559218057468.jpg

Успехов вам и новых интересных вызовов!

Підписатись на коментарі