Инсайды собеседования в Thoughtworks
Нужно провести собеседование, а вы не хотите давать задачки на кручение деревьев? Тогда у меня есть, что вам предложить.

На мой скромный взгляд, процесс собеседования в Thoughtworks один из лучших в мире.
Как я говорил в одном видео, Thoughtworks провел хорошую работу по выяснению функциональных и нефункциональных требований к кандидатам. А потом подумал, как именно их можно проверить. А не смалодушничал и не дал очередные задачи с leetcode 🙂

Требования к программистам простые:
- уметь читать написанный код
- отличать плохий код от хорошого
- обязательно уметь писать тесты до кода
- немножечко уметь писать код хотя бы на одном языке
- и уметь рефлексировать над своими провалами

Теперь посмотрим как это имплементируется в собеседованиях:

Этап 0. Собеседование с HR
Достаточно быть более-менее адекватным: не пускать слюни на интервью, более-менее понимать что тебя спрашивают по-английски. Хотя надо признать, что даже HR’ы наврят ли пропустят кандидата после фразы «а я без тестов в прод деплою прям с ноута».

Этап 1. Coding Challenge (1,5 часа)
Вам заранее высылают маленький проект на вашем любимом языке и дают ознакомится с кодом.
На самом собеседование вас обязательно спросят, что понравилось в коде, а что бы вы улучшили.
Бывали случаи, когда ребята с 5+ годами опыта говорили, что все хорошо, но лучше использовать 2 отступа вместо 4 и комментарии добавить. Тут, конечно, можно уже и не кодить. Я лично, по крайней мере от Лидов, ожидаю критику архитектуры.

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

По секрету скажу, что к этой задаче достаточно немного порефактрить и написать 5 строчек продакшен-кода. И тесты, куда же без них.

Кстати, напишите в комментариях, а что бы вы исправили вот в этом тестовом проекте. Можете выбрать любой язык 😉

Продолжение следует…

Завтра заканчивается предзапись на курс "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

Подробнее по ссылке - t.me/stringconcat/142
Места ещё есть.

Курс рассчитан на практикующих разработчиков. Чтобы во всём разобраться и получить от курса максимум пользы, вам потребуется:

1. Опыт работы на коммерческих проектах.
2. Знакомство с основными паттернами и инструментами разработки.

В курсе мы говорим о вещах не привязанных к какому-либо языку. Домашнюю работу вы можете делать на любом языке.

Но все же кое-где приходится показывать примеры. Тогда мы используем Котлин. Если судить по отзывам наших иноязычных студентов, то проблем у них не возникает.

Как можно себя проверить?

У нас есть бесплатный курс "Поваренная книга
Дядюшки Боба: как готовить Clean Architecture". Справляетесь с поваренной книгой? Значит справитесь и с основным курсом.

Проверить себя: t.me/sc_stringconcat_bot
Записаться на курс: howto.stringconcat.com/enterprise

Продолжаем говорить про собеседование в Thoughtworks

Этап 2. Технический кругозор (1,5 часа)
Для начала кандидата спрашивают о прошлых проектах: что было интересного и чем можно гордиться.

Я считаю это отличным началом разговора, так как человек расскажет о том, что хорошо знает, с чем он работал и чем горд. И по крайней мере перестанет нервничать, так как на первый вопрос из билета уже ответил 🙂 Ну а мы – интервьюеры — получаем пищу для последующих вопросов:

Почему выбрали микросервисы — поможет понять, анализировал ли кандидат другие варианты или взял первое, что попалось
Что бы вы сделали по другому — покажет, рефлексировал ли кандидат над содеянным
Если кандидат упомянул, что знает несколько языков, спросим какой из них любимый и почему
Можно спросить о технических деталях — про особенности распределенных транзакций и всякие garbage collector’ы, — если только кандидат упоминал, что работал с ними

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

Этап 3. Culture Fit
Финальная часть собеседования, на которой оценивается насколько органично кандидат вольётся в коллектив. Для этого задаём стандартные поведенческие вопросы про ситуации на работе, два стула, вот это всё.

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

Если вам понравился процесс и вы готовы попробовать свои силы, то сейчас Thoughtworks набирает разработчиков во Въетнам 😉

Когда дал джунам проект и вышел из кабинета
https://coub.com/view/3bmi5r

Хочу похвастаться, я стал тренером Tech Lead Development Program в Thoughtworks! 🥳🥳🥳

Конкретно я рассказываю про то как выстроить техническую стратегию на проекте и про нефункциональные требования.

Жопа босса знает лучше — важная особенность китайской культуры
В Thoughtworks мне предложили поработать на нового клиента, но предупредили, что это очень традиционная китайская организация. Оказалось, это важно знать заранее. И вот почему.

Пришёл к клиенту в офис, ищу стул. Пробую один, другой, регулирую — все не очень. Говорю разработчику Чену:
— Стулья неудобные какие-то.
— А я их сам выбирал.
— Так у тебя жопа как у меня, тебе удобно, что ли?
— Неудобно, но другие нельзя было выбрать.

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

