Amazon is hiring in Vancouver (and other locations)

Доброго дня,

Мене звати Артем і я Principal Engineer у Amazon Web Services.

Наша команда у Ванкувері шукає розробників для роботи в Amazon SQS — одним з наймасштабніших, базових сервісів що лежить в основі багатьох сервісів Амазону та по всій індустрії. При цьому наша команда відносно маленька (в порівнянні з, скажімо, S3 чи DynamoDB), завдяки чому кожен інженер має суттєвий вплив на технічні рішення та стратегічний розвиток продукту.

Компанія надає успішним кандидатам підтримку при переїзді — візова пітримка, перевезення речей, житло та авто на перший час, тощо.

Я можу відповісти на питання по команді, вакансії, процесу співбесідування, переїзду, та взагалі роботі на Амазоні — якщо вас не цікавить переїзд до Канади, є багато позицій в других командах у Європі — процеси всюди схожі.

www.amazon.jobs/...​-aws-simple-queue-service

Amazon SQS is a massively distributed, scalable message queuing service. It runs on almost 100,000 machines worldwide and is processing over 100,000,000 requests per second while generating 3 petabytes of logs per hour. It is a critical dependency of the Amazon Marketplace, many other AWS services, and hundreds of thousands of companies globally.

Because of its near-unlimited scalability, SQS is a foundational building block of many other cloud services. As such, SQS implements its own storage, load balancing, distributed caching and host lifecycle solutions. SQS engineers deal with these topics in their daily work, and their decisions have impact that resonates throughout the industry. These decisions can have a financial impact of tens of millions of dollars to the service’s monthly budget.

As a Software Development Engineer on the SQS Storage team, you will implement and own the next generation of the component that stores, replicates, and serves messages back to customers in a secure, durable, highly available, and efficient way. Your understanding and influence will span other services across SQS and the rest of AWS, with some of our biggest achievements coming from improving the interactions in these complex distributed systems.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Знакомый работал в Амазон Берлин.
Хороших отзывов не слышал.
Усьо через фругалити.

Читал на Quora что в Amazon очень жесткие овертаймы, и местные американцы туда идут только в самую последнюю очередь, когда во всех остальных компаниях не удалось получить оффер.
В этом есть доля правды? Сколько часов в неделю вы работаете в среднем?

Я видел что такое пишут, но не совсем понимаю откуда берётся такое мнение. На Амазоне ведь нет какой-либо системы трекания рабочих часов, и всем всё равно сколько ты работаешь, был бы результат.

Сколько я работаю в среднем — где-то с 10 утра до 5 вечера когда не онколл. Думаю что большинство тоже так — все митинги планируются в этих часах. В моём случае этого было достаточно чтобы пройти от SDEII до PE за 4.5 года :)

Онколл у каждой команды своей, у некоторых его вообще почти нету, у некоторых он очень интенсивный. На SQS держится много критических сервисов, так что мы ближе ко второй категории. Во время околла (одна неделя раз в два месяца) через каждые 8 часов нужно находиться в 10-минутной доступности если сработает пейджер, но вне дневных часов это происходит, может, 2-3 раза в неделю.

Я понял, а почему смена 8 часов?
Не легче было сделать 12? Что бы один дежурил всю неделю ночью, а второй днем. А потом менялись через 2 месяца.
Ведь с графиком 8 через 8 ты будешь спасть через день то днем то ночью, и от этого будешь ходить как зомби.

С 8 часовыми сменами выходит что у тебя ночное дежурство каждую вторую ночь. Быть дежурным ночью не значит что ты должен сидеть всю ночь за компом — это лишь значит что если что-то сломается и нужно срочно починить, у тебя зазвонит пейджер и нужно будет встать и исправить. На практике среди ночи пейджер звонит может 1-2 раза за неделю, и если действительно случается какой-то сложный ивент который нужно долго резолвить, мы просим оператора взять выходной после этого.

На практике среди ночи пейджер звонит может 1-2 раза за неделю

Надо уточнить, что это сильно зависит от команды, организации, операционной гигиены, количества людей в oncall rotation и степени упоротости начальства. На практике в AWS ситуация, когда просыпаешься втечение недели по несколько раз _каждую_ ночь, а потом еще втечение недели может каждую вторую ночь как secondary, абсолютно реальна, и повлиять на нее с уровня SDE2 невозможно от слова совсем (прописью — «совсем»), разве что переходом в другую команду, у которой ничего нет в продакшене.

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

