Вы правы. Часто встречаю эту ситуацию именно у молодых разработчиков, либо у кандидатов 25-35 лет, которые «меняют область»/«хотят уйти в IT», то есть раньше были продажниками, страховщиками и т.п.
Не так часто встречается у нас пока хорошая культура разработки и саморазвития.
Какой бы «подвешенный язык» не был, технические вопросы есть технические вопросы, это не рассуждения «о смысле жизни», то что вы говорите или работает или нет.
К сожалению, ваши утверждения больше склоняют меня ко мнению, что вы не совсем ориентируютесь в том, о чем говорите. В частности в том, как проводить собеседования и оценивать технических кандидатов.
Некоторых пугает такой подход. Можно даже услышать фразы «Это же ваша текущая работа? Вы мне заплатите за нее?». Все же иногда попадаются недобросовестные работодатели, хотя чаще это все же паранойя со стороны кандидата.
«Иметь под рукой», не значит «Задать обязательно все». Не путайте подготовку и проведение. Часто бывает что уже по первому вопросу видно насколько хорошо кандидат разбирается в области и дальнейшие вопросы отпадают.
Не знаю как образом отрытый вопрос вы считаете «ни о чем», он имеет вполне конкретный и развернутый ответ.
С тестовыми заданиями многие не готовы иметь дело, особенно если речь идет о senior-level разработчиках, им просто это не нужно.
Уверен, что это вопрос конкретного случая (большой проект в большой компании), и, судя по вашему комментарию, вы профессионально разрешили эту ситуацию. Вашей компании повезло с вами.
В случае, который вы описали, речь идет скорее не о регламентах, а о том, кто готов нести ответственность. Я очень четко про описал, что динамическое звено берет ее на себя. Как поступили и вы, защитив команду.
Так что регламент это вопрос именно ответственности. Если кто-то не готов ее брать, а порой и просто «переводит стрелки», то ни о каких динамических звеньях речи идти не может.
Все зависит от места. Если вы «живете по уставу», тогда да. Если же вы существуете в конкурентной среде, то мнение про инициативных людей как про «агентов хаоса в системе», с высокой долей вероятности, сведет вашу динамику на нет, а за ней и компанию.
1. Название статьи очень и очень косвенно говорит о ее содержании. Как минимум стоило бы написать в скобках (ч. 1).
2. Материалов по тому что вы написали, в довольно широком смысле и более раскрывающих тему в интернете огромное количество. Достаточно загуглить «mvc php».
3. Самый лучший способ понять поможет ли кому-то то что вы написали, это вспользоватся самостоятельно этим «tutorial». Поверьте, толку от него будет мало. То что вы описали мало того что часто уже написано в ORM библиотеках, так еще и может сбить с толку, когда будет выбираться подход к хранению бизнес-логики.
4. Если вам нужна информация, или хотите сделать что-то полезное, обратитесь сперва к опытным коллегам, они, как правило, помогут.
5. Лучше в черновики.
Поделитесь, пожалуйста, ссылочкой на доклад Марата про проектирование систем, о котором в начале видео говорится. Ссылка из доклада (http://study.yandex-team.ru/events/kmb-2/techno/talks/901) наружу не доступна.
Да, была такая идея.
Хочу посмотреть будет ли востребовано и если какую-то обратную связь получу, то допилю такую фишку.
Не так часто встречается у нас пока хорошая культура разработки и саморазвития.
К сожалению, ваши утверждения больше склоняют меня ко мнению, что вы не совсем ориентируютесь в том, о чем говорите. В частности в том, как проводить собеседования и оценивать технических кандидатов.
Не знаю как образом отрытый вопрос вы считаете «ни о чем», он имеет вполне конкретный и развернутый ответ.
С тестовыми заданиями многие не готовы иметь дело, особенно если речь идет о senior-level разработчиках, им просто это не нужно.
Скорее всего, вам понравится.
Так что регламент это вопрос именно ответственности. Если кто-то не готов ее брать, а порой и просто «переводит стрелки», то ни о каких динамических звеньях речи идти не может.
www.kickstarter.com/projects/sunn/sunn-lights-sync-with-the-rhythm-of-the-sun
2. Материалов по тому что вы написали, в довольно широком смысле и более раскрывающих тему в интернете огромное количество. Достаточно загуглить «mvc php».
3. Самый лучший способ понять поможет ли кому-то то что вы написали, это вспользоватся самостоятельно этим «tutorial». Поверьте, толку от него будет мало. То что вы описали мало того что часто уже написано в ORM библиотеках, так еще и может сбить с толку, когда будет выбираться подход к хранению бизнес-логики.
4. Если вам нужна информация, или хотите сделать что-то полезное, обратитесь сперва к опытным коллегам, они, как правило, помогут.
5. Лучше в черновики.