Все мы понимаем, что означает слово Junior в контексте разработки софта. Человек без опыта, недавно попавший в профессию, часто делающий ошибки, требующий помощи и наставлений. Но как так получается, что в FAANG на Junior позиции (напр., L3 в Google) платят, как на Senior позиции в остальной отрасли? За что? За ошибки, помощь, наставления и отсутствие опыта? Какая‑то бессмыслица!

Каждая компания определяет слово «Junior» по‑своему, и это правильно. В этой статье я расскажу, как эту позицию определяют FAANG компании, и значительная часть Big Tech индустрии вместе с ними. В прошлый раз я поговорил про общие требования к кандидатам. Разобравшись с требованиями к этой позиции, вы узнаете, кому стоит приходить на собеседование в FAANG, а также как к нему готовиться. При правильном подходе быть принятым на работу гораздо проще, чем кажется на первый взгляд.

Наверное, уже все слышали про процесс собеседования в FAANG (и другой BigTech). Leetcode задачи, системный дизайн, поведенческие вопросы, culture fit, и прочие баззворды регулярно обсуждаются на Хабре. Коллективный разум Хабра более или менее пришел к общему консенсусу: это бессмысленная процедура, которую проектировали некомпетентные люди.

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

После написания первой статьи про FizzBuzz (которая неожиданно для меня стала выбором редакции на Технотексте 2021) у меня появлялись мысли о том, как еще можно ускорить, но все время было не до того. И тут мне прилетает перчатка.

Привет, Хабр. Меня зовут Роман, я разработчик встраиваемых систем в Dannie и мы тут делаем умные камеры. По долгу службы, мне потребовалось завести эмуляцию прошивки для чипа из семейства MIPS. В рамках разработки проекта мы обозначили для себя задачу получения быстрой обратной связи при разработке ПО и прошивки. Для этого начали выстраивать CI/CD-цепочку с проверкой прошивки в эмуляторе. Одной из требуемых функций являлась возможность манипулировать окружением загрузчика (u-boot environment). В статье я расскажу что получилось и как из говна и палок завести авто-тесты прошивки в CI.

Всем привет, я Дима из мобильной команды Туту, мы делаем приложения с 20М инсталлов. Расскажу, как можно быстро добавлять в приложение новый контент и обновлять его, не проходя повторные ревью в сторах. Это нужно, например, когда мы хотим быстро донести до людей коронавирусные ограничения.

Ниже реализация на SwiftUI и Kotlin (но вы можете использовать UIkit и серверный язык, принятый в вашей команде), а в GitHub-репозитории в конце статьи вы найдёте код сервера и приложений для детального изучения.

Декабрь 2020, вторая волна Ковида в разгаре. Я ПМ на удаленке в Американской компании. После похорон отца в Тбилиси я находился в прострации, надо было возвращаться в США и как-то менять своё положение, ведь денег, которых я зарабатывал явно не хватало на нормальную жизнь. Сами воспоминания о моём предыдущем поиске вызывали во мне холодный озноб и какой-то внутренний голос тихо шептал «подожди, сейчас пандемия, многие и о таком мечтают, как-нибудь выкрутишься…».

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

Я зарегистрировал себе американский номер в Google Voice, чтобы мне начали звонить рекрутеры и начал рассылать резюме. Я разослал около сотни адаптированных резюме и указал в LinkedIn что активно ищу работу. Постепенно на меня начали выходить рекрутеры небольших компаний, но я понимал, что в них условия будут в лучшем случае на 40% лучше текущей и это все равно не решало моих проблем. Хоть и казалось, что на LinkedIn висят тысячи позиций, однако основных работодателей я этим исчерпал. Подавался я в основном на Sr. Project Manager или Engineering Manager позиции.

Осознание пришло, когда я стал читать teamblind.com – лучший ресурс в США по анализу рынка в ИТ и levels.fyi где можно посмотреть реальные зарплаты. Раньше я читал Glassdoor, но информация на нем устарела.

