Comments 218
Есть такая классификация программистов:
junior — легкие задачи решает сложно, сложные решить не может.
middle — легкие задачи решает легко, сложные сложно.
senior — все задачи решает легко.
junior — легкие задачи решает сложно, сложные решить не может.
middle — легкие задачи решает легко, сложные сложно.
senior — все задачи решает легко.
Да, подход частично имеет смысл. Хотя тут вопрос в том, что считать легким, а что — сложным (в Яндексе, в хостинге и в веб-студиях это будут задачи разного уровня).
Итого: не всегда в легкости и сложности задач дело.
- Senior все задачи могут решать легко, но уже не все задачи выполняют (для этого есть junior и middle)
- Middle решают уже очень многие задачи (и легкие и сложные), но им не системно, кругозора для вариативности решений + особо крупные задачи решать еще не в состоянии
- Хорошие Junior и Junior+ могут решать почти тот же набор задач, что и Middle, но не самостоятельно, а под надзором. И не оперируют полным набором факторов.
Итого: не всегда в легкости и сложности задач дело.
мне больше нравится такая классификация:
Middle — может выполнить проект в одиночку, без «оркестра»
Junior — не может
Senior — не будет.
В оригинале это шутка на баше, но по мне вполне себе реальный подход.
Middle — может выполнить проект в одиночку, без «оркестра»
Junior — не может
Senior — не будет.
В оригинале это шутка на баше, но по мне вполне себе реальный подход.
Какой-то маленький проект, видимо:)
В этом и шутка, что совсем не обязательно. И senior как раз это понимает, потому без оркестра делать не будет )
Не факт. Могут предложить проект на год и более в одно (или практически одно) лицо и миддл с радостью за него ухватится, если для него это первый шанс построить проект с нуля. Вполне возможно, что после такого проекта он уже может считаться сеньором. В том числе и потому что больше за такое не возьмётся :)
Я бы перевернул, и хуже не особо получается:
junior — все задачи решает легко (но в основном неправильно)
middle — сложные задачи решает легко (в основном костылями), легкие сложно (архитектуру там свою напридумать, потренировать новые фичи языков и фреймворков)
senior —cложные задачи решает сложно, а легкие легко решает больше проблем, чем создает в настоящем и в перспективе
junior — все задачи решает легко (но в основном неправильно)
middle — сложные задачи решает легко (в основном костылями), легкие сложно (архитектуру там свою напридумать, потренировать новые фичи языков и фреймворков)
senior —
А Что такое "сложная/легкая" задача и что такое "легко/сложно" решается?
То есть задача либо решается (и тогда она легка) либо не решается (и тогда она сложная). Разве тут есть средние варианты?
пытался пройти тестирование по ссылкам в конце статьи: после каждого ответа ERR_CONNECTION_RESET
Спасибо, что обратили внимание! Очень странно, такой ошибки не возникало в процессе. Иногда бывает, что нет связи с сайтом опросника, попробуйте через какое-то время пройти еще раз.
Очень странно, такой ошибки не возникало в процессе.
Только вчера обсуждал фундаментальный недочёт в подготовке программистов в плане софт-скилов, который приводит к этому классическому ответу "У меня работает/работало" xD
Как думаете, кому-то кроме Junior'ов допустимо пользоваться таким ответом?
А в чем вы видите проблему такого ответа?
потому что это совершенно не важно что и как работает у программиста. Работать должно у клиента.
А проблема ответа-то в чем?
Мне, кажется, вот этот ваш ответ гораздо хуже ответа "а у меня работает".
Проблема в том, что это никому не нужная информация не имеющая реального отношения к делу.
Почему же? Она имеет вполне отношение к делу, в частности: "Иногда бывает, что нет связи с сайтом опросника, попробуйте через какое-то время пройти еще раз.", а то, что "у нас работает" — это причина, по которой человек решил что проблема именно в отсутствии связи или чем-то подобном.
Какое же это "не имеет отношения к делу"?
Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет? Оно не работает у него, и только это его заботит.Единственное к чему она имеет отношение — к выяснению технических деталей инцидента. Но люди, которым этот ответ обычно дают, к такому выяснению обычно сами не причастны.
И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.
И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.
А чем разработчик поможет клиенту, если у разработчика работает, а у клиента не работает? Гадать на кофейной гуще? Дать рецепт «снести ОС, отформатировать все диски, установить с нуля конкретную версию ОС, установить программу согласно документации и больше на компьютер ничего не ставить?»
Люди, ответственные за выяснение технических деталей инцидента, должны выяснить эти детали, воспроизвести «не работает» и отправлять разработчику полное описание того в какой именно конфигурации окружения не работает. Да, бывают плавающие баги, но ответ разработчика «не могу воспроизвести „не работает“» вам понравится больше чем ответ «у меня всё работает»?
Люди, ответственные за выяснение технических деталей инцидента, должны выяснить эти детали, воспроизвести «не работает» и отправлять разработчику полное описание того в какой именно конфигурации окружения не работает. Да, бывают плавающие баги, но ответ разработчика «не могу воспроизвести „не работает“» вам понравится больше чем ответ «у меня всё работает»?
Определенно больше понравиться, хоть он и по прежнему плох. Из ответа «не могу воспроизвести» следует, что он пытался воспроизвести и у него не получилось. Из ответа «у меня все работает» вообще ничего не следует.
Хороший ответ должен давать информацию по следующим аспектам:
1. Насколько плотно работают над проблемой?
2. Когда она будет решена?
3. Требуется ли что-то, для того что бы задача была решена или решена быстрее?
По сути это единственное что волнует клиента, и как следствие, должно волновать разработчика. Ответ «у меня все работает» не отвечает ни на один из аспектов, более того, создает впечатление негативных ответов. Похоже, над проблемой сейчас не производится никаких работ, и не похоже что кто-то что-то делал. Вариант «не могу воспроизвести», означает что по крайней мере кто-то что-то попытался сделать, но ситуация по прежнему не улучшается.
Идеальный ответ звучит так:
«Наши лучшие специалисты в настоящий момент плотно работают над этим, ожидаем решения в течении часа. Ребятам здорово поможет, если вы дополнительно предоставите следующую информацию:
1.…
2. ....»
Хороший ответ должен давать информацию по следующим аспектам:
1. Насколько плотно работают над проблемой?
2. Когда она будет решена?
3. Требуется ли что-то, для того что бы задача была решена или решена быстрее?
По сути это единственное что волнует клиента, и как следствие, должно волновать разработчика. Ответ «у меня все работает» не отвечает ни на один из аспектов, более того, создает впечатление негативных ответов. Похоже, над проблемой сейчас не производится никаких работ, и не похоже что кто-то что-то делал. Вариант «не могу воспроизвести», означает что по крайней мере кто-то что-то попытался сделать, но ситуация по прежнему не улучшается.
Идеальный ответ звучит так:
«Наши лучшие специалисты в настоящий момент плотно работают над этим, ожидаем решения в течении часа. Ребятам здорово поможет, если вы дополнительно предоставите следующую информацию:
1.…
2. ....»
Так и вижу, спрашивает у меня начальник «ну что там с тем багом?», а я ему «Наши лучшие специалисты в настоящий момент плотно работают над этим...». Вот не могу решить, какая его реакция будет на это — уволит или скорую вызовет.
И варианты «не могу воспроизвести» и «у меня всё работает» означают почти одно и то же за исключением ситуаций типа «не могу воспроизвести, у меня комп сломался».
И варианты «не могу воспроизвести» и «у меня всё работает» означают почти одно и то же за исключением ситуаций типа «не могу воспроизвести, у меня комп сломался».
Ну в примере очевидно вариант ответа клиенту. По этому ощущение шизофрении при ответе начальнику нормально.
Для ответа начальнику очевидно достаточно «сейчас работаю над этим». В случае критичности проблемы можно сказать «отложил остальные задачи, сейчас работаю только над этим».
Ну и нужно понимать это это воображаемый пример который просто иллюстрирует как может звучать ответ, который отражает информацию по важным аспектам. Естественно его нужно допилить по месту.
Для ответа начальнику очевидно достаточно «сейчас работаю над этим». В случае критичности проблемы можно сказать «отложил остальные задачи, сейчас работаю только над этим».
Ну и нужно понимать это это воображаемый пример который просто иллюстрирует как может звучать ответ, который отражает информацию по важным аспектам. Естественно его нужно допилить по месту.
По месту такой ситуации вообще не должно возникнуть. Не потому что багов не должно быть, а потому что разработчик по вопросам «у меня ничего не работает» обычно не должен с клиентами общаться. А начальнику или саппорту вполне нормально сказать (или написать в причине реджекта тикета) «у меня всё работает» и адекватные коллеги должны понять, что недостаточно информации для воспроизводства бага.
Ну сейчас довольно можно вести прямой контакт между разработчиком и клиентом, сильно снижает уровень бюрократии и ускоряет коммуникацию.
Ну и «такой ситуации не должно возникнуть» так себе логика. По ней и багов то быть не должно. Пони, радуга, рок-н-ролл.
Ну и «такой ситуации не должно возникнуть» так себе логика. По ней и багов то быть не должно. Пони, радуга, рок-н-ролл.
Сомневаюсь, что обычный разработчик имеет подготовку для ситуаций типа «ниодногоразрыва».
а вы думаете откуда этот раздел про soft skills вырос. Лет десять назад такие вещи никого не волновали.
У нас кстати говоря разработчики работают с заказчиком напрямую. И в нескольких конторах до того, где я работал это происходило в той или иной степени.
Образ разработчика как нелюдимого тролля, говорящего не непонятном языке уходит в прошлое.
У нас кстати говоря разработчики работают с заказчиком напрямую. И в нескольких конторах до того, где я работал это происходило в той или иной степени.
Образ разработчика как нелюдимого тролля, говорящего не непонятном языке уходит в прошлое.
Раздел про soft skills явно вырос не из требований к сотрудникам первой линии по навыкам нейтрализации агрессии и прочей неадекватности клиентов.
В том числе. Там вообще большой список причин. Нынче разработчики это не только инженеры. Это еще и лицо компании, при том с разных сторон. И перед клиентом, и, например, перед рынком труда. По этому компании вкладываются в проведение мероприятий, отправляют своих инженеров спикерами. Ну и в командную игру нужно уметь. А так сложилось что это все довольно связанные вещи, и набор навыков для всего этого нужен плюс минус один и тот же.
Я знаю несколько непоследних компаний, в которых разработчики обязательно ходят на переговоры пре-сэйловские и выступают перед заказчиками на ПСИ (приемо-сдаточные испытания), даже презентации могут сами готовить. Не все, конечно, шибко рады, но, как говаривали выше, границы стираются. Плюс много небольших проектов, где разработки сами себе Руководители проектов и спецы, никто им не выделит отдельного супер-спикера.
Сейчас наверное все аутсорсеры так работают. В продуктовых компаниях еще можно как-то от клиента изолироваться, а вот в аутсорсе не выйдет. Особенно в проектах с совмещенными командами или под прямым управлением заказчика.
В таком аутсорсе я воспринимаю заказчиков как членов команды разработки, а клиенты в данном случае — клиенты этого заказчика.
В таком аутсорсе — это в каком? По сути аутсорс один, а это просто разные формы контрактов. Как правило аутсорсинговые компании не ограничивают себя какой-то конкретной формой сотрудничества и всегда готовы идти на встречу заказчикам. По факту это означает что у одной аутсорсинговой компании в работе как правило находятся контракты всех видов, и чем крупнее — тем большее разнообразие можно встретить.
В таком, где совмещенные команды или команды под прямым управлением заказчика. Ну и как-то так получалось в моей жизни, что ни разу аутсорсинговые компании не предлагали мне идти к ним «работу работать» (хотя и слышал о таком подходе типа «выметаем с рынка всё что есть, а проекты потом найдём») в роли разработчика (лид или архитектор — отдельный разговор), а предлагали конкретный проект без продолжения сотрудничества после его окончания, ну типа «постараемся что-то подобрать, если будет», но ни о каких «бенчах» не сообщали. Да я и не согласился бы наверное давать обязательство работать на любом проекте «куда Родина пошлёт». Поэтому на таких проектах я аутсорсера воспринимаю не столько как работодателя, сколько как посредника, а работодатель — заказчик, а клиенты — клиенты заказчика.
Видимо они до вас просто не добрались ) Обычно выметают с рынка все что есть что бы посадить на реальные проекты, спрос большой (у нас к примеру открыты вакансии в нескольких городах, мы как раз такая компания). Собственно частенько в компаниях существует перманентный дефицит который закрывают субподрядчиками.
Компании без бенча — не уверен что их можно называть аутсорс компаниями. Вполне себе тянет просто на посредника или биржу труда.
Компании без бенча — не уверен что их можно называть аутсорс компаниями. Вполне себе тянет просто на посредника или биржу труда.
Добирались компании, про которые я точно знаю, что бенч есть у них, но не на бенч мне предлагали, а конкретные проекты без описания того, что будет после — увольнение или бенч. Просто с предложениями «идите к нам — мы вам кучу всяких проектов дадим лет на 10 минимум, а не найдём — будете просто так деньги получать эти 10 лет» не обращались. :) А если бы обратились — не уверен, что согласился бы, ведь, как я понимаю, с бенча идёшь на проект, на который скажут, а не на который хочешь. Скажут «тыжпрограммист, разберёшься с кучей легаси и фреймворками, которые тебе не нравятся архитектурно»
Ну мы так даже конкретный проект обычно не предлагаем. Они у нас идут паровозами, и отправляются достаточно рандомно, так что на момент собеседования вообще сложно что-то сказать. Пока идет собеседование и найм, некоторые проекты можно и сделать успеть, даже такое бывает. Особенно если кандидат просит 1.5 месяца на переход.
А вот с выбором проекта это да, боль. Обычно куда поставят — туда поедешь, без вариантов. Это практически везде. Мы стараемся наверное больше остальных упарыватся подбирать проекты под людей, но сколько усилий не трать — гарантии получить проект не выходит. Но управление бенчом это тема для отдельного разговора.
А вот с выбором проекта это да, боль. Обычно куда поставят — туда поедешь, без вариантов. Это практически везде. Мы стараемся наверное больше остальных упарыватся подбирать проекты под людей, но сколько усилий не трать — гарантии получить проект не выходит. Но управление бенчом это тема для отдельного разговора.
Ну значит или мне везёт, или они как-то догадываются, что за такой режим работы я запрошу компенсацию намного выше той, что мне предлагают на конкретных проектах.
А что с управлением бенчом — ад? У меня нет особого опыта, есть только галлюцинации, что на бенчах сидят только средненькие миддлы и джуны (которых вообще трудно пристроить), и сложность только в том, чтобы с бенча их в проект какой угодно сбыть… Не так?
там уйма противоречивых требований которые очень не любят складываться.
К примеру — выпадает человек на бенч, подбираешь ему хороший проект, а он не стартует. Заказчик маринует месяц, потом второй, третий…
Новички(кто только пришел в компанию) очень не любят сидеть на бенче. Поскольку ежели я вам так нужен, что вы меня наняли, как так что для меня проекта нет? А именно их сложнее всего пристроить.
И да, на бенче чаще всего сидят миддлы и джуны, но именно им бенч меньше всего интересен и нужен — на бенч лучше всего сажать старших, что бы хоть передохнули между проектами, но их оттуда оттаскивают в первую очередь.
Это только в общих чертах. При этом бенч довольно важная штука в профилактике выгорания, росте и развитии компании, и качество управления им имеет очень большое значение для компании. Но управлять им — реальный ад. Почти всегда выбираешь наименее отвратительное решение, удачные и верные ходы — большая редкость.
К примеру — выпадает человек на бенч, подбираешь ему хороший проект, а он не стартует. Заказчик маринует месяц, потом второй, третий…
Новички(кто только пришел в компанию) очень не любят сидеть на бенче. Поскольку ежели я вам так нужен, что вы меня наняли, как так что для меня проекта нет? А именно их сложнее всего пристроить.
И да, на бенче чаще всего сидят миддлы и джуны, но именно им бенч меньше всего интересен и нужен — на бенч лучше всего сажать старших, что бы хоть передохнули между проектами, но их оттуда оттаскивают в первую очередь.
Это только в общих чертах. При этом бенч довольно важная штука в профилактике выгорания, росте и развитии компании, и качество управления им имеет очень большое значение для компании. Но управлять им — реальный ад. Почти всегда выбираешь наименее отвратительное решение, удачные и верные ходы — большая редкость.
да да, чаще слышишь от клиента «у меня не работает», а что где как не работает — это он выразить не в силах…
Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет?
Клиенту поможет совет попробовать еще раз через некоторое время. А "у меня работает" — лишь объяснение того, почему совет именно такой, а не какой-то другой. Просто чтобы клиент понимал, почему ему дали такой совет.
И да, «попробуйте еще раз через 5 минут» это допустимый ответ.
Так именно такой ответ выше и был дан.
Ну собственно речь о том, что «у меня работает» не может быть ответом. Может быть дополнительной информацией, пояснением к ответу, но самим ответом должно быть что-то другое. А иногда приходится сталкиваться с тем, что разработчик считает, что это может сойти именно за ответ.
Этот ответ означает «я пытался воспроизвести — не получилось». Ну и может иметься в виду «приходите, когда добудете от клиента больше информации», если разработчик считает, что проблема всё-таки в его коде, а не каком-нибудь (анти)вирусе, который что-то заблокировал.
Может. А может означать что ткнул пару раз, решил что муть какая-то и решил просто ничего не делать. А может там вся команда бьется над решением с привлечением смежных департаментов. Собственно это и значит что он не сообщает нужной вопрошающему информации. Вообще никакой кроме того, что судя по всему, что-то идет не так.
«О Великий Думатель, я хочу услышать ответ четкий и ясный, дай нам ответ на главный вопрос» (с)
«О Великий Думатель, я хочу услышать ответ четкий и ясный, дай нам ответ на главный вопрос» (с)
"Мы усиленно работаем над вашей проблемой" точно так же может значить что угодно.
Это значит что над ней по крайней мере работают. «у меня все работает» вообще ничего не значит.
Это значит что над ней по крайней мере работают.
Поверьте, совсем не значит.
ну если разработчики напрямую врут, то тут есть проблемы посерьезнее некорректных формулировок.
Почему же врет? Это все ваша интерпретация. "Мы усиленно работаем" = баг завели, он теперь в трекере (= в работе) и возможно даже не с минимальным приоритетом (= не просто работаем, а усиленно!). Все по-честному, и когда-нибудь до него у кого-нибудь дойдут руки.
Потому что если человек говорит «мы усиленно работаем», а на деле не делается ровным счетом ничего — это ложь как ни заморачивайся с интерпретациями. Все эти «ну он же в багтрекере есть» это пустые отмазки, а не интерпретации.
Это может быть не ложь, а заблуждение. Посмотрел на статус тикета, назначенного на другого человека, он активный и сообщаешь эту информацию.
Потому что если человек говорит «мы усиленно работаем», а на деле не делается ровным счетом ничего — это ложь
Ну как же ложь, если нет. Баг в трекере — значит над ним работают, по факту.
Софистикой не страдайте. Когда к вам начальник придет и спросит что было сделано за неделю такой «усилинной работы» вы о чем отчитаетесь? «Мы баг в прогресс перевели»?
Софистикой не страдайте.
Какая софистика? Над багом работают — это факт. Что вас не устраивает? или пол "работать" следует понимать исключительно момент написания кода? А если человек, ответственный за этот баг, в этот момент задумался о чем-то или пописать отошел — то все, никто над багом не работает, вывсеврети?
Когда к вам начальник придет и спросит что было сделано за неделю такой «усилинной работы» вы о чем отчитаетесь?
Если ничего не сделано — то о том, что ничего не сделано. А о чем еще отчитываться? И к чему этот вопрос?
удивительно что такой простой факт — производится работа или нет у вас вызывает сложности.
Производство работы это процесс. Состояние бага в багрекере это не процесс. Либо кто-то работает над задачей, либо нет. Вы сами сказали — статус выставили, и «когда-нибудь до него у кого-нибудь дойдут руки». Это совсем не тоже самое что «задумался о чем-то или пописать отошел».
Либо работа реально реально производится, либо нет. Работа это любая деятельность направленная на решение проблемы, будь то написание кода, либо просто размышление над задачей или общение с закачиком, это не важно. Если работа не производится, а разработчик говорит, что «мы плотно работаем», то это ложь. Независимо от того какие там статусы в багтрекере. Перевод статусов в багтрекере не способствует решению задачи.
Либо работа реально производится и кто-то над ней работает и тогда все ок.
Если вы не понимаете таких довольно простых вещей, не вижу большого смысла с вами обсуждать более сложные аспекты коммуникации
Производство работы это процесс. Состояние бага в багрекере это не процесс. Либо кто-то работает над задачей, либо нет. Вы сами сказали — статус выставили, и «когда-нибудь до него у кого-нибудь дойдут руки». Это совсем не тоже самое что «задумался о чем-то или пописать отошел».
Либо работа реально реально производится, либо нет. Работа это любая деятельность направленная на решение проблемы, будь то написание кода, либо просто размышление над задачей или общение с закачиком, это не важно. Если работа не производится, а разработчик говорит, что «мы плотно работаем», то это ложь. Независимо от того какие там статусы в багтрекере. Перевод статусов в багтрекере не способствует решению задачи.
Либо работа реально производится и кто-то над ней работает и тогда все ок.
Если вы не понимаете таких довольно простых вещей, не вижу большого смысла с вами обсуждать более сложные аспекты коммуникации
Вы не отличаете ложь от заблуждения? Если разработчик видит статус у тикета, назначенного на qa «In analysis», то разве он не имеет полного права сказать «мы плотно работаем»?
отличаю, а вы? Таки между заблуждением и распространением заблуждений есть весьма заметная разница.
И сказать то он может все что угодно, но за слова отвечать потом придется самостоятельно. В частности если вдруг язык повернулся отчитался что «плотно работаем» глядя чисто на статус тикета, неплохо бы пойти потом и проверить, что работа реально происходит.
И сказать то он может все что угодно, но за слова отвечать потом придется самостоятельно. В частности если вдруг язык повернулся отчитался что «плотно работаем» глядя чисто на статус тикета, неплохо бы пойти потом и проверить, что работа реально происходит.
Проверять чужую работу обычно в компетенции разработчика не входит (речь не про код ревью). Есть специально обученные люди, одна из задач которых состоит в том, чтобы статусы тикетов отражали реальное положение дел. Часто название их позиции содержит слово «менеджер» или «лид».
Люди, в чью компетенцию не входит проверять чужую работу и не отвечают о состоянии работ по задачам опираясь на статус тикета в багтрекере. Они и без багтрекера прекрасно знают работают они над задачей или нет.
Почему не отвечают? Я даже непосредственному начальнику отвечаю, что, например, такой-то багфикс в QA, хотя он сам может посмотреть. И вопрос не «ты работаешь или нет над багом», а «что с тем багом?»
Да, но давайте все таки вернемся к кейсу «мы плотно работаем» в том конкретном случае, когда на самом деле нет. Вы же не скажете «багофикс в QA, тестеры над ним активно работают» опираясь чисто на статус в багтрекере. Только в том случае если есть реальная информация, что они действительно над ним работают.
Опираясь на статус багов отчитываются только те, у кого есть менеджерские обязанности(бывает и разработчики). Остальные отчитываются в основном только за себя (где обладают полной информацией), либо если обладают реальной информацией о других, в которой они точно уверены, например видели своими глазами.
Опираясь на статус багов отчитываются только те, у кого есть менеджерские обязанности(бывает и разработчики). Остальные отчитываются в основном только за себя (где обладают полной информацией), либо если обладают реальной информацией о других, в которой они точно уверены, например видели своими глазами.
Почему не скажу? Вполне могу сказать, если в целом знаю, что статусы соответствуют действительности в компании.
Не «ничего не делать», а «отреджектить тикет с возможным(!) багом» на уточнение условий воспроизведения. Если в тикете есть условия воспроизведения фактические, то «пару раз ткнул» не по ним — повод задуматься об неполном или ненадлежащем исполнении задач. А если их нет или формально есть, но по ним баг не воспроизводится, то обычно попытки их воспроизвести, гадая на кофейной гуще — нецелевая трата ресурса разработчика.
Естественно исхожу из ситуации, когда тикет с багом не приходит с комментарием от начальника типа «Бросить всё и исправить любой ценой, забив на все остальные задачи. Даю полномочия на прямой контакт с клиентом с целью получения условий воспроизведения и согласования пути решения»
Естественно исхожу из ситуации, когда тикет с багом не приходит с комментарием от начальника типа «Бросить всё и исправить любой ценой, забив на все остальные задачи. Даю полномочия на прямой контакт с клиентом с целью получения условий воспроизведения и согласования пути решения»
заявить «у меня все работает» и «уточнять условия вопроизведения», «отреджектить тикет» это таки две большие разницы. Это может происходить одновременно, а может и не происходить. Тикет может висеть открытым годами, и по нему не будет ничего не происходить, потому что «у меня не воспроизводится», где подразумевается «фиг знает что с ним делать». Весьма распространенная ситуация. Видел такое в разных компаниях, в том числе крупных и известных.
Реджект «У меня не воспроизводится»/«у меня всё работает» подразумевает, что тикет висит на ответственном за сбор дополнительной информации об инциденте.
Как я уже написал выше, совсем не обязательно подразумевает. Это также может подразумевать «фиг знает что с ним делать, займусь пока чем то поважнее, может потом в голову чего придет».
Это вообще все что угодно может подразумевать. Сама фраза, как я уже сказал, не несет ровным счетом никакой полезной информации. Все остальное — домыслы, попытки опереться и угадать исходя из дополнительного контекста, что же разработчик имел ввиду.
Это вообще все что угодно может подразумевать. Сама фраза, как я уже сказал, не несет ровным счетом никакой полезной информации. Все остальное — домыслы, попытки опереться и угадать исходя из дополнительного контекста, что же разработчик имел ввиду.
Флоу разные бывают, да и в разных ситуациях разные нюансы могут быть. Но фраза «у меня работает» всё же несёт информацию о том, что разработчик пытался воспроизвести баг (ложь во внимание не принимаем), но не смог.
В нашем же случае речь идет скорее о работе стейкхолдера. Тест расположен на стороннем сервисе, на который работу которого мы не влияем. Можем жаловаться, но масс-маркет подход стейкхолдера избавляет нас от шансов на успех. Знаю, что и в компаниях происходят такие случаи (когда на аутсорсе целые компании и они косячат). Как (кроме категорической замены стейкхолдера) регулируются такие случаи?
В том, что это не ответ, а попытка переложить ответственность. Раз "такой ошибки не возникало", то разработчик типа уже не причем. Способность брать на себя ответственность и не отмазываться — крайне важный навык для всех разработчиков, начиная с мидла, а также для всех менеджерских должностей. Причём совершенно неважно, кто конкретно косякнул, при вопросах извне любой член команды может признать ошибку, извиниться, проинформировать о процессе решения вопроса. Иначе всё перерастает в перекидывание ответственности и поиск козла отпущения, иногда и в виде клиента.
Ответственность за что? За трату рабочего времени на гадание на кофейной гуще в попытках воспроизвести проблему без прямого указания начальства на то?
И не «разработчик типа уже не причем», а «не в моей компетенции устраивать клиенту допрос с пристрастием, для выяснения того чем его конфигурация отличается от рекомендованной, а, тем более, чем конфигурация продакшена, к которой у меня нет доступа, отличается от рекомендованной».
И не «разработчик типа уже не причем», а «не в моей компетенции устраивать клиенту допрос с пристрастием, для выяснения того чем его конфигурация отличается от рекомендованной, а, тем более, чем конфигурация продакшена, к которой у меня нет доступа, отличается от рекомендованной».
Ответственность за что?
Профессиональная ответственность за получившийся результат. Она есть практически во всех профессиях, но среди программистов, к сожалению, очень распространен подход сделать "для галочки".
Представьте, что вы купили машину, выехали из автосалона, а она разгоняется максимум до 30 км/ч и при этой скорости начинает дребезжать так, что вот-вот детали отваливаться начнут. Норм? А в программных решениях такое сплошь и рядом происходит.
не в моей компетенции
Ну, если не в вашей компетенции, то оставьте общение с клиентами тем, в чьи компетенции это входит. Всё просто же.
его конфигурация отличается от рекомендованной
Для начала надо ещё доказать, что проблема в этом. И спойлер: чаще всего проблема не в этом.
Результат вот он, на моей локальной машине, развёрнутый с нуля в виртуалке или контейнере по согласованной и утверждённой инструкции скриптами разворачивания, лежащими в продакшен ветке репозитория.
Собственно я и намекаю, что разбор инцидентов с клиентами не дело разработчика в общем случае, если не учитывать «тыжпрограммист».
Собственно я и намекаю, что разбор инцидентов с клиентами не дело разработчика в общем случае, если не учитывать «тыжпрограммист».
Допустимо всем при наличии процессов синхронизации дев-окружений со всеми остальными и выполнением всех действий по ним со своей стороны. Как абстрактный пример — если я внёс изменения в какой-то список пакетов для установки на сервере, а кто-то накатал остальные артефакты на сервер, но шаг установки пакетов пропустил «для скорости, всё равно раз в год меняется список», то вполне нормальный ответ.
После прочтения списка софт-скилов (особенно про «взять под крыло всю команду») возник вопрос: а что в этой парадигме остается тим-лиду? Или позиция тим-лида окончательно откатилась в менеджерскую сферу и с командой-аджайлами-проектированием уже никак не связана?
Видимо сеньёр это звание, а тимлид это должность.
Вряд ли. Потому как ему в довесок же еще будет всевозможное представление команды внешнему миру и пр. И в то же время выше в «жестких» скилах сказано, что нужно и фреймворки когда-то изучать =)
Т.е. вряд ли без ущерба для здоровья можно совмещать тимлида и супер-синьора. Либо я таки чего-то не понимаю.
Т.е. вряд ли без ущерба для здоровья можно совмещать тимлида и супер-синьора. Либо я таки чего-то не понимаю.
Так и есть. Жуткие штрафы за мульти-классовость. Видел лично, много раз, что совмещение менеджера со специалистом не бывает без ущерба роли «менеджера» или «специалиста».
Давайте так: если софт-скилл-часть у специалиста хорошо прокачана, то, скорее всего, он и сам не будет против совмещения — захочет двигаться дальше. Если прямо плохо, то скорее всего, у него будут те или иные сложности в работе. Зависит от степени сложностей, конечно. Мы для себя принимаем, что хорошему профессионалу достаточно среднего значения. А по тесту мы видим, что ему проще и лучше бы развить, а что несовместимо с его собственными желаниями роста
Чудес не бывает. Будет средний специалист и хороший менеджер. Либо средний менеджер и хороший специалист.
И как бы средний специалист это вредитель на большом проекте, средний менеджер это вредитель на любом проекте.
И как бы средний специалист это вредитель на большом проекте, средний менеджер это вредитель на любом проекте.
тут дело не столько в мультиклассовости, а в том что тимлид решает вопросы на другом уровне. Он оперирует архитектурой, и крупными блоками, не закапываясь в мелкие детали. Делает он это по прежнему руками (к примеру архитектор обычно уже нет). Тем не менее в детали обычно закапываются другие, за исключением случаев требующих особой квалификации или знаний. Это просто более высокий уровень абстракции, а не другой класс работы.
Хотя конечно, от компании зависит. Бывает по всякому.
Хотя конечно, от компании зависит. Бывает по всякому.
Пункт про фреймворки вообще странный, если человек концепции понимает, то нет никакого смысла изучать все фреймворки про запас.
Я придерживаюсь мнения, что «изучать фреймворки» полезно для поиска новых концепций (e.g. ECS, Sagas — из последнего для меня). Но в то же время есть фреймворки достаточно устоявшиеся и их специфику лучше знать.
Что такое ECS и Sagas?
ECS: habr.com/post/343778
Саги: habr.com/company/avito/blog/418235
Не уверен, лучшие ли это статьи — просто для пояснения нашел
Саги: habr.com/company/avito/blog/418235
Не уверен, лучшие ли это статьи — просто для пояснения нашел
Отличный вопрос, спасибо. Действительно, в последние годы мы явно видим именно такую тенденцию — руководители и CEO уходят функциями на уровень развития компании и направлений, больше занимаются кросс-функциональными вопросами и стратегиями, а тимлидам отходит все больше функций операционного менеджмента, ну а продвинутые senior-ы — все больше рулят технической стороной дела и помогают тимлидам. Так что возможностей для роста каждого — все больше) Было бы желание и способности
Такие ощущения и были, да. Вот только «возможностей для роста» я тут не вижу — просто «растянули» существующие позиции.
Ну, и в качестве отвлеченного замечания: это что же, теперь синьор еще и людей любить должен?!!!
Ну, и в качестве отвлеченного замечания: это что же, теперь синьор еще и людей любить должен?!!!
Скорее, это некое расслоение внутри большого уровня «Senior»: тот, кто может любить людей и ориентируется на вертикальную административную карьеру прокачивает софт-скиллы и все больше перенимает функций тимлида, чтобы со временем им стать. Те, кто ориентируются на развитие по технической части, тоже особо не могут себе позволить нелюбить людей, потому что Тех, к примеру,-лид и Архитектор тоже должны уметь с людьми конструктивно работать. Ну, а если уровня крепкого Senior достаточно, то, как минимум, все равно нужно хорошо взаимодействовать в команде, конструктивно договариваться и брать на себя ответственность за довольно большой кусок своей работы. Ответ — все равно «да», вопрос только дозы любви)
Кстати, во многих крупных/продвинутых компаниях выкристаллизовалось и направление скрам-мастера отдельное. Если Senior-у ориентироваться на эту ветку развития, то придется изучать методологии плотнее. И все равно: тот же набор софт-скиллз как база останется и там.
Ему хард-скиллы сеньора зачем?
А это их база, они изначально разработчики и развиваются как разработчики. Доходят до какого-то заметного уровня и, если хотят развиваться дальше таким путем, перестают качать хард. Но при этом до Senior-то уровня они уже добрались
Я к тому, что, по-моему, на скрам-мастера можно хоть с джуна начинать учиться, а может даже лучше вообще не иметь технического бэкграунда, чтобы, например, не занимать подсознательно ту или иную сторону в разгоревшемся споре.
Можно, только никто не будет джуна серьезно воспринимать. Чтобы стать скрам-мастером и команда приняла в таком качестве надо сначала себя спецом здорово показать. Иначе никакое руководство не будет поддерживать и вкладываться в развитие. Будут говорить: скрам — прекрасно, а когда кодить нормально начнешь? У нас пока что все-таки движение очень линейное
Скрам-мастер не является членом команды разработки, его функции чисто менеджерские.
А вот даже и не менеджерские =D Его задача фа-си-ли-ти-ро-вать аджайл практики в команде, простиоспади.
Главное суть — управлять людьми, говорить им что делать и что не делать :)
Тимлиду — заниматься мотивацией команды
Есть такое понятие как наставничество. Вот оно как раз относится к софт. Умение быть хорошим наставником полезный навык.
Это мне? Про тим-лида? Можно как-то перефразировать — я не уверен, что правильно понял ответ.
Да, ответ вам.
Просто авторы различных книжонок и рекомендаций вкладывают в софт скилс под управлением, в первую очередь навык наставничества. Не знаю откуда пошла эта мода но в здоровых коллективах оно выстраивается естественно. В каждой команде есть старожил который расскажет подробно о всех явных и не явных процессах в компании.
Просто авторы различных книжонок и рекомендаций вкладывают в софт скилс под управлением, в первую очередь навык наставничества. Не знаю откуда пошла эта мода но в здоровых коллективах оно выстраивается естественно. В каждой команде есть старожил который расскажет подробно о всех явных и не явных процессах в компании.
Более того — одна функция, но обилие навыков: организация своей работы и ближнего, коммуникация и аргументация, дробление задач больше-мельче/сложнее-проще, зачатки планирования и контроль, где-то и мотивация с поддержкой… Плацдарм для менеджмента, по сути
посмотрел требования к super senior, и даже не понял, это о senior или junior? «понимание принципов ООП», «шаблоны проектирования», «система контроля версий», это все от джунов требуют. Остальные форумлировки оставляют желать лучшего. Вот если взять все эти формулировки и перенести их в резюме, я бы не смог классифицировать его между middle и senior. Тут же фокус не в том чем владеть, а на каком уровне. Для мидла вполне себе нужно уметь развернуть, настроить и поработать с NoSQL, тем более что одно дело поработать с редисом, а другое — с эластиком. Для сениора уже недостаточно просто «иметь навыки управления», он уже должен всю внутреннюю механику понимать, и желательно в деталях.
По проблемам с софт скилами, тут мне кажется основное дело вот в чем. Как правило требования к ним растут не линейно. По факту обычно сидит человек кодит себе, никого не трогает, качает свои хард скилы. А в один прекрасный день к нему приходит менеджер и говорит, теперь ты будешь тимидом. Что это такое, как это делать, никто не объяснит. На курсы тоже не отправят. Вот тебе проблемы, разгребай. И дальше начинают прилетать проблемы. Ты чего своих не менторишь? А что надо было? И в том же духе. Сверху начинают сыпаться одни только проблемы, получается негативное закрепление. В итоге большая часть говорит, что нафиг мне такое счастье? Кодил себе и все хорошо было. Нафиг качать эти софт скилы, от них проблемы одни.
А качать их это хорошо, правильно, и классно. Просто далеко не везде.
По проблемам с софт скилами, тут мне кажется основное дело вот в чем. Как правило требования к ним растут не линейно. По факту обычно сидит человек кодит себе, никого не трогает, качает свои хард скилы. А в один прекрасный день к нему приходит менеджер и говорит, теперь ты будешь тимидом. Что это такое, как это делать, никто не объяснит. На курсы тоже не отправят. Вот тебе проблемы, разгребай. И дальше начинают прилетать проблемы. Ты чего своих не менторишь? А что надо было? И в том же духе. Сверху начинают сыпаться одни только проблемы, получается негативное закрепление. В итоге большая часть говорит, что нафиг мне такое счастье? Кодил себе и все хорошо было. Нафиг качать эти софт скилы, от них проблемы одни.
А качать их это хорошо, правильно, и классно. Просто далеко не везде.
UFO just landed and posted this here
«Принятие ответственности в сферах: целей и планов, профессиональных взаимоотношений, руководства, карьерного развития» — ответственность это хорошо, но о чём здесь речь?
ну тут мне как раз понятно, тут формулировка размытая, ибо в разных компаниях это очень разная деятельность. Но это как раз менторство, аттестации, индивидуальные планы развития, вот это все. Тут даже для одной компании сложно внятно сформулировать, а уж для рынка и вовсе никак лучше не скажешь.
Ощущение от всего этого описания и теста, что Сеньор — этакая палочка-выручалочка: придёт и молча исправит всё. Даже то, что вне его сферы ответсвенности.
Ну вроде так и есть. Разве нет? По опыту чего-то такого от сениоров и ждут.
Размытые формулировки еще не беда. Проблема в том, что в большинстве случаев ни в требованиях, ни внутри компании ими открыто не оперируют, но по ним оценивают и «отказывают». Мы вытаскиваем их на свет божий) В статье мы привели лишь названия критериев в двух софт-скиллз блоках. В интерпретации к тесту мы даем более развернутое представление о каждом критерии и степени его развития. Чтобы сделать это здесь потребовалась бы отдельная статья
Действительно, проблема разной оценки специалиста самим специалистом и руководителем нередко случается. Поэтому мы и считаем, что важно не только выяснять по каким конкретно критериям руководитель отказывает, но и воспользоваться как можно бОльшими альтернативными источниками оценки по этим критериям. Потому что, с одной стороны, сам специалист может не видеть дефицитов (особенно если скиллы по этим критериям крайне слабо развиты — это классика), а с другой — и у руководителя могут быть свои причины не продвигать сотрудника.
Если senior — это супер-профессионал высокого уровня, то он, безусловно, выручалочка) Не зря у него и статус, и ЗП соответственные. Хотя, конечно, не волшебник. Тут перегибать не стоит.
Если senior — это супер-профессионал высокого уровня, то он, безусловно, выручалочка) Не зря у него и статус, и ЗП соответственные. Хотя, конечно, не волшебник. Тут перегибать не стоит.
UFO just landed and posted this here
Ну вообще это отдельный актуальный и не раскрытый в статье вопрос. На самом деле сейчас от сениоров многие ждут не просто технических решений. От них ждут технических решений на уровне бизнеса, т.е. в том числе иногда и бизнес решений.
Другими словами нужен инженер который не просто пишет код, а делает продукт, а код это уже второстепенно. И сфера компетенции в таком случае естественным образом значительно размывается.
Правда разные компании находятся на разных стадиях осознания процесса. Кто-то явно понимает и открыто об этом говорит, а кто-то выстраивает непонятные абстрактные формулировки, за которыми можно только догадываться.
Другими словами нужен инженер который не просто пишет код, а делает продукт, а код это уже второстепенно. И сфера компетенции в таком случае естественным образом значительно размывается.
Правда разные компании находятся на разных стадиях осознания процесса. Кто-то явно понимает и открыто об этом говорит, а кто-то выстраивает непонятные абстрактные формулировки, за которыми можно только догадываться.
Полностью согласны! Чем выше уровень, тем больше бизнес-ожиданий накладывается. И там границы ответственности провести сложнее. Однако во все времена, чем большими факторами человек оперирует, чем шире поляну видит: целый продукт, продуктовая линейка/направление, компания и бизнес-сфера, их возможности/ограничения + все вариации технологических решений под это — тем выше он будет цениться.
Ну тут дело не только в высоте позиции. Есть еще такая штука как уровень развития компании (я сейчас про спиральную динамику и бирюзовые организации). По мере продвижения самой компании уровни ответственности начинают размыватся на всех уровнях иерархии. Как, впрочем, и сама иерархия.
Уровни начинают развиваться — точно. Но не степень личностной ответственности каждого. Один из краеугольных камней бирюзовых организаций именно в том, что члены команды разделяют высокую степень ответственности. Именно поэтому структура способна быть плоской, а руководителя в официальном эквиваленте вообще уже может не быть. Бирюза — она для высокооответственных и прокачано софт-скилловых, иначе все развалится)
Там дело не только в высокой ответственности и количестве софт скилов, там вообще огромный спектр требований. Нужно до идеала надраить все предыдущие уровни — и иерархическое управление, и роль индивидуума, и культурный слой, шаринг знаний, список длинный. Но сейчас речь не об этом.
В бирюзовых организациях любой сотрудник имеет возможность проводить изменения любого уровня. По сути, даже джун, может проводить изменения на уровне компании, то что в классической схеме управления часто может сделать только владелец компании. Это таки очень сильно увеличивает степень ответственности на всех уровнях, особенно на низких (на высоких она наоборот снижается, происходит выравнивание).
В бирюзовых организациях любой сотрудник имеет возможность проводить изменения любого уровня. По сути, даже джун, может проводить изменения на уровне компании, то что в классической схеме управления часто может сделать только владелец компании. Это таки очень сильно увеличивает степень ответственности на всех уровнях, особенно на низких (на высоких она наоборот снижается, происходит выравнивание).
Люблю говорить на собеседованиях: «хочу решать бизнес-задачи техническими методами» :)
> Вот допустим человек считает, что достоен повышение, а руководство отказывает. Что тогда? Ответственно сменить работу? Или не сменить и ответственно гребсти на галере?
Узнать причину отказа, выяснить что нужно сделать (грубо, какие скиллы прокачать), чтобы не отказали в следующий раз, оценить стоит ли овчинка выделки в данной компании и принять решение либо качать тут, либо качать в другом месте (грубо, курсы тимлидов), пока оставаясь тут работать, или качать в другом месте и работать в другом месте. А может в другом месте уже сочтут, что достаточно прокачен.
Узнать причину отказа, выяснить что нужно сделать (грубо, какие скиллы прокачать), чтобы не отказали в следующий раз, оценить стоит ли овчинка выделки в данной компании и принять решение либо качать тут, либо качать в другом месте (грубо, курсы тимлидов), пока оставаясь тут работать, или качать в другом месте и работать в другом месте. А может в другом месте уже сочтут, что достаточно прокачен.
UFO just landed and posted this here
Далеко не все знают правильные ответы на вопросы типа «Полчаса до конца рабочего дня, приходит критикал баг с высшим приоритетом. Начинаете разбираться, прошло 25 минут, но даже локализовать не получилось. Ваши действия?». Хотя бы потому что в разных компаниях или даже у разных руководителей разные понятия об ответственных действиях в данной ситуации.
Если без конкретики, то надо валить, если реально хочешь повышения. Возможно не сразу, а найдя что-то взамен предварительно, причём прямо на собеседованиях спрашивая «сейчас я пришёл сеньором, но через год вижу себя в вашей компании тимлидом. Вот вы меня поизучали, допустим делаете оффер и я его принимаю — скажите, что мне конкретно нужно ещё изучить-освоить чтобы при открытии такой вакансии вы её мне предложили? У вас внутренние курсы или типа того есть для этого? » На удивление, часто рассказывают. Ну или отвечают так, что даже если оффер будет, то принимать его не станешь.
Если без конкретики, то надо валить, если реально хочешь повышения. Возможно не сразу, а найдя что-то взамен предварительно, причём прямо на собеседованиях спрашивая «сейчас я пришёл сеньором, но через год вижу себя в вашей компании тимлидом. Вот вы меня поизучали, допустим делаете оффер и я его принимаю — скажите, что мне конкретно нужно ещё изучить-освоить чтобы при открытии такой вакансии вы её мне предложили? У вас внутренние курсы или типа того есть для этого? » На удивление, часто рассказывают. Ну или отвечают так, что даже если оффер будет, то принимать его не станешь.
Ответственность, пожалуй, самая сложная тема. Мало кто умеет ее оценивать. Мы по этому блоку (внешний-внутренний локус контроля по-психологически) приводим в тесте и интерпретациях вполне конкретные критерии и их расшифровку. Некие ориентиры это показывает — в каких направлениях человек более склонен брать на себя ответственность, а в каких -сливать или ожидать от других. У нас, конечно, очень краткая версия — но и собеседования никто не отменял.
UFO just landed and posted this here
ХМ, гиперответственность — это когда человек захватывает слишком много ответственности на себя и уже несколько в ущерб окружению. Этакий герой, который тянет на себе все до чего может дотянуться, и стонет от натуги. При этом остальные либо расслабляются (зачем напрягаться, герой сам все сделает), либо раздражаются, потому что им достается меньше и они не растут. Кажется, Вы имеет ввиду что-то другое. Например, когда вменяют в ответственность то, что делать не хочется или кажется, что лежит на чужой территории? Так?
Пока по личной практике гиперответственность это скорее плюс. Она конечно создает некоторые неудобства, но они с лихвой окупаются плюсами.
Гиперответственность — работа на износ. Ну и плюсы у неё появляются, по-моему, только если рядом чья-то безответственность.
Ну как тут было уже в комментариях, при росте в должности зоны ответственности обычно размываются. Тоже происходит при развитии компании в сторону самоорганизации. А при росте в должности, в компании растущей в сторону самоорганизации — размытие идет в квадрате. И обычно людей надо учить тому, как правильно в такой среде жить. И это не просто. Гиперответственных учить не нужно, даже наоборот, на них в этом вопросе нужно положится. Они сразу себя чувствуют в такой среде как рыба в воде.
А вот работа на износ, это да. С любопытством наблюдаю за такими. Пока вроде никто из тех за кем наблюдаю не сгорел за несколько лет. Но кто знает.
А вот работа на износ, это да. С любопытством наблюдаю за такими. Пока вроде никто из тех за кем наблюдаю не сгорел за несколько лет. Но кто знает.
UFO just landed and posted this here
Причём тут «не соблюдает субординацию»? Дать предложение непосредственному начальнику или стейкхолдеру, который ставит задачу, субординацию не нарушает.
UFO just landed and posted this here
Мы против крайностей. И согласны с предыдущим оратором. Я знаю много компаний, в который «в твоей власти» много зон, где ты способен предлагать хорошие идеи, реально что-то сделать помочь и нести ценность. Насколько широк или узок этот круг и насколько жесткие у него границы — каждый зачастую решает сам.
UFO just landed and posted this here
Вы удивитесь, но у нас в компании у сотрудников таки есть доступы к бюджетом. И любой разработчик может прийти (в том числе и к владельцу), и выдвинуть свои предложения о том, как этим бюджетам следует распорядится.
И вполне возможна ситуация, что владелец скажет — окей, займись этим, т.е. выдаст ему все полномочия для проведения этих изменений. Для этого есть специальный механизм, и касается это даже джунов.
Так что вы несколько ошиблись в том, кто плавает в теме.
И вполне возможна ситуация, что владелец скажет — окей, займись этим, т.е. выдаст ему все полномочия для проведения этих изменений. Для этого есть специальный механизм, и касается это даже джунов.
Так что вы несколько ошиблись в том, кто плавает в теме.
UFO just landed and posted this here
А границы далеко не всех радуют. Многие в них видят потолки) Не припомню, чтобы у меня лично или у кого-то из коллег возникали вопросы с полномочиями, когда они приходили с видением проблемы, аргументами, приносили решение и демонстрировали готовность действовать
Ну те доступы которые не выданы, ты вполне можешь запросить и получить. У нас нет вообще очень мало такого, что «тебе знать не положено». Любой человек может заниматься любыми вопросами. Это просто реальный пример по приведенному вами случаю, который приводился в пример, что «так не работает». Работает. И еще как. Не совсем так как приведено у вас конечно, но работает. Владелец выдает полномочия, когда ты сильно выходишь за рамки ответственности, и попадаешь на его «поле». Но если речь идет о бюджете департамента, то тоже будет происходить с руковдителем департамента.
Но границ нет. Есть зоны ответственности, но они никак не ограничивают в деятельности. Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь, но это не граница, там нет запрета на пересечение.
Но границ нет. Есть зоны ответственности, но они никак не ограничивают в деятельности. Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь, но это не граница, там нет запрета на пересечение.
UFO just landed and posted this here
Как я уже сказал, нет никакого «нет» на пересечение зон ответственности. Его и быть не должно. И да, человек должен лезть повсюду. Если человек видит проблему, знает как и хочет ее исправить, ничего не должно ему мешать. Наоборот — все должны ему помогать. Это не так часто происходит как хотелось бы, что бы еще какие-то ограничения вводить.
Ограничение областей власти нынче не в моде )
Да даже не скажут, что софт-скиллов не хватает, в большинстве случаев так и не узнаете, по каким причинам, кроме недочетов в хард-скиллз ы не прошли. В этом и проблема, потому что в картине мира разработчика того о чем ему НЕ сказали так и не появилось. А значит нечего развивать и корректировать. Замкнутый на хард-скиллз круг.
Чтобы оценить уровень важно понять не только senior специалист или нет. Поэтому, как правило, компаниями даются задания для разных уровней — попроще и посложнее. А в последнее время, читая требования к вакансиям junior, мы и сами удивляемся — насколько много от них сейчас требуют. Здесь мы привели обзор всех требований. А тест укомплектовали заданиями разной степени сложности, чтобы видеть «оттенки» уровней.
Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
ну просто формулировать надо точнее. А то «что такое синиор» и дальше набор требований не поймешь к какой позиции, что вроде и миддл тоже подходит. Весьма очевидно что этот набор должен по сути отвечать на вопрос «в чем разница между мидлом и сениором», и он на него не отвечает.
Ситуация «ты будешь лидом» не просто встречается. Это повсеместная практика. Что бы не быть голословным — я довольно долго искал в Питере компанию, в которой этот вопрос был бы решен. И мне оказалось проще найти ее за пределами Питера, и привести ее на рынок, чем найти. А это уже по факту означает что можно считать что это не решено в городе вообще нигде.
И дело не в наличии ресурсов. И мало всегда и везде, это в принципе лимитированная вещь. Дело в подходе. Нужно что бы к моменту, когда человеку придет время стать лидом, у него в голове уже должны быть необходимые опыт и знания. Видение. Он уже должен понимать что такое команда, что с ней делать, шарить в методологиях управления, и много чего еще. И при этом у него еще желательно должен быть какой-то маломальский опыт в этом. Для этого в компании должна быть очень продвинутся система роста людей и управления, работающая на опережение. А у нас обычно реактивное управление, никто ничем не занимается, пока петух не клюнет. Заранее даже на шаг не думают.
«опыт, это такая штука, которая приходит сразу после того, как была нужна».
Ситуация «ты будешь лидом» не просто встречается. Это повсеместная практика. Что бы не быть голословным — я довольно долго искал в Питере компанию, в которой этот вопрос был бы решен. И мне оказалось проще найти ее за пределами Питера, и привести ее на рынок, чем найти. А это уже по факту означает что можно считать что это не решено в городе вообще нигде.
И дело не в наличии ресурсов. И мало всегда и везде, это в принципе лимитированная вещь. Дело в подходе. Нужно что бы к моменту, когда человеку придет время стать лидом, у него в голове уже должны быть необходимые опыт и знания. Видение. Он уже должен понимать что такое команда, что с ней делать, шарить в методологиях управления, и много чего еще. И при этом у него еще желательно должен быть какой-то маломальский опыт в этом. Для этого в компании должна быть очень продвинутся система роста людей и управления, работающая на опережение. А у нас обычно реактивное управление, никто ничем не занимается, пока петух не клюнет. Заранее даже на шаг не думают.
«опыт, это такая штука, которая приходит сразу после того, как была нужна».
Маломальский опыт компании могут давать свои сеньорам относительно просто: разорвав основные прямые коммуникации между лидами(или ПМами) с джунами/мидлами, переведя последних в подчинению сеньорам, образовав мини-команды на 2-3 человека,
ну прям разрывать прямые коммуникации это так себе решение, саботажем отдает. Но да, так или иначе должна работать цепочка — лид работает с сеньорами, сеньоры с мидлами, мидлы с джунами, мидлы и джуны со стажерами.
Но вот что бы это прямо реально работало нужно много условий. Нужна налаженная система менторинга, планов развития, аттестаций, бюджетов на обучение (как финансовых так и временных) и так далее. Нужна постоянная подпитка системы снизу, при том желательно со стажировки. В очень небольшом количестве компаний все это есть, и в еще меньшем количестве это не просто формальность, а реально работающий инструмент.
Но вот что бы это прямо реально работало нужно много условий. Нужна налаженная система менторинга, планов развития, аттестаций, бюджетов на обучение (как финансовых так и временных) и так далее. Нужна постоянная подпитка системы снизу, при том желательно со стажировки. В очень небольшом количестве компаний все это есть, и в еще меньшем количестве это не просто формальность, а реально работающий инструмент.
Речь исключительно о получении небольшого опыта управления и делегирования сеньорами. Например, команда из двух сеньоров, миддлов и джунов, а лид собрался на повышение через несколько месяцев. Лид работает с сеньорами, ставит им все задачи, а те либо сразу переназначают на своего миддла или джуна, возможно дополнительно что-то объяснив, либо декомпозируют задачу, что-то делая самостоятельно, что-то делегируя. У кого лучше получится, тот и будет новым лидом :)
Вообще слышал совет такой: придя на руководящую должность, которая не является пределом твоих мечтаний, нужно с первого дня готовить себе заместителя из числа подчинённых. Это в том числе поможет убрать такое препятствие в карьере как: «да, ты потянешь эту должность, но я тебе её не дам, потому что на твоё место мне поставить некого, некому руководить твоей командой»
Вообще слышал совет такой: придя на руководящую должность, которая не является пределом твоих мечтаний, нужно с первого дня готовить себе заместителя из числа подчинённых. Это в том числе поможет убрать такое препятствие в карьере как: «да, ты потянешь эту должность, но я тебе её не дам, потому что на твоё место мне поставить некого, некому руководить твоей командой»
Когда компания переходит на стратегический уровень управления, на уровень прогнозирования бизнеса она начинает делать это и с персоналом: всегда на каждой ключевой должности должен быть #2. Руководитель на недельной страт.сессии? Рулит тимлид. Руководитель в отпуске, тимлид заболел — рулит самый крутой Senior или архитектор или тех.лид. Мы всегда исповедовали такой принцип. При нем компания вообще без руководителей отделов (хоть всех сразу) может спокойно проработать 2 недели. Иногда в операционном ключе — даже лучше))
Чтобы сеньор смог рулить у него должно быть хоть какое-то понимание как и зачем рулить :) Нередко это лучше поручить сеньору с самым крутым пониманием этого, а не самому крутому по техскиллам, который их имеет, потому что людей сторонится и всё свободное от работы время совершенствуется в них.
Похвально, жаль что не все это исповедуют де-факто, даже если де-юре у всех замы есть.
Похвально, жаль что не все это исповедуют де-факто, даже если де-юре у всех замы есть.
Как по мне, это надо делать в любом случае, независимо от должности и собственных амбиций. Это позволяет спокойно уйти в отпуск недели на три или заболеть сосредоточившись на себе, а не на том, что там с проектом.
Ну и опять же, если вдруг придется уходить (всякое бывает, например сделали предложение от которого сложно отказаться) можно уйти со спокойной совестью не отрабатывая месяца полтора.
Ну и опять же, если вдруг придется уходить (всякое бывает, например сделали предложение от которого сложно отказаться) можно уйти со спокойной совестью не отрабатывая месяца полтора.
Чтобы оценить уровень важно понять не только senior специалист или нет. Поэтому, как правило, компаниями даются задания для разных уровней — попроще и посложнее. А в последнее время, читая требования к вакансиям junior, мы и сами удивляемся — насколько много от них сейчас требуют. Здесь мы привели обзор всех требований. А тест укомплектовали заданиями разной степени сложности, чтобы видеть «оттенки» уровней.
Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
Ну а ситуация «ты будешь лидом!», к сожалению, встречается. Из-за дефицита человеческих ресурсов, особенно, на верхнем уровне. Хотя у компании всегда есть выбор: например, нанять тимлида с рынка по соотвестующим критериям. Мы делали или так, или помогали развиваться: у нас была целая программа тренингов развития всех нужных навыков.
Поймался на любопытство, прошёл тест. Ответ пришлём на почту.
Отличная компания сделала этот тест. Я думаю, в их коллективе хорошо относятся к сексуальным меньшинствам. Ну и разными другими достоинствами они тоже не обделены.
Отличная компания сделала этот тест. Я думаю, в их коллективе хорошо относятся к сексуальным меньшинствам. Ну и разными другими достоинствами они тоже не обделены.
Наша компания, безусловно, толерантна.
Поэтому мы понимаем недовольство «ответом на почту») Для целей нашего проекта нам достаточно неавтоматизированной обработки результатов. Здесь мы привели наш тест в качестве примера и практической иллюстрации приведеных требований. Но все же поделимся интерпретациями со всеми, кому будет интересно.
Поэтому мы понимаем недовольство «ответом на почту») Для целей нашего проекта нам достаточно неавтоматизированной обработки результатов. Здесь мы привели наш тест в качестве примера и практической иллюстрации приведеных требований. Но все же поделимся интерпретациями со всеми, кому будет интересно.
мне нравится очень краткая характеристика сениора: усталый, дорогой и предвзятый.
Почему автор статьи нарушает правила и использует нецензурную лексику?
Это Вы про цитату из песни?
> потребление fuck считается непристойным и расценивается как оскорбление в официальных, политических и культурных кругах. С другой стороны, данное слово может быть воспринято спокойно и даже ожидаемо в неформальном общении, или же в либерально настроенных культурных группах.
Что-то ничего про цензуру, и даже вряд ли можно сказать, что тут собрались официальные, политические и культурные круги.
Что-то ничего про цензуру, и даже вряд ли можно сказать, что тут собрались официальные, политические и культурные круги.
Я например не могу по памяти написать оптимальный алгоритм быстрой сортировки. Не могу даже быстро написать оптимальный алгоритм опрееления простоты числа. Банально потому, что не сталкиваюсь с этим и использую более высокие абстракции. Алгоритмы знаю, могу на словах рассказать как что должно работать, но написать быстро не могу.
Однако, я работаю в одной большой международной компании в ресерч отделе. Разрабатываю инфраструктуру (архитектуру и приложения, в том числе непосредственное написание приложений, клиент серверных и стендалон) для работы с инженерными данными и автоматизацию инженерных задач. Почти всегда мои предложения принимаются и мое начальство (забугорное) и тим лиды оценивают его как годное.
Вопрос: кто я?
Спрашиваю это к тому, что некоторые тесты, которые присылают компании в качестве предварительного этапа для отбора кандидатов, я не могу пройти, так как не хватате времени.
Однако, я работаю в одной большой международной компании в ресерч отделе. Разрабатываю инфраструктуру (архитектуру и приложения, в том числе непосредственное написание приложений, клиент серверных и стендалон) для работы с инженерными данными и автоматизацию инженерных задач. Почти всегда мои предложения принимаются и мое начальство (забугорное) и тим лиды оценивают его как годное.
Вопрос: кто я?
Спрашиваю это к тому, что некоторые тесты, которые присылают компании в качестве предварительного этапа для отбора кандидатов, я не могу пройти, так как не хватате времени.
Такой эффект у Senior (потери скорости решения более простых задач), действительно, случается. В этом одна из проблем оценочных методик, особенно когда компания пытается оценить разработчика по 1-2 однотипным задачам. Поэтому, на наш взгляд, при оценке все-таки важно дать более широкий охват (разные блоки в тесте). Если кандидат прошел самые сложные задания и «так себе» — более простые, то это повод задуматься для работодателя, уточнить что-то на собеседовании. Ну а если нужен, к примеру, Junior+ и средний Middle, чтоб все горело в руках и быстро решались типовые задачи, то такие задания имеют право на жизнь
Ха, да, было такое на собесе. Приходишь собеседоваться на тимлимлида, говорят очень нам нужен тимлид. И первый вопрос — реализуйте три алгоритма сортировки за ограниченное время. Чето там пытаешься вспомнить, накорябаешь. А они смотрят, качают головой, нет, на лида не тянете. И не понимаешь, это лыжи не едут, или как.
Было это кстати в одной очень известной компании. Выходишь такой и думаешь, ну и хорошо что не взяли.
Было это кстати в одной очень известной компании. Выходишь такой и думаешь, ну и хорошо что не взяли.
Это как раз то, почему мы все же не рекомендуем на высоком уровне «забывать» про базовые хард-скиллы. Потому что, по-факту, в компаниях все равно на них смотрят, какого бы уровня вакансия не была. Меряют так серьезность отношения разработчика к своей подготовке. И часто никакой балансировки по степени сложности заданий, что усугубляет картину.
А это вообще базовый хард скилл? Может для джуна да. Для школьника-олимпиадника, тоже да. Для тимлида? Я не могу это быстро сделать не потому что у меня мозги не варят. Я не могу это быстро сделать, потому что это знание не пригодилось мне ни разу за десять лет практики и целую кучу проектов самых разных видов. Мне даже сложно себе представить, где в современной разработке это может быть полезно.
Может быть, был бы я Си разработчиком (без плюсов, чистый Си), мне бы это и пригодилось. Но я питон разработчик. Любая ручная реализация сортировки заведомо медленнее чем [].sort() тупо из-за расходов на интерпретацию, другими словами никакой практической пользы не имеет.
Ну или для джуна или миддла еще приемлемо смотреть на «серьезность подготовки» по всякой ерунде. А если мы говорим о том, что даже старший разработчик должен иметь понимания бизнеса, то это уже не найм раба на галеру, где преданность в глазах должна быть. Это практически равноправная сделка, что уже говорить о ведущих разработчиках, которые частенько весь бизнес вывозят. Там подготовку по другим параметрам смотрят — погуглил ли он о компании, насколько меткие вопросы задает, внимательно ее изучает. И чем выше, тем больше вообще стоит вопрос — кто кого вообще собеседует. Начиная с определенной квалификации (особенно если есть чем ее подтвердить), то собеседование вообще наизнанку выворачивается.
Может быть, был бы я Си разработчиком (без плюсов, чистый Си), мне бы это и пригодилось. Но я питон разработчик. Любая ручная реализация сортировки заведомо медленнее чем [].sort() тупо из-за расходов на интерпретацию, другими словами никакой практической пользы не имеет.
Ну или для джуна или миддла еще приемлемо смотреть на «серьезность подготовки» по всякой ерунде. А если мы говорим о том, что даже старший разработчик должен иметь понимания бизнеса, то это уже не найм раба на галеру, где преданность в глазах должна быть. Это практически равноправная сделка, что уже говорить о ведущих разработчиках, которые частенько весь бизнес вывозят. Там подготовку по другим параметрам смотрят — погуглил ли он о компании, насколько меткие вопросы задает, внимательно ее изучает. И чем выше, тем больше вообще стоит вопрос — кто кого вообще собеседует. Начиная с определенной квалификации (особенно если есть чем ее подтвердить), то собеседование вообще наизнанку выворачивается.
Сначала нужно дать определение, что такое Тимлид в рамках конкретной компании. Это может быть, как Программист-звезда, так и Менеджер с техническим бэкграундом.
Было бы странно, если бы Программист-звезда не знал базовый computer science.
«Мне cs не нужен, всё уже есть в языке» — а потом можно посмотреть на одну из больших корпораций, например Одноклассники, где пишут, например, свои надстройки над базами, языками, виртуальными машинами и другим. А тут уже оказывается, что все алгоритмы придётся писать руками, а не брать из языка.
Было бы странно, если бы Программист-звезда не знал базовый computer science.
«Мне cs не нужен, всё уже есть в языке» — а потом можно посмотреть на одну из больших корпораций, например Одноклассники, где пишут, например, свои надстройки над базами, языками, виртуальными машинами и другим. А тут уже оказывается, что все алгоритмы придётся писать руками, а не брать из языка.
А чего странного, в том что у человека не отскакивает от зубов то, что ему никогда не пригодится? В наше время разработчик-звезда и так должен знать столько всего, что ему реально нужно. Нужно и на низком уровне понимать, и на высоком, и сто пятьсот архитектур, баз данных самых разных. Нужно и в менеджмент уметь, и методики управления понимать, и в бизнес контексте понимать. Быть и немного психологом до кучи. Список длинный.
Не странно ли при всем при этом спрашивать у людей то, что реально никогда не пригодится, и делать это ключевым критерием отбора? По мне так это откровенно не адекватно.
Не странно ли при всем при этом спрашивать у людей то, что реально никогда не пригодится, и делать это ключевым критерием отбора? По мне так это откровенно не адекватно.
Аналогично, нанимая гендиректора, допустим, фармакологической фирмы, надо спрашивать его примерно такое: «А напишите-ка нам, милейший, формулу Диметилтриптамина» — и по этому судить о его компетенции в качестве генерального директора — ведь ему не хухры-мухры, ему с химией иметь дело!
Извините, а когда Тимлид стал не просто играющим тренером, а одним из топ менеджмента?
… и даже не о тимлиде: речь об оценке программистов всех уровней, чуть прицельнее — Senior. У тимлидов уже много совсем других критериев — более сложных hard и soft.
Всё зависит от того, что вы хотите от тимлида, в какой пропорции и какова специфика. У человека так же ограничен ресурс знания, и держать абстрактное ВСЁ в актуальном состоянии — идеалистическая претензия. Недаром существует и разделение труда — иначе чем отличается ваш тимлид от любого другого программиста в команде. А работодатель это зачастую не понимает — отсюда монструозные списки требующихся навыков, написанных по принципу «всё-всё-всё, и еще вот это», когда из всего этого используется лишь часть и фрагментарно.
Взять тот же пример с сортировками — откуда это требование проистекает? Из действительно большой зависимости разрабатываемого кода от сортировок или «чтоб было» и «так положено»? Мало того, что все эти «на всякий случай»-навыки отфильтровывают действительно годных кандидатов, так они еще и в случае найма прошедшего такой фильтр могут просто ввести в компанию кандидата с невостребованными ею же навыками, или же привести к найму оверкомпетишн человека, которому вы будете платить деньги за знания, а не за деятельность, реально потребную вам.
Это ли не безумие?
Взять тот же пример с сортировками — откуда это требование проистекает? Из действительно большой зависимости разрабатываемого кода от сортировок или «чтоб было» и «так положено»? Мало того, что все эти «на всякий случай»-навыки отфильтровывают действительно годных кандидатов, так они еще и в случае найма прошедшего такой фильтр могут просто ввести в компанию кандидата с невостребованными ею же навыками, или же привести к найму оверкомпетишн человека, которому вы будете платить деньги за знания, а не за деятельность, реально потребную вам.
Это ли не безумие?
Ну на самом деле чем выше должность, чем больше тебе платят именно за знания, а не за деятельность. По сути по мере роста компании в сторону бирюзы (тут вроде оказалось достаточно много народу способных поддержать беседу в этом ключе), руководитель превращается из исполнителя в советника. И то чем он по сути занимается — это шарит знания, а не производит какую-то реальную работу. Они имеют гораздо большую ценность. Тимлид в таких структурах это самая верхняя из должностей кто реально еще может что-то делать руками, но должен уже стремится к тому, что бы перейти на следующую ступеньку, где ему этого не светит.
Ну а монструозные списки требований как правило вылезают из размазанных зон ответственности. По факту обычно не известно точно, что нужно. Есть некоторая дыра которую надо закрыть, и тут уж кого найдут — тем и закроют. Т.е. список требований — это список пожеланий и не нужно к нему подходить как то, что нужно реально все это знать. Как правило ожидают до 75% покрытия.
Ну, и опять же, планка критериев поиска всегда должна быть выше ожидаемого результата. Вы удивитесь по насколько безумным требованиям иногда удается находить реальных кандидатов, которые им удовлетворяют. А если не завышать ожидания, таких не найдешь.
Ну а монструозные списки требований как правило вылезают из размазанных зон ответственности. По факту обычно не известно точно, что нужно. Есть некоторая дыра которую надо закрыть, и тут уж кого найдут — тем и закроют. Т.е. список требований — это список пожеланий и не нужно к нему подходить как то, что нужно реально все это знать. Как правило ожидают до 75% покрытия.
Ну, и опять же, планка критериев поиска всегда должна быть выше ожидаемого результата. Вы удивитесь по насколько безумным требованиям иногда удается находить реальных кандидатов, которые им удовлетворяют. А если не завышать ожидания, таких не найдешь.
Как и сказано в статье — под должностью Х всякий понимает что-то своё, и название «Тимлид» по большому счету ничего не дает для понимания как именно он будет тимлидить в конкретной компании — то ли будет ведущим программистом в основном, то ли будет архитектором, то ли будет ревьюировать, то ли тренировать, то ли что еще.
Поиски универсальных волшебников — это, конечно, увлекательно и возвышенно, но как минимум непрактично — я это и хотел сказать своим комментарием.
Поиски универсальных волшебников — это, конечно, увлекательно и возвышенно, но как минимум непрактично — я это и хотел сказать своим комментарием.
Даже для играющего тренера, ожидать знания всех формул на зубок странно. И чем больше вы ожидаете от него как от тренера, тем меньше очевидно следует ожидать технических знаний.
Например если это тимлид плюс, который может уже не только тимлидить, а подхватывать и более высокоуровневые вопросы, то такой человек очевидно гораздо более ценен практически для любой компании. Таким подходом такие люди автоматом отсеиваются. А должно быть наоборот.
Например если это тимлид плюс, который может уже не только тимлидить, а подхватывать и более высокоуровневые вопросы, то такой человек очевидно гораздо более ценен практически для любой компании. Таким подходом такие люди автоматом отсеиваются. А должно быть наоборот.
Здесь мы говорим не о Гендиректоре (он уже давно «в менеджмент»), а все-таки, скорее о Ведущих спецах-химиках фирмы. Ну и опять же — спрашивать-то можно. Вопрос только спрашивать ли только это или еще много чего и как интерпретировать. Мы отражаем как это интерпретируют компании. А сами мы смотрим — если по языковому блоку так-сяк, а по самым крутым и сложным здорово… Нам эта картина интересна (писали уже об этом выше). На собеседовании поговорим и уточним.
Ну и даже в этом случае — это чаще всего следствие неразумных амбиций, вместо трезвого понимания — чем именно будет заниматься человек. Конечно, если вы ищете писателя сортировок — то да, нужен такой скилл. Но действительно ли этим и будет заниматься ваш нанимаемый спец? Вот о чём речь.
Кажется, мы говорим о разных вещах. Вы — о конкретных требованиях к конкретной позиции с конкретной спецификой и должностями обязанностями, а мы — в целом об оценке уровня программиста. Оценка для конкретной позиции с требованиями для конкретной компании — одно, а в целом чем оперирует специалист и в какой степени, а чем нет — это другое. Скорее мы видим общую картину и дальше уже имеем дело с требованиями. Определяемся — для какой позиции и 0% ничего страшного, а для чего и 70% — мало. Если нам нужен Middle — набор процентов по одним блокам, Senior — другой по другим.
Ну я писал о конкретном казусе — про сортировки. По большому счету — это уже не из набора общеупотребительных концепций, типа ООП, паттернов и структур данных — это уже скорее специализированный класс алгоритмов. И если этот класс не востребован в компании реально — это практически бессмысленный «тест» кандидата, к тому же на основе которого делаются обобщающие выводы. И это не редкость, и причин этому масса — и все они далеки от адекватности.
Иной раз так и хочется сказать — а зачем?! Вы тут велосипеды строите что ли? И ведь строят, и гордятся своими «знаниями». А потом вся эта самопальная красота выходит конторе огромным геморроем в сопровождении, ибо любая кастомная вещь — это дополнительная сложность в проект. Зато — кто-то продемонстрировал как он могёт!
Меня лично оторопь берет, когда люди хвалятся своими «хакерскими» достижениями. Потому что коммерческий софт — это не место, где надо упражняться в уникальности и забористости — это всё боком выходит в дальнейшем, если, конечно, это не какой-то усовершенствованный «хеллоуворд» или что-то из разряда «выстрелил — и забыл». А это распространенная причина включения в тесты таких специализированных вопросов от таких выбившихся выше «хакеров». Другая причина — это когда копипастом с аналогичных вакансий берут список скиллов и эти самые тестовые задания, совершенно не отражая — зачем они им?
Иной раз так и хочется сказать — а зачем?! Вы тут велосипеды строите что ли? И ведь строят, и гордятся своими «знаниями». А потом вся эта самопальная красота выходит конторе огромным геморроем в сопровождении, ибо любая кастомная вещь — это дополнительная сложность в проект. Зато — кто-то продемонстрировал как он могёт!
Меня лично оторопь берет, когда люди хвалятся своими «хакерскими» достижениями. Потому что коммерческий софт — это не место, где надо упражняться в уникальности и забористости — это всё боком выходит в дальнейшем, если, конечно, это не какой-то усовершенствованный «хеллоуворд» или что-то из разряда «выстрелил — и забыл». А это распространенная причина включения в тесты таких специализированных вопросов от таких выбившихся выше «хакеров». Другая причина — это когда копипастом с аналогичных вакансий берут список скиллов и эти самые тестовые задания, совершенно не отражая — зачем они им?
Отличный комментарий!
Действительно чем выше уровень специалиста тем он больше нужен компании чем она ему.
Поэтому уже специалист начинает присматриваться к компании, смотреть подойдет ли она ему, будет ли ему интересно и насколько полезный опыт он получит.
Соответсвенно и собеседуется уже не работник, а компания, и если представитель компании начинает с ходу задавать глупые вопросы, то собеседование такая компания уже не пройдет.
Действительно чем выше уровень специалиста тем он больше нужен компании чем она ему.
Поэтому уже специалист начинает присматриваться к компании, смотреть подойдет ли она ему, будет ли ему интересно и насколько полезный опыт он получит.
Соответсвенно и собеседуется уже не работник, а компания, и если представитель компании начинает с ходу задавать глупые вопросы, то собеседование такая компания уже не пройдет.
Я далек от уровня тимлида, и тем более не собеседовал никого на такую позицию, поэтому мое предположение может показаться глупым.
Я предполагаю, что тимлид также должен уметь объяснить, почему знания алгоритмов ему необязательны для своей работы. Хорошо так объяснять, с аргументами. Потому что (как мне кажется) важным навыком тимлида является умение убеждать/уговаривать в том числе собеседника, который абсолютно уверен в своей правоте. А еще тимлиду важно понимать, где он может задавить авторитетом, где включить свое хорошее понимание темы, а где использовать «софт-скиллы», т.е. умение убалтывать.
<мечтательно> Когда меня будут собеседовать на тимлида и я услышу аналогичный вопрос… Я должен буду понять, смогу ли ответить и если нет — доказать, почему незнание конкретно этого аспекта позволяет мне претендовать на должность. Причем оценку «знаю-не знаю» и поиск аргументов в случае «не знаю» я должен осуществить быстро.
Повторюсь, это взгляд снизу, если где неправ — поправьте.
Я предполагаю, что тимлид также должен уметь объяснить, почему знания алгоритмов ему необязательны для своей работы. Хорошо так объяснять, с аргументами. Потому что (как мне кажется) важным навыком тимлида является умение убеждать/уговаривать в том числе собеседника, который абсолютно уверен в своей правоте. А еще тимлиду важно понимать, где он может задавить авторитетом, где включить свое хорошее понимание темы, а где использовать «софт-скиллы», т.е. умение убалтывать.
<мечтательно> Когда меня будут собеседовать на тимлида и я услышу аналогичный вопрос… Я должен буду понять, смогу ли ответить и если нет — доказать, почему незнание конкретно этого аспекта позволяет мне претендовать на должность. Причем оценку «знаю-не знаю» и поиск аргументов в случае «не знаю» я должен осуществить быстро.
Повторюсь, это взгляд снизу, если где неправ — поправьте.
Не могу сказать что такая мысль меня не посетила в тот момент. Там было несколько других аспектов, которые наводили на мысль, что с собеседованием вообще что-то пошло не так. Так что я пообщался с HRом на тему не забыли ли они чего. Но вроде как нет, это «особенность политики найма». Бодаться с политиками найма крупных компаний при входе я нашел и неуместными и бесперспективными. Ну и честно говоря не уверен что хотел бы работать с командой, которую отбирали подобным образом.
К тому же по слухам зарплаты там были не особо высокие, да и в итоге на собеседования по сумме ушло больше 8 часов(только к ним), продолжать не похоже что имело смысл.
К тому же по слухам зарплаты там были не особо высокие, да и в итоге на собеседования по сумме ушло больше 8 часов(только к ним), продолжать не похоже что имело смысл.
Открыл тест, вы серьезно?
Тест на 50% состоит из плохо сформулированных вопросов. Я уже молчу за оформление кода в виде пережатых картинок. На часть вопросов в принципе невозможно ответить объективно. И правильный ответ должен быть — «невозможно правильно ответить». Под конец вообще какой-то психологический портрет.
Задания разного уровня сложности разрабатывались коллегиально Senior-ами крутых корпораций для оценки разного уровня специалистов. Команда посчитала, что правильные ответы среди предложенных есть. Хотя, конечно, у каждой компании есть своя специфика: задачи, которые она решает или не решает вовсе. И тут мнения могут различаться, а компания вправе в тесте выставлять свои требования.
Ну во-первых, я точно не поверю что все они согласились. А второе — ответы не просто должны быть правильные, а ясные и однозначные. Размер таблицы — «средний», это 1к или 1кк? Для меня большая это 1ккк, а средняя — 1кк, но это лично моё мнение, оно точно не совпадает со всеми. Что значит клиент — другой «узел сети»? Какой сети, внутри дц или города или планеты Земля?
Очень обидно, что всех программистов почему-то считают обязанными знать всякие web-технологии, но при этом забывают про все остальные, коих намного порядков больше. Мир программистов не заканчивается frontend'ом и backend'ом, даже несмотря на текущую популярность этих направлений. Главное, на мой взгляд — умение учиться и учить других, объяснять свои мысли и код самим кодом, комментариями, документацией. Широта кругозора важна для общего понимания вещей, но при этом надо уметь быстро погружаться в конкретику. И неважно, очередной это новомодный фреймворк или протокол связи с интерферометром.
По вашей классификации выходит, что Senior это венец развития для технического специалиста. Куда тогда ему развиваться дальше?
Как с вашей классификацией соотносятся позиции Tech Lead, Architect (Solution/Technical/Enterprise), Principal, CTO/CIO, VP of technology?
Куда вы отнесете Senior QA, Senior DevOps и какие к ним будут требования?
Им тоже нужно знать алгоритмы и ООП?
Как с вашей классификацией соотносятся позиции Tech Lead, Architect (Solution/Technical/Enterprise), Principal, CTO/CIO, VP of technology?
Куда вы отнесете Senior QA, Senior DevOps и какие к ним будут требования?
Им тоже нужно знать алгоритмы и ООП?
Уровень Senior — это плацдарм для целого веера позиций: тимлид, техлид, архитектор, скраммастер, менеджер по продукту (сейчас все больше любят их с техническим бэкграундом если это ИТ-продукт), и даже видим все больше вакансий аналитиков с программистским бэкграундом… Это всего на одну ступеньку дальше. Однако, на этих позициях ждут, прежде всего, Senior-ов. Мало кто пригласит в техлиды, тимлиды и т.д. специалиста среднего уровня (не знаю таких случаев).
Вполне могут пригласить на позицию тимлида миддла из этой команды, не дошедшего до сеньоров этой команды по хард-скиллам, но превосходящего их по софт, особенно если он и так является неформальным лидером команды.
Да? Здорово, что есть такие кейсы! Я за то, чтобы где возможно, не замешивать часто противоречащие друг другу верхенуровневые хард и софт-скиллы.
У нас некоторые проекты ведут мидлы, т.е. они выступают в роли девлида. Но обычно, конечно, это небольшие проекты, простые, с совсем маленькой командой, или даже скорее вовсе без нее. Человек-проект.
Но и требования к мидлам (да и вообще ко всем разработчикам) достаточно серьезные.
Но и требования к мидлам (да и вообще ко всем разработчикам) достаточно серьезные.
У нас отсроенная система Управления проектами. Мы начали проекты тоже отдавать все больше вниз, и несколько неруководящих сотрудников стали РП. Мы были удивлены, что эта стезя им была вполне даже интересна (а мы ожидали зубовный скрежет на требования Проектного офиса). Правда, сейчас им куда больше интересны продуктовые команды. Ну что ж, пусть дерзают.
Совсем недавно встречал чуть-чуть прикрашенную ситуацию: лид увольнялся, предупредил за месяц, кажется, «совершенно случайно» на встречу об условиях пригласили одного из миддлов, после неё сделали его сеньором, а через две недели лид стал ему официально передавать дела как новому лиду.
Как для чисто технического, разработчика, пожалуй, венец кроме исключительных случаев.
Все перечисленные позиции всё больше в сторону работы с людьми, финансами и другими ресурсами. Все перечисленные должны, грубо, обладать примерно одними техскиллами (пускай в прошлом), но с каждой ступенькой всё больше должны иметь разнообразных навыков работы с людьми, как минимум, навыки управления командами и навыки «продажи» своих технических идей бизнесу.
Все перечисленные позиции всё больше в сторону работы с людьми, финансами и другими ресурсами. Все перечисленные должны, грубо, обладать примерно одними техскиллами (пускай в прошлом), но с каждой ступенькой всё больше должны иметь разнообразных навыков работы с людьми, как минимум, навыки управления командами и навыки «продажи» своих технических идей бизнесу.
опять «знание принципов ООП», опять «знание паттернов». Это требования к senior в 2018? а где UML тогда уж
Ну что сказать, ничего не выдумываем — в компаниях это must. Логика такая: даже оперной диве не должно быть чуждо сальфеджио, гонщик способен прокатиться на жигулях ну и т.д. Однако, если спрашивают только ООП и паттерны, уточните все же, Senior ли нужен. Корректно уточнять требования и объяснять свою позицию же никто не запрещает.
Не претендую на 100% истиность, но имхо сеньёрить можно исключительно в конкретном месте(либо в отрасли), когда у тебя уже есть свита(тестировщики и джуниоры). Если ты солист, то каким бы талантливым не был — просто физически не получишь свой левел ап, сколько бы паттернов не знал.
Меняя работу(не дай бог отрасль) — первые пол года по любому уйдут на знакомство с предметной областью, корп.культурой и местными порядками, изучение проектов и т.д.
Людей сразу под реализацию идей тоже вряд-ли дадут, потому ты как бы будешь middle+ с перспективой.
Меняя работу(не дай бог отрасль) — первые пол года по любому уйдут на знакомство с предметной областью, корп.культурой и местными порядками, изучение проектов и т.д.
Людей сразу под реализацию идей тоже вряд-ли дадут, потому ты как бы будешь middle+ с перспективой.
Во многих компаниях сеньор — это не руководитель мини-команды, а рядовой разработчик, просто проскиллованный. Разница между сеньором и джуном визуально не наблюдется, оба берут таски и пилят, уточняя что-то у коллег, если не ясно.
Один из знакомых руководителей тоже говорил, что разницы визуальной никакой. Что джуны пилят практически те же задачи, что и синьоры, просто за ними нужно приглядывать. И что джуны хорошие вообще должны уметь все. Но это была небольшая компания и небольшой отдел разработки, с неЯндексовским все-таки уровнем задач
Я не про задачи даже, и даже не про приглядывать. Я про то, что часто команды не имеют иерархической структуры, они «плоские» — и джуны, и сеньоры в прямом подчинение у тимлида, и никаких тестировщиков, и вообще никого у них в подчинении нет — тестировщики или вообще в отдельной команде, или так же подчиняются лиду.
Sign up to leave a comment.
Хороший код до Google не доведет