Как я задаю вопросы и общаюсь с HR
За последние 10 лет я поменял 3 работы, прособеседовался с 10+ компаний на позицию разработчика (software engineer) и вел переписку с HR/рекрутерами из нескольких десятков фирм. По ходу дела заметил, что вопросы, которые я задаю на собеседовании с менеджером/командой или с HR, повторяются, и решил их структурировать. Некоторые из них являются общими, и их может задать кандидат на почти любую вакансию; другие касаются только вакансий для программистов. В этой статье поделюсь с вами наиболее типичными и важными вопросами, которые, на мой взгляд, может задать соискатель потенциальному работодателю.
Disclaimer:
Мой опыт трудоустройства ограничен средними IT-компаниями (с продуктом или консалтингом/сервисом), имеющими от 100 до 1000 человек в штате, поэтому для FAANG и каких-нибудь S&P 500 такой подход может не работать. Если вам покажется неуместным отправлять такие вопросы по почте, то можно их задать в процессе живого общения или после получения оффера.
Практически все интервью, которые я проходил, имели довольно стандартную схему: первичный созвон с HR -> скрининг на адекватность (по телефону или простая задачка по Google Meet / Zoom) -> несколько тех. интервью -> общение с будущим менеджером (и иногда командой) -> оффер или отказ.
Обычно я делаю так: в процессе первичного общения с HR стараюсь задать вопросы, которые являются для меня критичными (must по принципу MoSCoW). Если что-то меня не устраивает, идти дальше (на тех. интервью) нет смысла, за исключением случаев, когда вакансия уж очень классная и хотелось бы пообщаться с разработчиками на тех. интервью и попробовать свои силы. Затем говорю, что мне очень понравилась компания и я хотел бы узнать немного больше, но чтобы не затягивать телефонный разговор, отправлю свои вопросы в письме. Делаю это, чтобы для человека это не было неожиданным.
Если после общения с HR все в порядке и самые важные моменты устраивают, то тогда иду дальше на тех. интервью и параллельно отправляю HR небольшой опросник, в котором вежливо прошу ответить на некоторые вопросы. Времени для общения с HR на первичном созвоне довольно немного (обычно 30, и лишь иногда 45 минут), поэтому все HR говорили, что общаться текстом им даже удобнее, потому что они могут не знать каких-то моментов. Обычно это не к спеху, и ответы мне приходят в процессе прохождения тех. интервью (весь процесс интервью может занимать несколько недель). Вопросы, которые я задаю на этом этапе, не требуют развернутого ответа ("да"/"нет"/"иногда" может быть достаточно), и ответить на все вопросы HR может в письме за 10-15 минут. Если какие-то очень важные для вас моменты не будут включены в контракт, то хотя бы у вас будет текстовый след с договоренностями в электронных письмах (если возникнут какие-то сложности).
Помните, что у HR нет сильной мотивации тратить время на ответы на ваши вопросы, когда вы только в начале этапа интервью. Можно смело подождать, пока не пройдете первичный тех. скрининг, чтобы человек мог убедиться в серьезности ваших намерений и в том, что на вас стоит тратить время. Важно не отправлять все вопросы сразу, потому что это может создать слишком много работы для человека, а это может быть преждевременно (если тех. интервью будет завалено). Вы также можете показаться этаким smart ass, который хочет знать все и вся, и отношение к вам может быть соответствующим. Проявлять искренний интерес к тому, как устроена компания и процессы, поощряется, но терроризировать HR вопросами обо всех деталях (на этом этапе) не стоит.
Когда уже все тех. интервью пройдены и есть оффер, тогда "добиваю" финальными вопросами, чтобы получить полное представление о вакансии и компании, в которой, возможно, буду работать. На этом этапе HR (и нанимающий менеджер) готовы отвечать на все вопросы в деталях, часть из которых, возможно, будет определять зарплату и условия контракта. Компания готова вас взять, и (хорошая компания) заинтересована в том, чтобы вы были уверены, что условия вас устраивают, и чтобы вы не ушли на испытательном сроке.
Вопросы
Здесь, собственно, все вопросы. Под каждым вопросом небольшой развернутый комментарий. Некоторые вопросы могут быть неактуальны для вас; можете их смело пропускать. Погнали!
Вопросы перед тем, как подаваться
В каком формате проходит тех. интервью.
Это лучше всего узнать до того, как начинать процесс. Если этого не сделать, то можно попасть впросак: вдруг тех. интервью назначат через неделю, а пузырьковую сортировку вы уже забыли (или не знали). Подготовиться за неделю-другую может быть очень трудно.
Крупные компании могут описать, как проходит процесс интервью (смотрите страничку "о работе" в JetBrains и Bloomberg). Если повезет, будет написано, входят ли в интервью вопросы по алгоритмам и структурам данных. В этом случае может потребоваться дополнительная подготовка. Если же по алгоритмам гонять не будут, а дадут какое-то тестовое задание или какую-то задачку для лайв-кодинга (но не на алгоритмы), то можно подаваться!
Если на сайте компании информации об интервью нет, можно написать рекрутеру в LinkedIn или просто по электронной почте. Можно вежливо сказать, что очень хотел бы податься, но хочется уточнить, как выглядит тех. интервью. Если штудировать алгоритмы нет сил, то можно посмотреть, какие из компаний нанимают без алго-интервью. В сети даже есть такие списки, например, см. Companies that don't have a broken hiring process.
Помните, что компания может проводить алго-интервью на позиции разработчиков в один отдел, а в другие - нет. Например, какой-нибудь финтех может жестко гонять по алгоритмам на позиции разработчика систем высокочастотного трейдинга, но более лояльно относиться к инженеру на позицию в отдел системной интеграции. Если компания очень нравится и не принципиально, в какой команде или отделе работать, можно посмотреть на смежные должности помимо software engineer, например, solutions engineer, solutions architect, CI/CD или build systems engineer.
Общие вопросы о работе
Можно ли работать удаленно из дома?
Если важно, чтобы была такая возможность. Если работа исключительно из офиса, и из дома работать не разрешают, то делаем выводы :)Сколько времени я буду проводить в офисе (или работать из дома) и сколько в командировках?
Может быть, вы будете 100% в офисе/дома, а может быть, придется часто ездить к какому-то клиенту на какие-то встречи, сбор требований, возможно, понадобится проводить обучение персонала (пользователей вашего продукта/системы) и что-то в этом духе. Будут ли оплачиваться такие командировки и как. О таком хорошо знать заранее.Если работа в офисе (и вам так хочется), лучше уточнить, есть ли отдельный кабинет (личный или для команды) или офис открытого типа (open office)?
Если есть личный кабинет, это классно, можно поработать в тишине (у меня был такой в течение нескольких лет). Но сейчас это редкость, и скорее всего будет общее пространство с переговорками. Если в таком пространстве есть какие-то большие комнаты, в которых можно работать командно, это замечательно. Стоит спросить, есть ли место, где можно "тихонько посидеть и поработать", потому что бегать из переговорки в переговорку не лучший вариант. Если придется все-таки сидеть в общей комнате, то стоит изучить, где вы будете сидеть, чтобы не оказаться рядом с сотрудниками, работа которых связана с общением голосом.Насколько гибкий график работы?
Есть ли какое-то формальное время работы, когда вы должны быть "онлайн"? Если такое имеется, насколько можно от него отходить (пропасть на пару часов в обед, приехать попозже и т.д.). Нужно ли "отмечаться" об отсутствии (достаточно ли кинуть сообщение в общий чат или нужно какое-то формальное одобрение начальника)? Возможно, вам будет предоставлена полная свобода, и вы сможете работать когда угодно, если задачи будут закрываться, но хорошо это уточнить.Ведется ли учет времени работы разработчика?
Например, по контракту вы работаете 40 часов в неделю, но ведет ли работодатель учет отработанного вами времени? Достаточно ли вести учет времени в системе управления проектом?Как дела с переработкой?
Как часто приходится перерабатывать? Посидеть выходные раз в год, когда залило серверную - это нормально, работать по 10 часов каждый день месяцами из-за нереалистичных обещаний начальства - нет. Оплачиваются ли переработки и как? Есть ли возможность взять отпуск в качестве компенсации за переработку? Здесь возвращаемся к вопросу об учете времени - как работодатель будет знать, что вы работали больше 40 часов в неделю и имеете право на доп. отдых?Дресс-код на работе.
Такое крайне редко, но стоит спросить.Какой длины испытательный срок?
Как правило, это 1-3 месяца, но я видел случаи с 6 месяцами. Наличие такого длинного испытательного срока может быть подозрительным, и стоит задуматься. На испытательном сроке вас могут уволить с предупреждением за неделю или даже несколько дней (в зависимости от законодательства страны), что может быть неприятно, если имеются серьезные финансовые обязательства.
Компенсация
Какие условия отпуска?
Например, есть ли какие-то ограничения, когда можно брать отпуск. Возможно, будет нельзя (или "не одобряется начальством") брать отпуск в новогодний период, когда онлайн-магазин под нагрузкой и страшно, что все упадет, или в конце финансового года и так далее. Хорошо узнать, можно ли брать длинный отпуск (взять все дни подряд). Как происходит одобрение отпуска? Начальник кликает мышкой и готово? Или заявление идет длинной вереницей по череде начальников, каждый из которых не торопится отпускать вас на отдых? Хорошо понимать, может ли начальник отказать в отпуске и какие для этого могут быть причины. Есть ли возможность взять неоплачиваемый отпуск (случилась беда, и вы не можете работать месяц)?Какие условия больничных?
Зависит от законодательства страны, но хорошо проговорить, чтобы не было сюрпризов. В некоторых странах болеть может быть очень дорого :)Выделен ли бюджет на образование?
Если есть какой-то конкретный лимит на каждого инженера, то замечательно - вы сами можете решить, как его потратить (годовая подписка Pluralsight, O'Reilly Media или две конференции, например). Если оговоренного бюджета нет, то оплатит ли фирма покупку книг и курсов? Как выглядит процесс "давания добра" (начальник пишет "ок" в чате или опять череда заявлений и одобрений идет по бухгалтериям)?
Команда и разработка
Если считаете, что такие вопросы удобнее обсудить лично в ходе интервью, а не в переписке с HR (или нанимающим менеджером), так тоже можно, спросите, как людям удобнее.
Какое количество инженеров в компании, как они распределены по командам, сколько человек в моей команде?
Хорошо иметь представление о текущем положении дел. Как правило, количество разработчиков пропорционально размеру компании (об общем количестве сотрудников можно узнать на LinkedIn или спросить у рекрутера), но бывают исключения. В фирме может быть 200 человек (190 - продажи и маркетинг, а инженеров 10 штук и все держится на них). Ничего плохого в этом нет, но если вы в начале карьеры, я бы советовал все-таки пойти в фирму, где инженеров побольше. Если в вашей команде всего два человека, может быть очень уютно (если сработаетесь), а может быть тоскливо, как повезет. Рядом с вами может быть один крутой ментор, который научит вас всему, что знает, а может быть команда из 15 раздолбаев, уж как сложится :)Есть ли возможность переходить с проекта на проект (или между продуктами/сервисами)?
Например, поработав годик на бэкенде, может стать интересно переключиться на фронт, и наоборот. Как происходят такие переходы, были ли прецеденты? Если есть возможность поговорить с человеком, который поменял роль, то это очень хорошо.Какой компьютер у меня будет и можно ли выбрать?
Для кого-то это может быть важно. Но если вы всю жизнь на MacOS, а тут Windows, может быть больно, и наоборот. Хорошо уточнить, можно ли выбирать себе ноутбук самостоятельно. Есть компании, где единый стандарт - все на одной операционной системе и все ноутбуки одной фирмы (я был там, где везде HP+Windows, там, где везде Dell+Linux, и там, где везде MacBook Pro). Но есть такие, которые очень гибкие в плане компьютеров сотрудников. Однако, помните, что если вы возьмете что-то экзотическое, помочь вам может быть некому, так что выбирайте с осторожностью.Как выглядит мое рабочее место (в офисе)?
Если работаете из дома, компенсирует ли компания обустройство домашнего рабочего пространства (покупку мониторов, например)? Если из офиса, можно ли отовариться парочкой мониторов для рабочего места за счет фирмы?Можно ли участвовать в опенсорс-проектах (pet-проектах)?
Это хорошо уточнить заранее, чтобы понимать, сможете ли вы продолжать участвовать в каких-то проектах, будучи сотрудником этой компании. Тут как повезет - бывает, что достаточно подписать некоторое соглашение о том, что ваши проекты не помешают бизнесу компании (если вы работаете над платным приложением для учета финансов, то нельзя будет пилить такое же, но бесплатное приложение). Так же хорошо учесть, кто будет являться собственником продукта интеллектуальной деятельности, чтобы потом не было проблем с лицензией для вашего опенсорс-продукта/сервиса.Как проходят performance review, если такие есть, и как часто?
Если такие оценки работы инженера проходят пару раз за год, то это нормально. Я бы насторожился, если ревью чаще 3 раз в год. Но, может быть, это делается просто потому, что так захотел директор, а по факту это формальность. А может быть будут считать количество закрытых тикетов в Jira и вешать фотографии в коридоре у секции "сотрудник месяца".
Хорошо бы спросить, с какой целью они проводятся, и какие действия предпринимаются по итогам (повышение грейда и зарплаты, премии) и, главное, по каким критериям проводится оценка производительности разработчика. Если в фирме есть четко прописанные грейды, как например, у CircleCI и Capgemini или что-то в духе Engineering ladders (с зарплатной вилкой и требуемым набором компетенций), это замечательно, потому что будет куда расти по зарплате и компетенциям. Если нет, то не страшно, но хорошо бы спросить у нанимающего менеджера, как человек собирается отслеживать ваш прогресс как инженера (про отслеживание собственного роста писал в этой статье.-
Как выглядит испытательный срок, что от меня ожидается?
В некоторых вакансиях это уже прописано, но такое встречается довольно редко. Обычно это краткое описание того, что от вас ожидается в течение ближайших месяцев. Например:Через 1 месяц: настроите среду разработки, разберетесь, где все лежит, познакомитесь с коллегами;
Через 3 месяца: закончите первые задачи, сами выкатите что-то в продакшн, что-то почините в продакшн;
Через 6 месяцев: поучаствуете в планировании дорожной карты продукта, начнете менторить кого-то из коллег, выступите на внутренней конференции.
Если такое есть, то здорово, потому что это убирает все вопросы о том, что нужно сделать, чтобы пройти испытательный срок - нужно просто двигаться по этому списку.
Получать ответы на такие вопросы в процессе найма (а не после получения оффера) может быть просто необходимо, если вы собеседуетесь сразу в нескольких фирмах (у меня так было всегда). Есть риск, что когда вам потребуется сделать выбор в пользу какого-то оффера, вы все еще будете ждать ответа по каким-то важным вопросам от еще одной компании, и вас будет поджимать время.
В продолжение темы планируется отдельная статья по вопросам, которые стоит задать нанимающему менеджеру уже на интервью (или по почте, если такая опция доступна), например, вопросы о процессах разработки, код-ревью, и взаимодействии между инженерами.
Всем удачи на собеседованиях! И желаю найти работу своей мечты!
Комментарии (50)
askharitonov
10.07.2022 16:56+6Тут как повезет - бывает, что достаточно подписать некоторое соглашение о
том, что ваши проекты не помешают бизнесу компании (если вы работаете
над платным приложением для учета финансов, то нельзя будет пилить такое
же, но бесплатное приложение). Так же хорошо учесть, кто будет являться
собственником продукта интеллектуальной деятельности, чтобы потом не было проблем с лицензией для вашего опенсорс-продукта/сервиса.Вроде же по российским законам, если продукт разработан по собственной инициативе, не как служебное задание, и, тем более, если это делалось на собственном компьютере и не в рабочее время — то это однозначно собственность разработчика?
xSVPx
10.07.2022 17:06Скорее всего да, но хотите ли вы защищаться в российском суде ?
Если настроение работодателя знать заранее, то можно просто избежать всей ситуации.
SerjV
10.07.2022 20:16+2Скорее всего да, но хотите ли вы защищаться в российском суде ?
Если стороны "прописаны" в России - то в нероссийском суде рассматривать спор им и не светит.
Если настроение работодателя знать заранее, то можно просто избежать всей ситуации.
Не гарантия - настроение может и поменяться. Что и случилось в деле nginx. Но краткосрочную оценку адекватности работодателя - может показать.
Гарантию даёт только отсутствие документов, в которых работодатель может на такое претендовать.
funca
10.07.2022 20:55+1Внимательный к вашим open source активностям работодатель при необходимости может подложить вам такой пункт позже - в кипу новых доп.соглашений про корпоративную этику, правила безопасности и т.п.
SerjV
11.07.2022 00:42+2Может, может. Это один из примеров "смены настроения". Потому терять бдительность нельзя никогда.
И заодно если и верить рекрутёру на слово, то только заверенное подписью и печатью.
Lexicon
11.07.2022 09:43+1Подпишите уведомление, - сленговое выражение кадрового отдела, сопутствующее необходимости подписи документов, предполагающих обязательное, осознанное согласие работника.
SerjV
11.07.2022 12:43Так я ж не спорю, что такое сплошь и к ряду. Но тем более верить рекрутёру на слово нельзя, только документу... И любой документ обязательно читать перед подписанием, причём если что-то непонятно или подозрительно - то верить разъяснению не кадрового отдела, а доверенного юриста.
А вот бодаться при этом или тихо линять при появлении неадекватности - тут уже каждому решать самому.
SerjV
10.07.2022 17:07+1Вроде же по российским законам, если продукт разработан по собственной инициативе, не как служебное задание, и, тем более, если это делалось на собственном компьютере и не в рабочее время — то это однозначно собственность разработчика?
вообще да, но:
- следствие глобализации - человек пытается распространять на свой случай ситуацию в других странах (отчасти полезно: в плане проверки адекватности работодателя, а то если он сам делает то же самое, но в своих интересах и в ущерб интересам работника - то, возможно, работодатель неадекватен)-с сотрудником может подписываться куча документов и существовать куча локальных нормативных актов, а анализировать весь этот ворох самому или с юристом перед трудоустройством - хочется не всем. (отличие от предыдущего вариант - к подписанным соглашениям может быть применим принцип свободы договора, т.е. если заключил сделку с работодателем без принуждения со стороны - сам дурак).
MyraJKee
10.07.2022 20:28+2На последнем месте работы - неделя на настройку и то до сих пор работает сикась-накось и я так понимаю у всех так же. Вторая неделя - первый мерж в прод. Такое ощущение что чем крупнее компания, тем больше народу делают меньше или столько же вещей, чем в более мелкой компании.
Gromin
10.07.2022 20:42+3Я бы сюда добавил вопрос про различные ограничения в контракте. А лучше вообще попросить контракт почитать.
Я не задал такой вопрос когда в последний раз менял работу (аутсорс) и потом, уже после увольнения с предыдущего места, неприятным сюрпризом стал пункт в контракте "работник не имеет права в течении 5 лет после увольнения работать в компании клиента без согласования с руководством" (как-то так, суть ясна). Не уверен что там с юридической силой такого пункта в локациях расположения компании и ее партнеров (США, Европа), но я бы хотел знать о таких вещах до оффера.
powerman
10.07.2022 22:50Не уверен, что это применимо к миддлам, и уверен что вряд ли применимо к джунам, но для сениоров и выше все такие пункты договоров всегда можно было согласовать или убрать. Если компания отказывалась пункт убрать, то обычно его можно было достаточно сильно ограничить (по времени действия и/или по области применения), чтобы он не создавал реальных проблем. Да, для этого договор надо было внимательно читать, и да, нужно отстаивать важные для себя пункты, но компания почти всегда идёт навстречу.
Gromin
11.07.2022 00:46+1Это лишь пример из личного опыта.
Однако же вопрос "можно почитать контракт?" стоит задавать и мидлам, и джунам тоже. Кто его знает что в него добавили, те же конские штрафы за досрочное расторжение. Тогда, как минимум, будет еще не поздно задуматься "а точно ли оно мне надо?".powerman
11.07.2022 00:58На самом деле думать тут вообще не о чём. Если в договоре какая-то фигня, и компания не хочет идти навстречу и её исправить приемлемым для всех сторон способом - договор не стоит подписывать в принципе. По крайней мере если есть уверенность, что получится найти другую работу, что в нашей области не проблема для всех кроме джунов.
sergrt
10.07.2022 22:00+4На мой взгляд очень важно узнать больше про процессы. Это лучше делать на поздних этапах отбора, и лучше с потенциальными коллегами. Кто придумывает задачи, как их спускают разработчикам. Кто фиксирует definition of done, как тестируются выполненные пункты. Как работает команда - по спринтам или от релиза до релиза, и в связи с этим как набирается скоуп. Как дела обстоят с техническим долгом, как он попадает в скоуп работ, трудно ли убеждать менеджмент в необходимости таких работ.
Эти вещи способны радикально изменить ощущения от работы. Одно дело - гибкая динамичная команда в онлайн-диалоге с заказчиком, и совсем другое - масштабный энтерпрайз с большим числом согласований и ответственных за каждый шаг.
shark14
10.07.2022 22:33Кажется, упущен важный пункт: на каком языке проходит рабочее общение — причем на самых разных уровнях, как и на внутрикомандных стендапах, так и на митингах с заказчиками, менеджерами, планированиях и т д. И на каком языке переписка.
Потому что может оказаться так, что официально, например, рабочий язык — английский, но по факту все общение на русском, если вы только не тимлид. И если вы рассчитывали на данной работе попрактиковать профессиональный разговорный английский, с этим могут возникнуть проблемы.
Другая ситуация — когда вы переезжаете в страну, где в коллективе много неанглоговорящих разработчиков, которые между собой общаются на своем языке, т.к. им так комфортнее, и многие рабочие обсуждения будут просто проходить мимо вас.
fk0
11.07.2022 00:19+1Плюс вопросы:
1) можно ли приходить со своей клавиатурой (сейчас любят USB блокировать и т.п.);
2) практикуется ли работа через VNC (и сколько пинг в мс, а то может и невозможно так работать).
panzerfaust
11.07.2022 06:12+2Я всегда задаю такой вопрос: в каком виде разработчику приходят рекламации о проблемах на проде и какие у разработчика отношения с техподдержкой. Потому что:
Устроился однажды в контору. И внезапно оказалось, что каждый разраб по очереди обязан быть "дежурным". Это когда сидишь в каком-то всратом интерфейсе разбора инцидентов и тебе прилетают жалобы вида "Я что-то нажала и все исчезло". Ты должен проанализировать, перевести это на язык технического тикета и выполнить десять приседаний, чтобы в это всратом интерфейсе закрыть обращение как положено. А потом еще и баг исправить. Причем это был не стартап на полтора человка, а крупная страховая компания. Но на организации поддержки решили сэкономить. Там вообще много на чем экономили. Например, в мой отдел в принципе не нанимали QA - ну типа разрабы же умные, сами тесты напишут.
Теперь я в принципе любое "дежурство" на берегу обговариваю. Я согласен только на формат "вы мне баг в джире - я вам коммит".
ethien
11.07.2022 07:18+5В дополнение к вышеозвученному, обычно спрашиваю следующее (это на позицию senior):
как устроен процесс разработки (scrum, kanban). Как коммуницируются требования разработчикам. Чем обуславливаются приоритеты задач и их скоуп.
процесс планирования и оценки. Есть ли дедлайны и как/кем они определяются.
как устроен процесс коммуникации в команде (offline-first или online-first). Какие есть обязательные митинги и сколько они занимают
в какой стадии проект, какие будут задачи (какой баланс между поддержкой legacy и разработкой нового)
как устроен процесс принятия решений (технических или нетехнических), насколько просто предложить и внести изменения
как обстоит дело с документацией по продукту (собираем требования по jira ticketам или есть единый детальный документ, который поддерживается в актуальном состоянии)
какая политика по тестам (есть ли порог по покрытию, что тестируем)
какие будут обязанности по данной вакансии (например, будут ли менеджерские задачи и какой % времени они занимают)
-
вопрос к человеку , который проводит техническое интервью: как вам самому нравится в этой компании, довольны ли вы?
BugM
12.07.2022 03:07А расскажите желаемые вами ответы? Вопросы больно неоднозначные и обсуждаемые. В отличии от списка в статье.
У меня как-то так вышло
Разработка ближе к хаотической. Коммуницируются требования текстом в тикетах и лидами которые расскажут что непонятно в тикете. Редко но могут вмешиваться менеджеры.
Дедлайны по разному. Есть задачи с дедлайном умри но сделай. Или скажи хотя бы за пару месяцев что не успеваешь. Есть без дедлайна вообще. И любые промежуточные варианты. Зависит от конкретной задачи.
Комуникация хаотическая. От тикетов до чатиков и живого общения на встречах и в коридоре.
Принятия технических решений консенсусом конкретной команды разработки. Слова вида мне просто не нравится или нравится или я где-то слышал/читал что-то около не котируются вообще. Обоснуй, желательно докажи. Предложить дело нехитрое. Если консенсус за, то дальше зависит от пользы/трудоемкости. Тратить полгода на минорное улучшение с которым все согласны никто не будет. Увы. А вот недельку и делает тот кто внес предложение скорее да и довольно быстро. Сразу после завершения текущих задач того кто делать будет.
В нетехнические решения разработка не лезет. Разве что на уровне: Вот эта фича которую менеджеры придумали противоречит математике и ее невозможно сделать.
Документация местами и временами. Зависит от части продукта. То что смотрит в интернет документировано на 100%, то что не смотрит документировано в виде наскальных рисунков.
Тесты должны быть и тестировать то что сделано в задаче. Интеграционные ок.
Зависит от вакансии. У типичного мидла менеджерства совсем мало. Дальше больше. Наверно как и везде.
Конечно же нравится. Я же тут работаю, не увольняюсь и не собираюсь увольняться в планируемой мной перспективе. И подмигну.
MagicBun
11.07.2022 07:20Где тут самый главный вопрос - о вилке и зп?
Arbuzer
11.07.2022 09:41+8Напомнило:
В институте экзамен. Заходит преподаватель.
— Вопрос на "пять": как меня зовут?
Все молчат.
— Вопрос на "четыре": как называется предмет, который сдаете?
Все молчат.
— Вопрос на "три": какого цвета учебник?
С задних рядов приглушенный голос:
— Во валит, гад!
bagryancevm
11.07.2022 08:03Познавательная статья, спасибо! Для себя взял на заметку несколько вопросов. Я бы уточнил, что для начинающего специалиста задавать подобный список вопросов будет не совсем уместно. Ну а если вы уже с большим практическим опытом, то да – лучше уточнить заранее все интересующие вас нюансы.
lagudal
11.07.2022 08:26+3Какой длины испытательный срок?
Как правило, это 1-3 месяца, но я видел случаи с 6 месяцами. Наличие такого длинного испытательного срока может быть подозрительным, и стоит задуматься.
Для Германии 6 месяцев является практически стандартом. Очень редко бывает меньше, только однажды мне предложили 4 месяца.
vedenin1980
11.07.2022 19:04+1Да, только уволнение в Германии с испытательного практически аналогично уволнению с постоянки в РФ (2 недели отработки и т.п.).
А после испытательного уволить сотрудника ОЧЕНЬ сложно (требуется обоснования, возможно восстановление по суду и т.д.), поэтому тех в ком есть хоть какие-то сомнения постараются уволить за пару недель до испытательного даже если работник относительно неплох. Это минус относительной защищенности работника после испытательного.
BugM
12.07.2022 02:42В начале читал список и думал ну что за дичь? Потом прикинул что ведь может быть и по другому. Не как я считаю единственно возможным и правильным в принципиальных для меня вопросах. Если есть опасения или тем более были прецеденты, то проверить точно не лишним будет.
Для проверки ответил за компанию где я работаю заняло 15-20 минут. Значит hr еще быстрее справится. Там много типового. Расход времени небольшой и разумный. Можно потом следующим кандидатам сразу рассказывать и завлекать. Может они и не знают что так бывает?
sphinxthecat
12.07.2022 09:36Самый главный вопрос совершенно другой.
"Сколько было в компании людей два года назад и сколько сейчас?"
powerman
Какие… интересные ожидания.
По моему опыту на первый пункт нужен не месяц, а неделя максимум, чаще дня 3-4 (разумеется, речь не о всём коде компании и не о всех сотрудниках, а только о той части кода/коллег, знакомство с которыми актуально для выполнения задач в ближайшие пару месяцев). Разумеется, чтобы была возможность быстро вкатиться в работу новому сотруднику в компании должны быть подготовлены нужные ему документы и поставлен процесс онбординга, чтобы у нового сотрудника не возникало необходимости задавать кучу тривиальных вопросов коллегам, ждать пока они найдут время ответить, да ещё и сначала побегать в поисках кому конкретно нужно задать каждый вопрос.
А первая задача должна быть смержена недели через две максимум, это при условии достаточно жёсткого ревью с 2-3 раундами фиксов в процессе ревью.
romxx
Вы просто не работали никогда в по-настоящему больших компаниях.
powerman
Это правда. Так и в статье ведь тоже речь не о FAANG.
DVF
Я один раз месяца полтора ждал заведения учёток. Задач не было, сидел, учился, фрилансил, получал зарплату. Большая компания. Потом получал по неделе разрешения на установку IDE и прочих утилит, с высочайшего одобрения. То, что в это время работа стояла, тоже никого не волновало, зарплата выплачивалась в полном объёме.
Jsty
Банк?
yonen93148
Интересно где такой банк, который за деньги не удавит? Я как-то не встречал. Даже на испытательном сроке запрягают так, что только держись!
Arty_Fact
Зеленый с галочками на логотипе. Некоторые по полгода без работы сидели и зп получали.
Xambey97
Плюсую. Было неоднократно, что неделю-две получал только ДОСТУПЫ! К тем или иным хостам, базам и тп. чтобы хотя бы начать работать. Я бы сказал, что это в целом хороший показатель для компании, если доступы жестко контролируют. Это снижает вероятность утечек и что кто-то некомпетентный что-то сломает. Если конечно время на получение доступов когда это нужно вчера, адекватное…
powerman
Контроль доступов никак не связан с временем его выдачи. А если связь и есть, то она скорее обратная - чем выше контроль, тем быстрее доступы выдаются (потому что поставлены процессы, известно кто их выдаёт, как их выдавать, и руководитель подаёт типовую заявку на выдачу для каждого нового сотрудника).
А вот если в компании вместо нормальных процессов наросла излишняя бюрократия, либо процессов нет и там бардак - тогда да, выдача может сильно затянуться.
DistortNeo
А где гарантии, что после увольнения доступы закрывают сразу же, а не через неделю-две? Или вообще забывают про это?
Xambey97
Ну по своему опыту работы в нашем 'МЯСЦЕ' по аналогии с FAANG'ом, если вы понимаете о чем я, блочат обычно в процессе увольнения, по мере близости к сдаче пропуска в офис. Как только отработка заканчивается, если она есть. В компаниях поменьше все ограничение доступов максимум сводилось к «vpn до прод. машин», все остальное за NAT, доступное по vpn разраба. Особенно в гос-ке (о вселенная зачем ты меня с этим свела?!). Сломать и украсть можно многое при таком подходе.
О случаях вроде «вам приходит сообщение, что в компании увольнения и всем кому пришло это письмо уволены», и доступы при этом тут же заблокированы, чтобы люди не могли нанести ущерб, на моей памяти не доходило
SpiderEkb
По моему опыту работы в банке из Топ-10, сотрудник приходит сразу на комп, где подключены все учетки (сетевая, телефония, тестовые сервера). До боевых серверов доступа нет и не будет у рядовых разработчиков. Установкой поставок на прод занимается только сопровождение после того как поставка проходит все этапы тестирования.
Новому сотруднику нужно только оформить ряд заявок на доступы к различным ресурсам (гит, джира, конфлюенс, артифактори, дженкинс и т.п.) но все это занимает 1-2 дня - выдается памятка какие заявки надо заполнить (это все на специальном внутреннем ресурсе делается путем заполнения форм), выполняются они максимум за день.
Основной инструментарий весь уже раскатан на машине из стандартного образа. Недостающее ставится со внутренних ресурсов, все расписано в памятке и разделе "новому сотруднику" в конфлюенсе.
Испытательный срок - 3 месяца. Но это больше обучение (специфика наших команд в том, что "готовых" разработчиков под используемую платформу практически нет - их в стране немного и в целом большинство так или иначе знакомы между собой) - освоение платформы, технологий. Первый месяц - учебные задачки под руководством ментора. К концу обучения человек уже способен решать несложные боевые задачи.
Так что "испытательный срок" тут - обучение + стыковка с командой. Оплата 100% Единственное ограничение - бессрочный контракт на 100% вступает в силу по окончании испытательного срока и тогда же оформляется соцпакет.
Раньше работа была 100% в офисе. Но это связано со сложной политикой в области ИБ (в частности, доступа даже к тестовым серверам только из внутренней сети, которая на 100% изолирована от внешнего мира - даже в инет не выйти с рабочего компа, только через специальный "безопасный браузер" который работает через виртуалку). Но с карантином сопровождению пришлось напрячься и организовать возможность удаленной работы для всех. Организовали. Не все просто, но в целом работает. Более того, это признано удачным решением и теперь режим работы "временно удаленный". Т.е. каждые полгода в САП оформляется заявка на удаленную работу и все работают по домам. Хотя при желании никто не запрещает приходить в офис и работать там (бывает что просто договариваемся собраться в какой-то день в офисе всей командой). Единственное ограничение - работа только с территории РФ. С нероссийских адресов никакого доступа не будет. Ну разве что сидеть за рубежом, а в банковский VPN входить через VPN с российским сервером.
В принципе, у банка есть коворкинг в Сочи. Можно заказать себе на неделю-две и уехать туда.
Учет рабочего времени не ведется. Есть задачи, у каждой есть срок. Укладываешься в срок - больше от тебе ничего не требуется. Какого-то вот прям "рабочего времени" как такового нет. Понятно, что очень нежелательно пропадать и быть недоступным по каналам связи в течении рабочего дня, но вполне возможно предупредить "у меня тут прям край как приперло, завтра до обеда недоступен буду".
Авралы бывают, но крайне редко. Есть если крайняя необходимость работы выходные - оформляется заявка на работу в выходные за двойную оплату. Но у меня за пять лет это было всего один раз когда пришлось субботу-воскресенье поработать (и то все это вылилось в что в субботу более-менее полный день работа, а в воскресенье только после обеда пришлось посидеть немного, но зачлось все как два полных дня).
При удаленной работе можно заказать ноут, можно на своем работать. Можно попросить второй монитор - дадут вынести из офиса домой. Но я лично предпочитаю иметь все свое.
По отпускам единственное требование - один из периодов не меньше 14-ти дней. Я обычно разбиваю 7+7+14. В конце года расписываешь график в САП, он утверждается и все. Остальное все само происходит.
В целом все процессы выстроены и автоматизированы без лишних бумажек и бюрократии.
Пересмотры з/п регулярны и ощутимы (лично у меня сейчас, спустя 5 лет работы, з/п более чем в три раза выше той, на которую пришел). Вся з/п 100% белая, приписана в ТД. Бонусы - отдельно, раз в квартал, 15% от квартальной з/п с учетом личного КПИ (оценка руководства по результатам работы). Опять же, лично у меня стандартный КПИ 1.05-1.10. В целом получается где-то половина месячной з/п бонусом раз в квартал (+2 з/п в год набегает).
В каких-то исключительных случаях, за выполнение чего-то экстраординарного, может быть дополнительная премия от руководства (плюсом к квартальному бонусу). Тоже как-то раз такое было, совершенно неожиданно пришел бонус в два раза больше ожидаемого - сказали что отдельная премия за "вот ту задачу".
Так и живем...
themen2
Спасибо за развернутый ответ!
vadimr
В приличных домах безопасник и сисадмин подписывают обходной лист.
fk0
Да, в больших компаниях рабочий e-mail настроить могут только через неделю...
dvserg
Или же сразу активировать с выдачей учетки. Зависит от "экосистемы" в компании.
segment
Месяц и правда звучит слишком долго, но и 3-4 дней может не хватить. Я бы сказал, что вводное время около 1-2 недель.
powerman
Всё верно. Только вот "вводное время" должно завершаться первым мержем, а не "познакомился с коллегами и настроил IDE". Именно первый мерж показывает, что новый сотрудник "вошёл в проект" в достаточной степени, чтобы ему можно было выдавать (хотя бы простые) таски. Именно первый мерж - является DoD (definition of done) для задачи онбординга нового разработчика.
euroUK
Мерж или ребейз?)
powerman
Вообще к теме это не относится, но мы практикуем squash. Это позволяет разработчикам не заморачиваться описаниями отдельных коммитов (потому что финальное описание формируется в момент мержа, и вот оно уже пишется аккуратно по conventional commits) и при этом иметь чистую историю в master.
SpiderEkb
Ну коль к теме не относится...
У нас практикуется так - в master лежит то, что уже установлено в пром. В develop то, что прошло стадию компонентного тестирования (ITTest) и ушло на бизнестест. Тут есть правило - на этапе компонентного тестирования поставку можно править, после уже нет - нужно делать новую.
feature - текущая поставка. На этапе разработки коммиты можно плодить сколько угодно. Когда разработка закончена, очень желательно все коммиты объединить в один (это упрощает ревью PR). Дальше создается PR feature->develop, поставка собриается в артифактори для последющего развертывания в юниты компенентного тестирования и переходит в статус ITTest
После успешного завершения компонентного тестирования поставка передается на бизнестест (в соотв. юнит). К этому моменту должно быть сделано ревью кода, аппрув PR и о мержится в develop.
После установки поставки в бой develop мержится в master.
Такая вот схема сложилась у нас.
PyReader Автор
Да, согласен на 100%, что хорошо бы сократить время, которое требуется, чтобы начать "приносить пользу". Просто привел пример, как такое описание может выглядеть без привязки к идеальному варианту. Но, наверное, мне нужно было бы более гибко написать, т.е. спустя 1 месяц человек со всем разберется (но может и в 1й день работы), а спустя 3 месяца уже точно выкатит что-то (т.е. это может произойти на 1й день работы, главное, чтобы не позднее 3 месяцев). Про онбординг тоже верно, чем лучше процессы налажены, тем быстрее новый человек вливается в работу.
UnknownUser
Ну вот на текущей работе все нужные учетки и права выдали сразу. При этом два месяца у меня не было вообще никаких обязанностей по ведению текущих проектов. Проходил различные тренинги, знакомился с коллегами и процессами компании - и это обычная практика онбординга в организации.
А так, в небольшой фирме обычно да - 3-4 дня и поехали.