Может быть где-то и есть. Я таких не видел. Потому что это очччень дорого - у вас должен быть костяк архитекторов-проектировщиков-сеньор-(и частично)мидл разработчиков, которые
Это не дороже, а может даже дешевле, чем ляпать что-то не думая на перед, без нормальной многоуровневой системы с тестами и продуманной архитектуры. Минимум регрессий, минимальное время вхождения в проект, расширяемость, масштабируемость. В в среднесрочной и долгосрочной перспективе просто огромная экономия денег.
собственно и декомпозируют проект до тех кусков, которые можно отдать новичкам
Это не так, если есть поставленный процесс. Если проект декомпозируется до задач каждая из которых не более 3-5 дней, а в идеале менее, все идет очень легко.
Вот врать и искать бревно в чужом глазу, одновременно озадачиваясь минусами - это, действительно, интересный подход
Я не озадачиваюсь минусами, мне до них нет никакого дела. Я как раз привел минусы без какого-либо объяснения как отличный пример поведения которое на реальном проекте будет опасным и скорее всего будет выглядеть как тихий, или не очень тихий, саботаж работ.
В статье по первой ссылке это менеджер, который появился только в самом конце, хотя, появись он в самом начале - возможно, Рику и не пришлось бы работать два года сверхурочно и он бы не дошёл до такого состояния
Появись менеджер имеющий опыт с brilliant jerk в самом начале, проблем безусловно не было бы, так как в проекте не было бы Рика. Люди со звездной болезнью не переносят быть часть коллектива, и если их просят это сделать они предпочитают уйти. Что в итоге благо для проекта.
А в статье по второй ссылке решили просто не озадачивать менеджеров этим вопросом и работать только с ничем не выделяющиеся людьми.
Во второй статье менеджеры решили что здоровый климат в команде важнее наличия в ней "звезды" которая не хочет играть по общим правилам и требует своих собственных правил в ущерб команде и проекту. При этом разработка ПО это командная работа, где звезда по большому счету и не нужна, а нужны общие цели и задачи над которыми коллектив дружно работает. Так же не стоит забывать о том, что есть куча звезд в разработке которые не ведут себя как brilliant jerk, являются выделяющимися людьми, очень ценны для проекта и любимы менеджерами.
И заметьте, здесь гораздо больше информации, чем в Вашей пафосной писанине.
Пафосная? В каком месте? Что пафосного в утверждении, что brilliant jerk надо отсеивать еще на стадии собеседования либо увольнять после, если они таки просочились как-то?
Я наблюдал brilliant jerk дважды, в обоих случаях их уход из команды повысил предсказуемость разработки и моральный настрой команды, а так же сократил сроки. Сейчас, при намеке на brilliant jerk поведение на собеседовании я просто не нанимаю человека и все.
В более менее серьезных проектах срок вхождения сотрудника меньше недели.
В более менее серьезных проектах есть система автоматизации тестирования в которой всегда надо что-то доработать и это безопасно доверить новичку.
В более менее серьезных проектах всегда есть документация ознакомившись с которой новичок может сразу править не сложные дефекты, а компания не бояться что он что-то сломает так как автоматизация из пункта выше.
В более менее серьезных проектах есть качественный бэклог где отдельно помечены задачи для новичков, которые с одной стороны быстро повысят осведомленность в проекте, а с другой не критичны с точки зрения скорости исполнения. И новичок ничего не сломает потому что пункт 1.
Топать вы прочитали две статьи по линкам, состоящие из огромного количества аргументов и доводов, проигнорировали тот факт что в статьях нет ни одного момента пересекающегося с доводами в статье на Хабре, и хотите еще доводов? Это интересный подход.
Инициатива прекрасна на деле. Все новое продаваемое железо будет идти с правильными сертификатами и правильным ПО. Просто отличный способ улучшить качество цензуры, идеально дополнит цифровые повестки, оплату прохода в метро «лицом» и другие продвинутые технологи слежения.
Интересный момент про jerks, которые brilliant и не очень. Так как высказать свое мнение публично им величие не позволяет, они стараются гадить по-мелочи. Ну к примеру на Хабре они могут зайти и в карму нагадить. Вроде и мелочь, но приятно.
Поэтому, к реальным проектам, их ни в коем случае допускать нельзя. Отсев на этапе собеседования критичен вне зависимости от уровня гениальности. Человек гадящий по мелочи опасен для проекта.
Мы компания AGIMA, крупнейший интегратор digital-решений в России
Довольно хорошо подтверждает мой тезис про «кому нужен директор из России, разве только не в дочку компании с российскими корнями».
После того как куда-то перевезли на управляющей позиции, шансы перехода на аналогичную позицию в той же стране безусловно вырастут. Хотя и останутся ниже чем у IC.
—
Так, стоп, но вы же переехали как IC, а не EM, если верить LI профайлу. Именно то, о чем я и говорю ?♂️
А вы статью на которую ссылаетесь в самом начале читали дальше заголовка? Потому как Рик из статьи является классическим brilliant jerk, которых приличные компании еще на стадии собеседования отсеивают, и совершенно правильно делают.
Еще задать себе вопросы про мобильность, что как мне кажется одна из главных проблем в EM ветке развития. Если ты IC, то и рынок сильно больше и переезд между странами весьма простой. В то же время для EM ты сильно завязан на культуре страны. Грубо говоря кому нужен в условной Германии директор из РФ, разве только не в дочку компании с российскими корнями?
В любом месте жить будет не просто если TC попадает в 25 перцентиль. А так, Бкк просто замечательное место, иногда на выходные туда летаем поесть в интересных ресторанах.
В том, что половина дают тестовое "на 4 часа", которое со всеми тестами и хорошим качеством совсем не на "4 часа". А потом не дают почти никакого фидбека, а то и вообще не зовут на собес.
Тоже с таким сталкивался один раз. С одной стороны обидно. С другой стороны задание было интересным. В результате стал делать только в том случае если компания ну очень привлекательная. Как по мне такой подход работает.
Или в пяти часовых (в смысле, пять по часу) собеседованиях, после которых выясняется, что отсеяли ещё на первом, но просто процесс так устроен.
Обычно до того как все собеседования пройдут те кто проводят собеседования не могут посмотреть результатов других собеседований, что разумно. После всяко идет обсуждение и если кандидат на одном собеседовании был так себе, зато на остальных супер, его скорее всего возьмут. Я бы сказал что этот процесс в целом разумен.
Дизайн систем - отдельная боль. Невозможно нормально задизайнить что-то за час. Да и ждут именно правильного ответа. Поэтому приходится просто нарешивать и выдавать решение не как в жизни, а как надо.
Ждут не правильного ответа, а ответа который будет потенциально рабочим. Сам часто провожу дизайн собеседования и никогда не ожидаю какого-то правильного ответа.
Не, может, я просто не "нормальный кандидат", но тогда хорошо бы какие-то критерии (хотя и понятно, что их очень сложно было привести).
Критерий первый. Умеет писать достаточно вменяемый код которых хоть как-то но работает и предложить тестовые сценарии. Критерий второй. Кандидат может предложить дизайн системы который потенциально может работать и тестовые сценарии к ней. Критерий третий. Кандидат умеет общаться, задавать вопросы, давать развернутые ответы, объяснять свое решение. Вроде не много вышло, но это для миддла/синьора где-то. Для джуна было бы без дизайна и без особых ожиданий в области развернутых ответов или грамотных вопросов.
Хз, мне кажется есть. Раньше спрашивали немного и не сильно.
Что бы получить свою первую работу ~20 лет назад я неделю (без преувеличения) делал весьма объемное тестовое задание. Потом еще спрашивали что, почему, да как. С тех пор самое объемное тестовое задание что я делал, а делать я их редко стал соглашаться, у меня одни выходные занимало.
Нормальных кандидатов как было не шибко много, так и остается. При этом нормальный кандидат проблем с трудоустройством как не испытывал, так и не испытывает. Я бы сказал что какого-то кардинального отличия от собеседований 10ти летней давности не наблюдаю ни с одной из сторон.
Кстати, статья не раскрывает в чем состоят унижения в текущем процессе найма. В том что попросят написать задачку в онлайн IDE? Или в том что попросят нарисовать дизайн какой-то системы? Или может быть то, что поболтают за жизнь дабы убедиться что кандидат в целом вменяем и его не страшно к другим добавить?
Мёсье предполагает что у азиатов английский не может быть родным? Никогда не повторяйте такой интересной мысли в приличном обществе, решат что мёсье расист ?♂️
Я бы сказал что это прикладные, а не фундаментальные знания. Как минимум все будет сильно зависеть от платформы (iOS VS Android, как пример), культуры (в арабском мире удобно и красиво будет отличаться от принятого в Китае), и времени (тут можно глянуть на разницу в правилах верстки в 90-х и сейчас).
В то же время книги по теории распределенных систем 10 летней давности актуальнее некуда, а уж математика выученная 30 лет назад актуально совершенно так же как и тогда. Так что в одном случае у нас теоретическая база устаревает, а в другом ты набираешь знаний и опыта который актуален как и 10, и 20 лет назад, так и будет еще много лет.
В компаниях где практикуются регулярные оценки производительности (performance review), ты должен предоставить список того что сделал с момента последней оценки. Соответственно ты должен собирать заметные вещи которые были сделаны за, к примеру, пол года и упорядочить их.
Тут предлагается делать тоже самое, только добровольно. За что-то же деньги платили? Что-то было сделано. Какая-то особо полезная фича, какое-то изменение в процессах, какие-то полезные для других команд вещи.
я тут могу только посочувствовать отсутствию опыта работы в нормальных проектах ?♂️
Это не дороже, а может даже дешевле, чем ляпать что-то не думая на перед, без нормальной многоуровневой системы с тестами и продуманной архитектуры. Минимум регрессий, минимальное время вхождения в проект, расширяемость, масштабируемость. В в среднесрочной и долгосрочной перспективе просто огромная экономия денег.
Это не так, если есть поставленный процесс. Если проект декомпозируется до задач каждая из которых не более 3-5 дней, а в идеале менее, все идет очень легко.
Это беспилотные автомобили.
Я не озадачиваюсь минусами, мне до них нет никакого дела. Я как раз привел минусы без какого-либо объяснения как отличный пример поведения которое на реальном проекте будет опасным и скорее всего будет выглядеть как тихий, или не очень тихий, саботаж работ.
Появись менеджер имеющий опыт с brilliant jerk в самом начале, проблем безусловно не было бы, так как в проекте не было бы Рика. Люди со звездной болезнью не переносят быть часть коллектива, и если их просят это сделать они предпочитают уйти. Что в итоге благо для проекта.
Во второй статье менеджеры решили что здоровый климат в команде важнее наличия в ней "звезды" которая не хочет играть по общим правилам и требует своих собственных правил в ущерб команде и проекту. При этом разработка ПО это командная работа, где звезда по большому счету и не нужна, а нужны общие цели и задачи над которыми коллектив дружно работает. Так же не стоит забывать о том, что есть куча звезд в разработке которые не ведут себя как brilliant jerk, являются выделяющимися людьми, очень ценны для проекта и любимы менеджерами.
Пафосная? В каком месте? Что пафосного в утверждении, что brilliant jerk надо отсеивать еще на стадии собеседования либо увольнять после, если они таки просочились как-то?
Я наблюдал brilliant jerk дважды, в обоих случаях их уход из команды повысил предсказуемость разработки и моральный настрой команды, а так же сократил сроки. Сейчас, при намеке на brilliant jerk поведение на собеседовании я просто не нанимаю человека и все.
В более менее серьезных проектах срок вхождения сотрудника меньше недели.
В более менее серьезных проектах есть система автоматизации тестирования в которой всегда надо что-то доработать и это безопасно доверить новичку.
В более менее серьезных проектах всегда есть документация ознакомившись с которой новичок может сразу править не сложные дефекты, а компания не бояться что он что-то сломает так как автоматизация из пункта выше.
В более менее серьезных проектах есть качественный бэклог где отдельно помечены задачи для новичков, которые с одной стороны быстро повысят осведомленность в проекте, а с другой не критичны с точки зрения скорости исполнения. И новичок ничего не сломает потому что пункт 1.
Топать вы прочитали две статьи по линкам, состоящие из огромного количества аргументов и доводов, проигнорировали тот факт что в статьях нет ни одного момента пересекающегося с доводами в статье на Хабре, и хотите еще доводов? Это интересный подход.
Инициатива прекрасна на деле. Все новое продаваемое железо будет идти с правильными сертификатами и правильным ПО. Просто отличный способ улучшить качество цензуры, идеально дополнит цифровые повестки, оплату прохода в метро «лицом» и другие продвинутые технологи слежения.
Интересный момент про jerks, которые brilliant и не очень. Так как высказать свое мнение публично им величие не позволяет, они стараются гадить по-мелочи. Ну к примеру на Хабре они могут зайти и в карму нагадить. Вроде и мелочь, но приятно.
Поэтому, к реальным проектам, их ни в коем случае допускать нельзя. Отсев на этапе собеседования критичен вне зависимости от уровня гениальности. Человек гадящий по мелочи опасен для проекта.
В купе с
Довольно хорошо подтверждает мой тезис про «кому нужен директор из России, разве только не в дочку компании с российскими корнями».
После того как куда-то перевезли на управляющей позиции, шансы перехода на аналогичную позицию в той же стране безусловно вырастут. Хотя и останутся ниже чем у IC.
—
Так, стоп, но вы же переехали как IC, а не EM, если верить LI профайлу. Именно то, о чем я и говорю ?♂️
А вы статью на которую ссылаетесь в самом начале читали дальше заголовка? Потому как Рик из статьи является классическим brilliant jerk, которых приличные компании еще на стадии собеседования отсеивают, и совершенно правильно делают.
Да, разумно. Слона то я и не приметил. Спасибо.
Никто не сталкивался с сервисом в МО для замены «мамы» которая документы отнесет, принесет и т.д.?
Еще задать себе вопросы про мобильность, что как мне кажется одна из главных проблем в EM ветке развития. Если ты IC, то и рынок сильно больше и переезд между странами весьма простой. В то же время для EM ты сильно завязан на культуре страны. Грубо говоря кому нужен в условной Германии директор из РФ, разве только не в дочку компании с российскими корнями?
В любом месте жить будет не просто если TC попадает в 25 перцентиль. А так, Бкк просто замечательное место, иногда на выходные туда летаем поесть в интересных ресторанах.
https://www.levels.fyi/t/software-engineer/locations/bangkok-metro-region
Тоже с таким сталкивался один раз. С одной стороны обидно. С другой стороны задание было интересным. В результате стал делать только в том случае если компания ну очень привлекательная. Как по мне такой подход работает.
Обычно до того как все собеседования пройдут те кто проводят собеседования не могут посмотреть результатов других собеседований, что разумно. После всяко идет обсуждение и если кандидат на одном собеседовании был так себе, зато на остальных супер, его скорее всего возьмут. Я бы сказал что этот процесс в целом разумен.
Ждут не правильного ответа, а ответа который будет потенциально рабочим. Сам часто провожу дизайн собеседования и никогда не ожидаю какого-то правильного ответа.
Критерий первый. Умеет писать достаточно вменяемый код которых хоть как-то но работает и предложить тестовые сценарии. Критерий второй. Кандидат может предложить дизайн системы который потенциально может работать и тестовые сценарии к ней. Критерий третий. Кандидат умеет общаться, задавать вопросы, давать развернутые ответы, объяснять свое решение. Вроде не много вышло, но это для миддла/синьора где-то. Для джуна было бы без дизайна и без особых ожиданий в области развернутых ответов или грамотных вопросов.
Что бы получить свою первую работу ~20 лет назад я неделю (без преувеличения) делал весьма объемное тестовое задание. Потом еще спрашивали что, почему, да как. С тех пор самое объемное тестовое задание что я делал, а делать я их редко стал соглашаться, у меня одни выходные занимало.
Нормальных кандидатов как было не шибко много, так и остается. При этом нормальный кандидат проблем с трудоустройством как не испытывал, так и не испытывает. Я бы сказал что какого-то кардинального отличия от собеседований 10ти летней давности не наблюдаю ни с одной из сторон.
Кстати, статья не раскрывает в чем состоят унижения в текущем процессе найма. В том что попросят написать задачку в онлайн IDE? Или в том что попросят нарисовать дизайн какой-то системы? Или может быть то, что поболтают за жизнь дабы убедиться что кандидат в целом вменяем и его не страшно к другим добавить?
Мёсье предполагает что у азиатов английский не может быть родным? Никогда не повторяйте такой интересной мысли в приличном обществе, решат что мёсье расист ?♂️
Я бы сказал что это прикладные, а не фундаментальные знания. Как минимум все будет сильно зависеть от платформы (iOS VS Android, как пример), культуры (в арабском мире удобно и красиво будет отличаться от принятого в Китае), и времени (тут можно глянуть на разницу в правилах верстки в 90-х и сейчас).
В то же время книги по теории распределенных систем 10 летней давности актуальнее некуда, а уж математика выученная 30 лет назад актуально совершенно так же как и тогда. Так что в одном случае у нас теоретическая база устаревает, а в другом ты набираешь знаний и опыта который актуален как и 10, и 20 лет назад, так и будет еще много лет.
В компаниях где практикуются регулярные оценки производительности (performance review), ты должен предоставить список того что сделал с момента последней оценки. Соответственно ты должен собирать заметные вещи которые были сделаны за, к примеру, пол года и упорядочить их.
Тут предлагается делать тоже самое, только добровольно. За что-то же деньги платили? Что-то было сделано. Какая-то особо полезная фича, какое-то изменение в процессах, какие-то полезные для других команд вещи.
Можно просто быть хорошим специалистом в стране где возрастная дискриминация действительно является преступлением.