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

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

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

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

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

Всем привет! Вместе с коллегами я занимаюсь наймом в Максилекте. Обычно в блоге на Хабре высказываются наши разработчики. От них были статьи не только о технологиях, но и о том, на что смотреть в ходе собеседования и как правильно подобрать компанию по душе. Их мнение вызвало бурный отклик среди коллег-ИТ-шников и заодно выпады в сторону HR, как направления в целом. Известное ведь “противостояние”: ИТ-шники против кадровиков.

Сегодня хочется вставить свои пять копеек в примирение сторон. Иногда отдельные представители HR действительно “перегибают”, применяя в ИТ методы, которые здесь не очень-то работают. Но не все мы такие! Поделюсь своим видением того, откуда берутся надоевшие вопросы про “видение через пять лет”, стоит ли на них “правильно” отвечать и о чем надо задуматься рекрутерам, которые все еще их задают.

Около двух лет назад вышла небольшая статья Kafka Streams — непростая жизнь в production, в которой я описывал сложности, с которыми наша команда столкнулась при попытке решить задачи проекта с помощью kafka-streams. Эксперимент вышел неудачным, и мы в итоге совсем отказались от этой технологии. Вместо нее решили попробовать Clickhouse (CH), и сейчас уже можно сказать, что эта база нам очень хорошо подошла и отлично решает почти все задачи, которые нам ставит бизнес. В этой статье я расскажу об особенностях использования CH.

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

Мы в свое время настроили удаленный формат и работаем так уже почти семь лет. Продолжаем допиливать детали, но в общих чертах можем отчитаться о том, что “контроль без контроля” действительно работает. В этой статье рассказываем, как он устроен.

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

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

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

Поговорим о том, откуда растут ноги у последних тенденций возврата в офис и означают ли они “смерть удаленке”.

Говорят, у менеджеров никогда нет времени - у них постоянные созвоны и миллион разных дел. Свободный слот в их расписании найти сложнее, чем билеты на концерт твоей любимой группы. Создаётся впечатление, что чем выше твоя должность, тем больше времени в сутках тебе нужно, чтобы всё успевать. И начинает казаться, что помочь тут может только маховик времени из мира волшебства. Так вот, это не так. Если к вашему тимлиду нужно записываться за 2 недели, или вы сами менеджер, и у вас постоянно не хватает ни на что времени, то знайте - это не норма.

Чаще всего мы просто не умеем управлять своим временем. Пытаемся быть везде, делать всё. Но через какое-то время должно прийти понимание простого факта - невозможно решать проблему нехватки времени простым масштабированием рабочих часов. В такой тупик часто упираются менеджеры-новички, но к некоторым понимание, как быть более эффективным, не приходит ещё очень долго. У новоиспеченного тимлида может сформироваться ощущение, что он обязан обрабатывать весь поток входящей информации и как-то на него реагировать, - помогать, решать их проблемы и т.п., т.е. тратить на все это время. Ведь он теперь тимлид, на нем всё держится! И вообще, хочется показать коллегам, что не зазнался и не превратился в небожителя, который теперь игнорирует все проблемы “простых смертных”, а наоборот всё ещё бывший коллега-разработчик, весь в доску свой и небезразличный. Но с такой загруженностью у него просто не остается времени на высокоуровневый взгляд на работу, при котором видны проблемы всего проекта. Когда же планировать стратегические - кадровые, архитектурные и коммуникационные - решения?

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

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

Мой рассказ ориентирован на тех, кто еще только думает о карьерном росте в направлении тимлида. Возможно, здесь вы найдете ответы на некоторые свои вопросы.

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

Осторожно, много фото!

Хобби коллег очень многогранны. Сегодня расскажем об ИТ-шном подходе к выращиванию арбузов в регионе, где, казалось бы, нормально вызревать они не должны. Наш девопс, Игорь Иванов, объединил системный подход к сбору информации и комплектующие с AliExpress и из магазинов для садоводов, и уже не первый год собирает отличный урожай. 

Своеобразная “инструкцию для начинающих” получилась довольно объемной. Мы  разделили ее на две части: в первой автор разбирает теоретические основы, а во второй переходит к практике.

Осторожно, много фото!

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

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

Статья написана по мотивам ИТ-посиделки, где мы обменивались полезными лайфхаками.

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

Статья написана по мотивам ИТ-посиделки, где мы обменивались полезными лайфхаками. Все команды, которые успели обсудить, мы разделили на две части. В первой поговорим про запросы общей информации о пользователях и системе, работу с файлами, процессами и текстом. Во второй части - о bash и работе с сетью, в частности ssh.

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

Софт скиллы можно и нужно развивать. Поговорим о том, как это сделать в рамках компании - о том, как это делаем мы.

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

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

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

Ведь так?

Мы провели эксперимент и проверили это на практике. Больше полугода наша команда проработала без тестировщика, перестроив свою работу.

Каждый месяц выходит пачка потенциально полезных устройств для умного дома. Проблема в том, что часть функционала - лишь забавная игрушка, а не полезный на длинных дистанциях механизм. Понять, “зайдет” ли какая-то конкретная опция, выбирая очередную “игрушку”, не так просто. На одном из внутренних созвонов у нас заходила речь о том, кто что использует. И внезапно всплыла интересная практика от тех, кто по роду деятельности много времени проводит дома, следит за техническими новинками и успел пощупать разнообразные новинки. 

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

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

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

Привет, я редактор блога Максилект на Хабре. Сегодня я впервые буду высказываться от своего имени. Расскажу, как выглядит история с нашим блогом в ракурсе событий последнего года и почему ИТ-специалистам все еще стоит тратить время на написание статей.

2022 год был непростым для тех, кто занимается контентом. И блог на Хабре, несмотря на свою аполитичность, не исключение. Пришлось наблюдать за происходящим и подстраиваться. Зато по итогам есть интересные цифры, которые лично в моей голове впервые превратили абстрактные графики в статистике публикаций в реальные человеческие истории.

Но обо всем по порядку.