Сегодня расскажу про подготовку и опыт собеседований в FAANG(и не только). Почему из двух офферов выбрал FB, а не Apple. И почему считаю, что FB одна из лучших компаний для работы.
Спустя два года жизни в Сингапуре, мы решили что он плохо подходит на роль страны для жизни. Ужасный климат, проблемы с PR и гражданством, разительно отличающаяся от привычной нам культура. Конечный путь назначения, ну тот момент, был очевиден - США.
Для переезда в США, нам больше всего подходила виза L1(релокация из зарубежного офиса после года работы), так как моя жена тоже планировала устроиться на работу, а H1B/O1 такой чести не предполагают.
Но для релокации из офиса outside USA, сначала нужно было устроиться в такой офис. Поэтому все компании не предлагающие релокацию отпали сами собой. Оставался только FAANG.
На тот момент, мой синдром самозванца говорил мне, что это плохая идея пробоваться в такие серьезные места. (Как же я заблуждался)
Почитав немного про собеседования в такие компании, я конечно немного приуныл. Несколько раундов интервью, серьезная алгоритмическая подготовка, написание кода на доске. Но цель уже была поставлена, ничего не оставалось, как смириться и начать готовиться.
За основу подготовки я взял leetcode.com. `Cracking the coding interview` стала моей настольной книгой на пару месяцев. В своих занятиях английским я сделал упор на проработку Behavioural questions.
Начал освежать свои знания всякого разного low-level стаффа. И параллельно искать реальные интервью, на которых я смог бы потренировать все свой свежеприобретенные склиллы.
Уверенности не внушал тот факт, что многие компании просто не утруждали себя ответами и игнорировали мои отклики. Другие присылали заготовленные письма с отказами. Зато мой синдром самозванца рос и креп.
Первый мой собес был в китайскую Alibaba. Я, разумеется, многое слышал про нее, но я же не собирался реально туда устраиваться! Тут тебе были и behavioral quiestions, и решение задачек на доске и немного дизайна системы.
Но внезапно меня стали игнорировать(Интересно почему? 🤣), после того как я сказал рекрутеру, что я ценю WLB, предпочитаю тщательное планирование, и поэтому перерабатывать обычно не приходится.
Начало было положено. Не получится с FAANGом, попробую к китайцам еще разок, держа язык за зубами, думал я. 🙂
После этого интервью поперли. Отписался Booking, Bloomberg и пара сингапурских конторок.
Booking был первой компанией, которая после телефонного интервью пригласила меня на онсайт в Амстердам.
Все шло хорошо, мне казалось, что мой первый оффер не за горами, но пришел реджект. 🙂 Мое решение дизайна системы назвали overcomplicated и пригласили еще раз через год.
Я уверен, что им не понравился мой ответ на интервью про улучшение в их продукте. За пару месяцев до этого, в Калифорнии букинг списал с меня оплату за жилье 2 раза. Мой банк вернул мне эти деньги обратно на кредитку через пару дней. Букинг через неделю только соизволил ответить.
Разумеется, я предложил улучшить их техподдержку. После этого мне сказали, что это плохое улучшение, так как это невозможно AB-протестировать и интервью закончилось. ☹️
Интервью с блумбергом, тоже прошло относительно хорошо, пока меня не попросили задизайнить BE, API and iOS за 40 минут 😬. К такому повороту я был не готов. Имея только теоретические знания в это области, я смог покрыть только небольшую часть задания не успев добраться до iOS.
Cовет-это окей спрашивать у рекрутера, что ожидать от интервью. Обычно компании заинтересованы максимально снизить уровень стресса у кандидатов. Однако, с блумбергом мне это не помогло, мне сказали что будут обычные iOS задачки но никак не BE high-load на 10к запросов в секунду.
Собес в Google я завалил на этапе телефонного интервью, завалив задачку с pretty-print JSON и парой доп условий. В свое оправдание могу лишь сказать, что интервью было в 6 утра, а так рано обычно думается лишь о том, как можно продолжить дальше спать. 😂
Мой внутренний самозванец торжествовал: “Я же говорил тебе, что FAANG не для тебя, а ты меня не слушал, мог бы и избежать всего этого позора.”
Но тут мне ответили из FB, куда я отправлял резюме парой месяцев ранее...
Телефонное прошло норм, позвали на онсайт. Взял месяц на подготовку. Онсайт прошел хуже чем я ожидал. Пока я ждал ответа, мне написали с Apple, куда меня рефферил мой бывший коллега.
Получить ответ от эппл, это вообще само по себе достижение. Рекрутеры там вообще не торопятся, и за год не удосужились прислать даже отписки 🙂
Все прошло довольно неплохо. Все интервью были из сингапурского офиса по VC с Купертино. (Вакансия была в Синге) На одном интервью мне даже пришлось объяснять решение hard задачи с литкода устно, потому что рекрутер посадила меня в комнату без whiteboard.
Жизнь и уверенность в своих силах потихоньку налаживались. Я не мог и мечтать и об одном то оффера из FAANG, а в результате получил целых два. Видимо синдром самозванца именно поэтому и называют синдромом, потому что мы сами его выдумываем.
Почему я выбрал FB? На тот момент это было не так очевидно, как сейчас. Обычно для iOS разработчиков кажется, что Apple идеальное место, но это не совсем так.
И на это есть целый ряд причин:
- Культура секретности.
- Сложность поменять команду.
- Жесткая иерархия.
Работая в Apple, чтобы поменять команду, нужно пройти интервью почти с начала. Так как все команды собеседуют к себе сами.
Вся работа происходит в режиме строгой секретности. Иногда даже нельзя общаться с коллегами на интересные темы. Вдруг что сболтнешь? Очевидно, что в такой атмосфере может быть сложно развиваться, общаться и пробовать что-то новое.
В Apple у меня бы почти не было шансов попасть в команду Swift компилятора без должного опыта с языками программирования. Но в FB это возможно.
Мне иногда кажется, что FB это почти полная противоположность Apple.
- Открытость только поощряется.
- Ты сам решаешь над чем и как работать.
- А задача менеджера помочь тебе в этом, а не говорить что делать и как.
Как человеку, кто имеет интерес не только в написании кода, но и в развитии продукта, мне было это особенно интересно. После буткампа, я намеренно не пошел обратно в клиентскую разработку, а решил попробовать что-то новое.
Моя любовь к разного рода low-level штукам получила свое воплощение в околокомпиляторной команде, где мы занимаемся линтерами на основе компиляторов, инструментами для кодмоддинга, и другими очень интересными вещами.
А полгода назад, я создал и начал работать над линтером, который работает поверх Swift компилятора. В отличии от swift-format/SwiftLint этот линтер работает не с CST a c full typed AST, и имеет доступ ко всей информации что известна компилятору.
По архитектуре выглядит как clang-tidy, за исключением того, что Swift не имеет открытого API для тулинга, но позволяет отлавливать и исправлять нетривиальные паттерны, которые приводят к регрессу binary size.
Но вся эта свобода, имеет и цену. Нужно четко понимать свою цель, выстраивать стратегию и доносить ее до команд партнеров и юзеров. Иначе к концу полугодия можно получить no impact и плохой рейтинг.
Мне это напоминает работу в стартапе о которой я писал в понедельник - Нет смысла делать то, что никому не нужно, и не принесет никакой импакт.
Поменять команду в ФБ можно после года работы в компании. Официально проходить интервью не требуется, но нужно заручиться поддержкой менеджера принимающей стороны.
В итоге, я работаю над тем, что мне безумно нравится, сам решаю что и как делать и определяю дальнейшее направление продукта. А общение с крутыми коллегами из Google, Apple etc. позволяет мне обращать внимание на те области, в которые я раньше никогда бы не полез.
Например в том, как работает DYLD, как сделать запуск приложения сильно быстрее, и найти баг в самом DYLD. (openradar.appspot.com/FB7527953)
Расскажу подробнее про это завтра. Возможно это поможет и вашему приложению стать чуточку быстрее.
Недавно все таки решил получить ачивку, написав и запилив Proposal в Свифт. Вчера поправил PR по замечаниям от @jckarter, скоро поправлю сам питч. Надеюсь, получится добить до конца 🙂 🤞
Представить все вышеописанное в компании отличное от FB, лично мне довольно сложно (хоть и возможно). Но я очень рад, что мой внутренний самозванец не победил, и я смог найти почти идеальное место для развития своих навыков.
Тем кому интересно, на литкоде и прорешал около 400 проблем, прошел пару тестовых на interviewing.io и тренировал поведенчиские вопросы на pramp.com.
На протяжении пары месяцев, каждый выходные я приезжал в офис, и решал задачи на доске маркером.
Забыл упомянуть важный топик про важность алгоритмов. Не хочу разводить срач, но...
Для клиентского разработчика они обычно не важны, какая кому разница какой алгоритм используется для матчинга строки по префиксу. Но чем глубже погружаешься в тему, тем больше начинаешь находить алгоритмов.
Например бинарник динамической либки содержит секцию `__LINKEDIT` в которое лежит сериализованное префиксное дерево со всеми доступными символами в бинаре.
DYLD использует его, чтобы в рантайме при запуске приложения быстро найти символы из либки, используемые в бинаре самого приложения.
Компиляторы Swift и Clang просто нашпигованы разными алгоритмами (в особенности деревьями), которые позволяют вашему коду работать относительно быстро.
К моему большому удивлению, опыт решения задачек с литкода сильно пригодился для понимания некоторого кода в этих компиляторах.
Поэтому не могу сказать, что все за зря. Я думаю, что все это идет от размера компаний. В маленьких нужно просто писать новые фичи. В больших приходится эти фичи оптимизировать. И к сожалению, это все аппроксимируется и на тех людей, кто оптимизациями не занимается.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Как и обещал, сегодня будет много low-level твиттов про Swift, iOS и алгоритмы.
В больших компаниях, существует 3 ключевые области, регресс в которых, при разработке под iOS, внимательным образом отслеживается, анализируется и оптимизируется.
* Build speed
* Binary size
* Performance
Миграция на Swift, влияет на них всех и к сожалению не самым лучшим образом. Давайте начнем с Build Speed.
До переезда в Сингапур, я постоянно откладывал поход в школы по изучению английского языка. Где-то в глубине душы, я понимал что для эмиграции язык необходим, но постоянно казалось что я еще успею его выучить, а более важные дела нельзя отложить.
После получения оффера, да, получил я его без знания английского, видимо специалист был хороший 😅, я начал осознавать свою роковую ошибку. Договорившись на 3 месяца удаленной работы чтобы закончить все свои дела в Спб, я ускоренно начал заниматься языком.
К большому счастью, Skyeng(НЕ реклама) уже работал, поэтому вопрос куда идти даже не всплывал. За 3 месяца занятий по 3 в неделю, я более менее научился связывать слова в предложения и спрашивать дорогу в булошную.
До FB я около 7 лет работал в клиентской разработке, успел поработать и в аутсорсе, и в стартапах, и в более менее зрелых компаниях. Но началось все относительно случайно. Живя в общаге ИТМО, от нечего делать, я решил установить на свой Асер Хакинтош...
Две недели без сна, минимум еды, много стресса, тонны прочитанных мануалов по бутлоадерам и прочим хакам и я получил отлично работающую версию OS X на моем ноуте. Почти под все железо я смог найти kextы, кроме дискретной видюхи.
Исследуя возможности, неизвестной на тот момент, системы, я запустил Xcode...с тех пор так его и использую. Первое мое приложение было рисовалка граффити для ВК, очень простое написанное в основном по туториалам и говнокодом.
Сегодня суббота, и давайте поговорим про стили и темы в Android🎨.
Наверное, начать стоит с того, в чём разница между стилем и темой.
По сути, стиль — это некоторый набор атрибутов для конкретной View. Лучше делать этот набор уникальным для каждого типа View, потому что набор атрибутов отличается.
Можно представить, что стиль — это Map<view attribute, resource>.
Думаю рассказ про мой опыт с Kotlin Multiplatform (далее просто МП/MP) стоит начать с небольшого предисловия. Я занимаюсь разработкой приложения для отслеживания своей активности для лыжников и сноубордистов
У нас уже больше 1.5 года была вынесена часть логики в МП, это была логика определения состояния пользователя, будь то отдых, подъем на подъёмнике или райд. Там в основном алгоритмы, но не простые и хотелось иметь single source of truth на обеих платформах...
... что бы не фиксать разные баги на iOS и Android. Так как с точки кода это был не сложный модуль работало там все прекрасно, но потом мы решили что хотим пойти дальше и сделать так что бы на платформе остался только UI и какие то специфические сервисы
Итак, в 2018 году со мной случилось выгорание. Шла я нему несколько лет.
Так получилось, что в 2018 году у меня было несколько проектов, в которых я была задействована. Проекты были тогда интересными, и в той стадии, когда там много нового и полезного для тебя.
Проекты все были у разных партнеров и разных заказчиков. Суммарно моя загрузка в неделю занимала 60-80 часов. Почему столько? Потому что сначала мой менеджер попросил меня взять к обычной нагрузке еще что-то, а мне было интересно попробовать в себя в том проекте, куда звали
Да, едут на том, кто везет. Я везла, мне казалось, что так я себя показываю со стороны ответственного сотрудника. Но знаете, не все воспринимают это, положительное качество. С течением времени некоторые начинают наглеть.