Как определить хорошего разработчика на собеседовании

Редакция Executive.ru продолжает цикл статей о подборе сотрудников в ключевые отделы компании. Ранее на сайте уже выходили публикации о том, как подбирать менеджера по продажам, как не ошибиться с выбором маркетолога и как определить подходящих кандидатов на роль бухгалтераHR-специалиста и менеджера проектов.

В этот раз мы попросили руководителей IT-компаний рассказать, какие методы помогают им выбирать разработчиков и программистов. На что обращать внимание во время собеседования? Как понять, что кандидат не подойдет или что у него нет опыта? Какие качества оценивать в первую очередь?

Признаки хорошего разработчика

Дмитрий ЗавалишинДмитрий Завалишин, основатель и генеральный директор группы компаний DZ Systems

Хороший разработчик:

  • Владеет широким спектром инструментов.
  • Умеет принимать верное решение в отношении того, какой инструмент идеален для решения данной задачи. Опытный разработчик представляет себе, что находится «под капотом» у инструментов, которые он применяет. Для него библиотеки и фреймворки не должны быть «черным ящиком», внутри которого происходит неведомая магия.
  • Умеет работать в команде — как с точки зрения коммуникационных навыков (чисто человеческого умения общаться), так и с точки зрения современных технологий, применяемых для организации работы.

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

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

Хороший разработчик обладает аналитическим мышлением и должен уметь:

  • Разбивать сложные задачи на простые подзадачи.
  • Находить оптимальные решения.
  • Предвидеть потенциальные проблемы.

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

  • Предлагают улучшения в процессах и продуктах.
  • Берут на себя ответственность за результат.
  • Не боятся сложных задач.

Об этом многое может сказать опыт работы над pet-проектами или участие в open-source.

Алексей ГришанковАлексей Гришанков, руководитель Android-подразделения мобильной разработки в Notamedia.Agency

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

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

Также я обращаю внимание на анализ ошибок: хороший специалист понимает, что ошибки — это часть работы, и может объяснить, как он их выявляет и устраняет. Были случаи, когда в беседе кандидат начинал описывать проект и показывал глубокое понимание системы, в том числе узких мест, где могли быть ошибки. Это говорит о том, что он знает код «наизнанку» и готов его улучшать.

Алгоритм оценки разработчика

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

1. Определите, кто вам нужен

Прежде чем начинать поиск, четко сформулируйте, какой именно специалист вам требуется. «Хороший программист» – понятие относительное. Мы всегда начинаем с составления детального профиля вакансии. Какие технологии должен знать кандидат? Какой опыт необходим? Какие личные качества важны для успешной работы в нашей команде? Например:

  • Python-разработчик с опытом работы в Data Science от 3 лет, знанием SQL и умением работать в команде.
  • Frontend-разработчик со знанием React, опытом создания адаптивных интерфейсов и навыками UI/UX дизайна.

Четкое понимание требований поможет сфокусироваться на действительно важных критериях при оценке кандидатов.

2. Наведите справки о кандидате

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

  • Над какими проектами работал кандидат?
  • Насколько самостоятельно он справлялся с задачами?
  • Были ли сложности в коммуникации?
  • Почему закончилось сотрудничество?

Такой подход позволяет составить более полную картину о профессиональных качествах разработчика еще до личной встречи.

3. Проведите тестирование

Теоретические знания важны, но еще важнее – практические навыки. Поэтому мы всегда проводим техническое тестирование кандидатов. Возможно использовать платформу HackerRank для оценки навыков программирования. Кандидату предлагается решить несколько задач разной сложности. Это позволяет оценить:

  • Знание синтаксиса языка.
  • Умение писать эффективный код.
  • Навыки отладки и оптимизации.
  • Скорость решения задач.

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

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

4. Проведите личное собеседование

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

На что мы обращаем внимание:

  • Умение четко и структурированно излагать мысли. Разработчик должен уметь объяснять сложные технические концепции простым языком.
  • Подход к решению задач. Мы предлагаем кандидату решить несколько алгоритмических задач, наблюдая за ходом его мыслей. Важно не столько получить правильный ответ, сколько увидеть логику рассуждений.
  • Знание основ. Понимание базовых структур данных, алгоритмов, принципов ООП – обязательно для хорошего разработчика.
  • Опыт работы с инструментами разработки. Git, CI/CD, Docker – без этого сегодня никуда.
  • Умение работать в команде. Мы задаем вопросы о прошлом опыте, о том, как кандидат решал конфликтные ситуации.
  • Мотивация и желание развиваться. Хороший разработчик должен следить за новыми технологиями, постоянно учиться.

