Меня зовут Олег Кандауров, я руководитель отдела бэкенд-разработки в ЮMoney. На этой должности я провёл более 400 собеседований в свою команду. Сегодня расскажу, что для меня важно в найме сотрудников, какие форматы собеседований у нас есть и как выглядит типичное интервью с кандидатом. А ещё поделюсь советами для тех, кто собирается на собеседование.

Вторая часть статьи — тут.

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

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

Сложно представить человека, у которого перед выходом на сцену не дрожали бы коленки. Особенно, если ТАМ ждут 100 (200) человек, а за плечами у вас только выступление на школьном утреннике.

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

В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.

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

Так как базы данных Яндекс.Денег вынуждены хранить массу второстепенной и временной информации, однажды такое решение перестало быть оптимальным. Поэтому в инфраструктуре появился распределенный Data Grid с функциями in-memory базы данных на базе Hazelcast.

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

В этом материале я продолжаю делиться полевым опытом работы с системой сбора логов на базе Heka и ElasticSearch.

На этот раз рассказ пойдет про миграцию данных между двумя кластерами ElasticSearch 2.2 и 5.2.2, которая стоила немалых нервов лично мне. Как-никак, предстояло перевезти 24 миллиарда записей, не сломав уже работающую систему.

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

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

Рассказывать о долгом и тернистом пути всегда непросто. Однако за последние годы инфраструктура разработки Яндекс.Денег сделала большой шаг в сторону автоматизации самого важного для нас процесса — релиза, о чем просто грех не рассказать. Фактически получилось полноценное решение Continuous Integration и Continuous Delivery на базе связки Bitbucket, Jenkins и Jira.

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

Система построена на базе стека EHK (Elasticsearch/Heka/Kibana), с прицелом на работу практически в реальном времени. Особый упор сделаю на тонкие места и нюансы обработки миллиардов строк текста в сутки.