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

Во-первых, я не проверяю софт-скилз, ответственность, усидчивость и все вот это. Для этого, кмк, есть испытательный срок, на котором вылезет 80% косяков, а это и так максимум на который можно расчитывать. Тем не менее я задаю пару общих вопросов, что бы понять общую логику и мотивацию кандидата. Обычно это что-то типа: "что вы делаете для того что бы профессионально расти?(тут я жду, что чувак расскажет про книги, которые он прочитал, курсы, которые прослушал и т.д.)", "какое было ваше самое большое достижение на предыдущем месте работы?"(тупо для затравки), "а какой был самый большой факап?"(тоже вобщем-то для затравки, но так же для понимания того готов ли чувак отвечать за свои косяки. Для того что бы чувак расслабился я, обычно, рассказываю про какой-то из своих залетов), ну и самое главное: "а чему вы научились в результате этого горького опыта?"(надо понять что чувак как-то обрабатывает обратную связь, анализирует свою деятельность и т.п.). Так же, стандартно спрашиваю чем бы чувак на 100% не хотел заниматься на работе и почему(на этом вопросе из кандидата очень часто почему-то вылезает все говно). Вот вобщем-то и все общие вопросы.

Дальше по списку идет опыт работы. Честно говоря, мне кажется, что вот прям заострять внимание тут стоит только если собеседуете синиора-помидора или выше. Дело в том, что джуны и мидлы на работе "работают работу", особо не принимая каких-то решений приводящих к глобальным последствиям. Но прослушать рассказ чувака все же надо, как минимум ради того что бы узнать почему чувак свалил(тут, как не странно, тоже выливается много говна). Для синиоров на этом история не заканчивается, т.к. ретроспектива прошлого опыта -- это единственная возможность понять готов ли чувак принимать решения и нести за них ответственность. Для этого можно попросить рассказать про архитектуру(стек/процессы/что угодно) на последнем месте работы и начать задавать вопросы из серии "а почему так, а не вот так?". Абсолютно не приемлемый ответ тут: "ну это тех. дир(тим.лид/архитектор) решил", т.к. с такими лычками надо уже участвовать в принятии решений и уметь как-то отстаивать свое мнение.

Ну и, собственно, тех. интервью. Тут ваще все просто: надо просто определить минимум скилов для кандидата при котором вы готовы взять его на позицию. У меня это обычно:
+ для джуна -- возможность как-то закрывать тикета (разраб должен знать язык на котором разрабатывает, одмен должен уметь в туллинг как системный так и в IaaC. Причем уметь/знать -- это, конечно же, подразумевает, что уметь надо хорошо)
+ для мидла -- надо уже уметь решать задачи самостоятельно(для разраба нужно уметь в дизайн, понимать как работает его софт и т.д., одмен должен мочь собрать пайплайн, поднять тачки и базы, настроить сети, опираясь на требования/спецификации)
+ синиор, как уже было сказано, должен уметь принимать архитектурные решения. Тут, соответственно , надо зарамсить за архитектуру(софтварную для разраба и деплоймент для инфраструктурщика), понимать как работает система в целом, а не конкретные сервисы, иметь какое-то понимание о трейд-офах и т.д.

Кароч все достаточно просто. Вот и все, вот и все)

Ещё один awesome, на этот раз про консенсус https://github.com/dgryski/awesome-consensus #consensus #awesome

Исследуя GitHub

Некоторое время назад писал о процессе публикации npm-пакета.

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

Хотелось переложить максимум забот на компьютер, и избежать этой боли. На выходных сделал библиотеку @solid-soda/scripts, которая содержит в себе все рутинные штуки. Линтер, преттир, генерация новых версий, все там.

Теперь любой проект начинается с установки этой библиотеки.

#автоматизация

Интересный способ готовить распределенные системы через персистентные акторы: https://habr.com/ru/post/267509/ Мне идея показалось очень похожей на https://pulsar.apache.org

​​Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions (2016)
Авторы: Грегор Хоп, Бобби Вульф

#design_patterns #book #english #advanced

Язык: английский.

Целевая аудитория: опытные разработчики.

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

В книге рассматриваются следующие темы:
✔ стили интеграции;
✔ системы обмена сообщениями;
✔ каналы обмена сообщениями;
✔ маршрутизация сообщений;
✔ управление системой и многое другое.

Преимущества:
➕ многочисленные примеры;
➕ качественный материал по теме.

Недостатки:
➖ не обнаружено.

Книжка очень хорошая (рально маст-рид для тех у кого распределенные архитектуры), но название не соответствует содержанию. Вся книжка про мессаджинг, а про остальные способы интеграции(общая база, файлообмен, RPC) там буквально пара страниц <s>негатива</s>. Не, ну безусловно, мессаджинг должен быть дефолтным способом интеграции, но только им обойтись не получится, так что придется вооружаться еще какой-то макулатурой, что бы получить полную картину

Продолжение статьи-расшифровки доклада Ивана Фролкова с разбором типичных ошибок при работе с PostgreSQL.
https://habr.com/ru/company/postgrespro/blog/443792/

Тут подъехала очередная часть гайда по postmortem'ам от PagerDuty, так что кину ссылку на весь гайд, а вы там уже сами разбирайтесь))

https://postmortems.pagerduty.com/

​​KeyDB - A Multithreaded Fork of Redis

John Sully disagrees with Salvatore Sanfilippo’s thoughts on multithreading, so he make own Redis, with multhithreading and enterprise features.

KeyDB have:
- 60% lower latency
- direct backup to AWS S3
- FLASH storage support

KeyDB designed with AWS in mind and has full compatibility with the Redis protocol, modules, and scripts. This includes full support for transactions, and atomic execution of scripts.

#database #aws

Монорепозиторий: 7 фактов, которые должен знать каждый

Монорепозиторий используют в Google, Facebook, Twitter. В чем его прелесть? Вот перечень основных плюсов и минусов монорепозиториев.

https://prglb.ru/4062u

При всех этих хайп-воплях за монорепу и транк-бейзд мне резко вспоминается вот этот видос: https://youtu.be/W71BTkUbdqE где extremely pregnant тетя из гугла объясняет(несколько раз), что они юзают все это добро потому что у них есть специальный(Карл!) туллинг, написанный, специально(Карл!) под это дело! А у кого такого специального(Карл!) туллинга нет, то ни в коем случае лезть в это не надо

Поддержка больших JavaScript приложений. Уроки, вынесенные из долгосрочных проектов

https://9elements.com/io/maintaining-large-javascript-projects/

подъехал эл. вариант:

Новый фонд для DevOps-проектов от Linux Foundation начался с Jenkins и Spinnaker
https://habr.com/ru/post/444394/
Tags: Блог компании Флант, DevOps, Open source, Системное администрирование, Системы сборки, Linux Foundation, Jenkins, Jenkins X, Spinnaker, Tekton
Author shurup on #habrahabr

Вчера в офисе IBM прошел митап по API Management'у. Были докладчики из IBM(странно, да?), Leroy Merlin, Google(Apigee) и Yandex Cloud. Для тех, кто не дошел вот ссылка на запись: https://youtu.be/djQ5R6nyWtc
Особо хочется отметить докладчика из Google. Не смотря на довольно очевидный и наименее технологичный доклад, чувак реально зажигал(а еще он похож на Саймона Пега)

[Перевод] Автоматические canary деплои с Flagger и Istio
https://habr.com/ru/post/444808/
Tags: Блог компании Southbridge, DevOps, Серверное администрирование, Системное администрирование, k8s, CI/CD, microservices, istio, flagger
Author RENESiS on #habrahabr