За что могут уволить программиста: опыт и мнение экспертов
2026-02-26 15:11 Diff
https://ru.hexlet.io/blog/posts/za-chto-mogut-uvolit-programmista-opyt-i-mnenie-ekspertov

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

Важный момент: сразу несколько специалистов отказалось участвовать в опросе из-за деликатности вопроса.

Содержание

Алексей Резвов: увольнял, если сотрудник не соблюдал договорённости или был недостаточно компетентным

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

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

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

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

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

Итак, случаи, в которых увольнял сотрудников я.

Сотрудник не соблюдает наши договорённости

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

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

Вместо опозданий в этот алгоритм можно вписать многое: несоблюдение style guide, игнорирование инструкций по работе с продом, грубое поведение при общении с коллегами, срыв сроков сдачи задач (по оценке сотрудника же) и тому подобное. Было даже появление на рабочем месте в пьяном виде в совокупности с опозданиями однажды. Действия такие же: предупреждения, разговор, последнее предупреждение, увольнение.

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

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

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

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

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

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

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

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

Анна Ишмухаметова: увольняют из-за некачественного продукта или неспособности адаптироваться к культуре компании

Анна Ишмухаметова, Software Development Engineer в Energi Cryptocurrency.

Причины для увольнения могу быть такими:

  • В одной канадской компании уволили разработчиков из-за «политического» решения сократить отдел разработки. Продукт был неудачным, уволили руководителя отдела и его команду.
  • Опыт китайской компании: уволили разработчика, так как он был изгоем в команде. Не смог адаптироваться к культуре компании.
  • Опыт австралийской компании: увольняют из-за недостаточной экспертизы, плохого качества кода.
  • Ещё одна причина — непоследовательность, недостаточный вклад в общее дело.

Артём Алейник: равнодушие, оторванность от бизнеса, неумение общаться — смертные грехи разработчика

Артём Алейник, руковожу отделом разработки интерфейсов в Текстерре.

Отвечая на этот вопрос, я не буду приводить д��журный довод «все может зависеть от обстоятельств/бизнеса/кадровой системы/популяции сусликов в Казахстане на текущий год/еще миллиона причин». Фактор специфики всегда имеет место, и от него никуда не денешься. Уверен, уважаемые читатели и так это понимают. Поэтому я приведу то, что сформулировал, основываясь на личном опыте.

Равнодушие к результатам своего труда

Если сотрудник работает на должности разработчика, это уже подразумевает, что он должен в процессе выполнения своих обязанностей задаваться какими-то вопросами:

  • Зачем это делается?
  • Почему именно так?
  • Можно ли упростить?
  • А кто будет работать с результатами моего труда на следующем этапе?

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

Оторванность от бизнес-процессов

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

Неразрешимые проблемы в коммуникациях

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

Александра Шинкевич: разработчика можно уволить за нарушение юридических соглашений

Александра Шинкевич, Lead full-stack Node.js разработчик. Соорганизатор митапов MinskCSS и MinskJS, и конференции CSS-Minsk-JS.

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

Разработчика, как и любого другого наемного сотрудника, можно уволить за нарушение юридических соглашений. Например, условий договора/контракта, трудового кодекса или других законов. К таким нарушениям могут относиться систематические прогулы или невыполнение поставленных задач. Речь не идет о том, когда джуниору дали задачи уровня Senior, и он — кто бы мог подумать — не справился (спойлер: в этом случае виноват в первую очередь тот, кто поставил ему такую задачу и вовремя не заметил несоответствие компетенции). Нет, для официального увольнения должны быть действительно веские причины, прописанные в договоре или ТК страны, где работает разработчик. В этом плане официально устроенный разработчик защищен со стороны государства, так как его нельзя просто так взять и уволить.

Более грустная, как мне кажется, история — это когда разработчик не оправдывает ожидания. Такое бывает не так уж редко. Многие IT-компании набирают разработчиков и сами их «растят»: проводят тренинги, внутренние митапы, мастер-классы, практикуют менторство и так далее. И вполне логично, что не все могут или хотят развиваться в том темпе, в котором от них ожидается. Или наоборот — overqualified, то есть разработчик «слишком хорош» для тех задач, которые выполняет. В обоих случаях получается, что для таких сотрудников нет подходящих задач, ведь для первого все слишком сложно, а для второго — слишком легко и скучно. Часто во втором случае разработчик сам понимает, что ему пора искать другое место работы, если перспектив роста у текущего работодателя больше нет.

