За что могут уволить программиста

Опубликовано: 19.09.2024

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

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

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

Алексей Резвов, больше 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). За нарушение этих пунктов контракта конечно же увольняют, и в придачу отсуживают у бывшего работника много денег.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Даже самый хороший программист может оказаться далеко не лучшим сотрудником. Несмотря на то, что сейчас айтишники любого уровня вполне востребованы, и на рынке огромное количество вакансий, периодически увольняют и ведущих разработчиков, и даже самых «крутых» senior’ов. Давайте разберемся в основных причинах.

«Почивает на лаврах»

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

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

Увлечение кодом и «самоуправство»

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

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

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

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

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

Безответственность и саботаж

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

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

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

Неумение работать в команде

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

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

Вот основные варианты действий таких разработчиков:

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

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

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

Негативизм и токсичность

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

Скорей всего, вы тоже знакомы с такими людьми:

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

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

Неорганизованность при удаленной работе

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

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

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

Как избежать увольнения

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

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

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

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

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

Его уволили за то, что он соврал об этом. Вот так просто.

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

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

Очень глупый вор

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

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

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

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

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

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

Хотел как лучше…

Я работал архитектором в Microsoft, мы делали прототип медицинской системы для британской государственной службы здравоохранения (UK NHS). В проект входили в частности геозапросы на поиск ближайшей подходящей для пациента клиники. Я должен был реализовать в картографическом сервисе MS вычисление расстояния по GPS-координатам.

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

Оказалось, он решил, что картографический сервис MS недостаточно хорош, поэтому написал гениальный алгоритм для вычисления наикратчайшего расстояния на сфере по прямой линии.

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

Я уволил того разработчика по трем причинам:

Игнорирование прямых указаний руководителя проекта (то есть меня).
Обеспечение бесполезной альтернативы.
Бесцельная трата ограниченных ресурсов — денег и времени.

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

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

Их не очень умный админ настроил IE так, что любой желающий мог выполнять пакетные команды. Руководство оставалось глухо к моим жалобам или отвечало «О, нельзя этого сделать, это невозможно». Это подтолкнуло меня на глупый поступок.

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

Вскоре после этого (спустя считанные часы) мой компьютер внезапно заблокировался. У нас была эта реально тупая программа, которая мониторит, сколько ударов по клавишам ты сделал за час, и вылогинивает тебя на пять минут, чтобы ты поделал какие-нибудь упражнения. Я подумал, что это оно. Но через пару часов за мной пришел HR.

Я работал в e-commerce компании, где нам дали задание добавить еще один метод оплаты. У нас была встреча с разработчиком, которому это поручили.

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

На встрече я объяснил проблему СТО и тому парню, и все трое согласились на быстрый рефакторинг одного файла, чтобы упростить проблему на будущее.

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

Обматерил босса в коде

В дни SourceSafe один наш коллега написал в коде комментарий с упоминанием босса в стиле «Джон м**озвон», и наш босс каким-то образом увидел это, думаю, на консольном сервере. Его тогда уволили, указав причиной очень непрофессиональное и неэтическое поведение.

Стал причиной военной облавы на компанию

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

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

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

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

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

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

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

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

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

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

Как вы думаете, а все-таки возможно увольнение программиста только за его плохие soft skills?

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

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

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

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

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

Один UI/UX дизайнер, который работал в American Airlines, в переписке со своим знакомым (который по совместительству клиент авиалиний) рассказал, какие проблемы есть у компании, как они их решают и как сложно работать в больших компаниях.

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

Неправильное суждение может принимать различные формы, такие как:

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

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

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

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

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

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

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

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

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

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

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

Сознательная ложь, особенно “в лицо” или в отчетах, и любая кража также приводят к плачевным последствиям. Обычно караются штрафами, взысканиями и испытательным сроком.

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

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

Унижение коллег, просмотр сайтов для взрослых и другие распространенные ошибки программиста могут лишить вас места работы – будьте вежливы, внимательны и предельно осторожны!

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