Добавлю, что девелоперу который не в дев плане (нижние 5%) перейти в другую команду очень легко, и совсем не обязательно в такую где «ничего нет в продакшине». Вот, например, SQS (да и другие сервисы в нашей организации)...

По понятным причинам вам верить — себе вредить.
Почему я так думаю — в любой конторе есть неисчерпаемый ушат говна. Я думаю что вы за 4.5 года прошли достаточный путь чтобы столкнуться и с гонками топ перформеров(ага, с 10 до 5 вечера) и с попаданием(от ебанутого манагера) в андерперформеры и менеджерскими проебами(а всю вину скидывали на девов) — но врядли вы расскажете здесь об этом.
Такой себе стокгольмский синдром после определённого времени работы)

Коментар порушує правила спільноти і видалений модераторами.

На чем пишете?
Какие этапы интервью? Стандартные: Литкод, Системдизайн, и Бихевеарал?
Какого уровня(по меркам Литкода) задачи могут быть на интервью?
В США тоже набираете?

Процесс интервьювания стандартизирован по всему Амазону и не специфичен для нашего тима — кандидат апплаится конкретно на нашу вакансию, но в интервью участвует 5-6 человек, из которых только 1-2 из целевого тима.

В SQS почти весь новый код мы пишем на Kotlin. Интервью при этом можно проходить на любом промышленном языке программирования, главное чтобы человек был хороший :)

Этапы интервью:
— online assessment — надо решить в веб аппке задачу
— 1 hour phone screen: leadership principles + coding
— 5 interviews one hour each — каждое интервью наполовину состоит из leadership principles и «функциональной компетенции»: 4 coding interviews, 1 system design interview

Leadership principles: amazon.jobs/en/internal/principles

Каждый интервьювер спрашивает у кандидата пару примеров из его/её опыта которые продемонстрировали бы что кандидат _уже_ следует leadership principles. Например, «расскажи случай как клиент просил об одном, а на самом деле ему нужно было другое», «расскажи как ты решил сложную задачу простым решением», и т.д.

По кодингу, сложность по литкоду где-то между medium и hard, с несколькими особенностями:
— времени на решение даётся где-то 30-40 минут, соотвественно от кандидата не ожидается, скажем, что он будет писать тесты
— код пишется в редакторе но не запускается. Ожидается что код «на глаз» выглядит как продакшин, но компилировать и запускать его никто не будет
— От кандидата ожидается хороший problem solving, знание стантартных структур данных, умение оценить runtime complexity, написание maintainable code, OO design — каждый из четырёх кодинг интервьюверов будет иметь свою задачку специально нацеленную на соотвествующий аспект умений кандидата.

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

В США сейчас не набираем, ибо сложно сделать визу. Но если бы был кандидат там, рассмотрели бы ремоут. Также будет возможность перевестись в США по L1 после года в Канаде.

Как я уже упомянул, каждое интервью нацелено на определённый аспект coding competency, и использует специально заточенную под это задачу.

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

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

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

Как говорит один из leadership principles, «Leaders raise the performance bar with every hire». Вот этот «raise the bar» означает что успешный кандидат должен быть лучше половины сотрудников что уже на Амазоне в этой роли. Такое решение требует достаточно данных от нескольких людей, поэтому столько интервью.

Как говорит один из leadership principles, «Leaders raise the performance bar with every hire». Вот этот «raise the bar» означает что успешный кандидат должен быть лучше половины сотрудников что уже на Амазоне в этой роли. Такое решение требует достаточно данных от нескольких людей, поэтому столько интервью.

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

Не зря корпоративные принципы именуют буллшит)
Они годятся только для транспарантов.

успешный кандидат должен быть лучше половины сотрудников что уже на Амазоне в этой роли

Если я правильно понимаю то с учетом кол-ва сотрудников(на позиции найма о которых в статье) на столько велико что этот принцип вырождается в чушь, так как нету никакой возможности проверить)

О мені в Лінкед недавно приходило щось таке від Амазона схоже з 5 інтервʼю.
Навіть не дивився умови і зарплату — зразу дропнув. Дікіє люді :)

Накидайте(с анонимного аккаунта) здесь промеров ответов на такие вопросы. Чтобы можно было заучить)

Чи можна наразі віддалено працювати ?

Можна, але потрібно знаходитись відносно недалеко від решти команди — у Канаді, бажано в тому ж часовому поясі що й Ванкувер.

Тобто ремоут == не потрібно приходити в офіс, але не повна свобода місцезнаходження.

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