А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
нужно создавать внутренние документы какие-то описания, согласования и прочее
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Пресловутые пять миров?
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
разрабатывает новые вещи
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
И вот тут сеньор, умеющий только управлять джунами
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...
Потому что в одиночку. Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.
а потом, если убедит менеджеров, получает штат на то, чтобы превратить имеющийся прототип в что-то работающее.
Другими словами, речь идёт об изначально никому ненужных проектах? Ну ok. Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали. Может Facebook и может себе позволить нанять людей просто про запас и дать им хобби-проектами под крылом компании заниматься. Но это просто индикатор, что до основных проектов вас пока не готовы допустить, даже в роли мидла.
Ну и как ваш сеньор должен пройти начальный этап, если он программировать разучился?
С чего Вы это взяли? Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.
искать сотрудника под конкретную практическую область — бессмысленно
Причём тут предметная область? Сравните 2 вопроса:
1) напишите алгоритм группировки списка слов по таким-то условиям.
2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий. На первый вопрос адекватный сеньор (если уж ему такой вопрос всё-таки задали) сначала спросит "для чего?". Знаете в каком коде не бывает багов?
А дальше — да, набросав за 10-15 минут какое-нибудь решение сеньор должен уметь о нём ещё и поговорить (чем и будет отличаться от джуна).
Бред. Если человек сразу кидается писать код — это не сеньор. Сеньор из вас сначала всю душу вытрясет, проясняя требования и зачем это вообще вам. Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.
Какие конкретно вопросы вы задали бы такому человеку с учётом того, что каждый из проектов он начинал с нуля в одиночку
Это уже фриланс какой-то, а не командная работа…
Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?
У меня есть ощущение, что вы вообще путаете сеньоров и менеджеров.
Только вот путаете Вы… Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде. Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер. Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются… Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно. Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.
Имхо, для сеньоров — это не простая задача, а тупая. И единственный ответ, который я бы от сеньора принял как правильный, — назначить этот таск джуниору или стажёру.
Вопросы, которые Вам выше писали тоже уместны, т.к. люди хотя бы пытаются понять с какого перепуга им прилетела эта задача, где в ней сложность, с которой не справился стажёр.
Если человек начинает решать такую задачу, то на должность сеньора он не подходит, т.к. не имеет навыков делегирования и проактивного подхода к задачам.
На многолетних наблюдениях за локальным рынком. Ну ладно, в миллионниках может быть 10-15 более-менее серьёзных компаний в одном сегменте. Существенно больше только в Москве и Питере. Но всё равно это странно сравнивать с сотнями remote-вакансий.
Что значит для разнообразия?
Есть должности, на которых удалёнка проблематична. Решил поработать техническим директором и посмотреть насколько мне будет интересно в этой роли.
Ну и опять, если удалёнка так хороша, то почему у одних и тех же компаний вакансии висят очень долго?
Это Вы про кого? Какие-нибудь Crossover или Toptal? Это не конечные компании, а прослойки, поэтому у них постоянный найм.
А так как выстраивать процесс работы с удаленщиками— дело не простое
Это, кстати, заблуждение. Никаких кардинальных сложностей в этом нет. Просто удалёнщики должны быть способны к самоорганизации.
Ну и Вы по себе всех судите…
Ну а Вы по себе, поэтому я Вам и показываю альтернативный взгляд. И объясняю, почему к вам не ломанулась куча специалистов, когда вы чуть выше среднего по региону з/п поставили. Ваше право сомневаться в моём объяснении, но более правдоподобного у Вас ведь всё равно нет.
Ну, не совсем… У Вас акцент на "Спрашивайте технические нюансы из предыдущего опыта" и совершенно непонятно что под этим подразумевается и с чего вдруг из ответа на данный вопрос станет понятно всё, что дальше перечислено.
Собеседования тестируют только навык прохождения собеседований. И придумать какой-то формализованный процесс, который покажет реальную квалификацию практически невозможно. Лучшее что можно сделать, это расспросить о предыдущем опыте, какие задачи приходилось решать, какие задачи нравится решать, какие области интересны. А потом сопоставить это с задачами и областями деятельности компании. Всё остальное от лукавого.
То есть да, можно найти удаленную вакансию, хотя их и в разы меньше, но так делает очень маленький процент разработчиков.
В разы меньше, чем где? Вы же сами написали, что не из Москвы, поэтому я сильно сомневаюсь, что кол-во вакансий в вашем городе может сравниться с кол-вом вакансий на удалёнку. В большинстве региональных центров по конкретному профилю редко бывает более 5-7 компаний, ещё реже бывает, чтобы они все одновременно имели открытые вакансии.
Ну а вторая очень веская причина — у нас компании не умеют с удалёнщиками работать.
Даже в России есть которые умеют, но необязательно себя российскими компаниями ограничивать.
Вы сами сейчас работаете удаленно?
Буквально в этом месяце переключился на офис для разнообразия, до этого 7 лет удалённо работал.
Но со знанием английского лучше сразу переехать за рубеж.
Кому лучше и зачем? У меня, например, никогда такой цели не было, хотя почти каждый месяц приглашают куда-то переехать.
Вы поймите одно: с одной стороны, Вы хотите найти высококвалифицированных специалистов, а с другой — считаете, что они не способны удалённо работать. Это противоречащие требования. Те, кто развивается, за редким исключением личных обстоятельств, способны работать на любой рынок. А те, кто "я могу только из офиса, даже если из дома будут в 2 раза больше платить и проекты будут поинтереснее" — они почти все вечные джуны или максимум мидлы, если с офисами повезло.
IT рынок глобализован, поэтому среднее по региону слабо волнует людей с опытом. Судя по текущим раскладам, мидл с опытом не будет рад з/п меньше 90 т.р., а если у него ещё и с английским всё хорошо, то умножайте на 1.5.
Всё что ниже, можно считать ниже среднего по рынку, вне зависимости от региона.
Developers же. Чем больше лояльных разработчиков, тем лучше Microsoft. Потому что создаётся больше программных решений, которые работают на их ОС. А кто-то из разработчиков её и Visual Studio купит, так что плюсы со всех сторон.
Ну а Oracle что? Их основной бизнес — СУБД, так что с Java они могут экспериментировать как угодно.
Месиво всё-таки было и именно благодаря ему обрели популярность Prototype, MooTools и jQuery. Они брали на себя большую часть боли по поддержке особенностей браузеров. Отдельной историей было ещё и месиво с реализациями CSS.
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Да тут уже давно не Ваш кейс обсуждают, а в целом подход, какими вопросами какой уровень можно проверить.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...
Потому что в одиночку. Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.
Другими словами, речь идёт об изначально никому ненужных проектах? Ну ok. Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали. Может Facebook и может себе позволить нанять людей просто про запас и дать им хобби-проектами под крылом компании заниматься. Но это просто индикатор, что до основных проектов вас пока не готовы допустить, даже в роли мидла.
С чего Вы это взяли? Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.
Вы имеете в виду само железо или прошивки под него? Второе, в принципе, возможно на удалёнке, но процент таких вакансий будет ниже, в силу специфики.
Причём тут предметная область? Сравните 2 вопроса:
1) напишите алгоритм группировки списка слов по таким-то условиям.
2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий. На первый вопрос адекватный сеньор (если уж ему такой вопрос всё-таки задали) сначала спросит "для чего?". Знаете в каком коде не бывает багов?
Бред. Если человек сразу кидается писать код — это не сеньор. Сеньор из вас сначала всю душу вытрясет, проясняя требования и зачем это вообще вам. Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.
Это уже фриланс какой-то, а не командная работа…
Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?
Только вот путаете Вы… Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде. Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер. Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются… Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно. Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.
Имхо, для сеньоров — это не простая задача, а тупая. И единственный ответ, который я бы от сеньора принял как правильный, — назначить этот таск джуниору или стажёру.
Вопросы, которые Вам выше писали тоже уместны, т.к. люди хотя бы пытаются понять с какого перепуга им прилетела эта задача, где в ней сложность, с которой не справился стажёр.
Если человек начинает решать такую задачу, то на должность сеньора он не подходит, т.к. не имеет навыков делегирования и проактивного подхода к задачам.
Вы, вроде, начали с "Причем, вакансия на сеньора".
На многолетних наблюдениях за локальным рынком. Ну ладно, в миллионниках может быть 10-15 более-менее серьёзных компаний в одном сегменте. Существенно больше только в Москве и Питере. Но всё равно это странно сравнивать с сотнями remote-вакансий.
Есть должности, на которых удалёнка проблематична. Решил поработать техническим директором и посмотреть насколько мне будет интересно в этой роли.
Это Вы про кого? Какие-нибудь Crossover или Toptal? Это не конечные компании, а прослойки, поэтому у них постоянный найм.
Это, кстати, заблуждение. Никаких кардинальных сложностей в этом нет. Просто удалёнщики должны быть способны к самоорганизации.
Ну а Вы по себе, поэтому я Вам и показываю альтернативный взгляд. И объясняю, почему к вам не ломанулась куча специалистов, когда вы чуть выше среднего по региону з/п поставили. Ваше право сомневаться в моём объяснении, но более правдоподобного у Вас ведь всё равно нет.
У вас реально в компании сеньоры такими задачами занимаются? Или вы просто чтобы джуниоров подбодрить называете их сеньорами?
Ну, не совсем… У Вас акцент на "Спрашивайте технические нюансы из предыдущего опыта" и совершенно непонятно что под этим подразумевается и с чего вдруг из ответа на данный вопрос станет понятно всё, что дальше перечислено.
Собеседования тестируют только навык прохождения собеседований. И придумать какой-то формализованный процесс, который покажет реальную квалификацию практически невозможно. Лучшее что можно сделать, это расспросить о предыдущем опыте, какие задачи приходилось решать, какие задачи нравится решать, какие области интересны. А потом сопоставить это с задачами и областями деятельности компании. Всё остальное от лукавого.
В разы меньше, чем где? Вы же сами написали, что не из Москвы, поэтому я сильно сомневаюсь, что кол-во вакансий в вашем городе может сравниться с кол-вом вакансий на удалёнку. В большинстве региональных центров по конкретному профилю редко бывает более 5-7 компаний, ещё реже бывает, чтобы они все одновременно имели открытые вакансии.
Даже в России есть которые умеют, но необязательно себя российскими компаниями ограничивать.
Буквально в этом месяце переключился на офис для разнообразия, до этого 7 лет удалённо работал.
Кому лучше и зачем? У меня, например, никогда такой цели не было, хотя почти каждый месяц приглашают куда-то переехать.
Вы поймите одно: с одной стороны, Вы хотите найти высококвалифицированных специалистов, а с другой — считаете, что они не способны удалённо работать. Это противоречащие требования. Те, кто развивается, за редким исключением личных обстоятельств, способны работать на любой рынок. А те, кто "я могу только из офиса, даже если из дома будут в 2 раза больше платить и проекты будут поинтереснее" — они почти все вечные джуны или максимум мидлы, если с офисами повезло.
IT рынок глобализован, поэтому среднее по региону слабо волнует людей с опытом. Судя по текущим раскладам, мидл с опытом не будет рад з/п меньше 90 т.р., а если у него ещё и с английским всё хорошо, то умножайте на 1.5.
Всё что ниже, можно считать ниже среднего по рынку, вне зависимости от региона.
Developers же. Чем больше лояльных разработчиков, тем лучше Microsoft. Потому что создаётся больше программных решений, которые работают на их ОС. А кто-то из разработчиков её и Visual Studio купит, так что плюсы со всех сторон.
Ну а Oracle что? Их основной бизнес — СУБД, так что с Java они могут экспериментировать как угодно.
Месиво всё-таки было и именно благодаря ему обрели популярность Prototype, MooTools и jQuery. Они брали на себя большую часть боли по поддержке особенностей браузеров. Отдельной историей было ещё и месиво с реализациями CSS.