Как поступают, когда официальных поводов для увольнения нет, а уволить очень хочется? Ждут окончания срока контракта или договариваются. Работодателю невыгодно портить свою репутацию как HR-бренда. Варианты могут быть разные: от денежной компенсации до рекомендации компании-партнера, куда можно устроиться увольняемому разработчику. Все зависит от условий заключенного трудового договора, размера компании, области деятельности и ещё сотни факторов.

Михаил Ларченко: причины для увольнения могут быть абсолютно разные

Михаил Ларченко, работаю техническим руководителем в компании Sytac B.V. Аккаунт в Twitter.

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

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

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

Иван Акулов: найти нового человека, нанять его, ввести его в проект — очень дорого

Иван Акулов, фронтенд-разработчик, автор канала в Telegram.

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

Как можно помочь человеку?

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

Зачем тратить на это время?

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

Что насчёт увольнений за катастрофические ошибки?

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

Евгений Обрезков: на первом месте среди причин увольнения находятся плохие soft skills

Евгений Обрезков, Senior Software Engineer. Аккаунт в Twitter.

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

Начну с самой частой причины. Обычно работодатели говорят «не сработались», «не сошлись характерами», «тяжелый человек», «с ним было трудно работать» и тому подобное. Все они, обычно, скрывают под собой одну причину — плохие soft skills. Что подразумевается под soft skills? Это способность человека вживаться в команде, взаимодействовать с людьми. Все эти люди с разными характерами, принципами, амбициями. Довольно часто на этой почве могут возникать конфликты между членами команды. Так вот, человек с хорошими soft skills сможет найти решение, найти общий язык с людьми, нивелировать конфликт. Люди же с плохими soft skills будут наоборот подливать масла в огонь, разжигать. Они это могут делать даже неосознанно и не специально, вот они такие просто есть, «со своим характером». Поэтому будьте хорошим и адекватным человеком, который готов принять фидбек не на личный счёт и обидеться на всю команду, а отталкиваться от него и рефлексировать, стараясь стать лучше. И вам не придется слушать от работодателя фразу «не сработались».

И уже после идут причины технического характера (hard skills). Они случаются реже всего по моему опыту. Это когда человек хороший, команда с ним сработалась, всё прекрасно. Но вот он никак не может изучить проект, не может понять, что в нём происходит, постоянно задаёт одни и те же глупые вопросы без каких-либо видов на прогресс. Тут начинают люди себя спрашивать: «А есть ли польза от него, если он за всё это время так и не смог разобраться?»

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

Хотелось бы ещё сказать, что ситуации у всех уникальные, и какого-то списка правил, по которым работодатель увольняет своих сотрудников, нету. Всё, что мы можем, это пытаться обобщать эти уникальные ситуации и находить общие признаки. Но если вы попали в ситуацию, что вас хотят уволить — лучше не ищите советов в интернете, а поговорите со своей командой, со своим работодателем и попытайтесь решить проблему индивидуально. Скорее всего, вы найдете корень всех зол и придумаете компромиссное решение в этой ситуации. Спасибо за уделенное время :-)

Дмитрий Горячев: у нас увольняют только неадекватных

Дмитрий Горячев, Senior Software Engineer в Kofax.

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

Дмитрий Ивахненко: если человек скрывает косяки, его можно уволить

Дмитрий Ивахненко, работаю в Uploadcare.

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

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

Роман Слободенюк: на моей памяти ни одного программиста не увольняли

Роман Слободенюк, инженер-программист в «Инфотекс».

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

Аноним: сотрудников нельзя увольнять без консультации с юристом

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

Лев Солнцев: причины могут быть разными — от разглашения внутренней информации до каналов с мемами в чате

Лев Солнцев, фронтенд-разработчик.

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

Антон Немцев: наиболее серьезными являются проблемы, которые влияют на работу других людей

Антон Немцев. О себе:

  • независимый разработчик на протяжении 16 лет. Продался корпорациям;
  • Jack of all trades, master of none. Скорее последнее;
  • создатель и главный редактор Frontender Magazine. Всё про*рал;
  • докладчик на международных и поместных конференциях. Чем дальше, тем поместнее.
  • эксперт UA Web Challenge. Бывший.

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

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

Ожидания могут быть в самых разных областях:

  • профессиональные ожидания;
  • качество коммуникации;
  • соответствие культуре компании;
  • ...

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

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

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