Комментарии 70
Через 1 месяц: настроите среду разработки, разберетесь, где все лежит, познакомитесь с коллегами;
Через 3 месяца: закончите первые задачи, сами выкатите что-то в продакшн, что-то почините в продакшн;
Какие… интересные ожидания.
По моему опыту на первый пункт нужен не месяц, а неделя максимум, чаще дня 3-4 (разумеется, речь не о всём коде компании и не о всех сотрудниках, а только о той части кода/коллег, знакомство с которыми актуально для выполнения задач в ближайшие пару месяцев). Разумеется, чтобы была возможность быстро вкатиться в работу новому сотруднику в компании должны быть подготовлены нужные ему документы и поставлен процесс онбординга, чтобы у нового сотрудника не возникало необходимости задавать кучу тривиальных вопросов коллегам, ждать пока они найдут время ответить, да ещё и сначала побегать в поисках кому конкретно нужно задать каждый вопрос.
А первая задача должна быть смержена недели через две максимум, это при условии достаточно жёсткого ревью с 2-3 раундами фиксов в процессе ревью.
Вы просто не работали никогда в по-настоящему больших компаниях.
Это правда. Так и в статье ведь тоже речь не о FAANG.
Я один раз месяца полтора ждал заведения учёток. Задач не было, сидел, учился, фрилансил, получал зарплату. Большая компания. Потом получал по неделе разрешения на установку IDE и прочих утилит, с высочайшего одобрения. То, что в это время работа стояла, тоже никого не волновало, зарплата выплачивалась в полном объёме.
Контроль доступов никак не связан с временем его выдачи. А если связь и есть, то она скорее обратная - чем выше контроль, тем быстрее доступы выдаются (потому что поставлены процессы, известно кто их выдаёт, как их выдавать, и руководитель подаёт типовую заявку на выдачу для каждого нового сотрудника).
А вот если в компании вместо нормальных процессов наросла излишняя бюрократия, либо процессов нет и там бардак - тогда да, выдача может сильно затянуться.
А где гарантии, что после увольнения доступы закрывают сразу же, а не через неделю-две? Или вообще забывают про это?
О случаях вроде «вам приходит сообщение, что в компании увольнения и всем кому пришло это письмо уволены», и доступы при этом тут же заблокированы, чтобы люди не могли нанести ущерб, на моей памяти не доходило
По моему опыту работы в банке из Топ-10, сотрудник приходит сразу на комп, где подключены все учетки (сетевая, телефония, тестовые сервера). До боевых серверов доступа нет и не будет у рядовых разработчиков. Установкой поставок на прод занимается только сопровождение после того как поставка проходит все этапы тестирования.
Новому сотруднику нужно только оформить ряд заявок на доступы к различным ресурсам (гит, джира, конфлюенс, артифактори, дженкинс и т.п.) но все это занимает 1-2 дня - выдается памятка какие заявки надо заполнить (это все на специальном внутреннем ресурсе делается путем заполнения форм), выполняются они максимум за день.
Основной инструментарий весь уже раскатан на машине из стандартного образа. Недостающее ставится со внутренних ресурсов, все расписано в памятке и разделе "новому сотруднику" в конфлюенсе.
Испытательный срок - 3 месяца. Но это больше обучение (специфика наших команд в том, что "готовых" разработчиков под используемую платформу практически нет - их в стране немного и в целом большинство так или иначе знакомы между собой) - освоение платформы, технологий. Первый месяц - учебные задачки под руководством ментора. К концу обучения человек уже способен решать несложные боевые задачи.
Так что "испытательный срок" тут - обучение + стыковка с командой. Оплата 100% Единственное ограничение - бессрочный контракт на 100% вступает в силу по окончании испытательного срока и тогда же оформляется соцпакет.
Раньше работа была 100% в офисе. Но это связано со сложной политикой в области ИБ (в частности, доступа даже к тестовым серверам только из внутренней сети, которая на 100% изолирована от внешнего мира - даже в инет не выйти с рабочего компа, только через специальный "безопасный браузер" который работает через виртуалку). Но с карантином сопровождению пришлось напрячься и организовать возможность удаленной работы для всех. Организовали. Не все просто, но в целом работает. Более того, это признано удачным решением и теперь режим работы "временно удаленный". Т.е. каждые полгода в САП оформляется заявка на удаленную работу и все работают по домам. Хотя при желании никто не запрещает приходить в офис и работать там (бывает что просто договариваемся собраться в какой-то день в офисе всей командой). Единственное ограничение - работа только с территории РФ. С нероссийских адресов никакого доступа не будет. Ну разве что сидеть за рубежом, а в банковский VPN входить через VPN с российским сервером.
В принципе, у банка есть коворкинг в Сочи. Можно заказать себе на неделю-две и уехать туда.
Учет рабочего времени не ведется. Есть задачи, у каждой есть срок. Укладываешься в срок - больше от тебе ничего не требуется. Какого-то вот прям "рабочего времени" как такового нет. Понятно, что очень нежелательно пропадать и быть недоступным по каналам связи в течении рабочего дня, но вполне возможно предупредить "у меня тут прям край как приперло, завтра до обеда недоступен буду".
Авралы бывают, но крайне редко. Есть если крайняя необходимость работы выходные - оформляется заявка на работу в выходные за двойную оплату. Но у меня за пять лет это было всего один раз когда пришлось субботу-воскресенье поработать (и то все это вылилось в что в субботу более-менее полный день работа, а в воскресенье только после обеда пришлось посидеть немного, но зачлось все как два полных дня).
При удаленной работе можно заказать ноут, можно на своем работать. Можно попросить второй монитор - дадут вынести из офиса домой. Но я лично предпочитаю иметь все свое.
По отпускам единственное требование - один из периодов не меньше 14-ти дней. Я обычно разбиваю 7+7+14. В конце года расписываешь график в САП, он утверждается и все. Остальное все само происходит.
В целом все процессы выстроены и автоматизированы без лишних бумажек и бюрократии.
Пересмотры з/п регулярны и ощутимы (лично у меня сейчас, спустя 5 лет работы, з/п более чем в три раза выше той, на которую пришел). Вся з/п 100% белая, приписана в ТД. Бонусы - отдельно, раз в квартал, 15% от квартальной з/п с учетом личного КПИ (оценка руководства по результатам работы). Опять же, лично у меня стандартный КПИ 1.05-1.10. В целом получается где-то половина месячной з/п бонусом раз в квартал (+2 з/п в год набегает).
В каких-то исключительных случаях, за выполнение чего-то экстраординарного, может быть дополнительная премия от руководства (плюсом к квартальному бонусу). Тоже как-то раз такое было, совершенно неожиданно пришел бонус в два раза больше ожидаемого - сказали что отдельная премия за "вот ту задачу".
Так и живем...
Спасибо за развернутый ответ!
Можете рассказать, от чего зависит КПИ, какие показатели?
Выполнение поставленных задач в первую очередь.
Т.е. задачи на разработку приходят постоянно. Их раскидывают по разработчикам. У каждой задачи есть свой срок выполнения.
Если хочется повышенной оценки - нужно еще что-то сверх "проектных" задач делать. Какое-то саморазвитие, "проактивность". Развитие внутренней кодовой базы, например. Есть достаточно много наших внутренних библиотек для общего использования в которые все понемногу вкладываются.
Может быть решение какой-то особенно сложной или особенно важной задачи. Или какое-то решение, дающее особый профит для бизнеса...
В приличных домах безопасник и сисадмин подписывают обходной лист.
Да, в больших компаниях рабочий e-mail настроить могут только через неделю...
Всё верно. Только вот "вводное время" должно завершаться первым мержем, а не "познакомился с коллегами и настроил IDE". Именно первый мерж показывает, что новый сотрудник "вошёл в проект" в достаточной степени, чтобы ему можно было выдавать (хотя бы простые) таски. Именно первый мерж - является DoD (definition of done) для задачи онбординга нового разработчика.
Мерж или ребейз?)
Вообще к теме это не относится, но мы практикуем squash. Это позволяет разработчикам не заморачиваться описаниями отдельных коммитов (потому что финальное описание формируется в момент мержа, и вот оно уже пишется аккуратно по conventional commits) и при этом иметь чистую историю в master.
Ну коль к теме не относится...
У нас практикуется так - в master лежит то, что уже установлено в пром. В develop то, что прошло стадию компонентного тестирования (ITTest) и ушло на бизнестест. Тут есть правило - на этапе компонентного тестирования поставку можно править, после уже нет - нужно делать новую.
feature - текущая поставка. На этапе разработки коммиты можно плодить сколько угодно. Когда разработка закончена, очень желательно все коммиты объединить в один (это упрощает ревью PR). Дальше создается PR feature->develop, поставка собриается в артифактори для последющего развертывания в юниты компенентного тестирования и переходит в статус ITTest
После успешного завершения компонентного тестирования поставка передается на бизнестест (в соотв. юнит). К этому моменту должно быть сделано ревью кода, аппрув PR и о мержится в develop.
После установки поставки в бой develop мержится в master.
Такая вот схема сложилась у нас.
Да, согласен на 100%, что хорошо бы сократить время, которое требуется, чтобы начать "приносить пользу". Просто привел пример, как такое описание может выглядеть без привязки к идеальному варианту. Но, наверное, мне нужно было бы более гибко написать, т.е. спустя 1 месяц человек со всем разберется (но может и в 1й день работы), а спустя 3 месяца уже точно выкатит что-то (т.е. это может произойти на 1й день работы, главное, чтобы не позднее 3 месяцев). Про онбординг тоже верно, чем лучше процессы налажены, тем быстрее новый человек вливается в работу.
Ну вот на текущей работе все нужные учетки и права выдали сразу. При этом два месяца у меня не было вообще никаких обязанностей по ведению текущих проектов. Проходил различные тренинги, знакомился с коллегами и процессами компании - и это обычная практика онбординга в организации.
А так, в небольшой фирме обычно да - 3-4 дня и поехали.
Тут как повезет - бывает, что достаточно подписать некоторое соглашение о
том, что ваши проекты не помешают бизнесу компании (если вы работаете
над платным приложением для учета финансов, то нельзя будет пилить такое
же, но бесплатное приложение). Так же хорошо учесть, кто будет являться
собственником продукта интеллектуальной деятельности, чтобы потом не было проблем с лицензией для вашего опенсорс-продукта/сервиса.
Вроде же по российским законам, если продукт разработан по собственной инициативе, не как служебное задание, и, тем более, если это делалось на собственном компьютере и не в рабочее время — то это однозначно собственность разработчика?
Скорее всего да, но хотите ли вы защищаться в российском суде ?
Если настроение работодателя знать заранее, то можно просто избежать всей ситуации.
Скорее всего да, но хотите ли вы защищаться в российском суде ?
Если стороны "прописаны" в России - то в нероссийском суде рассматривать спор им и не светит.
Если настроение работодателя знать заранее, то можно просто избежать всей ситуации.
Не гарантия - настроение может и поменяться. Что и случилось в деле nginx. Но краткосрочную оценку адекватности работодателя - может показать.
Гарантию даёт только отсутствие документов, в которых работодатель может на такое претендовать.
Внимательный к вашим open source активностям работодатель при необходимости может подложить вам такой пункт позже - в кипу новых доп.соглашений про корпоративную этику, правила безопасности и т.п.
Может, может. Это один из примеров "смены настроения". Потому терять бдительность нельзя никогда.
И заодно если и верить рекрутёру на слово, то только заверенное подписью и печатью.
Подпишите уведомление, - сленговое выражение кадрового отдела, сопутствующее необходимости подписи документов, предполагающих обязательное, осознанное согласие работника.
Так я ж не спорю, что такое сплошь и к ряду. Но тем более верить рекрутёру на слово нельзя, только документу... И любой документ обязательно читать перед подписанием, причём если что-то непонятно или подозрительно - то верить разъяснению не кадрового отдела, а доверенного юриста.
А вот бодаться при этом или тихо линять при появлении неадекватности - тут уже каждому решать самому.
Вроде же по российским законам, если продукт разработан по собственной инициативе, не как служебное задание, и, тем более, если это делалось на собственном компьютере и не в рабочее время — то это однозначно собственность разработчика?
вообще да, но:
- следствие глобализации - человек пытается распространять на свой случай ситуацию в других странах (отчасти полезно: в плане проверки адекватности работодателя, а то если он сам делает то же самое, но в своих интересах и в ущерб интересам работника - то, возможно, работодатель неадекватен)
-с сотрудником может подписываться куча документов и существовать куча локальных нормативных актов, а анализировать весь этот ворох самому или с юристом перед трудоустройством - хочется не всем. (отличие от предыдущего вариант - к подписанным соглашениям может быть применим принцип свободы договора, т.е. если заключил сделку с работодателем без принуждения со стороны - сам дурак).
На последнем месте работы - неделя на настройку и то до сих пор работает сикась-накось и я так понимаю у всех так же. Вторая неделя - первый мерж в прод. Такое ощущение что чем крупнее компания, тем больше народу делают меньше или столько же вещей, чем в более мелкой компании.
Я бы сюда добавил вопрос про различные ограничения в контракте. А лучше вообще попросить контракт почитать.
Я не задал такой вопрос когда в последний раз менял работу (аутсорс) и потом, уже после увольнения с предыдущего места, неприятным сюрпризом стал пункт в контракте "работник не имеет права в течении 5 лет после увольнения работать в компании клиента без согласования с руководством" (как-то так, суть ясна). Не уверен что там с юридической силой такого пункта в локациях расположения компании и ее партнеров (США, Европа), но я бы хотел знать о таких вещах до оффера.
Не уверен, что это применимо к миддлам, и уверен что вряд ли применимо к джунам, но для сениоров и выше все такие пункты договоров всегда можно было согласовать или убрать. Если компания отказывалась пункт убрать, то обычно его можно было достаточно сильно ограничить (по времени действия и/или по области применения), чтобы он не создавал реальных проблем. Да, для этого договор надо было внимательно читать, и да, нужно отстаивать важные для себя пункты, но компания почти всегда идёт навстречу.
Это лишь пример из личного опыта.
Однако же вопрос "можно почитать контракт?" стоит задавать и мидлам, и джунам тоже. Кто его знает что в него добавили, те же конские штрафы за досрочное расторжение. Тогда, как минимум, будет еще не поздно задуматься "а точно ли оно мне надо?".
На самом деле думать тут вообще не о чём. Если в договоре какая-то фигня, и компания не хочет идти навстречу и её исправить приемлемым для всех сторон способом - договор не стоит подписывать в принципе. По крайней мере если есть уверенность, что получится найти другую работу, что в нашей области не проблема для всех кроме джунов.
Тут зависит от страны, по законодательству РФ действие договора заканчивается в момент увольнения и данный пункт противоречит Конституции (Письмо Министерства труда и социальной защиты РФ от 19 октября 2017 г. N 14-2/В-942 О дополнительном соглашении о неконкуренции), так что можно не обращать внимание на него, суды отклоняют такие иски.
работник не имеет права в течении 5 лет после увольнения работать в компании клиента без согласования с руководством
А иначе что будет?
На самом деле, включение подобного пункта всегда предполагает определённую компенсацию. Компания продолжает платить работнику деньги после увольнения за то, что он не работает на конкурентов. Если работник нарушает это условие, то должен вернуть деньги.
На мой взгляд очень важно узнать больше про процессы. Это лучше делать на поздних этапах отбора, и лучше с потенциальными коллегами. Кто придумывает задачи, как их спускают разработчикам. Кто фиксирует definition of done, как тестируются выполненные пункты. Как работает команда - по спринтам или от релиза до релиза, и в связи с этим как набирается скоуп. Как дела обстоят с техническим долгом, как он попадает в скоуп работ, трудно ли убеждать менеджмент в необходимости таких работ.
Эти вещи способны радикально изменить ощущения от работы. Одно дело - гибкая динамичная команда в онлайн-диалоге с заказчиком, и совсем другое - масштабный энтерпрайз с большим числом согласований и ответственных за каждый шаг.
Кажется, упущен важный пункт: на каком языке проходит рабочее общение — причем на самых разных уровнях, как и на внутрикомандных стендапах, так и на митингах с заказчиками, менеджерами, планированиях и т д. И на каком языке переписка.
Потому что может оказаться так, что официально, например, рабочий язык — английский, но по факту все общение на русском, если вы только не тимлид. И если вы рассчитывали на данной работе попрактиковать профессиональный разговорный английский, с этим могут возникнуть проблемы.
Другая ситуация — когда вы переезжаете в страну, где в коллективе много неанглоговорящих разработчиков, которые между собой общаются на своем языке, т.к. им так комфортнее, и многие рабочие обсуждения будут просто проходить мимо вас.
Плюс вопросы:
1) можно ли приходить со своей клавиатурой (сейчас любят USB блокировать и т.п.);
2) практикуется ли работа через VNC (и сколько пинг в мс, а то может и невозможно так работать).
Я всегда задаю такой вопрос: в каком виде разработчику приходят рекламации о проблемах на проде и какие у разработчика отношения с техподдержкой. Потому что:
Устроился однажды в контору. И внезапно оказалось, что каждый разраб по очереди обязан быть "дежурным". Это когда сидишь в каком-то всратом интерфейсе разбора инцидентов и тебе прилетают жалобы вида "Я что-то нажала и все исчезло". Ты должен проанализировать, перевести это на язык технического тикета и выполнить десять приседаний, чтобы в это всратом интерфейсе закрыть обращение как положено. А потом еще и баг исправить. Причем это был не стартап на полтора человка, а крупная страховая компания. Но на организации поддержки решили сэкономить. Там вообще много на чем экономили. Например, в мой отдел в принципе не нанимали QA - ну типа разрабы же умные, сами тесты напишут.
Теперь я в принципе любое "дежурство" на берегу обговариваю. Я согласен только на формат "вы мне баг в джире - я вам коммит".
В дополнение к вышеозвученному, обычно спрашиваю следующее (это на позицию senior):
как устроен процесс разработки (scrum, kanban). Как коммуницируются требования разработчикам. Чем обуславливаются приоритеты задач и их скоуп.
процесс планирования и оценки. Есть ли дедлайны и как/кем они определяются.
как устроен процесс коммуникации в команде (offline-first или online-first). Какие есть обязательные митинги и сколько они занимают
в какой стадии проект, какие будут задачи (какой баланс между поддержкой legacy и разработкой нового)
как устроен процесс принятия решений (технических или нетехнических), насколько просто предложить и внести изменения
как обстоит дело с документацией по продукту (собираем требования по jira ticketам или есть единый детальный документ, который поддерживается в актуальном состоянии)
какая политика по тестам (есть ли порог по покрытию, что тестируем)
какие будут обязанности по данной вакансии (например, будут ли менеджерские задачи и какой % времени они занимают)
вопрос к человеку , который проводит техническое интервью: как вам самому нравится в этой компании, довольны ли вы?
А расскажите желаемые вами ответы? Вопросы больно неоднозначные и обсуждаемые. В отличии от списка в статье.
У меня как-то так вышло
Разработка ближе к хаотической. Коммуницируются требования текстом в тикетах и лидами которые расскажут что непонятно в тикете. Редко но могут вмешиваться менеджеры.
Дедлайны по разному. Есть задачи с дедлайном умри но сделай. Или скажи хотя бы за пару месяцев что не успеваешь. Есть без дедлайна вообще. И любые промежуточные варианты. Зависит от конкретной задачи.
Комуникация хаотическая. От тикетов до чатиков и живого общения на встречах и в коридоре.
Принятия технических решений консенсусом конкретной команды разработки. Слова вида мне просто не нравится или нравится или я где-то слышал/читал что-то около не котируются вообще. Обоснуй, желательно докажи. Предложить дело нехитрое. Если консенсус за, то дальше зависит от пользы/трудоемкости. Тратить полгода на минорное улучшение с которым все согласны никто не будет. Увы. А вот недельку и делает тот кто внес предложение скорее да и довольно быстро. Сразу после завершения текущих задач того кто делать будет.
В нетехнические решения разработка не лезет. Разве что на уровне: Вот эта фича которую менеджеры придумали противоречит математике и ее невозможно сделать.
Документация местами и временами. Зависит от части продукта. То что смотрит в интернет документировано на 100%, то что не смотрит документировано в виде наскальных рисунков.
Тесты должны быть и тестировать то что сделано в задаче. Интеграционные ок.
Зависит от вакансии. У типичного мидла менеджерства совсем мало. Дальше больше. Наверно как и везде.
Конечно же нравится. Я же тут работаю, не увольняюсь и не собираюсь увольняться в планируемой мной перспективе. И подмигну.
Честные ответы приветствуются, хотя по моему опыту чаще всего кандидатам на такие вопросы стараются правду не отвечать, или приукрасить действительность. Но в приниципе после прохождения десятка собесов научаешься это распознавать.
Конечно это вопросы не на позицию мидла, а на сениора.
В вашем случае я бы спросил, а готовы ли вы к быстрым улучшениям с моей помощью и дадите ли мне карт-бланш на внесение изменений.
Если не готовы, то скорее всего вам действительно стоит рассматривать кандидатов мидл-уровня, сениоры вам не нужны, это будет заколачивание гвоздей микроскопом. При таких условиях скорее всего у вас окажется и вилка по зарплатам ниже рынка, поэтому буду рассматривать другие предложения.
Что касается вопросов из статьи, только часть из них для меня важна
1. В каком формате проходит тех. интервью - не важно, они все обычно более-менее одинаковые.
2. Вопросы про удаленный режим работы, гибкий график, переработки, отпуска и больничные – важно.
3. Вопросы про офис и командировки, а также дресс-код для меня лично неактуальны, поскольку я рассматриваю только 100% удаленку. Но для тех, кому нравится офис, наверное важны.
4. Учет времени – для меня непринципиально. Даже если он автоматический, я в среднем работаю > 8 часов в день.
5. Длительность испытательного срока и ожидания от него – вообще неважно, если только на нем нет каких-то ограничений по зарплате. По моему опыту, ни разу не увольняли с испытательного. А наоборот – пару раз бывало, сам уходил.
6. Бюджет на образование, компьютер – ну камон, это не так дорого стоит по сравнению с зарплатами, даже топовый MB Pro. Я даже лицензии на софт покупал за свои и не просил компенсировать.
7. количество инженеров и их распределение по командам – по-моему не важно.
8. Возможность переходить между проектами, возможность пилить свои пет проекты – важно.
9. Performance review – лучше бы их вообще не было, обычно это такой BS.
В вашем случае я бы спросил, а готовы ли вы к быстрым улучшениям с моей помощью и дадите ли мне карт-бланш на внесение изменений.
Легко. Со стандартными условиями. Их все проходят перед большими изменениями, ничего особого.
По техническим вопросам убедите команду (около 10-20 человек все программисты) что это хорошо. Команде с этим жить потом, их мнение важно. И вперед. Вероятно вы сами будете это делать. По продуктовым вероятно никак. Это надо в менеджеры переходить.
Приукрашивать мы все готовы, но разумно приукрашивать. Зачем не студенту говорить что иногда придется перекладывать джейсон и делать круды? Взрослые люди. Все вроде понимаем что иногда всем приходится делать продуктовые фичи. Срочно делать.
По техническим вопросам убедите команду (около 10-20 человек все программисты) что это хорошо. Команде с этим жить потом, их мнение важно.
Это всегда пожалуйста, я могу детально обосновать все изменения, и технические, и процессные. Готов для каждого предоставить все за и против. Но может оказаться так, что несущественные против будут против существенных за. Тогда нужна будет поддержка сверху для проталкивания изменений.
По продуктовым вероятно никак. Это надо в менеджеры переходить.
Часто путают проектный менеджмент и продуктовый. То, как собираются, формализуются требования и на их основе формируется беклог и принимаются и документируются решения по дизайну, не должно смешиваться с построением планов, сроков, управлением ресурсами, майлстонами, бюджетами, отчетами. Это разные активности.
Срочно делать.
При нормально выстроенном процессе продуктовые фичи делаются плюс-минус в срок и без спешки. Если эти авралы частое явление, тогда наверно стоит на ретроспективе задать себе вопрос, а что мы делаем не так? Неправильно понимаем скоуп, плохо оцениваем, плохо планируем, или может нам не хватает ресурсов? Готов помочь выправить и эту проблему.
Готов для каждого предоставить все за и против. Но может оказаться так, что несущественные против будут против существенных за. Тогда нужна будет поддержка сверху для проталкивания изменений.
Не так. Все разумные люди. Если у изменения есть значимые плюсы и разумные минусы, то против никто не будет. Это не голосование, это сесть за стол и поговорить. Вопрос в сроках на разработку, но это решаемо. Как раз сверху можно его решить. Ну не год же там работать?
Против это вроде: Мы не будем внедрять полный TDD. По опыту наш код падает не в хитрых внутренних алгоритмах, а на странных взаимодействиях со внешними системами, когда они себя ведут себя каким-то необычным или непредусмотренным образом. TDD никак не поможет поймать ошибку неверных таймаутов при зависании внешней системы которая никогда не зависает или забытых ретраев в месте где они возможны. И прилетевший гигабайт данных в месте где больше 100 килобайт никогда не было и не может быть TDD не поймает. Давайте и дальше писать интеграционные тесты массово, а юнит тесты только в алгоритмически сложных местах.
Часто путают проектный менеджмент и продуктовый.
Продуктовый это пользовательские фичи которые делаем. Если фича технически реализуема, не ломает общую архитектуру и не вызывает каких-то адских костылей она планируется и делается. Нравится разработчику то что она делает или не нравится это не важно. Можно попробовать возразить мол это бесполезно и можно сделать вот сяк (как-то по другому). Но не факт что это возражение пройдет. Решение тут не за разработчиком. У разработчика совещательный голос.
Остальное решаемо в процессе планирования. Кто, как, на каких технологиях, в какие сроки и тому подобное. Мелочи это все. Если технологии особо необычные и не тривиальные, то опять нужно идти к команде и уговаривать их что они хорошие. Этот фреймворк сейчас самый модный и все крутые стартапы его используют, вместо вот того который у нас уже пять лет работает без проблем - вообще не аргумент. А вот "у нас тут все устарело на 10 лет, и весь мир перешел вот на это потому что оно правильнее, удобнее, понятнее, быстрее и архитектурно классно встраивается (Надо быть готовым аргументировать идеальными и неопровержимыми примерами каждое слово если кто попросит Математика и строгие доказательства идеальны по определению)." Это уже аргумент. Команде с этими технологиями жить. Кодовая база общая.
При нормально выстроенном процессе продуктовые фичи делаются плюс-минус в срок и без спешки.
Я неверно выразился. Срочно это в смысле надо садится и делать начиная с завтра. А не еще пару месяцев заниматься чем-то другим и только потом приступать. Хочет или нет разработчик писать кучу крудов и перекладывать вагон джейсонов никому не интересно в этот момент. После уже станет интересно и все реально постараются и вероятно даже найдут другую более интересную разработчику задачу. Но иногда бывает что вот сиди и пиши что сказали.
Дедлайны и переработки из-за "через две недели в прод, а еще не работает" могут быть, но редко. Ну раз в год наверно. Может реже.
Если фича технически реализуема, не ломает общую архитектуру и не вызывает каких-то адских костылей она планируется и делается.
Нравится разработчику то что она делает или не нравится это не важно.
Если вышеописанные условия соблюдаются и нет риска, что поддержка фичи вызовет головные боли в будущем, и при этом нет более простого, дешевого способа решить ту же бизнес проблему, то не вижу причины почему бы она должна не понравиться разработчику.
Обычно процесс устроен так, что бизнес аналитик или клиент формулирует "что" и "зачем" в максимально абстрактном виде. "Что" и "зачем" - это важная часть.
Разработчики совместно с дизайнером и продакт менеджером формулируют "как" это будет реализовано (в том числе, с точки зрения UX) c учетом существующей архитектуры, подобных UX в других фичах, а также простоту поддержки в будущем. Естественно, нужно учитывать и простоту использования для пользователя. Для этого заранее готовятся описания персон.
BA может предложить какой-то вариант решения проблемы ("как"), "но не факт что это предложение пройдет" ;).
Но по-хорошему, все разумные люди, и должны идти навстречу друг другу. В особенности, когда заказчик внешний.
Срочно это в смысле надо садится и делать начиная с завтра. А не еще пару месяцев заниматься чем-то другим и только потом приступать
Здесь не имею принципиальных возражений, разве что могут быть редкие случаи, когда бросить то, что делаешь сейчас, и переключиться на новую задачу может вылиться в то, что в будущем контекст будет потерян и текущую задачу нужно будет начинать с нуля. В таких случаях лучше потратить немного времени и довести задачу до какой-то точки.
Хочет или нет разработчик писать кучу крудов и перекладывать вагон джейносов никому не интересно в этот момент.
Да это обычно не проблема. Хотите платить миллион за перекладывание джейсонов, пожалуйста. Хороший разработчик всегда найдет себе интересную задачу и помимо основной работы, в пет-проекте. Правда опыт скорее показывает, что больше платят за более сложные задачи , где требуется поломать голову.
Заказчики только внутренние. Аналитики тоже. Клиенты внешние, но они идут к другим людям и если они пройдут их задача станет внутренней. Всех этих проблем со внешними заказчиками нет. Я о них рассуждать совсем не готов.
Здесь не имею принципиальных возражений, разве что могут быть редкие случаи, когда бросить то, что делаешь сейчас, и переключиться на новую задачу может вылиться в то, что в будущем контекст будет потерян и текущую задачу нужно будет начинать с нуля.
Опять все разумные люди. Никто не дает большую задачу поверх большой задачи. А мелкие поверх крупной разработчик сам разрулит. Если разруливает плохо придет тимлид и расскажет про приоритеты. Это даже не осуждается. Всякое бывает.
Задачи на полдня считаются мелкими и не участвуют в планировании. На них закладывается типовой расход времени на больших сроках. У всех такие задачи есть. Текучка.
Да это обычно не проблема.
Бывает по разному. Бизнес считает деньги. Если есть идея которая по мнению бизнеса принесет миллионы а никого кроме сеньора свободного нет сейчас, то он и будет ее делать. А задача переложить кучку джейсонов. И иногда у разработчиков это вызывает проблемы.
Где тут самый главный вопрос - о вилке и зп?
Познавательная статья, спасибо! Для себя взял на заметку несколько вопросов. Я бы уточнил, что для начинающего специалиста задавать подобный список вопросов будет не совсем уместно. Ну а если вы уже с большим практическим опытом, то да – лучше уточнить заранее все интересующие вас нюансы.
Какой длины испытательный срок?
Как правило, это 1-3 месяца, но я видел случаи с 6 месяцами. Наличие такого длинного испытательного срока может быть подозрительным, и стоит задуматься.
Для Германии 6 месяцев является практически стандартом. Очень редко бывает меньше, только однажды мне предложили 4 месяца.
А после испытательного уволить сотрудника ОЧЕНЬ сложно (требуется обоснования, возможно восстановление по суду и т.д.), поэтому тех в ком есть хоть какие-то сомнения постараются уволить за пару недель до испытательного даже если работник относительно неплох. Это минус относительной защищенности работника после испытательного.
Во Франции тоже 6 месяцев.
В начале читал список и думал ну что за дичь? Потом прикинул что ведь может быть и по другому. Не как я считаю единственно возможным и правильным в принципиальных для меня вопросах. Если есть опасения или тем более были прецеденты, то проверить точно не лишним будет.
Для проверки ответил за компанию где я работаю заняло 15-20 минут. Значит hr еще быстрее справится. Там много типового. Расход времени небольшой и разумный. Можно потом следующим кандидатам сразу рассказывать и завлекать. Может они и не знают что так бывает?
Самый главный вопрос совершенно другой.
"Сколько было в компании людей два года назад и сколько сейчас?"
Я бы насторожился, если ревью чаще 3 раз в год.
Я бы насторожился, если ревью РЕЖЕ, чем три раза в год. Ревью нужно для получения подробной стратегической обратной связи, корректировки косяков, осознания своего положения на карте. Зачем мне в январе обратная связь по тому, что происходило в июне?
А зачем вообще нужно ревью?
Я ж примерно написал: для получения обратной связи, для постановки целей развития, для трекинга прогресса, для корректировки косяков.
Формализованный способ раздавать премии, повышения и наказания.
Просто проблему неэффективности компаний, где куча людей не знают, что они вообще делают и зачем пытаются решить формальными способами оценки, тогда как единственный правильный вариант - повышать эффективность.
Возьмем простой пример. Вот делается какой-то простой SAAS продукт, есть PM который придумывает фичи, есть результаты продаж. Если продажи растут, значит команда работает хорошо и ПМ сам уж как нибудь распределит премии, ему невыгодно зажимать кого-то, т.к. результаты команды непосредственно влияют на результат.
Далее конечно собственник пытается оценить, что команда могла бы еще больше продаж делать и пытается оценить это. Начинает вводить кучу людей в HR которые пытаются придумывать формальные метрики, люди вместо работы начинают работать на KPI и в результате получаем огромную структуру, которая не может ничего нового создать.
Мои вопросы работодателю, когда подаюсь на разработчика