Обсудить виды сп тут: t.me/ctorecordschat

Чьё конфу круче?
public poll

PostgreSQL Server – 43
👍👍👍👍👍👍👍 73%

MS SQL Server – 16
👍👍👍 27%

👥 59 people voted so far.

*** На правах рекламы ***

@zaksenova объявляет про пятничный митап: 1 марта Digital October X Binary District проводят митап для тимлидов и всех, кто вовлечен в процессы оценки и мотивации разработчиков.

Эксперты из Tinkoff, AGIMA, CSSSR будут обсуждать темы, которые не раз поднимались в этом чате: как давать обратную связь и проводить performance review, чтобы не демотивировать сотрудников, как обойти сложности найма в крупную компанию со сложившимся брендом, какие вещи раздражают разработчиков на работе и как тимлид может это исправить.

Teamlead Meetup — это нетворкинг с возможностью поделиться опытом и идеями с коллегами в дружеской обстановке.

Будем рады вас видеть! Вход на митап бесплатный по регистрации: https://bit.ly/2NcsuoB.

При наличии Clickhouse в телеком-сервисе необходимость репорт-сервера резко снижается
anonymous poll

Нет, Clickhouse не снижает нагрузки с репорт-сервера, хотя конечно и полезен – 7
👍👍👍👍👍👍👍 78%

Да, верно – 2
👍👍 22%

Другое
▫️ 0%

👥 9 people voted so far.

Обсудить за репорт-сервера тут: https://t.me/ctorecordschat

Обсудить за OLAP-системы тут: http://t.me/ctorecordschat

Поговорим за погоду!

Пробки на улице дикие, правда ведь? Сколько деткам лет? Где был в отпуске?

Такие беседы называют смоллтолк или разговоры ни о чём. Вот с фронт-енд разработчиком или сисадмином едва знакомым зачем о таком разговаривать? Зачем тратить на это время? Чепуха же!

Но айтишники хоть и индивидуалисты (ещё бы! с такой-то зп!), но в последние годы всё самое великое собирать получается только в командах. Поэтому hr-ы всё больший упор на собеседованиях делают на детект токсичности, на софтскиллы и вот это вот всё.

Поэтому в большой сложном коллективе надо как-то уживаться, дружить и поддерживать отношения. Чтобы понять, кто тут свой, а кто нет, надо выработать какую-то систему координат, общеценную для всех.

И тут на сцену профессиональных разговор с триумфом выходят смоллтолки.

В Яндексе мы обсуждали качество разных сортов травки. В Рамблере с Монсом сорта зимней резины. В мейле почему-то больше речь шла о стартапах.

А за окном погода, как говорит Димка Белявский, сдохнуть, обнимая кофеварку!

Обсудить за смоллтолки тут: http://t.me/ctorecordschat

Как правильно выбрать хороший спелый арбуз

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

Правило 1. Смотрите на календарь.
Обратите внимание в резюме арбуза на сроки его работ, - у спелого хорошего арбуза обычно 2-3 места со сроками от года до 2-3х лет. Если больше - неплохо.

А вот если мест работы много и они коротки, - это должно насторожить. Имеет смысл прозвонить по этим местам, собрать фидбек.

Правило 2. Место встречи изменить нельзя.
Очень важно следить за тем, где вы нашли арбуз. Если арбуз вам по знакомству передала жена руководителя, которая лично его выкормила грудью, то возможно имеет смысл такой ценный подарок подарить в формате "нанести пользу" конкурентам.

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

Правило 3. Встречают по одежке.
Внимательно посмотрите на арбуз и его шкурку. Вполне возможно шкурка это будет необычной - дреды вместо полубокса, комок вместо костюма, кроссы вместо туфель, но всё это должно быть чистым и аккуратным. Речь должна быть связной и осмысленной.

Если же арбуз плюётся ругательствами вида "заткнитесь и платите мне центрер денег", а вид одежды не очень соответствует этим деньам, имеет смысл задуматься.

Правило 4. Все дело в хвостике.
Хороший арбуз, как ни странно, обычно человек семейный или почти семейный. Это хороший признак! Конечно же немало арбузов и несемейных, но зарплаты такие, что девушки арбузов на внешность обычно не смотрят :)

Продолжение coming soon...

Обсудить за арбузы тут: http://t.me/ctorecordschat

А посоветуйте толкового UX дизайнера, Plz! Нужно выстроить внутреннюю админку, достаточно развесистую перерисованную из уже из рабочего интерфейса. Главный упор скорее на аккуратность, чем на пафосность. В личку, Plz!

Человек или арбуз

Вся фишка в сборе команды заключается в том, чтобы скопмлектовать её ключевые слоты людьми, а все остальные  - "арбузами", цена ошибки по которым максимально снижена целым спектром hr-приёмов: собеседование техническое, собеседование по soft-скиллам, тестовое задание, испытательный срок и вот это вот всё.

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

Все остальные - арбузы.

Аксиома

Никакие собеседования и тестовые задания не дадут 100% гарантии качества арбуза. Их задача вообще в другом, - отсеять явный неадекват.

Обсудить за арбузы и людей тут: http://t.me/ctorecordschat

Следствие главной аксиомы найма: уменьшай цену ошибки

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

Получи тестовое задание
Посмотри, как разработчик принимает тестовое задание, какие вопросы задаёт, как именно делает.

По оплате тестового задания каждый должен сам решать, платить или нет, но если платить, то понятно, что это строго почасовка.

Имеет значение сама дискуссия с кандидатом, если он поднимает эту тему. Внимательно вообще следите за всеми разговорами кандидата, - как он сейчас работает и общается, так и в основной работе он будет себя вести. Кстати, верно и обратно, - как компания общается на этапе "предварительных ласк", так будет и в основной работе.

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

Закажи разработку неключевого функционала в формате почасовки
Чтобы кто не говорил, но проверка только реальной работой всегда даёт хоть какой-то существенный результат.

Возьми на испытательный срок
Суть испытательного срока в том, что Ты нанимаешь человека на условиях готовности к увольнению одним днём. Если компания вопреки закону и здравому смыслу на время этого срока уменьшает зп, то имеет смысл в испытательный срок платить зп горкой, растущей от -30% к зп до -0%.

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

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

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

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

Работа после второго отпуска
К этому периоду у разработчика должно быть уже несколько очевидных побед. Пройдено несколько корпоративов. Уже как минимум один раз он заболевал или у него случился какой-нибудь пипец. И уж точно он где-то накосячил.

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

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

Обсудить за уменьшение цены ошибки: http://t.me/ctorecordschat

Документирование и обсуждения

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

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

Более того, он потом подходил к участникам бесед и переспрашивал какие-то детали, которо он сам проговаривал и оказалось, что и коллеги чего-то из таких деталей не очень помнили.

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

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

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

Обсудить за коммуникации тут: http://t.me/ctorecordschat