если ответ на вопрос занимает 1 минуту, то потери производительности, у человека, пишущего код — 15-30 минут.
Это всё так, но вас послушать так программисты только и делают, что код пишут. Обсуждать идеи прежде, чем переводить их в код — очень даже полезно. И уж хватает методологий как это делать, чтобы не вызывать проблему постоянных отвлечений.
А сколько людей вы на работу опросили и наняли, позвольте спросить?
Не так много, нанимал около десятка, опрашивал соответственно в разы больше.
Потому что бо́льшая часть «сеньоров» код писать не умеет.
Тут если только вам поверить, я ни одного такого сеньора вживую не видел. Я допускаю, что есть куча сеньоров, которые не напишут на бумажке QuickSort, потому что в прошлый раз они этим интересовались 10-15 лет назад, или вообще на бумажке ничего не напишут, т.к. давным давно переложили автодополнение на IDE. Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.
Конечно, у каждой роли есть своя основная зона ответственности. Но на практике все эти границы размываются… И архитектор и тимлид могут сделать что-то в коде, а сеньоры обсудить архитектуру.
Если разделять прям строго, то всё закончится фигнёй типа "это не по моей части" и чехардой перекидывания ответственности друг на друга. Вот вы пишете "код и только код", т.е. такой сеньор в любой момент времени может сказать "я так сделал, потому что мне так сказали"… такой формализованный подход, без вникания в суть.
Имхо, Вы переусложняете классификацию… Если tech lead больше архитектор, то чем он отличается от архитектора?
Вот тут немножко про ведущего программиста.
Я бы даже не стал строгой границы между тимлидом и сеньором проводить. Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации, который в силу роли просто несколько больше управленческой работы выполняет, чем обычный сеньор.
Всё, о чём Вы говорите, затрагивает только R&D.
И в данном контексте речь идёт по сути не о сеньорах, а об исследователях. Т.е. с одной стороны — да, человек, имеющий квалификацию сеньора, может выступать в роли исследователя. Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый. Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.
Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?
А кроме регламентных документов и телепатии Вы других способов общения не знаете?
Ну раз вы на собеседовании только это и спрашиваете — то, скорее всего, наберёте людей, которые только это и умеют…
Да бросьте, я спокойно доверяю людям в этом отношении. И не сомневаюсь, что отработав многие годы программистами они могут набрать код. Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.
Tech Lead, Lead Developer, ведущий программист — это просто альтернативные названия для Senior Developer.
И это не только моё частное мнение… Почти никто не разделяет эти роли. Вот для примера: What Defines a “Senior Developer?”
А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
нужно создавать внутренние документы какие-то описания, согласования и прочее
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Пресловутые пять миров?
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
разрабатывает новые вещи
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
И вот тут сеньор, умеющий только управлять джунами
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...
Потому что в одиночку. Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.
а потом, если убедит менеджеров, получает штат на то, чтобы превратить имеющийся прототип в что-то работающее.
Другими словами, речь идёт об изначально никому ненужных проектах? Ну ok. Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали. Может Facebook и может себе позволить нанять людей просто про запас и дать им хобби-проектами под крылом компании заниматься. Но это просто индикатор, что до основных проектов вас пока не готовы допустить, даже в роли мидла.
Ну и как ваш сеньор должен пройти начальный этап, если он программировать разучился?
С чего Вы это взяли? Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.
искать сотрудника под конкретную практическую область — бессмысленно
Причём тут предметная область? Сравните 2 вопроса:
1) напишите алгоритм группировки списка слов по таким-то условиям.
2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий. На первый вопрос адекватный сеньор (если уж ему такой вопрос всё-таки задали) сначала спросит "для чего?". Знаете в каком коде не бывает багов?
А дальше — да, набросав за 10-15 минут какое-нибудь решение сеньор должен уметь о нём ещё и поговорить (чем и будет отличаться от джуна).
Бред. Если человек сразу кидается писать код — это не сеньор. Сеньор из вас сначала всю душу вытрясет, проясняя требования и зачем это вообще вам. Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.
Какие конкретно вопросы вы задали бы такому человеку с учётом того, что каждый из проектов он начинал с нуля в одиночку
Это уже фриланс какой-то, а не командная работа…
Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?
У меня есть ощущение, что вы вообще путаете сеньоров и менеджеров.
Только вот путаете Вы… Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде. Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер. Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются… Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно. Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.
Имхо, для сеньоров — это не простая задача, а тупая. И единственный ответ, который я бы от сеньора принял как правильный, — назначить этот таск джуниору или стажёру.
Вопросы, которые Вам выше писали тоже уместны, т.к. люди хотя бы пытаются понять с какого перепуга им прилетела эта задача, где в ней сложность, с которой не справился стажёр.
Если человек начинает решать такую задачу, то на должность сеньора он не подходит, т.к. не имеет навыков делегирования и проактивного подхода к задачам.
Это всё так, но вас послушать так программисты только и делают, что код пишут. Обсуждать идеи прежде, чем переводить их в код — очень даже полезно. И уж хватает методологий как это делать, чтобы не вызывать проблему постоянных отвлечений.
Не так много, нанимал около десятка, опрашивал соответственно в разы больше.
Тут если только вам поверить, я ни одного такого сеньора вживую не видел. Я допускаю, что есть куча сеньоров, которые не напишут на бумажке QuickSort, потому что в прошлый раз они этим интересовались 10-15 лет назад, или вообще на бумажке ничего не напишут, т.к. давным давно переложили автодополнение на IDE. Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.
Конечно, у каждой роли есть своя основная зона ответственности. Но на практике все эти границы размываются… И архитектор и тимлид могут сделать что-то в коде, а сеньоры обсудить архитектуру.
Если разделять прям строго, то всё закончится фигнёй типа "это не по моей части" и чехардой перекидывания ответственности друг на друга. Вот вы пишете "код и только код", т.е. такой сеньор в любой момент времени может сказать "я так сделал, потому что мне так сказали"… такой формализованный подход, без вникания в суть.
Не, для этой графы надо оставить табы vs пробелы.
Имхо, Вы переусложняете классификацию… Если tech lead больше архитектор, то чем он отличается от архитектора?
Вот тут немножко про ведущего программиста.
Я бы даже не стал строгой границы между тимлидом и сеньором проводить. Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации, который в силу роли просто несколько больше управленческой работы выполняет, чем обычный сеньор.
Всё, о чём Вы говорите, затрагивает только R&D.
И в данном контексте речь идёт по сути не о сеньорах, а об исследователях. Т.е. с одной стороны — да, человек, имеющий квалификацию сеньора, может выступать в роли исследователя. Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый. Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.
А кроме регламентных документов и телепатии Вы других способов общения не знаете?
Да бросьте, я спокойно доверяю людям в этом отношении. И не сомневаюсь, что отработав многие годы программистами они могут набрать код. Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.
Надо в следующую перепись населения включить вопрос: "На каких ЯП Вы программируете?" xD
Tech Lead, Lead Developer, ведущий программист — это просто альтернативные названия для Senior Developer.
И это не только моё частное мнение… Почти никто не разделяет эти роли. Вот для примера: What Defines a “Senior Developer?”
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Да тут уже давно не Ваш кейс обсуждают, а в целом подход, какими вопросами какой уровень можно проверить.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...
Потому что в одиночку. Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.
Другими словами, речь идёт об изначально никому ненужных проектах? Ну ok. Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали. Может Facebook и может себе позволить нанять людей просто про запас и дать им хобби-проектами под крылом компании заниматься. Но это просто индикатор, что до основных проектов вас пока не готовы допустить, даже в роли мидла.
С чего Вы это взяли? Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.
Вы имеете в виду само железо или прошивки под него? Второе, в принципе, возможно на удалёнке, но процент таких вакансий будет ниже, в силу специфики.
Причём тут предметная область? Сравните 2 вопроса:
1) напишите алгоритм группировки списка слов по таким-то условиям.
2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий. На первый вопрос адекватный сеньор (если уж ему такой вопрос всё-таки задали) сначала спросит "для чего?". Знаете в каком коде не бывает багов?
Бред. Если человек сразу кидается писать код — это не сеньор. Сеньор из вас сначала всю душу вытрясет, проясняя требования и зачем это вообще вам. Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.
Это уже фриланс какой-то, а не командная работа…
Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?
Только вот путаете Вы… Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде. Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер. Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются… Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно. Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.
Имхо, для сеньоров — это не простая задача, а тупая. И единственный ответ, который я бы от сеньора принял как правильный, — назначить этот таск джуниору или стажёру.
Вопросы, которые Вам выше писали тоже уместны, т.к. люди хотя бы пытаются понять с какого перепуга им прилетела эта задача, где в ней сложность, с которой не справился стажёр.
Если человек начинает решать такую задачу, то на должность сеньора он не подходит, т.к. не имеет навыков делегирования и проактивного подхода к задачам.
Вы, вроде, начали с "Причем, вакансия на сеньора".