Оказалось, что в финансовой сфере в США, которая мне была интересна - плохие условия и токсичная культура, тоже самое в консалтинге кроме компаний из Big4 или MBB где надо работать долгие часы, но возможно получать 1+ миллион долларов в год дослужившись до партнёра. Самыми интересными оказались компании, которые называют FAANG (Fb, Apple, Amazon, Netflix, Google) иногда в место этого списка используют FAANGMULA справедливо добавляя туда Microsoft, Uber, Lyft и Airbnb – все они технологические, инновационные компании не просто создающие бизнес-продукты, но и технологии, которыми пользуются весь мир. Компании, создающие де-факто стандарты разработки цифровых продуктов, инвестирующие в научные исследования, создающие легендарные условия для своих сотрудников, чем привлекают умнейших инженеров и ученных со всего мира.

Продолжаем «изобретать» медиацентр. Разберемся, как иметь несколько KODI-медиацентров и одну медиатеку на все устройства в доме. Причем такую медиатеку, которая понимает, где вы закончили просмотр и позволит его продолжить на другом устройстве.

• плюсы-минусы работы в крупных компаниях,
• оформление резюме,
• как проходят скрининг, алгоритмическая и архитектурная секции,
• какова роль английского и soft skills — на поведенческой секции и в целом на собеседовании,
• где тренироваться необходимым навыкам для каждого этапа: собрали полезные ссылки.

• Нереалистичные ожидания
• Слишком много открытых тикетов
• Неконтролируемый объем задач
• Накопление код ревью
• Плохая подготовка
• Выгорание разработчиков
• Баги
• Текучка кадров

Здравствуйте уважаемые читатели Хабра!

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

Данный цикл будет состоять минимум из четырех статей:

1. В первой из них я расскажу, как на голое железо установить отказоустойчивый кластер kubernetes, как установить стандартный дашборд и настроить доступ к нему, как установить ingress контроллер.
2. Во второй статье я расскажу, как развернуть отказоустойчивый кластер Ceph и как начать использовать RBD тома в нашем кластере Kubernetes. Также немного затрону остальные виды стораджей (storages) и более подробно рассмотрю local-storage. Дополнительно расскажу, как на базе созданного кластера CEPH организовать отказоустойчивое хранилище S3
3. В третьей статье я расскажу, как в нашем кластере Kubernetes развернуть отказоустойчивый кластер MySql, а именно — Percona XtraDB Cluster on Kubernetes. И также опишу все проблемы с которыми мы столкнулись, когда решили перенести БД в kubernetes.
4. В четвертой статье я постараюсь собрать все вместе и рассказать, как задеплоить и запустить приложение, которое будет использовать БД и тома ceph. Расскажу, как настроить ingress контроллер для доступа к нашему приложению извне и сервис автоматического заказа сертификатов от Let's Encrypt. Еще — как автоматически поддерживать данные сертификаты в актуальном состоянии. Также немного затронем тему RBAC в контексте доступа до панели управления. Расскажу в двух словах про Helm и его установку.
   Если Вам интересна информация данных публикаций, то — добро пожаловать!

Как GitLab с fastlane собирает, подписывает и публикует приложения для iOS в App Store.

Недавно у нас был пост о том, как быстро собрать и запустить приложение Android с GitLab и fastlane. Здесь мы увидим, как собрать и запустить приложение iOS и опубликовать его в TestFlight. Зацените, как круто я вношу изменение на iPad Pro с GitLab Web IDE, беру сборку и получаю обновление тестовой версии приложения на том же iPad Pro, где я его разработал.

Здесь мы возьмем простое приложение для iOS на Swift, с которым я записывал видео.

Часть 2/3 тут
Часть 3/3 тут

Всем привет! В этой статье я хочу упорядочить информацию и поделиться опытом создания и использования внутреннего кластера Kubernetes.

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

0. Вступление

Kubernetes — это масштабируемая технология оркестровки, которая может начинаться с установки на одной ноде и достигать размеров огромных НА-кластеров на основе нескольких сотен нод внутри. Большинство популярных облачных провайдеров представляют разные виды реализации Kubernetes — бери и пользуйся. Но ситуации бывают разные, и есть компании, которые облака не используют, а получить все преимущества современных технологий оркестровки хотят. И тут на сцену выходит инсталляция Kubernetes на «голое железо».

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

С этого момента вам больше не придется думать об установке ОС и отдельных пакетов на каждую ноду. Зачем? Вы можете сделать все это автоматически через Dockerfile!

Тот факт что вы можете купить сотню новых серверов, добавить их в рабочее окружение и почти моментально получить их готовыми к использованию — это действительно потрясающе!

Заинтриговал? Теперь давайте обо всем по порядку.