Никто не отрицает, что могут попадаться персонажи с сертификатом или дипломом, но заметно не дотягивают до заявленных знаний. Но ведь речь идёт не об этом. Вот если у вас 100 кандидатов на должность и вы хотите найти наиболее подходящего, то вы замучаетесь выбирать. А если вы заявите необходимость сертификата, то внезапно кандидатов станет в 4 раза меньше. Причём вероятность, что вы найдёте кого вам надо среди оставшихся будет очень высока. Просто дворник не пойдёт заморачиваться сдавать Amazon сертификат. Соответственно, наличие сертификата - это значимый показатель. Далее, при необходимости можно проверить, достаточно ли реальных знаний.
Так что, это не филькина грамота, а очень полезный инструмент как для работодателя, так и для специалиста. И это становится намного очевидней, если смотреть на них через вероятности применительно к множеству кандидатов.
Ну и пускай это будет ритуальная пляска. Зато толпа кандидатов готовится, читает умные книжки, учится конструктивно вести обсуждение. Если человек способен выполнить ритуал как положено, значит и работать сможет как необходимо для компании. Кругом одни плюсы, разве не так?
Статья описывпет очень явно висящую в воздухе тему. Только рассуждение на тему "как должно быть" немного неправильно. Тут нет центра принятия решений, которой сделает как хотелось бы. Тут есть многотонный самосвал, который разогнался до огромной скорости и выехал на лёд. Вся система набрала большую инэрцию и у нас довольно мало рычагов влияния. ЖЕЛАЕМАЯ траектория движения и конечный пункт скрее всего вообще не достижимы. Надо надеяться, что впереди нет бетонной стены, и стараться хоть как-то влиять на процесс.
Вобщем, я к тому что более ценно сейчас говорить не как должно быть, а рассуждать какие реальные действия и меры стоит пробовать применять, чтобы влиять на всю систему для движения в предпочтительную сторону.
Чтобы разметка не разьезжалась при добавлении цены за единицу, я бы рассчитанную цену отображал как всплывающий tooltip при неведении мыши. Таким образом мы не перегружаем интерфейс множеством цифр, не меняем визуально дизайн вообще, но даём возможность легко узнать цену за единицу, когда этого желает пользователь.
Вот так почитаешь, что надо знать и сходу уметь делать, чтобы пройти собеседование, и становится немного не по себе. Даже не смотря на многолетний опыт и хорошую должность. Уверен, много специалистов сходу не пройдут такое интервью без подготовки. А те кто пройдут, вряд-ли будут все эти знания на рабочем месте каждый день использовать. Так что получается скил прохождения интервью для того чтобы пойти интервью (как наука ради науки). Компании по сути выбирают кто лучше подготовился.
Мне кажется заголовок статьи привлекает определённую аудиторию - тех кто хочет, но ещё не умеет. Однако, статья очень искусно обходит стороной все делали, которые были бы очень важны для этой аудитории.
Вроде бы и пример какой-то рассмотрен, но совершенно не понятно что, как, куда, с чего начать... Вообще не понятно "как стать AI-разработчиком" после прочтения этой статьи. Таким образом, либо заголовок не соответствует содержанию, либо в статье не хватает множества подробностей, и какого-то внятного заключения с ответом на вопрос, как же всё таки стать AI-разработчиком.
Первый раз услышал про СкрамБан, и приятно удивился. Значит мы не единственные, кто берет известные практики, но не следует им. Потом это всё перемешивается, и получившийся монстр, который не имеет названия. Но ведь главное, чтобы все были счасливы, правда?!
Кстати, когда пытались строго следовать скраму, жизнь в проекте была очень изнурительной. Всё время казалось, что что-то висит над головой, а мы постоянно опаздываем. Потом вспоминая этот опыт я даже увидел наглядное объяснение почему мне не нравится этот подход. Спринт - это очень быстрый бег, когда тебе надо пробежать короткую дистанцию. Но ведь разработать программный продукт - это не короткая дистанция. Попробуйте пробежать марафон, нарезав его на стометровки, и бежать каждую как спринт... А потом удивляются, почему все айтишники говорят про выгорание.
Да! Я тоже был студентом, хотел получить опыт, мечтал о таких проектах... Но мне повезло видимо чуть больше. Залог успеха в моём случае был в том, что "проект" был очень ограничен по времени (кажется 2 недели), в командах было по 10 студентов, и мы соревновались между универами. При этом, на период проекта мы не просто не ходили на лекции, а мы вообще уехали в другой город. Полное погружение, и мотивация зашкаливала. И конечно в конце это можно было зачесть за подобный предмет.
Много лет спустя я вспоминаю тот свой опыт, и понимаю, что студентов нельзя наверное мерить уровнем работника предприятия. Если есть Junior/Middle/Senior, то студент это pre-Junior. И по знаниями, и по ответственности (как много раз было упомянуто в статье), и по умению работать в команде. Однако, я всё равно верю, что правило "спрос рождает предложение" применимо и здесь. Студенты хотят и могут участвовать в таких проектах. Надо только создать правильные условия, и не ждать больших результатов, ведь для многих это будет первый опыт.
По моему, автор молодец! Он добился своей цели. Написал короткую статью про очень важную и полезную вещь. Пусть его изложение и далеко от идеала, но помогает начинающим в этой теме. А хабр, и всё сообщество неравнодушных комментаторов, в данном случае, продолжает тему в виде дискуссий и покрывает многие пробелы, сглаживает шероховатости. Читатель имеет возможность посмотреть на ошибки и их обсуждения, как те что были описаны в самой статье, так и те, о которых говорится в комментариях. Особенно приятно видеть философские примечания о целесообразности некоторых принцыпов в разных ситуациях!
А никто не заметил, что несмотря на присутствие ссылок на трёх гигантов: Amazon, Microsoft, Google, все примеры и описания говорят только про AWS? Хотелось уже увидеть какое-то обобщение, или разнообразие примеров - статья выглядела бы заметно лучше.
В последнем примере как-то явно в тексте не говорится, что речь идёт про удаление несуществующего элемента "response", и именно из-за этого и возникает проблема, о которой идёт речь. Приходится догадываться об этом из строк кода.
Прочитал первую букву вашего комментария и сразу могу сказать...
Вы же понимаете, что после такого вступления ценность следующих слов близится к нулю.
Ну не правда!
Никто не отрицает, что могут попадаться персонажи с сертификатом или дипломом, но заметно не дотягивают до заявленных знаний. Но ведь речь идёт не об этом. Вот если у вас 100 кандидатов на должность и вы хотите найти наиболее подходящего, то вы замучаетесь выбирать. А если вы заявите необходимость сертификата, то внезапно кандидатов станет в 4 раза меньше. Причём вероятность, что вы найдёте кого вам надо среди оставшихся будет очень высока. Просто дворник не пойдёт заморачиваться сдавать Amazon сертификат. Соответственно, наличие сертификата - это значимый показатель. Далее, при необходимости можно проверить, достаточно ли реальных знаний.
Так что, это не филькина грамота, а очень полезный инструмент как для работодателя, так и для специалиста. И это становится намного очевидней, если смотреть на них через вероятности применительно к множеству кандидатов.
Ну и пускай это будет ритуальная пляска. Зато толпа кандидатов готовится, читает умные книжки, учится конструктивно вести обсуждение. Если человек способен выполнить ритуал как положено, значит и работать сможет как необходимо для компании. Кругом одни плюсы, разве не так?
Статья описывпет очень явно висящую в воздухе тему. Только рассуждение на тему "как должно быть" немного неправильно. Тут нет центра принятия решений, которой сделает как хотелось бы. Тут есть многотонный самосвал, который разогнался до огромной скорости и выехал на лёд. Вся система набрала большую инэрцию и у нас довольно мало рычагов влияния. ЖЕЛАЕМАЯ траектория движения и конечный пункт скрее всего вообще не достижимы. Надо надеяться, что впереди нет бетонной стены, и стараться хоть как-то влиять на процесс.
Вобщем, я к тому что более ценно сейчас говорить не как должно быть, а рассуждать какие реальные действия и меры стоит пробовать применять, чтобы влиять на всю систему для движения в предпочтительную сторону.
Чтобы разметка не разьезжалась при добавлении цены за единицу, я бы рассчитанную цену отображал как всплывающий tooltip при неведении мыши. Таким образом мы не перегружаем интерфейс множеством цифр, не меняем визуально дизайн вообще, но даём возможность легко узнать цену за единицу, когда этого желает пользователь.
Спасибо за перевод.
Вот так почитаешь, что надо знать и сходу уметь делать, чтобы пройти собеседование, и становится немного не по себе. Даже не смотря на многолетний опыт и хорошую должность. Уверен, много специалистов сходу не пройдут такое интервью без подготовки. А те кто пройдут, вряд-ли будут все эти знания на рабочем месте каждый день использовать. Так что получается скил прохождения интервью для того чтобы пойти интервью (как наука ради науки). Компании по сути выбирают кто лучше подготовился.
Мне кажется заголовок статьи привлекает определённую аудиторию - тех кто хочет, но ещё не умеет. Однако, статья очень искусно обходит стороной все делали, которые были бы очень важны для этой аудитории.
Вроде бы и пример какой-то рассмотрен, но совершенно не понятно что, как, куда, с чего начать... Вообще не понятно "как стать AI-разработчиком" после прочтения этой статьи. Таким образом, либо заголовок не соответствует содержанию, либо в статье не хватает множества подробностей, и какого-то внятного заключения с ответом на вопрос, как же всё таки стать AI-разработчиком.
Первый раз услышал про СкрамБан, и приятно удивился. Значит мы не единственные, кто берет известные практики, но не следует им. Потом это всё перемешивается, и получившийся монстр, который не имеет названия. Но ведь главное, чтобы все были счасливы, правда?!
Кстати, когда пытались строго следовать скраму, жизнь в проекте была очень изнурительной. Всё время казалось, что что-то висит над головой, а мы постоянно опаздываем. Потом вспоминая этот опыт я даже увидел наглядное объяснение почему мне не нравится этот подход. Спринт - это очень быстрый бег, когда тебе надо пробежать короткую дистанцию. Но ведь разработать программный продукт - это не короткая дистанция. Попробуйте пробежать марафон, нарезав его на стометровки, и бежать каждую как спринт... А потом удивляются, почему все айтишники говорят про выгорание.
Да! Я тоже был студентом, хотел получить опыт, мечтал о таких проектах... Но мне повезло видимо чуть больше. Залог успеха в моём случае был в том, что "проект" был очень ограничен по времени (кажется 2 недели), в командах было по 10 студентов, и мы соревновались между универами. При этом, на период проекта мы не просто не ходили на лекции, а мы вообще уехали в другой город. Полное погружение, и мотивация зашкаливала. И конечно в конце это можно было зачесть за подобный предмет.
Много лет спустя я вспоминаю тот свой опыт, и понимаю, что студентов нельзя наверное мерить уровнем работника предприятия. Если есть Junior/Middle/Senior, то студент это pre-Junior. И по знаниями, и по ответственности (как много раз было упомянуто в статье), и по умению работать в команде. Однако, я всё равно верю, что правило "спрос рождает предложение" применимо и здесь. Студенты хотят и могут участвовать в таких проектах. Надо только создать правильные условия, и не ждать больших результатов, ведь для многих это будет первый опыт.
По моему, автор молодец! Он добился своей цели. Написал короткую статью про очень важную и полезную вещь. Пусть его изложение и далеко от идеала, но помогает начинающим в этой теме. А хабр, и всё сообщество неравнодушных комментаторов, в данном случае, продолжает тему в виде дискуссий и покрывает многие пробелы, сглаживает шероховатости. Читатель имеет возможность посмотреть на ошибки и их обсуждения, как те что были описаны в самой статье, так и те, о которых говорится в комментариях. Особенно приятно видеть философские примечания о целесообразности некоторых принцыпов в разных ситуациях!
Приятно почитать, спасибо!
А никто не заметил, что несмотря на присутствие ссылок на трёх гигантов: Amazon, Microsoft, Google, все примеры и описания говорят только про AWS? Хотелось уже увидеть какое-то обобщение, или разнообразие примеров - статья выглядела бы заметно лучше.
В последнем примере как-то явно в тексте не говорится, что речь идёт про удаление несуществующего элемента "response", и именно из-за этого и возникает проблема, о которой идёт речь. Приходится догадываться об этом из строк кода.