Мне кажется, многие из этих вопросов особого смысла не имеют. Ну какая тебе разница, как они там созваниваются, ты что, откажешься от работы, если они скайпом пользуются? А так — устроишься и разберёшься уже по факту.
Про миссию вообще не понял. Ну наплетут тебе с три короба, по факту миссия это заколачивать бабло собственнику.
А вот про коммиты я бы поспорил. На мой взгляд это очень хороший вопрос. Я бы вполне мог решить отказаться от работы, если видно, что там бардак. Или если там наоборот всё слишком уж причёсано. Я бы хотел посмотреть на коммиты, на структуру репозитория (папки, файлы) и бегло глянуть на какой-нибудь файл в несколько сотен строк. Просто покрутить мышкой на чужом ноутбуке.
Когда я людей собеседовал, изредка такой вопрос задавали, я ничего страшного в этом не видел. Не знаю, как другие к этому относятся, конечно.
S>1)Работа по ТК, с 40-часовой рабочей неделей? Есть ли и как часто переработки?С чем связаны? Отдельно ли оплачиваются?
Жирным — имеет смысл спрашивать.
Зачернутым — не имеет. Очевидно и так. Можно спросить, если разговор будет к тому клониться.
S>2)Есть ли ДМС?
Сильно зависит от страховой. Бывает, что все равно, что нет.
S>3)Оплачивает ли компания софт?
Очевидный вопрос. Докажешь что нужно — купят.
S>4)Есть ли отгулы, т.е. взять нерабочий день за счет работодателя. Либо отгул за свой счет. Что из этого есть?
Это почти тоже самое что п.1
S>5) Вопрос по оборудованию, какое железо используется и т.д. Или каждый со своим ноутбуком (на удаленке)? S>6) Есть ли обучение и оплата курсов со стороны компании или все за свой счет?
Очевидный вопрос. Докажешь что нужно — заплатят. Хуже, когда заставляют, чтобы хвастаться перед клиентами, что все разрабы с сертфикатами.
S>7)(Для больших компаний актуально)Можно ли менять специализацию внутри компании, ну т.е. поменять отдел внутри компании --
Может не понравиться потнециальному начальнику, что ты всегда готов уйти.
S>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?)
Шта??! Тебе действительно это интересно?
S>9)Возможен ли гибкий график начала рабочего дня?(например, с утра в спортзал и начну соотв. позже)
это в разделе коммуникации
S>1)зарплата белая? S>2)есть ли индексация? S>1)В связи с чем открыта позиция? S>2)Какое направление мне, соискателю, надо закрыть? S>3)Оценка эффективности сотрудника -- ревью а-ля гугл или фб. Или что-то свое?
всегда это субъективно, формальный подход обычно для больших начальников, чтобы доказать какой ты нужный.
S>4)перспективы роста на этой позиции, как часто бывают повышения?
не бывает у программистов роста, кроме профессионального
S>5)Из чего складывается типичный рабочий день? S>6)Как осущ. коммуникация -- созвоны по zoom, skype или где-то еще? Слак, tg и тп. S>1)Как устроены процессы, какие роли, текущая команда, заказчики
это одна из самых важных частей собеседования
здесь же спросить про инструментарий, шаблоны, подходы, практики принятые в команде, наличие и актуальность документации.
Этот раздел хорошо бы продумать перед собеседованием. Исключение — ты один на проекте сам по себе, обычно такое в очень мелких канторах.
S>2)Какие задачи стоят перед командой на ближайшее время, процесс постановки задач?
захват мира, на меньшее не соглашайся.
S>3)На какой стадии проект, какие планы на\у проект(а)?
Задержки выплаты зп. Аккуратно узнать про количество клиентов и стабильность денежных потоков.
Если разговор с hr, то спросить как давно она сама работает на них и сколько разрабов уже наняла. Цель — понять как быстро уходят оттуда.
Сколько в багтрекере открытых багов. Это скажет о качестве кода.
Есть ли субподрядчики, с которыми придется иметь дело. Лучше в такое не влезать, особенно если их много.
Спросить про сторонние компоненты, если будет много незнакомых — будет печаль.
Составил список вопросов потенц. работодателю на собеседовании. Агрегировал по сути выдачу гугла, где разброс
был от 5 вопросов до 50. У меня что-то около 20 вопросов, и не факт, что все так уж необходимы. Или наоборот -- упустил
что-то важное. Ну т.е. 20 вопросов, чтобы и немного времени ответы занимали и можно было более-менее составить свое впечатление о потенц. работодателе. Т.е. минут на 15-20 вопрос-ответ. И кончено, докидывайте свое, добавлю и может отедльным документом сделаю.
Общее
1)Работа по ТК, с 40-часовой рабочей неделей? Есть ли и как часто переработки? С чем связаны? Отдельно ли оплачиваются?
2)Есть ли ДМС?
3)Оплачивает ли компания софт?
4)Есть ли отгулы, т.е. взять нерабочий день за счет работодателя. Либо отгул за свой счет. Что из этого есть?
(На прошлой работе было что-то вроде 5 того и 5 другого, хотя за свой счет можно было брать и больше).
5) Вопрос по оборудованию, какое железо используется и т.д. Или каждый со своим ноутбуком (на удаленке)?
6) Есть ли обучение и оплата курсов со стороны компании или все за свой счет?
7)(Для больших компаний актуально)Можно ли менять специализацию внутри компании, ну т.е. поменять отдел внутри компании --
из бэка в ML или ML ops, или из ML ops в биг дату и т.п. В больших компаниях такое сплошь и рядом.
8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?)
9)Возможен ли гибкий график начала рабочего дня?(например, с утра в спортзал и начну соотв. позже)
ЗП
1)зарплата белая?
2)есть ли индексация?
Позиция
1)В связи с чем открыта позиция?
2)Какое направление мне, соискателю, надо закрыть? (это скорее из вакансии будет понятно, но мало ли уточнить)
3)Оценка эффективности сотрудника -- ревью а-ля гугл или фб. Или что-то свое?
4)перспективы роста на этой позиции, как часто бывают повышения?
5)Из чего складывается типичный рабочий день? (Имеет ли смысл данный вопрос?)
6)Как осущ. коммуникация -- созвоны по zoom, skype или где-то еще? Слак, tg и тп.
Проект
1)Как устроены процессы, какие роли, текущая команда, заказчики
2)Какие задачи стоят перед командой на ближайшее время, процесс постановки задач?
3)На какой стадии проект, какие планы на\у проект(а)?
Порядка 20 вопросов. Что упустил или наоборот -- лишнее? Последовательность категорий общее->зп->позиция->проект нормальна или
стоить поменять? Вопрос о самих категориях -- нормально расставлены или следует поменять\убрать? Например, в кат. "общее" вопрос
про миссию нужен ли вообще и не поставить ли его в самое начало?
В общем, жду советы.
ЗЫ: Вопросы типа покажите код или последний коммит не считаю для себя уместным задавать, поскольку это как-то...ну пафосно
что ли? Ну вот я обычный программист с улицы, буду просить показывать коммиты и т.п. Я такое вижу в 2х ситуациях -- когда
человек с улицы, но он либо гуру с крутым гитхабом и типа делает одолжение компании, либо когда на вас сами выходит и пытаются
переманить, при этом вы работу не искали. Вот в этих случаях я бы просил показать код, коммиты и проч. кухню. Как-то так вижу.
Здравствуйте, Sharov, Вы писали:
S>Составил список вопросов потенц. работодателю на собеседовании. Агрегировал по сути выдачу гугла, где разброс S>был от 5 вопросов до 50. У меня что-то около 20 вопросов, и не факт, что все так уж необходимы.
Можно спросить про дежурства, on-call, как часто случаются инциденты (по ночам вставать не особо люблю)? Как это вообще работает?
Состав команды — обязательно, чтобы понять, придется возглавлять или учиться есть у кого.
CI/CD, как все работает? Насколько девы вовлечены? Не всем хочется заниматься девопсом.
Ну и 20 вопросов наверное многовато, обычно ожидают гораздо меньше (опять же, сужу по опыту, не работаю в России давно).
Спрашивать нужно самое главное, для тебя, то, что повлияет на твоё решение, работать тут или нет. Для разных людей эти пункты разные.
Обязательно нужно пообщаться с твоим будущим начальником (скорее всего он будет на собесе, но иногда нет, всякое бывает), иногда сразу понимаешь, что с этим человеком я работать не хочу
Здравствуйте, Antidote, Вы писали:
A>Можно спросить про дежурства, on-call, как часто случаются инциденты (по ночам вставать не особо люблю)? Как это вообще работает?
Вот, наверное, самый важный вопрос. Зарплату можно выбить побольше. ПО, курсы — тоже, если докажешь. Процесс сборки, разработки всегда можно поменять в лучшую сторону, если обосновать. Но дежурства могут прибить нервную систему с последующим влиянием на физическое здоровье. Я вот, честно, не понимаю смысл этих дежурств. Программы нужно изначально писать так, чтобы они не падали или сами перезапускались. У меня был опыт работы on-call на проекте с роботами, и довольно быстро было принято решение уйти от ручной перезагрузки роботов к автоматизированному варианту.
S>3)Оценка эффективности сотрудника -- ревью а-ля гугл или фб. Или что-то свое? S>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?) S>9)Возможен ли гибкий график начала рабочего дня?(например, с утра в спортзал и начну соотв. позже)
Все вопросы имеют смысл в той или иной степени. Первый из тех, что процитирован — самый важный, еще два могут быть полезны (если только не самоочевидны во время интервью).
С моей точки зрения самыми важными вопросами являются:
* чего ожидают от меня? Как мне узнать, успешен ли я в этой роли? (тот самый вопрос про ревью, хотя в другой оболочке, больше про ожидания от меня, чем мои ожидания от компании)
* с кем я буду работать бОльшую часть времени (люди, позиции и т.п.)
* business outlook компании (само собой, нужно изучить вопрос заранее) и команды, в которую меня берут: ожидается ли рост, какова моя роль в этом росте
С позиции того, кто принимает решение о найме в свою компанию.
Все вопросы, которые я не рассматриваю здесь, считаю хорошими, адекватными вопросами. За исключением вопроса про белую зарплату, но я не в РФ достаточно давно, может, опять скатились в работе вчёрную, не знаю.
S>7)(Для больших компаний актуально)Можно ли менять специализацию внутри компании, ну т.е. поменять отдел внутри компании -- S>из бэка в ML или ML ops, или из ML ops в биг дату и т.п. В больших компаниях такое сплошь и рядом.
Меня, как лида небольшой команды этот вопрос немного напряг бы. Я ищу человека для себя, а не для компании. Да, вот такой я эгоист, как и большинство людей, отвечающих за найм внутрь своих команд.
Если хочешь это знать — спрашивай HR, не людей внутри команды.
S>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?)
Лично я весь этот булшит не люблю. Про свой проект и цели своего проекта рассказать готов.
Про цели борождения космическими кораблями просторов Большого театра проповедовать не готов.
При этом, наверное, HR будут счастливы, если этот вопрос будет задан. Наверное его тоже уместно задавать именно им.
S>5)Из чего складывается типичный рабочий день? (Имеет ли смысл данный вопрос?)
В такой формулировке — не уверен. Тем более, что есть куда более адекватные вопросы о стоящих задачах, твоей роли в компании и процессах внутри компании, включая методы коммуникации.
В совокупности они отвечают на этот вопрос более чем подробно и куда более релевантны, ИМХО.
Здравствуйте, Sharov, Вы писали:
S>1)Работа по ТК, с 40-часовой рабочей неделей?
Это надо выяснять еще на этапе предварительных ласк с HR. Если нет (для синьора+ таких вакансий ну, 10% — то завершать собес) S>1)Есть ли и как часто переработки? С чем связаны? Отдельно ли оплачиваются?
А потом поднять вопрос про рабочий график с начальством еще раз. Прямо тебе вряд ли ответят, но по косвенным признакам можно судить про глубину жп.
S>2)Есть ли ДМС?
Если есть, HR сами расскажут, зачем спрашивать. Ну или если тебе так важно — можно спросить, но опять-таки, на этапе беседы с HR
ДМС со стоматологией — это ваще бред. Они там всегда нае... Зубы все потеряешь, нафиг-нафиг.
S>3)Оплачивает ли компания софт?
А какая разница? Мы же про РФ говорим? Если оплачивает — то оплачивает. Если нет — сидишь на свободном софте или пиратках. Хотя, я не сталкивался с тем, чтобы нормальная компания не оплачивала.
А сейчас добавился третий вариант — оплачивает, но ты сидишь на пиратках из-за санкций.
S>4)Есть ли отгулы, т.е. взять нерабочий день за счет работодателя. Либо отгул за свой счет. Что из этого есть? S>(На прошлой работе было что-то вроде 5 того и 5 другого, хотя за свой счет можно было брать и больше).
Если бы меня спросили — я бы подумал, что чел хочет по максимуму набирать отгулов. Как бы, звоночек.
S>5) Вопрос по оборудованию, какое железо используется и т.д. Или каждый со своим ноутбуком (на удаленке)?
Ну, я задавал такие вопросы 10-15 лет назад. Сейчас не сталкиваюсь с тем, чтобы железо не выдавали.
Если идешь в приличную компанию — это вообще странный вопрос.
S>6) Есть ли обучение и оплата курсов со стороны компании или все за свой счет?
S>7)(Для больших компаний актуально)Можно ли менять специализацию внутри компании, ну т.е. поменять отдел внутри компании -- S>из бэка в ML или ML ops, или из ML ops в биг дату и т.п. В больших компаниях такое сплошь и рядом.
Это то же, что и перспективы роста. В лоб вопрос не спраашивал бы, ибо чревато
S>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?)
Мы про РФ говорим? нафиг тогда тебе это?
S>9)Возможен ли гибкий график начала рабочего дня?(например, с утра в спортзал и начну соотв. позже)
Воот, это правильный и очень важный вопрос.
S>
ЗП
S>1)зарплата белая?
дубль вопроса про ТК
Я бы скорее уточнил про структуру доходов. Ну например, 13 зп, или премии. Это можно еще на этапе HR выяснить. То есть понять структуру и величину совокупного дохода. S>2)есть ли индексация?
индексация — нехорошее слово. Надо показать проактивную позицию. например: "Как проходит повышение, что для этого нужно сделать?"
S>
Позиция
S>1)В связи с чем открыта позиция?
Ну да, хороший вопрос. Обязательный.
S>2)Какое направление мне, соискателю, надо закрыть? (это скорее из вакансии будет понятно, но мало ли уточнить)
Скорее, спросить про роль на проекте.
S>3)Оценка эффективности сотрудника -- ревью а-ля гугл или фб. Или что-то свое?
дубль вопроса про индексацию.
S>4)перспективы роста на этой позиции, как часто бывают повышения?
обсудишь в том же вопросе про индексацию.
S>5)Из чего складывается типичный рабочий день? (Имеет ли смысл данный вопрос?)
Очень хороший, даже лучший.
S>6)Как осущ. коммуникация -- созвоны по zoom, skype или где-то еще? Слак, tg и тп.
А не пофигу, в чем именно созвоны?
S>
Проект
S>1)Как устроены процессы, какие роли, текущая команда, заказчики S>2)Какие задачи стоят перед командой на ближайшее время, процесс постановки задач?
Отличные вопросы
Например, я спрашиваю про workflow. Типа, заказчику пришла гениальная идея. Что дальше происходит с этой идеей? Жду, когла расскажут, кто и что дальше делает. Как и кем формулируются требования. Кто решает, берем ли задачу в работу. Кто и как ставит приоритеты. Аналитика. Разработка. Ревью. Тестирование. Приемка. Деплой. В общем, вся эта кухня. Это самый-самый важный вопрос, чтобы понять, что будешь делать на этой работе
S>3)На какой стадии проект, какие планы на\у проект(а)?
Тоже норм.
S>Порядка 20 вопросов. Что упустил или наоборот -- лишнее? Последовательность категорий общее->зп->позиция->проект нормальна или S>стоить поменять? Вопрос о самих категориях -- нормально расставлены или следует поменять\убрать? Например, в кат. "общее" вопрос S>про миссию нужен ли вообще и не поставить ли его в самое начало?
не-не-не.
Ну вот скажи, какая разница? Скажут тебе "миссия — спасти мир". Что это изменит?
S>В общем, жду советы.
Вот чего явно не хватает — формат работы. Удаленка, гибрид, офис? Если офис — то где? нужно прикинуть, сколько времени будешь тратить в дороге. Если гибрид — то как часто надо приезжать.
S>ЗЫ: Вопросы типа покажите код или последний коммит не считаю для себя уместным задавать, поскольку это как-то...ну пафосно
Не, потому что никто не покажет. Хотя бы из соображений безопасности.
Хоть ты Линус Торвальдс. Не покажу. Хотя бы потому, что не хочу быть уволенным, когда соискатель это заскринит и растащит по форумам.
Здравствуйте, T4r4sB, Вы писали:
TB>Я вот боюсь соковыжималок, потому что имею негативный опыт. Но вот не знаю, как бы ненавязчиво их определить.
Спросить. Про постановку задач, кто назначает сроки (спускают сверху или снизу, сами разработчики), есть ли дедлайны, есть ли переработки, как часто. Наиболее частый ответ: бывают, перед релизами — уже тревожный звоночек, ибо говорит о том, что плохо поставлено планирование, когда полгода пинают гуи, а потом сутками жопа горит.
В среднем, если свой продукт, то темп обычно размеренный. Если бодишоп или аутсорс, или вообще стартап, то там сроки сжатые по жизни, отдыхать не дадут.
TB>Спросить про трекеры, есть или нет?
Это отдельно и не часто связано с потогонкой. Чаще это утешить менеджмент, который боится отпустить на удалёнку народ, либо с почасовой оплатой. Скорее, нужно спросить, чистое ли время считается по трекеру, и как быть с обедом/перерывами. Если скажут, что только чистое — сразу в лес, ибо высидеть 8 часов (480 минут) в день очень сложно и не имеет смысла.
TB>Или у любой адекватной конторы, работающей по ТК, это по умолчанию считается, что такой хрени нет?
С ТК это никак не связано. Но в РФ любят экономить, в среднем, поэтому любят выжимать (забесплатно, естественно) из сотрудников. В Европе/США с work-life балансом получше, особенно, в Европе.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте.
S>Составил список вопросов потенц. работодателю на собеседовании.
Я вот боюсь соковыжималок, потому что имею негативный опыт. Но вот не знаю, как бы ненавязчиво их определить.
Спросить про трекеры, есть или нет?
Узнать что-то про перманентные дедлайны.
Или у любой адекватной конторы, работающей по ТК, это по умолчанию считается, что такой хрени нет?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте.
S>Составил список вопросов потенц. работодателю на собеседовании. Агрегировал по сути выдачу гугла, где разброс
Вопросов многовато. Я бы поинтересовался в первую очередь DevOpsом, ci/cd и т.д. По моему мнению все нехорошие вещи начинаются от туда.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте.
S>В общем, жду советы.
S>ЗЫ: Вопросы типа покажите код или последний коммит не считаю для себя уместным задавать, поскольку это как-то...ну пафосно S>что ли? Ну вот я обычный программист с улицы, буду просить показывать коммиты и т.п. Я такое вижу в 2х ситуациях -- когда S>человек с улицы, но он либо гуру с крутым гитхабом и типа делает одолжение компании, либо когда на вас сами выходит и пытаются S>переманить, при этом вы работу не искали. Вот в этих случаях я бы просил показать код, коммиты и проч. кухню. Как-то так вижу.
"Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем. Бывает нечто, о чем говорят: "смотри, вот это новое"; но это было уже в веках, бывших прежде нас. Нет памяти о прежнем; да и о том, что будет, не останется памяти у тех, которые будут после." Книга Екклесиаста
S>2)Какие задачи стоят перед командой на ближайшее время, процесс постановки задач?
Дополнить: Какие задачи ставятся для этой роли на испытательный срок?
Недавно меня наняли как старшего разработчика. Подкидывали задач. Я их решал. Вместе с этим общался с аналитиками, тестировщиком. Нарабатывал общее понимание проекта.
Предлагал в виде уже реализованого pr улучшение тестового фреймворка. Рефакторинг каких-то моментов. Заносило от еще не полного понимания. Зато был энтузиазм. Мог что-то пока еще и не на 100% выверенное сделать в своих таких дополнительных предложениях.
Считал, что проактивен. И это большой плюс.
К концу 3его месяца мне сказали, что нужно было только решать задачи. Т.е. не до 1ого рабочего дня, не после месяца работы. А к концу испытательного срока.
Когда я был в уверенности что приношу пользу в этой роли. Что так и должно быть. А так было только у меня в голове.
Здравствуйте, Antidote, Вы писали:
A>Ну и 20 вопросов наверное многовато, обычно ожидают гораздо меньше (опять же, сужу по опыту, не работаю в России давно).
Да пусть хоть 40, если вопросы по существу, то я отвечу на них без проблем и раздражения.
Я относительно недавно нанял человека, который задал больше всех вопросов со своей стороны.
Правда, другие задавали вопросы формальные, а он по существу, стараясь понять, что нам надо и как он может и нам помочь и сам раскрыться.
Но люди разные бывают, кого-то, может и раздражает большое количество вопросов от кандидата.
A>Спрашивать нужно самое главное, для тебя, то, что повлияет на твоё решение, работать тут или нет. Для разных людей эти пункты разные.
+100500.
S>>Составил список вопросов потенц. работодателю на собеседовании. Агрегировал по сути выдачу гугла, где разброс S>>был от 5 вопросов до 50. У меня что-то около 20 вопросов, и не факт, что все так уж необходимы.
A>Можно спросить про дежурства, on-call, как часто случаются инциденты (по ночам вставать не особо люблю)? Как это вообще работает?
Разве это задача разработчика?
Для ночных дежурств есть support.
M>Если расследование проблемы (не говоря уже о решении) само по себе дело не быстрое, то почему его не сделать в обычные рабочие часы?
Большая часть оных и делается только в рабочие часы. И cppguard как раз и возмущался, что проведя целый рабочий день в подобном колесе, на следующий день он не мог сосредоточиться на рабочих задачах. И это ожидаемый результат! Инженер on-call не обязан выдавать проектную работу на-гора. Более того, если менеджмент адекватный, все это учитывается в ожиданиях и требованиях к сотрудниками.
Но бывает так, что и по ночам требуется что-то сделать. Простой пример: твои коллеги по команде выкатили апдейты (днем, в рабочие часы). В это время соседняя команда в Индии спит, а у них начинают происходить ошибки, вызванные вашим апдейтом. Когда у них начинается рабочий день, они видят, что сломалось из-за вашего апдейта, и вот тут уже придется встать среди ночи, разобраться и откатить/накатить обновление.
Здравствуйте, avovana, Вы писали:
A>Какие задачи ставятся для этой роли на испытательный срок? A>Недавно меня наняли как старшего разработчика. Подкидывали задач. Я их решал. Вместе с этим общался с аналитиками, тестировщиком. Нарабатывал общее понимание проекта. A>Предлагал в виде уже реализованого pr улучшение тестового фреймворка. Рефакторинг каких-то моментов. Заносило от еще не полного понимания. Зато был энтузиазм. Мог что-то пока еще и не на 100% выверенное сделать в своих таких дополнительных предложениях. A>Считал, что проактивен. И это большой плюс.
A>К концу 3его месяца мне сказали, что нужно было только решать задачи. Т.е. не до 1ого рабочего дня, не после месяца работы. А к концу испытательного срока. A>Когда я был в уверенности что приношу пользу в этой роли. Что так и должно быть. А так было только у меня в голове.
Надеюсь не уволили?
Это очень правильные вопросы, всегда нужно стараться пинговать менеджера на тему "я все правильно делаю или как?". В каждой конторе свои критерии и ожидания, особенно от старшего разраба.
Была ситуация наоборот, старшой в соседней команде был ниже травы, тише воды, нафигачил огромный PR за 2 месяца, попросили на выход.
N>Сколько в багтрекере открытых багов. Это скажет о качестве кода.
Это скажет лишь о качестве менеджера. Равнодушный — бэклог будет наполняться годами открытыми задачами. Ибо проект растёт, всё не закроешь — постоянно что-то новое будет появляться (и баги, и фичи). Инициативный — бэклог будет расти ещё быстрее. Боязливый (жопу прикрывать) — бэклог будет уменьшаться любыми способами, не обязательно фиксами — придумает что-то вроде "задача не должна быть открытой больше полугода, если больше — закрываем, потом переоткроем".
О качестве кода это не скажет абсолютно ничего. Посмотри на любые проекты, если владелец не параноик (читай, идиот), любящий закрывать тикеты по неактивности, то бэклог будет не маленький.
Здравствуйте, avovana, Вы писали: A>Когда я был в уверенности что приношу пользу в этой роли. Что так и должно быть. А так было только у меня в голове.
Ну вообще тут вопросы и к тебе, и к ним. Как оно так вышло, что у вас совершено разное представление об исполняемых обязанностях?
Мне кажется, что во время онбординга хороший начальник должен сам проговорить словами через рот, что тебе делать. Если начальник не очень хороший — тогда ты самостоятельно словами через рот должен спросить. Это же в твоих интересах )) Ну и озвучить свое видение. Потом прийти к единому пониманию обязанностей.
По мере работы твое видение может меняться. Например, как ты сказал, ты заметил потребность налаживании взаимодействий со смежниками, потребность в рефакторинге. И тогда, стоит на 1-1 еще раз поднять вопрос, о том, что бы делаешь вот это и это, как, норм? У вас нет 1-1? Ну значит лучше проявить инициативу и самому зафигачить встречи с начальством.
Здравствуйте, namespace, Вы писали:
S>>6) Есть ли обучение и оплата курсов со стороны компании или все за свой счет? N>Очевидный вопрос. Докажешь что нужно — заплатят. Хуже, когда заставляют, чтобы хвастаться перед клиентами, что все разрабы с сертфикатами.
Кстати — да. Был в моей практике случай. Только там не про клиентом, а про тендеры. Когда в тендере прописаны сертификаты и их надо иметь. Мне не понравился этот процесс и я бы предпочёл в этом не участвовать, экзамены вспомнились. Типа учишь там что-то, зазубриваешь вопросы.
Здравствуйте, vsb, Вы писали:
vsb>Кстати — да. Был в моей практике случай. Только там не про клиентом, а про тендеры. Когда в тендере прописаны сертификаты и их надо иметь. Мне не понравился этот процесс и я бы предпочёл в этом не участвовать, экзамены вспомнились. Типа учишь там что-то, зазубриваешь вопросы.
А потом держат этих людей, любыми способами, боятся потерять сертификаты. Так что палка о двух концах
S>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?)
Странный вопрос. Деньги конечно, как для любой коммерческой разработки софта.
По поводу некоторых других вопросов (распорядок дня; покажите код): на стадии собеседования может быть ещё неизвестно, в какую именно команду ты попадешь.
А у команд может существенно различаться подход к разработке.
Так же добавил бы в список просьбу посмотреть рабочие места сотрудников, если предполагается работа в офисе.
C> Я вот, честно, не понимаю смысл этих дежурств. Программы нужно изначально писать так, чтобы они не падали или сами перезапускались. У меня был опыт работы on-call на проекте с роботами, и довольно быстро было принято решение уйти от ручной перезагрузки роботов к автоматизированному варианту.
В большинстве случаев программу (систему, сервис и т.п.) ты пишешь не с нуля, а получаешь "Чу́дище о́бло, озо́рно, огро́мно, стозе́вно и ла́яй" в наследство.
Опять же, каждое "падение и перезапуск" должны быть протоколированы и разобраны, т.к. они оказывают влияние на пользователей. Если это влияние сильно бесит пользователей (а оно так и есть), будет происходить отток к конкурентам, да и вообще SLA положено выполнять. Так что от operations никуда не деться. Разве что писать действительно качественный софт, или работать где-то в фреймворках, где цикл исправления меряется месяцами (поэтому oncall неприменим). Но там свои чудища.
Здравствуйте, SkyDance, Вы писали:
SD>В большинстве случаев программу (систему, сервис и т.п.) ты пишешь не с нуля, а получаешь "Чу́дище о́бло, озо́рно, огро́мно, стозе́вно и ла́яй" в наследство. SD>Опять же, каждое "падение и перезапуск" должны быть протоколированы и разобраны, т.к. они оказывают влияние на пользователей. Если это влияние сильно бесит пользователей (а оно так и есть), будет происходить отток к конкурентам, да и вообще SLA положено выполнять. Так что от operations никуда не деться. Разве что писать действительно качественный софт, или работать где-то в фреймворках, где цикл исправления меряется месяцами (поэтому oncall неприменим). Но там свои чудища.
Так надо нанимать специальных индусов людей для этого. Я помню, что мой oncall был в среду, и весь четверг я отходил от дежурства с 5 до 19. Пятницу ходил как зомби, а в выходные отсыпался. Довольно быстро мне это дело надоело, и наши пути с компанией разошлись. Одно дело, когда раз в месяц на почту приходит сообщение, что сервер упал и надо бы его поднять (хотя в 2023-ем есть стопицот способов делать это автоматически), и другое дело, когда действительно что-то делаешь активно, параллельно продолжая программировать.
Здравствуйте, _ABC_, Вы писали:
_AB>Да пусть хоть 40, если вопросы по существу, то я отвечу на них без проблем и раздражения. _AB>Я относительно недавно нанял человека, который задал больше всех вопросов со своей стороны. _AB>Правда, другие задавали вопросы формальные, а он по существу, стараясь понять, что нам надо и как он может и нам помочь и сам раскрыться.
Могу сюда добавить, что не помню, чтобы мы кого-нить взяли, кто не задавал вопросов
Но обычно те, кто задаёт много вопросов, много стоят
_AB>Но люди разные бывают, кого-то, может и раздражает большое количество вопросов от кандидата.
+1
Такое сразу можно понять (может там следующий митинг через 5 минут), тогда и полезно иметь список "важных вопросов".
Здравствуйте, Qulac, Вы писали:
Q>Вопросов многовато. Я бы поинтересовался в первую очередь DevOpsом, ci/cd и т.д. По моему мнению все нехорошие вещи начинаются от туда.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Вопросов многовато. Я бы поинтересовался в первую очередь DevOpsом, ci/cd и т.д. По моему мнению все нехорошие вещи начинаются от туда.
S>Чтобы конкретно спросили, 3-5 своих вопросов?
1. Как устроен процесс, есть ли ci/cd, если есть то как устроен в общих чертах.
2. Есть ли внутренняя документация по продукту для разработчиков.
3. Что дается для работы, какое железо, софт и т.д или что — то свое нужно или можно что-то использовать свое.
Здравствуйте, namespace, Вы писали:
S>>2)Есть ли ДМС? N>Сильно зависит от страховой. Бывает, что все равно, что нет.
Вопрос важный, если есть страховка в Медси, то как бы это плюс. Есть ли даже стоматологии нету, то это
странно, уже звоночек.
S>>4)Есть ли отгулы, т.е. взять нерабочий день за счет работодателя. Либо отгул за свой счет. Что из этого есть? N>Это почти тоже самое что п.1
Вот не знаю, помимо ТК это еще может от компании зависеть. Как минимум кол-во отгулов за свой счет может и не быть
вообще, а может и с десяток быть. От странны тоже зависит (ТК). Т.е. одни компании могут идти на встречу, другие -- нет.
S>>5) Вопрос по оборудованию, какое железо используется и т.д. Или каждый со своим ноутбуком (на удаленке)? S>>6) Есть ли обучение и оплата курсов со стороны компании или все за свой счет? N>Очевидный вопрос. Докажешь что нужно — заплатят. Хуже, когда заставляют, чтобы хвастаться перед клиентами, что все разрабы с сертфикатами.
Может там это все за свой счет и в свое личное время, почему не спросить?
S>>7)(Для больших компаний актуально)Можно ли менять специализацию внутри компании, ну т.е. поменять отдел внутри компании -- N>Может не понравиться потнециальному начальнику, что ты всегда готов уйти.
Вариант. Но опять же, в крупных компаниях такое не редкость.
S>>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?) N>Шта??! Тебе действительно это интересно?
С одной стороны все это на сайте можно прочитать, в резделе миссия, например. С другой стороны -- ну этакая вежливость
как сейчас принято. Софт скилс, показать что для тебя это важно. Уберу я этот вопрос, пожалуй. Он и вправду дурацкий.
Лучше что-то уточнить непосредственно про предметную область фирмы, как-то конкретнее будет, чем "за все хорошее,против всего плохого."
S>>4)перспективы роста на этой позиции, как часто бывают повышения? N>не бывает у программистов роста, кроме профессионального
Ну а почему не спросить как у фирмы с ростом из, скажем, мидла в сеньеры. Полгода, 2 года и т.д.
S>>5)Из чего складывается типичный рабочий день? S>>6)Как осущ. коммуникация -- созвоны по zoom, skype или где-то еще? Слак, tg и тп. S>>1)Как устроены процессы, какие роли, текущая команда, заказчики N>это одна из самых важных частей собеседования N>здесь же спросить про инструментарий, шаблоны, подходы, практики принятые в команде, наличие и актуальность документации. N>Этот раздел хорошо бы продумать перед собеседованием. Исключение — ты один на проекте сам по себе, обычно такое в очень мелких канторах.
S>>2)Какие задачи стоят перед командой на ближайшее время, процесс постановки задач? N>захват мира, на меньшее не соглашайся.
Процесс постановки задач вынесу в отдельный вопрос, а планы уберу.
S>>3)На какой стадии проект, какие планы на\у проект(а)?
N>Задержки выплаты зп. Аккуратно узнать про количество клиентов и стабильность денежных потоков.
А для программиста с улицы это тактичные вопросы -- вынь да полож фин. потоки, т.е. бухгалтерию компании?
N>Если разговор с hr, то спросить как давно она сама работает на них и сколько разрабов уже наняла. Цель — понять как быстро уходят оттуда.
Тоже, кмк, не очень вежливый вопрос -- ответ можно понять по вопросу "в связи с чем отрыта вакансия". Все будут говорить, что
в связи с расширением, а как на самом деле --
N>Сколько в багтрекере открытых багов. Это скажет о качестве кода.
Совсем не то, кмк. Больше от возраста продукта зависит. Т.е. факторов куча, помимо кода.
N>Есть ли субподрядчики, с которыми придется иметь дело. Лучше в такое не влезать, особенно если их много.
Ну если речь об интеграторе коих масса, то без этого никуда. Но такие стараюсь избегать.
N>Спросить про сторонние компоненты, если будет много незнакомых — будет печаль.
Хороший кадровик сам расскажет большинство из того, что ты собираешься спросить.
S>ЗЫ: Вопросы типа покажите код или последний коммит не считаю для себя уместным задавать, поскольку это как-то...ну пафосно S>что ли? Ну вот я обычный программист с улицы, буду просить показывать коммиты и т.п. Я такое вижу в 2х ситуациях -- когда S>человек с улицы, но он либо гуру с крутым гитхабом и типа делает одолжение компании, либо когда на вас сами выходит и пытаются S>переманить, при этом вы работу не искали. Вот в этих случаях я бы просил показать код, коммиты и проч. кухню. Как-то так вижу.
Да почему?! Что за комплексы? Твой авторитет относительно известности компании тут совершенно не при чем. Это очень эффективный способ понять насколько вы друг другу подходите.
Тебе могут наврать и пустить пыть в глаза по большинству других вопрос, но с кодом тебе наврать не могут, код это то, что ты действительно знаешь. Код это то, с чем ты действительно будешь работать.
И да, у тебя опыта может быть поболее, чем возраст многих компаний.
Здравствуйте, Skorodum, Вы писали:
S>Да почему?! Что за комплексы? Твой авторитет относительно известности компании тут совершенно не при чем. Это очень эффективный способ понять насколько вы друг другу подходите. S>Тебе могут наврать и пустить пыть в глаза по большинству других вопрос, но с кодом тебе наврать не могут, код это то, что ты действительно знаешь. Код это то, с чем ты действительно будешь работать.
Это можно понять работая непосредственно с кодовой базой, а не по одному коммиту или файлу. А реально понять,
это взять проект, собрать и, возможно, где-нибудь развернуть. А это уже сильно рабочие моменты.
S>И да, у тебя опыта может быть поболее, чем возраст многих компаний.
И? Здесь есть люди с опытом, больше чем лет fb, но их туда не возьмут. Так что это совсем не довод.
Здравствуйте, Sharov, Вы писали:
S>Это можно понять работая непосредственно с кодовой базой, а не по одному коммиту или файлу. А реально понять, S>это взять проект, собрать и, возможно, где-нибудь развернуть. А это уже сильно рабочие моменты.
Речь не про понимание конкретного кода и задачи, а про понимание рабочих процессов и культуры. Тут даже язык программирования не важен.
В идеале это должно быть как-то так:
- Покажите какую-нибудь закрытую задачу и коммит.
— Да пожалуйста. На митинге решили X, занесли задачу в беклог, на планировании спринта дали ее Васе, вот Вася сделал, вот PR.
По коммиту/закрытой задаче можно понять о рабочем процессе и культуре гораздо больше, чем по устным описаниям.
S>>И да, у тебя опыта может быть поболее, чем возраст многих компаний. S>И? Здесь есть люди с опытом, больше чем лет fb, но их туда не возьмут. Так что это совсем не довод.
Опыт это не про то, что должны обязательно взять, а про то, что соискатель имеет право на свою оценку компетенций и культуры компаний.
C>Так надо нанимать специальных индусов людей для этого. Я помню, что мой oncall был в среду, и весь четверг я отходил от дежурства с 5 до 19. Пятницу ходил как зомби, а в выходные отсыпался. Довольно быстро мне это дело надоело, и наши пути с компанией разошлись. Одно дело, когда раз в месяц на почту приходит сообщение, что сервер упал и надо бы его поднять (хотя в 2023-ем есть стопицот способов делать это автоматически), и другое дело, когда действительно что-то делаешь активно, параллельно продолжая программировать.
Я же объяснил: с "органическим" ростом сложности системы простое "рестартовать сервер" давно уже делается автоматически, и никого не беспокоит. oncall занимается куда более сложными вещами, которые автоматизировать не так легко. Скажем, увеличилось количество ошибок по определенной операции. Куда смотреть — сразу неясно, но начинаешь копать, проходишь всю rabbit hole целиком, и узнаешь, что где-то кто-то, через 10 прокси-серверов и 5 смежных серверов, делает какой-то апдейт, который ломает кучу легаси кода.
C>>Так надо нанимать специальных индусов людей для этого. Я помню, что мой oncall был в среду, и весь четверг я отходил от дежурства с 5 до 19. Пятницу ходил как зомби, а в выходные отсыпался. Довольно быстро мне это дело надоело, и наши пути с компанией разошлись. Одно дело, когда раз в месяц на почту приходит сообщение, что сервер упал и надо бы его поднять (хотя в 2023-ем есть стопицот способов делать это автоматически), и другое дело, когда действительно что-то делаешь активно, параллельно продолжая программировать.
SD>Я же объяснил: с "органическим" ростом сложности системы простое "рестартовать сервер" давно уже делается автоматически, и никого не беспокоит. oncall занимается куда более сложными вещами, которые автоматизировать не так легко. Скажем, увеличилось количество ошибок по определенной операции. Куда смотреть — сразу неясно, но начинаешь копать, проходишь всю rabbit hole целиком, и узнаешь, что где-то кто-то, через 10 прокси-серверов и 5 смежных серверов, делает какой-то апдейт, который ломает кучу легаси кода.
Что-то я с всё равно плохо понимаю, что это за дежурства такие
Если расследование проблемы (не говоря уже о решении) само по себе дело не быстрое, то почему его не сделать в обычные рабочие часы?
Здравствуйте, m2user, Вы писали:
A>>Можно спросить про дежурства, on-call, как часто случаются инциденты (по ночам вставать не особо люблю)? Как это вообще работает?
M>Разве это задача разработчика? M>Для ночных дежурств есть support.
Счастливый ты человек.
Если support действительно есть, то он очень ограничен в своем инструментарии.
Если в компании норм процессы — то поддержка отрабатывает по инструкции. Не сработало — эскалирует. То есть будит тебя. И тебе желательно бы проснуться и все починить, да побыстрее. Потому что никто не любит, когда его будят по ночам. Особенно — твой начальник. А его разбудят, если ты будешь недостаточно расторопен.
Если в компании бардак — поддержка делает что-то типа попинать по колесам перезагрузки сервака. Не помогло? Будят тебя.
Ну, не конкретно тебя. Скорее, или дежурного (если дерурства есть) или лида.
После поднятия прода ночью тебе надо провести аналитику инцидента, дополнить инструкции для поддержки, завести (и желательно потом все-таки сделать) задачи, чтобы такого не повторилось.
A>>>Можно спросить про дежурства, on-call, как часто случаются инциденты (по ночам вставать не особо люблю)? Как это вообще работает?
M>>Разве это задача разработчика? M>>Для ночных дежурств есть support.
G>Счастливый ты человек. G>Если support действительно есть, то он очень ограничен в своем инструментарии. G>Если в компании норм процессы — то поддержка отрабатывает по инструкции. Не сработало — эскалирует. То есть будит тебя. И тебе желательно бы проснуться и все починить, да побыстрее. Потому что никто не любит, когда его будят по ночам. Особенно — твой начальник. А его разбудят, если ты будешь недостаточно расторопен. G>Если в компании бардак — поддержка делает что-то типа попинать по колесам перезагрузки сервака. Не помогло? Будят тебя. G>Ну, не конкретно тебя. Скорее, или дежурного (если дерурства есть) или лида. G>После поднятия прода ночью тебе надо провести аналитику инцидента, дополнить инструкции для поддержки, завести (и желательно потом все-таки сделать) задачи, чтобы такого не повторилось.
Я подозреваю, что речь идет про разработку каких-то SaaS решений, или что-то в этом роде.
Однако никто из предыдущих комментаторов это никак не обозначил.
В случае же разработки "коробочного" продукта вопросы про on-call для разработчика выглядят несколько странно.
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, Sharov, Вы писали:
S>>1)Работа по ТК, с 40-часовой рабочей неделей? G>Это надо выяснять еще на этапе предварительных ласк с HR. Если нет (для синьора+ таких вакансий ну, 10% — то завершать собес)
Само собой, позже сделаю обновление поста, где добавлю hr или ит к каждой категории.
S>>1)Есть ли и как часто переработки? С чем связаны? Отдельно ли оплачиваются? G> А потом поднять вопрос про рабочий график с начальством еще раз. Прямо тебе вряд ли ответят, но по косвенным признакам можно судить про глубину жп.
Ок.
S>>2)Есть ли ДМС? G>Если есть, HR сами расскажут, зачем спрашивать. Ну или если тебе так важно — можно спросить, но опять-таки, на этапе беседы с HR G>ДМС со стоматологией — это ваще бред. Они там всегда нае... Зубы все потеряешь, нафиг-нафиг.
Ну, а если забудут? Хотя это в вакансии пишут.
S>>3)Оплачивает ли компания софт? G>А какая разница? Мы же про РФ говорим? Если оплачивает — то оплачивает. Если нет — сидишь на свободном софте или пиратках. Хотя, я не сталкивался с тем, чтобы нормальная компания не оплачивала. G>А сейчас добавился третий вариант — оплачивает, но ты сидишь на пиратках из-за санкций.
4-й вариант -- покуать за свой счет, как делал я. Тот же R#.
S>>4)Есть ли отгулы, т.е. взять нерабочий день за счет работодателя. Либо отгул за свой счет. Что из этого есть? S>>(На прошлой работе было что-то вроде 5 того и 5 другого, хотя за свой счет можно было брать и больше). G>Если бы меня спросили — я бы подумал, что чел хочет по максимуму набирать отгулов. Как бы, звоночек.
А что говорит ТК по этому поводу, вроде кроме офиц. отпуска ничего такого нет? А на посл. работе такое было --
и отгул за счет отпуска (-1 отпусной день) и неоплачивается отгул (кажется, не более 5 за год или что-то в этом роде).
Т.е. это фирмы зависит и можно уточнить.
S>>5) Вопрос по оборудованию, какое железо используется и т.д. Или каждый со своим ноутбуком (на удаленке)? G>Ну, я задавал такие вопросы 10-15 лет назад. Сейчас не сталкиваюсь с тем, чтобы железо не выдавали. G>Если идешь в приличную компанию — это вообще странный вопрос.
А если кот в мешке, т.е. не Я., Каспер, Сбер или ит Газпрома, а просто какая-то фирма, да еще на удаленке.
Почему бы не спросить про железо в этом случае?
S>>7)(Для больших компаний актуально)Можно ли менять специализацию внутри компании, ну т.е. поменять отдел внутри компании -- S>>из бэка в ML или ML ops, или из ML ops в биг дату и т.п. В больших компаниях такое сплошь и рядом. G>Это то же, что и перспективы роста. В лоб вопрос не спраашивал бы, ибо чревато
Да, для небольших компаний скорее всего имеет смысл убрать.
S>>8)Какова цель или миссия компании? (Этот вопрос на первое бы место, что скажете?) G>Мы про РФ говорим? нафиг тогда тебе это?
Уберу, просто типа аналог улыбки, а-ля показать свои софт-скиллс. Для России это нафиг не нужно, а за бугром
(когда это теперь будет...)можно было бы и спросить, аналог бесполезной вежливости-улыбки.
S>>9)Возможен ли гибкий график начала рабочего дня?(например, с утра в спортзал и начну соотв. позже) G>Воот, это правильный и очень важный вопрос.
S>>
ЗП
G>Я бы скорее уточнил про структуру доходов. Ну например, 13 зп, или премии. Это можно еще на этапе HR выяснить. То есть понять структуру и величину совокупного дохода. S>>2)есть ли индексация? G>индексация — нехорошее слово. Надо показать проактивную позицию. например: "Как проходит повышение, что для этого нужно сделать?"
Отличный вариант, добавл это вопрос в раздел про зп.
S>>
Позиция
S>>3)Оценка эффективности сотрудника -- ревью а-ля гугл или фб. Или что-то свое? G>дубль вопроса про индексацию.
Не совсем, но близко -- рост зп и рост должности, обычно сильная корреляция, но может повысили в должности
сильно, а в зп -- не очень. Или должность старая, а зп сильно повысили. Тут речь все-таки про позицию, а не деньги,
как в резделе ЗП.
G>Вот чего явно не хватает — формат работы. Удаленка, гибрид, офис? Если офис — то где? нужно прикинуть, сколько времени будешь тратить в дороге. Если гибрид — то как часто надо приезжать.
Это же в самой вакансии сейчас пишут,один из обязательных параметров на hh. Т.е. это ясно уже из описания.
TB>>Спросить про трекеры, есть или нет?
F>Это отдельно и не часто связано с потогонкой. Чаще это утешить менеджмент, который боится отпустить на удалёнку народ, либо с почасовой оплатой. Скорее, нужно спросить, чистое ли время считается по трекеру, и как быть с обедом/перерывами. Если скажут, что только чистое — сразу в лес, ибо высидеть 8 часов (480 минут) в день очень сложно и не имеет смысла.
8 часов (480 минут) и не требуют. Ожидают значительно меньшего чистого времени. Сколько точно, этого не скажут конечно.
Здравствуйте, Antidote, Вы писали:
A>Надеюсь не уволили?
Договорились о новом испытательном после испытательного. Делать только задачки, которые даёт руководитель.
Здравствуйте, m2user, Вы писали:
A>>Можно спросить про дежурства, on-call, как часто случаются инциденты (по ночам вставать не особо люблю)? Как это вообще работает?
M>Разве это задача разработчика? M>Для ночных дежурств есть support.
Шота похоже что это становится вариантом нормы, вешать на разработчиков деружрства, on-call и тд. Особенно там, где исповедуют dev-test-sec-ops подход
Что за комплексы? Твой авторитет относительно известности компании тут совершенно не при чем. Это очень эффективный способ понять насколько вы друг другу подходите.