Важно создать комфортную атмосферу на собеседовании. Стресс-интервью не наш метод – мы хотим увидеть реальные способности кандидата, а не его реакцию на стресс.

5. Дайте тестовое задание

Финальный этап отбора – выполнение тестового задания. Это может быть мини-проект или решение реальной задачи из практики компании. Тестовое задание позволяет оценить:

  • Качество кода.
  • Умение следовать требованиям ТЗ.
  • Навыки проектирования архитектуры.
  • Умение писать тесты.
  • Навыки документирования.

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

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

На что обратить особое внимание

Иван ФеденковИван Феденков, тимлид разработки в IT-компании HFLabs

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

  • «Провел рефакторинг модуля, и это позволило вносить доработки проще и быстрее».
  • «Оптимизировал работу программы, что ускорило формирование отчета в 10 раз».

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

На этапе собеседования:

  • В обязательном порядке проверяем базу, даже у сеньоров. Для нас важно знание java-core, умение работать с коллекциями, понимание разницы между проверяемыми и непроверяемыми исключениями и умение объяснить эту разницу «на пальцах».
  • Задаем каверзные вопросы, которые позволяют понять, работал ли кандидат со сложными задачами. Оцениваем технический кругозор. За час это позволяет сформировать картину об опыте кандидата и понять, интересен ли он нам.
  • Оценить софт-скиллы на техническом собеседовании обычно не хватает времени, но иногда в процессе общения понимаешь, что нам с кандидатом не по пути. Обычно это ситуации, когда человек увиливает от прямых ответов, а вместо этого ударяется в философствование и пытается «заболтать». 

По сути, оцениваем будущего коллегу по двум критериям: «хорошо соображает в ситуации, когда что-то не знает» и «есть опыт, знает». Чтобы оценить по первому критерию, задаем прикладные вопросы — например, как достать элемент из множества. А опыт оцениваем вопросами про обработку данных (это наш домен) — нам важно, чтобы человек понимал основные принципы работы с ними.

Алексей ГришанковАлексей Гришанков, руководитель Android-подразделения мобильной разработки в Notamedia.Agency

В первую очередь оцениваю технические знания. Для мобильного разработчика это базовые навыки работы с платформой (будь то Android или iOS), знание популярных библиотек, понимание архитектурных паттернов и принципов работы с сетевыми запросами. На практике было много случаев, когда кандидат демонстрировал глубокие знания, но оказался недостаточно гибок в применении разных подходов.

Хороший специалист должен быть готов учиться и держаться в курсе новых трендов. Например, после смены API (Application programming interface) или обновления фреймворка кандидат должен быть готов адаптировать свой подход, а не строго придерживаться старых решений.

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

Я смотрю, насколько кандидат внимательно слушает вопросы и как отвечает. Важно, чтобы кандидат не пытался впечатлить обилием технических терминов, а мог объяснить логику своих решений простыми словами. В одной из бесед мы обсуждали использование архитектуры MVI (Model-View-Intent) в мобильной разработке, и кандидат, без сложных терминов, объяснил, почему этот паттерн помогает ему избежать путаницы с состоянием экрана при сложной навигации. Подобные ответы показывают не только знания, но и умение «приземлить» их на конкретные задачи и требования платформы.

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

Как вычислить новичка, у которого нет опыта

Иван ФеденковИван Феденков, тимлид разработки в IT-компании HFLabs

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

Вычислить выпускников курсов можно и еще по нескольким признакам. Например, они указывают в качестве своего работодателя компании, которые невозможно найти через поиск в Интернете. Или пишут опыт работы в той организации, где сейчас числятся. Скажем, работает человек на заводе по производству труб и «рисует», что он делал там CRM-систему. Часто выпускники курсов просто пишут про стек технологий. И, самое главное, они всегда идут «пачкой» – и резюме у всех одинаковое.

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

Какие вопросы задать кандидату на роль разработчика

Иван ГринкевичИван Гринкевич, CEO & Founder PHPdev.org

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

Я заостряю внимание на этих вопросах:

  • «Почему ты ушел с прошлого места работы?». Если кандидат сразу описывает прошлую компанию как «полный бардак», для меня это повод уточнить, что конкретно его не устраивало. Если кандидат акцентируется исключительно на негативе, жалуется на команду или руководство, это сигнал возможной токсичности.
  • «Как ты решал задачи, которые перед тобой стояли?». Здесь мне важно услышать о реальном опыте: типах задач, с которыми ему приходилось сталкиваться, и подходах к их решению. Кандидат с релевантным опытом сможет объяснить, как он подходил к решению задач, какие методы и лайфхаки применял, какие ошибки совершал и что из этого вынес.
  • «Какие задачи ты выполнял на предыдущей должности?». Каков был результат? Я обязательно спрашиваю кандидата о его достижениях: смог ли он привнести что-то полезное для компании, каких конкретных успехов достиг. Хороший кандидат способен показать, как он сделал что-то значимое, привел к положительным изменениям, а не просто выполнял задачи ради процесса.
  • «Чего ты ждешь от работы у нас?». Выясняю, какую зарплату кандидат считает справедливой и за какие достижения.
  • «При каких условиях ты бы задумался о смене работы?».

