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

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

В этой статье будут вещи, с которыми вы можете не согласиться. Это нормально. Это просто моё мнение, а так как я уже вышел на пенсию, то больше не представляю опасности ни для интервьюеров, ни для инженеров Google при принятии решений о найме! ;-)

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

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

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

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

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

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

Виртуализация оборудования — одна из важнейших и фундаментальных технологий в области облачных вычислений. Без нее не смогло бы работать ни одно «устройство» внутри виртуальных машин: ни сетевая карта, ни диск, ни клавиатура, ни мышь и т. п. В статье мы проследим развитие технологий виртуализации оборудования в Linux.

Привет Хабрчанам! Меня зовут Дима Туркин, я — код-ревьюер на курсе «Python-разработчик» Яндекс Практикума и Python-тимлид.

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

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

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

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

Я начала пользоваться ClickHouse до того, как это стало мэйнстримом: первый раз я столкнулась c этой базой данных лет 8 назад. C тех пор я уверена, что это лучшая DB для аналитики. Большинство аналитиков, которых я знаю, в восторге от ClickHouse (иногда чтобы проникнуться, требуется немного времени: разобраться и привыкнуть к синтаксису).

В этой статье я расскажу что такое ClickHouse и почему я считаю его идеально подходящим мощным инструментом для аналитики. А также поделюсь tips & tricks из моего опыта. Поехали.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

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

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

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.

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

Размытое зрение, стук по клавиатуре и одно глобальное правило продуктивности.

Я был там. Слишком долго работаю над проектом. Я начинаю ошибаться. Я теряю детали. Ошибки продолжают появляться, а качество падает.

Делаю что-нибудь творческое в течение нескольких часов, и это утомительно.

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

Великие умы всех времен имеют нечто общее: