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

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

Сотрудники, вкладывающие свои сердца и души в работу, создают великие продукты и великую компанию.

Привет, Хабр!

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

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

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

Пока все кому не лень пишут статьи о том, как войти в айти, некоторые из нас нет-нет, да задумываются, а не выйти ли оттуда. Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни? А вдруг там, за дверью серверной или опенспейса R&D, всё по-другому? 

Всем привет! Возможно уже совсем скоро разные новостные и  IT-ресурсы будут подчищать информацию о способах обхода блокировок. А пока этого не случилось, запасаемся полезными гайдами и разворачиваем свои собственные VPN с защищенными от блокировок протоколами. Расскажу как это сделать, как изменилась Amnezia и как мы защитили WireGuard от блокировок.

Ultimate Mortal Kombat 3

Многие игроки считают, что разработка — это интересный и увлекательный процесс (о, святая наивность!). Это, конечно, так, но, к сожалению, в этой сфере вся романтика заканчивается, когда начинаются проблемы. Одной из таких проблем и является «кранч», или работа на износ. Карьера в области искусственного интеллекта или Data Science не застрахует от переработок полностью, но в последнее время компании понимают, что культура кранчей не приводит к хорошим результатам. В данном посте попробуем разобраться с этим неприятным явлением, которое заставляет разработчиков сходить с ума.

Старайтесь изо всех сил, чтобы произвести впечатление на своего начальника.

Думайте, что команда Вас уважает за Вашу работу, когда команда токсична.

Создайте иллюзию, что продвигаетесь вперед и Вас замечают.

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

И Вы сгорите, не продвинувшись вперед.

Пару месяцев назад Steam выложил в Steamworks инструмент для разработчиков, позволяющий отправлять игры на сертификацию: Steam тестирует и проверяет игру, а затем решает, совместима ли она с Steam Deck. Так как я уже реализовал в своей игре поддержку геймпадов, то сразу приступил к делу. Мне понадобилось два месяца переписок со Steam, чтобы он наконец верифицировал полную совместимость игры со Steam Deck. Я не нашёл особо много информации об этом процессе, поэтому захотел поделиться своим опытом, чтобы другим разработчикам не приходилось совершать те же ошибки.

Примечание: у меня нет Deck и я ни разу им не пользовался. Разработка игры целиком зависела от помощи моего фаната и простоты разработки под сам Steam Deck.

На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.

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

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

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

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

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

С реляционными базами данных я знаком очень давно, с конца 90-х. Мои первые шаги в мире компьютеров и программирования связанны именно с ними. Реляционным БД было отведено особое место в моей образовательной программе и стажировке на инженера-программиста. Они преследовали меня на протяжении всей моей карьеры. Я буквально провалился на самое дно кроличьей норы реляционных систем управления базами данных (РСУБД) – и до сих пор люблю их.

За годы работы я испробовал практически все РСУБД, а их попадалось мне немало: MySQL, Postgres, Oracle, Microsoft SQL Server, DBase, Access, SQLite, DB2, MariaDB, AWS RDS, Azure SQL, Google Cloud SQL. Нельзя любить РСУБД, если не любишь SQL, а это отдельная вселенная. И не все SQL одинаковы. Есть MySQL со своим собственным жаргоном, есть T-SQL от Microsoft и всемирно известный PL/SQL от Oracle. Наверное, не стоит упоминать, что все они несовместимы друг с другом.

Пассивный DPI

В последние полгода появилась четкая тенденция: крупные корпорации загоняют сотрудников обратно в офис. Они обязуют 60% рабочего времени проводить в офисе, что примерно равно трем дням в неделю.

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

Сам работаю программистом в Амазоне уже больше двух лет. Начинал в команде в Ванкувере, Канада. Мне не понравилось и я переехал в Испанию, поменяв команду.

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

В Go 1.20 сделали возможность сбилдить приложение с флагом cover

go build -cover

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

Это, конечно, было сделано для интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но, вероятно, это можно попробовать использовать и по-другому:

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

Так можно найти недовыпиленный легаси-код, старые эндпоинты API, которые давно никому не нужны, малозначимые проверки if err != nil и прочее. Как минимум, на это интересно посмотреть, можно найти что-нибудь удивительное.

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