Анатолий КурочкинАнатолий Курочкин, эксперт Executive.ru

Этот ряд вопросов считаю очень полезным:

  • «В каких фреймворках вы работали? С какими языками?». Ответ может помочь определить насколько кандидат увлечен программированием, на сколько ему это интересно.
  • «В каких коммерческих проектах вы участвовали? В каких ролях? Были ли самостоятельные разработки или только в команде?». Эти вопросы помогут определить границу опыта кандидата.
  • «С какими СУБД вы работали? Как вы оцениваете свой опыт работы с ними?».
  • «К каким способам документирования вы привыкли?». Необязательно у хорошего программиста должна быть склонность к написанию больших текстов, но одних только комментариев в тексте программы явно мало. Он должен уметь в паре абзацев пояснить логику своей программы или отдельного модуля.
  • «Есть ли у вас дополнительный опыт, например, в написании скриптов для тестирования? Как вы работаете с отладкой программы?».

У меня есть и шуточный вопрос: «Чем отличается число с плавающей точкой от числа с плавающей запятой?». Этот вопрос идет первым и позволяет разрядить атмосферу.

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

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

  • Как кандидат осваивает новые технологии?
  • Какую профессиональную литературу читает?
  • Участвует ли в конференциях, митапах?

Какие ответы кандидата говорят о том, что он не подойдет

Иван ГринкевичИван Гринкевич, CEO & Founder PHPdev.org

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

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

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

Алексей ГришанковАлексей Гришанков, руководитель Android-подразделения мобильной разработки в Notamedia.Agency

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

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

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

Есть несколько «красных флажков», на которые мы обращаем внимание:

  • Неумение признавать ошибки. Если кандидат не может признать, что чего-то не знает или в чем-то ошибся – это плохой знак. Хороший разработчик должен уметь учиться на ошибках.
  • Отсутствие интереса к новым технологиям. Если человек не следит за трендами в своей области, не читает профессиональную литературу – он быстро устареет как специалист.
  • Неумение работать в команде. Фразы вроде «я предпочитаю работать один» или истории о конфликтах с коллегами говорят о проблемах с мягкими навыками.
  • Отсутствие собственного мнения. Если кандидат на все вопросы отвечает «как скажете» – это признак отсутствия инициативности.
  • Нежелание брать на себя ответственность. Хороший разработчик должен уметь принимать решения и отвечать за результат.
  • Неумение объяснить простыми словами проекты, над которыми он работал – это признак поверхностных знаний.
  • Отсутствие вопросов о компании и проекте. Заинтересованный кандидат всегда задает встречные вопросы.
  • Неадекватные зарплатные ожидания. Это говорит либо о переоценке своих навыков, либо о недостаточном понимании рынка.

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


Материал подготовлен с помощью сервиса «Лига экспертов» Executive.ru.
Вы тоже можете оставить комментарии на запросы редакции:

Посмотреть открытые запросы

Читайте также:

Расскажите коллегам:
Комментарии
Researcher, Москва

Как определить хорошего разработчика на собеседовании?

По портфолио на GitHub.
Нету ножек (портфолию на GitHub) -- нет конфетки (предложения).

Аналитик, Москва

Отдельно надо выделить программистов в 1С. Понимание бухучёта там просто необходимо. Слабое звено у "одинэсников" - работа с базами данных и применение API.
Я не стал бы относить к хорошим программистам тех, кто не может объяснит отличие структурного программирования от объекто-ориентированного. 

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

Researcher, Москва
Анатолий Курочкин пишет:
Ну а если человек работал с ассемблером, то он принимается сразу.

Ну да, и с Бэйсиком.

Аналитик, Москва
Сергей Средний пишет:
Анатолий Курочкин пишет:
Ну а если человек работал с ассемблером, то он принимается сразу.

Ну да, и с Бэйсиком.

Васёк даже я не знаю (точнее забыл). А вы, видимо, не знаете, что такое ассемблер.

Researcher, Москва
Анатолий Курочкин пишет:
Васёк даже я не знаю (точнее забыл). А вы, видимо, не знаете, что такое ассемблер.