Для сравнения в Скандинавии царит дух равенства и даже тимлид не может решать за всю команду. Любое решение придётся продавать, а команда может его не принять. И я такое встречал даже в банке.

По моим наблюдениям в атмосфере равенства получаются более качественные продукты: каждый в команде чувствует причастность и ответственность за результат. При подходе «спустили сверху» причастности не ощущается. С другой стороны, скандинавы некоторые проблемы решают месяцами, утопая в бесконечных обсуждениях. Китайцам же консенсус искать не нужно, за них всё Конфуций решил.

Полезное для линуксоидов и маководов

SDKMAN — пакетный менеджер для JVM-мира. Позволяет устанавливать и жонглировать SDKашками и инструментами без геморроя и ручных манипуляций с переменными окружения, как, например, в brew.

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

Работает на большинстве Unix-образных систем и вроде как даже на винде через Cygwin, но я не пробовал. Не заменит brew или же apt, но рулить Java-миром через него однозначно удобнее. Крайне рекомендую к установке.

Для чего же всё-таки нужно резюме

Представьте, заходите вы в чат, а там два полярных мнения:

1. Резюме бесполезно. Соискатели всё врут, поэтому работодатели резюме не читают и всё нужное узнают на собеседовании.

2. Резюме полезно. Соискатель может показать важные кейсы, а работодатель получить общее представление и подумать, о чём спрашивать на собеседовании.

Какое сами лайкните, а какое друзьям перешлёте?

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

Как Netflix мигрировали на новый API и ничего не потеряли. Первая часть

У Netflix недавно рассказали, как они мигрировали на новый API без даунтайма.

Вот самое любопытное:

Netflix мигрирует с legacy API на GraphQL. Просто выключить старый API и включить новый они не могут: обязательно что-нибудь пойдёт не так и будет стоить дорого.

Чтобы проверить новый API в боевых условиях, но без ущерба для пользователей, они деплоят его рядом со старым и проверяют через Reply Testing.

Когда получается, запрос пользователя отправляется на оба API: на новый и на старый, а ответы сравниваются. Если есть разница, значит, что-то в новом API упустили. Например:

/data/videos/0/tags/3/id: (81496962, null)

Очевидно, забыли про поле ID и отдаём null.

А тут слетела локализация:

/data/videos/0/tags/5/displayName: (Série, value: “S\303\251rie”)

В статье пишут, что Reply Testing помог Netflix выявить следующие ошибки:
— encoding errors
— локализация
— формат даты и времени
— ну и, конечно, числа с плавающей точкой

А в следующей заметке поговорим, как они использовали A\B-тесты.

Как Netflix мигрировали на новый API и ничего не потеряли. Вторая часть

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

Для A\B-тестов Netflix поделили миллион пользователей на 2 группы:
— контрольную на старом API
— экспериментальную на новом.

Обе группы пользовались сервисом, а разработчики тщательно сравнивали quality of experience metrics: как часто возникают ошибки на клиенте, latency и прочее.

Конечно, разница метрик — это ещё не решение. Выявление проблем похоже на детектив: какой-то показатель ухудшился, а вам ещё нужно понять, из-за чего именно. К примеру, у Netflix нестабильный latency подсказал, что нужно подкрутить TTL кешей.

A\B-тесты оказались хорошим инструментом для проверки нефункциональных характеристик. За полгода Netflix уравняли показатели и мигрировали всех пользователей на новый API.

Здравствуйте! Это пост с набросом. Вы предупреждены.

Преамбула: в одном из архитектурных чатов у нас развернулась дискуссия по поводу специальности «разработчик»: стала она уже рабочей или ещё нет.

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

Всё описано в регламентах, собрано во фреймворки, поэтому средний разраб заменяется за день. А придумывать, как оно должно работать, — работа системных инженеров. И тут у нас получается условное деление по признаку образования:

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

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

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

Как сэкономить 120 000 $ в год на инфраструктуре? Просто возьмите старый проверенный EC2

Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.

Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate

Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.

Что мы изменили

1. Смёржили всё в два сервиса.

Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.

2. Перевели деплой с AWS Fargate на EC2.

У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.

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

EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.

Наткнулся на неплохой мануал с примерами по spring-security и oauth

Как известно, в spring-security сам черт ногу сломит, а если туда oauth добавить, то, вообще, никогда в жизни не разберёшься. В мануале автор неплохо объясняет, как что устроено с точки зрения спринга.

Я тут систематизировал стратегии как я торговался за оффер в Thoughtworks 4 года назад. 🙂 https://www.youtube.com/watch?v=jtu_FdNDxNc

Кстати, а как вы обычно выбиваете на собеседованиях зарплату по-больше?

Небольшая заметка о том, как гарантированно заехать в дурку, находясь в айтишечке

Собрали у своих коллег истории чего необычного они находили в самописных библиотеках.

Нашлись
- Конфигурации Спринга,
- Override Бинов,
- Хабернейт.
Но победителем посчитали либу со @SpringBootApplication внутри.

А вы что находили в либах?