Java-программист в Петербурге. Обзор рынка труда с точки зрения соискателя. Часть 3/3. Какие бывают работодатели

    Часть 1/3. Какие бывают 'плюшки'.
    Часть 2/3. Подводные камни для «новичка».

    Какие бывают работодатели. Характерные особенности.


    Вместо краткого вступления, одну закономерность можно назвать сразу: чем длиннее и крупнее проект, тем древнее технологии. Хотите на практике освоить новые технологии — участвуйте в стартующих проектах длиной 3-6 месяцев.

    • Фирмы, работающие на Министерство обороны и подобные структуры.
      Секретность, используется относительно узкий набор технологий — которые сертифицированы в ФСБ. Например, Java 1.6 и Tomcat сертифицированы, а EJB-контейнеры не сертифицированы, вместо них может использоваться самописная недо-пародия. Что хорошего в самописных недо-пародиях — разработчик, что обычно рядом и доступен для общения, что плохого — какая-то мелкая функция, которая есть, но её пока (почти год) не использовали, но которая внезапно понадобилась тебе, — может просто тупо не работать (но можно заставить разработчика быстро починить).

    • Фирмы, разрабатывающие продукт на собственных, старых и кастомных платформах.
      Бывают и EJB 2.0 без аннотаций и собственные недо-ORM 1999 года выпуска (*)и прочие самописные недо-пародии и “системы, управляемые метаданными”. Самое плохое в этих платформах, с точки зрения человека, привыкшего оценивать платформы и языки в значительной степени по лёгкости рефакторинга (пишущие на PHP, Python, Ruby и NodeJS могут выказать недовольство, но я пишу в первую очередь про Java), — это отсутствие поддерживающих эти изобретения нормальных IDE-плагинов для редактирования этих управляющих метаданных не в сыром текстовом виде и недостаточный уровень средств отладки и диагностики этих систем. По последнему пункту — ну это как если бы виртуальная машина Java вместо бросания NPE с дампом стека просто бы падала из-за ошибки уже в самом своём бинарнике, вызванной попыткой всё же получить что-то там от объекта, который находился бы по этому неинициализированному указателю “в никуда” или «куда-то» или «непонятно куда» (через раз в новое место) (о безопасности, разумеется, при этом можно забыть), скупо что-то сообщая об этой вызванной входными данными ошибке в интерпретаторе — так что даже поиск ответа на вопрос “в каком месте метаданных (в данном случае в роли метаданных выступает программа на интерпретируемом данным интерпретатором языке) находится ошибка” может сам по себе оказаться нелёгкой задачей. Отдельный вопрос — качество кода с методами по 2000 строк и интенсивным переиспользованием переменных. Причина обычно проста: эти системы (точнее, их первые версии) написаны ещё до того, как понятие “качество кода” стало в России в ходу (а ещё и понятие «ORM» и представление о том как адекватно строить систему персистирования объектов).

    • Фирмы, работающие по заказам от гос- и муниципальных структур.
      Разные сочетания длительности проекта и новизны технологий. Практически неизбежна, на определённом этапе, интеграция через SOAP с серверами госведомств с геморроем на тему что делать с участком этой интеграции на стадии отладки и тестирования. Иногда строгий дресс-код с пиджаком и галстуком. Нередко требуется писать на других языках, кроме Java.

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

    • Фирмы, разрабатывающие софт (на Java) для работы на финансовых рынках.
      Ключевые требования к софту — быстрота (в частности, по части оптимизации под сборщик мусора) и многопоточность. Может требоваться разработка встроенного мета-языка то ли пере-настроек то ли недо-программирования.

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

      Качество кода — особый “пойнт”. Писать код нужно лучшего качества, чем программисты самого заказчика. Основное требование к качеству — чтобы не было в коде ничего такого, к чему можно было бы придраться, в основном сходу: чтоб никто из штатных работников заказчика не мог просто так подойти, ткнуть в какое-нибудь место в коде и с полным на то правом сказать “а чо за хрень они тут написали”. Бывает, дело доходит до требований писать комментарии к геттерам и сеттерам. Ещё момент: нужна овер-коммуникация — чтобы заказчик был (у)спокоен. Несколько напоминает ситуацию обращения с “VIP-пациентом в психушке”, но именно этот “VIP-пациент” и платит деньги.

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

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

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

    • “ИТ-компании”, обслуживающие итернет-тотализаторы.
      “Хитрая” работа с БД — без domain-объектов, с domain-методами и “голыми” идентификаторами, на зато быстро. “Экзотические” и малораспространённые web-фреймворки. Большая “текучка новичков” (испытательный срок проходит около половины принятых на работу) и некоторая ориентация рабочего процесса на эту большую “текучку новичков”.

    • “Программистские” отделы не-ИТ-компаний.
      Бывает разное. Самое плохое, что вы будете подчиняться распорядку рабочего дня предприятия, а не тому, который удобен для работы программиста. Особенно же “веселит” ситуация с соответствующими отделами компаний, держащих во внутренней сети компании (единой для всех предприятие) клиентские базы и прочую «чувствительную» конфиденциальную информацию, и этого из-за замороченных на безопасности. Там “рулят” безопасники. С их точки зрения нет понятия “разработчик”, а есть только понятие “сотрудник”. Представления у безопасников такие: Рабочая среда настраивается один раз и по запросу обновляется сотрудниками хэлпдеск… Каждый должен заниматься своим делом — программист программировать на предоставленном инструменте, техподдержка — поддерживать актуальное состояние ПО и решать технические вопросы пользователей, системные администраторы — администрировать инфраструктуру, а сотрудник отдела ИБ — контролировать соблюдение условий безопасной работы IT-сервисов предприятия. Заметим: «программировать на предоставленном инструменте». Т.е. чтобы не висеть у программиста “гирей на ногах”, пресловутый «хэлпдеск» должен не хуже, чем программисты, разбираться в “предоставленном инструменте” — средах разработки, виртуальных машинах, средствах работы с базами данных типа SQL Developer и прочем инструментарии. Ведь такая же картина с уровнем знания софта имеется в отношении других “сотрудников” типа секретарей, инженеров, юристов, продажников и снабженцев. Далее вопрос: зачем с такими скиллами работать в техподдержке, если программистом с ними же заработать можно больше? Поэтому нормальная, в общем-то, «техподдержка» для нормального, в общем-то, программиста непременно будет «дубиноголовым вахтёром», постоянно мешающим работать.

      Из-за этого в таких компаниях постепенно приходят к разумному выводу, что лучше «внутри» ничего не разрабатывать, разработку отдавать “вовне”, а «внутри» только ставить задания подрядчику, взаимодействовать с ним и готовить для него специально обезличенные “игральные” данные для отладки.

      Но ради строчки в резюме (хотя кто ещё из знающих реальный расклад на неё “поведётся”?) поработать можно…

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


    Вместо заключения.


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

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


    • Android-разработчики.
      «Тоже Java, хотя и не совсем Java». Растущий сектор рынка труда. Автор с этим сектором пока не соприкасался, хотя с технической стороной программирования по Android чуть-чуть знаком.

    • «Одноклассники», прочие социальные сети и другие высоконагруженные системы.
      NoSQL-базы данных, map-reduce-системы типа Hadoop, многоступенчатые собеседования с целью отобрать «лучших из лучших» (*). К этой же сфере относится часть сектора онлайн-игр — там через Hadoop с обработчиками «пропускаются» в реальном времени события, происходящие в игре (каждый отдельный игровой сервер генерирует свой поток событий).

    • Хостеры-сайтостроители-сайтодержатели с CMS.
      Как это ни могло бы на первый взгляд показаться странным, но CMS на Java всё же существуют. Как зарубежные лицензированные (с исходниками), так и полностью отечественные — в частности, на базе того самого «недо-ORM» 1999 года выпуска. Соответственно, и услуги Java-программиста там тоже бывают нужны — хотя бы для развития и модернизации CMS.



    Часть 1/3. Какие бывают 'плюшки'.
    Часть 2/3. Подводные камни для «новичка».
    Поделиться публикацией

    Комментарии 30

      +6
      Спасибо вам за труд! Я хоть и не java-разработчик, но все равно почитать было интересно.
        +3
        Просто прекрасно. Добавить к этому презентацию и получится шикарный вариант на конференцию.
          +4
          Что-то я не увидел в списке продуктовых фирм, которые делают и продают свой продукт. А ещё Android-приложения это тоже Java
            +2
            Меткая статья, некоторые замечания прямо за живое задели… С другой стороны, когда читаешь, кажется что жесть и как так можно вообще жить. А когда работаешь — то просто делаешь свое дело, по возможности качественно. Тогда и новые технологии внедряются на старых проектах, и с ИБ находится общий язык, и SOAP наконец-то работает с обеих сторон (а потом снова, и снова, с другими)… На «хорошем» месте работы познаешь одно, на «плохом» дополняешь свой опыт чем-то другим, а в результате понимаешь, что и то и другое одинаково важная часть тебя.
              +1
              Не совсем согласен с мнением автора. Во-первых, МО и ФСБ абсолютно разные ведомства. Если предприятие работает на Министерство Обороны, то ФСБ лишь выдает лицензию на проведение определенного вида деятельности и выпуска определенного вида продукции, например средств РЭБ. Кроме того, большинство требований как к софту, так и к железу, при правильном менеджменте легко обходятся. Проработал достаточно долго в этой макросистеме, поэтому утверждаю наверняка.

              «Фирмы-оффшорные разработчики» и «Аутсорсинговые фирмы» — как мне кажется, эти понятия идентичны, если мы не говорим о совсем мелком аутсорсе — веб-студии из четырех человек. Иначе — специфика одинаковая. В любом случае, процесс работы может отличаться, все зависит от требований заказчика (или, как говорят «от проекта»). Ситуации могут быть самыми различными — от микроменеджмента клиента с работой девелоперов через RDP на машинах клиента до полнейшего пофигизма и заинтересованности лишь в конечном продукте.
                +2
                По первому абзацу: насколько я знаю, «военная» Java сертифицирована в составе одного программного изделия как его компонент, сертифицирована в виде исходников на C. Собирается из них при помощи открытого компилятора (вроде как GNU C). Требование, как мне объясняли, — чтоб программное изделие собиралось из предоставленных либо открытых исходников по предоставленной инструкции. Ну и исходники анализируются в ФСБ на предмет отсутствия разных «сюрпризов», вроде как на правах платной услуги. Разумеется, исходники секретятся.

                По второму абзацу насчёт идентичности 1) поправил формулировку 2) нередко те, кто сдаёт персонал в аренду, занимаются и оказанием услуг по аутсорсной разработке — натренируют, проверят, посмотрят персонал на чужих проектах, и сами потом берут заказы и запускают проекты. Тоже дополнительная свобода манёвра. Но даже в рамках одной фирмы эти направления деятельности пересекаются не так сильно, как кажется.
                  +2
                  В смысле, предоставленные исходники секретятся…
                –1
                Свеном ты?
                  +3
                  Хм… А где же софтверные компании где и технологии новые и задачи интересные, а также платят хорошо и относятся тоже не плохо? Где собственно профильные софтверные компании которые разрабатывают топовые продукты? Ведь они тоже есть и если вы программист, логично было бы стремиться именно туда.
                    +3
                    «технологии новые и задачи интересные» если делать что то самому… а так, у всех фирм свои вальты…
                      0
                      нет, есть фирмы которые заинтересованы в решении задачь, развитии своих программистов и тд. Вот к примеру в компании, где я работаю, положительно смотрят на инициативы вносить какие-то новшетсва в проект (технологии, библиотеки, фреймворки), если эти новшетсва ускоряют процесс разработки или делают приложение более стабильным, в общем как-то улучшают текущее положение дел.
                    +2
                    Мда… я не очень силён в рынке Украины, но судя по DOU у нас здесь всё просто — все работают на аутсорс иногда с с элементами аутстафа в ИТ-гигантах по 2-3к человек в компании. И есть сотня фирм поменьше. Редко кто занимается своими продуктами. Честно говоря, все описанное, а особенно собственные ORM 1999 года меня крайне напугали. Теперь понимаю, что грех жаловаться на говнокод от америкосов, когда есть ещё «безопасник-вахтёр»

                    Кстати, автор, последний пункт «Фирмы, сдающие персонал в аутсорс» это, судя по описания out-stuff когда фирма предоставляет своего «сотрудника» другой компании и он почти полностью подчиняется той компании (почти как работорговля). А аутсорс это когда фирма получает заказ от компании и сама решает, как реализовать бизнес-задачу, у вас это идёт под «Фирмы-оффшорные разработчики».
                      0
                      В Украине всё примерно так же, как в России. Тот же спектр от фабрик-аутсорсеров типа EPAM и Luxoft до гаражных студий и Приватбанка. Другое дело, ещё относительно недавно многие работали «подпольно» из-за весёлого законодательства, регулирующего зарубежные финансовые вливания, потому особо себя не рекламировали. Ещё был не менее весёлый этап, когда органы толпой вламывались в офисы и проверяли софт на лицензионность, что тоже не добавляло желания высовываться.
                      +1
                      недо-ORM 1999 года выпуска
                      Позиционируется не как ORM, а как «хранилище данных» (в терминологии производителя). Имеет возможность динамического изменения набора атрибутов сущности (с «пробрасыванием» соотв. изменений в «физический» слой хранения, в частности, для БД — с выполнением команд из серии ALTER TABLE, при этом перегенерация или перезагрузка каких-либо Java-классов не требуется) и встроенный механизм миграции данных («пообъектно», с настройкой механизма резолвинга значений атрибутов типа «ссылка на объект другой сущности» и широкого использования механизма глобальных уникальных идентификаторов) между узлами. Также имеет возможность использовать в качестве «физического» слоя хранения SOAP-сервис и, наоборот, предоставлять данные в своём хранилище БД-типа в качестве такого SOAP-сервиса, что позволяет даже «каскадировать» узлы в качестве части «SOAP-цепочек хранилищ».
                        +1
                        В общем, концепция по возрасту не сильно отстаёт от мейнстримной концепции Java-ORM и развивалась параллельно ей с упором на несколько другие цели.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          +1
                          Автор в 2011 году собеседовался в «Одноклассники», на первом этапе успел привильно ответить на 18 вопросов из 20, на следующий этап не пригласили. Одну задачку из оставшихся двух (правда, ответ на неё надо было выбрать из 5 вариантов, что теоретически позволяло частично догадаться и уложиться в средние 2 минуты) — про выбор перчаток разного цвета из ящика — автор потом решил двумя способами: первый — «в лоб» — никак не мог бы занять меньше 10 минут даже в самом лучше случае, второй, из серии «надо на одном из этапов посмотреть под другим углом» — позволял решить устно за 2 минуты. Не говоря о варианте «догадаться по экзотическому знаменателю, отметя всё заведомо неподходящее».
                            +3
                            Ну и как, собственно, эта информация связана с постом?
                              +1
                              Это примечание к нему.
                            +4
                            Насчет «Программистские» отделы не-ИТ-компаний", расскажу свою историю: полгода назад повелся на уговоры HR и устроился в подобную организацию в нефтянку, в отдел научно-технического развития, на внутренний проект. Проект начинался с нуля и взяли двух программистов для начала. За время разработки столкнулся с несколькими проблемами:

                            1) Рулят действительно безопасники. Чтобы установить любую, мало-мальски значимую тулзу, приходится выдерживать кучу бюрократии и ждать недели, а то и месяцы, пока тебе ее согласуют и установят. Админские права ждем до сих пор, а установка по — только через сервисный отдел.
                            2) Интернет полностью закрыт, ютубы, блоги, и прочее, доходит до смешного, когда невозможно скачать какую-либо информацию по работе или необходимый софт.
                            3) С покупкой ПО тоже дела обстоят не очень, четыре месяца пришлось работать на своем ноуте, потому что согласовывался и закупался софт для разработки
                            4) Второго программиста взяли без всякого согласования с умениями и навыками первого, о психологической совместимости и речи не шло, поэтому проект пришлось разрабатывать в одиночку, тогда как я надеялся на помощь, развитие отдела и командную работу
                            5) Полная незаинтересованность начальства в процессе разработки, какие-то попытки выстроить agile разбились о стену бюрократии
                            6) Принципы работы организации — строгая иерархичность и подчинение, хотя мы с коллегой и уходим вовремя, сделав работу, многие сидят на работе до последнего, пытаясь показать, какие они хорошие работники, а нас считают бездельниками.
                            7) Никаких плюшек и строгий распорядок дня, начало работы в 9.

                            Несмотря на это, мы все-таки пока стараемся вести проекты и доделать их до конца, но учитывая все эти минусы, работать в подобной организации по завершении проекта уже не очень-то и хочется, несмотря на белую зарплату и… хм, ну в общем-то и всё.
                              +3
                              Простите за нетактичный вопрос. Что дают взамен за такое? Сильно больше зарплата, чем в среднем по отрасли?
                                +3
                                Да я бы не сказал, что больше. Все мы делаем ошибки, но дело, не доделав, бросать неохота и резюме портить, а то скажут — несерьезный, летун итд. Да и была возможность лучше изучить .net, пока идет проект.
                                +3
                                Шикарные условия работы создают себе менеджеры — люди приближённые к руководству. Так исторически сложилось, что в IT-компаниях менеджеры и разработчики кода это одни и те же люди.

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

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

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

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

                                    Адекватные люди распределены поровну среди представителей любых специальностей.
                                      0
                                      Производительность — здесь ключевое слово.

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

                                      Следующему программисту вы окажете большую услугу, если он будет реинженерить ваш проект. Руководство будет вынуждено платить ему больше, если хочет, чтобы проект вообще работал. Вопросы этики рассматриваем там, где этика есть в голове у менеджмента.
                                    +4
                                    Это ад… беги оттуда
                                      +1
                                      Я работал в нескольких не-ИТ компаний. Степень паранойи безопасников варьируется. На последнем месте были и права админа, и интернет (кроме торрентов), но вот график работы был всегда «от звонка до звонка».
                                        0
                                        четыре месяца пришлось работать на своем ноуте
                                        Безопасники разрешали? Свой интернет в виде личного модема можно было использовать?

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

                                      Самое читаемое