Вы меня недооцениваете. Ну как же? Я писал на ассемблере под 580 процессор код в конце 80-х и самом начале 90-х. А на компьютере Микроша даже реализовал автозапуск программы после считывания её с кассеты (что по мнению многих экспертов журнала Радио считалось невозможным), так как досконально разобрался в коде Монитора (так называлась операционная система или точнее низкоуровневая среда). Я тогда учился в старших классах.


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

Я почти такой же древний винтажный как и вы, Анатолий :)
Просто знаю секрет вечной молодости -- тоже своего рода ассемблер, по которому тикают часики.
Мне нравится хакать всё что можно и нельзя.

Консультант, Москва
Анатолий Курочкин пишет:
Васёк даже я не знаю (точнее забыл). А вы, видимо, не знаете, что такое ассемблер.

Про ассемблер я помню из далекого 1979 года команду BALR. Но вот Вы, Анатолий , помните ли команду в кодах (какие такие языки? Ассемблер - это просто "космос"!), например,  001 и сколько адресов должно следовать за ней (это еще М-220)? 

Кстати, смех смехом но на COBOL до сих пор работает немалое количество софта, как утверждают специалисты, коих совсем немного.

Аналитик, Москва
Сергей Средний пишет:
Анатолий Курочкин пишет:
Васёк даже я не знаю (точнее забыл). А вы, видимо, не знаете, что такое ассемблер.

Вы меня недооцениваете. Ну как же? Я писал на ассемблере под 580 процессор код в конце 80-х и начале 90-х. А на компьютере Микроша даже реализовал автозапуск программы после считывания её с кассеты (что по мнению многих экспертов журнала Радио считалось невозможным), так как досконально разобрался в коде Монитора (так называлась операционная система или точнее низкоуровневая среда). Я тогда учился в старших классах.


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

Ну супер!

Эрнст Мальцев пишет:
Анатолий Курочкин пишет:
Васёк даже я не знаю (точнее забыл). А вы, видимо, не знаете, что такое ассемблер.

Про ассемблер я помню из далекого 1979 года команду BALR. Но вот Вы, Анатолий , помните ли команду в кодах (какие такие языки? Ассемблер - это просто "космос"!), например,  001 и сколько адресов должно следовать за ней (это еще М-220)? 

Кстати, смех смехом но на COBOL до сих пор работает немалое количество софта, как утверждают специалисты, коих совсем немного.

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

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

Вон у Павла Дурова требуют раскрыть его билотеки. Он не даёт. Потому что полмира прогаммистов работают с чужими библиотеками. Кубики складывают.

По Коболу. Лет 10 назад мне предлагали работу с этим языком в Германии. Очень много старого софта на нём. Я, правда, отказался. Чужой код - хуже некуда. 

Researcher, Москва
Анатолий Курочкин пишет:
При этом я не призываю всем переходить на ассемблер, поймите меня правильно. Но не знать его, или хотя бы понимать, стыдно. Это кругозор, это глубина знаний. 

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

Анатолий Курочкин пишет:
Чужой код - хуже некуда. 

Это самое интересное.
Поэтому настаиваю: хотите найти хорошего разработчика -- посмотрите его код на ГитХабе.

Генеральный директор, Москва
Анатолий Курочкин пишет:
Он не даёт. Потому что полмира прогаммистов работают с чужими библиотеками.

Или больше. Но со времен ООП иначе уже не получается. Когда-то приходилось  частично переписывать библиотеки распространённых компиляторов для PC - там попадались ошибки в некоторых функциях.

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

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

Сергей Средний пишет:
Я писал на ассемблере под 580 процессор код в конце 80-х и самом начале 90-х

Насколько я помню, это К580? Это Intel 8080, еще 8-битный, там около 80 команд. Проблем с ним не было. Assembler IBM/360 был принципиально сложнее. И на этом список не заканчивается.

Сергей Средний пишет:
Поэтому настаиваю: хотите найти хорошего разработчика -- посмотрите его код на ГитХабе.

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

Консультант, Новосибирск

Интересная статья.

Тут, по крайней мере, не HR-менеджеры отбор делают.

Это радует!

Из форума программистов:
— Помогитенеработаетпробел!!!
— Настоящие_программисты_пробелами_не_пользуются!
(Шутка).

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Названы лауреаты «Премии Рунета 2024»

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

В Индии компания уволила всех сотрудников, испытывавших стресс

Так компания решила избавиться от стресса в команде. Под сокращение подпали более 100 человек.

Большинство россиян предпочтут 13-ю зарплату новогодним корпоративам

Четверть россиян относятся к корпоративным развлечениям негативно.

Япония перейдет на 4-дневную рабочую неделю

По задумке властей Японии, должна будет способствовать решению проблем с рождаемостью.