Олицетворение того, как огромный процент программистов предлагает автоматизацию процесса, который стоит без автоматизации 10 рублей, а сама автоматизация миллион рублей.
У всех предметные области разные. Где-то можно пройти полное погружение за неделю, где-то и полгода не хватит. Я имею ввиду про погружение без ненужных деталей
Никто не отменял работу продактов, но разработчик, который более глубоко понимает предметную область, вероятно быстрее будет понимать поставленные задачи, и сможет эффективнее с ними работать.
Ну и если так подумать. Погружение в предметную область (поверхностно) не занимает какого-то огромного количества времени, а эффект может принести колоссальный.
Объемные тестовые задания могут отфильтровать как слабых специалистов, так и сильных - которых вы ищите. Считаю, что нет отчетливого ответа на вопрос - нужно тестовое задание или нет, везде индивидуально.
Иногда достаточно провести собеседование "качественно", в несколько этапов, причем это можно сделать за одну встречу.
Задача человека, который собеседует кандидата - постараться более точно оценить уровень специалиста, а так же его мышление, но сделать это так, чтобы человек захотел придти работать к вам.
Например, после технических вопросов можно дать код на ревью этому человеку, посмотреть как он его видит, послушать его рассуждения, иногда уже на этом этапе можно увидеть что специалист сильный, или слабый.
Возможно скажу очень цинично, но часто в компаниях боятся найти неподходящего специалиста, и готовы искать его год, лишь бы подошел по всем параметрам, тогда зачем нужен испытательный срок? За это время специалист оценивает, подходите ли вы ему, а вы оцениваете его. И за этот срок, пока он онбордится, вполне реально закрыть те пробелы, которых ему не хватало. Тестовое задание, может такой кейс отфильтровать, это будет, как мне кажется, неправильно. А если специалист оказался неподходящим, с ним вполне честно можно расстаться.
Но вот если компания понимает, что такой подход ей не подходит, тогда уже можно включать фильтр тонкой очистки в виде тестового задания.
Опять же повторюсь, все индивидуально. Специалист может быть нужен "срочно", а где-то вы можете позволить искать специалистов год и больше
Как мне кажется, важно уметь описывать свой богатый опыт лаконично, но наполнив текст всей глубиной смысла, чтобы резюме было понятно и HR'у, и разработчику, и тимлиду. Чтобы резюме можно было начать смотреть и снизу и сверху. А так же важно указывать, с помощью какого инструментария ты решал те или иные задачи, тогда резюме становится более ценным.
Еще важно помнить, что очень часто на первичный просмотр резюме человек может потратить от 10 до 30 секунд, и если он нашел для себя те ключевые навыки, инструменты или зацепился за интересный опыт, будет готов потратить больше времени на его изучение, для того, чтобы пригласить человека на собеседование.
Интересно, что будет с данной статистикой, если добавить людей из IT, которые не заполняют анкеты на habr по зарплате и не следят за актуальными трендами?
Не понимаю почему в самом начале статьи, где вы описываете кто такой Teamlead, через запятую приводите как синоним - Ведущий разработчик.
Ведущий разработчик != Тимлид
Ну и вообще в классическом скраме нет такой роли, как тимлид.
Но вообще было интересно почитать, и многое откликается.
По моему мнению, популярное "выгорание тимлидов" связано как раз с тем, что у многих людей на этой позиции невероятная любовь к программированию, без чего человек вообще не может.
Сужу исключительно по своему опыту и обратной связи коллег и знакомых. Встречи в живую фактически проходят дольше, как минимум - человек тратит время, чтобы дойти до переговорки, и обратно. Плюс личные встречи просто банально проходят дольше.
Вполне допускаю, что могу быть и не прав, плюс наверняка и в той и в другой ситуации могут быть частные случаи, но на моем опыте именно так.
Период пандемии вынуждено сдвинул развитие культуры удаленной работы вперед. Развитие информационных технологий к тому моменту уже давно достигло планки, когда человек мог работать удаленно, но многие работодатели, да и в целом сами люди очень медленно принимали этот факт. У многих "начальников" был страх потерять контроль над сотрудниками на удаленке, или страх уменьшения эффективности.
Принятие удаленки, как мне кажется, сильно ускорило многие рабочие процессы и развитие бизнеса в целом, например рабочие звонки в Zoom (раньше это были очные встречи), занимают гораздо меньше времени и на подготовку и на проведение звонка.
Удаленка это конечно хорошо, но есть огромное количество проблем, в том числе которые описаны в этой статье. Как мне кажется, культура удаленной работы развита еще очень слабо, и возможно многие проблемы нужно решать глобально, возможно даже на уровне общего образования. Очень остро стоит проблема переработок на удаленной работе, люди явно стали работать больше, а не меньше, и часто это не проблема работодателя, а самого работника (простите за такую жесткую позицию). Разделение работы от остальной жизни, часто является серьезной задачей, с которой очень многим сложно справиться - и это только один из больших кейсов, которые нужно решать, потому что культура удаленки не куда не денется, и теперь будет с нами всегда.
Самими лучшими шпаргалками всегда будут собственные шпаргалки, чтобы по 100 раз не вспоминать и не изобретать велосипеды. Лучше всего сохранять свои наработки или короткие команды в шпаргалки в условный github, чтобы через неделю, месяц или пару лет можно было вернуться и быстро использовать знания, которые могли подзабыться.
Статистике могу поверить, но все же, на основании каких данных делалась выборка по типу людей, готовым к изменениям?
Тут нужно понимать, что не всегда новаторы сами готовы на новые изменения, бывают разные ситуации.
Борьба с сопротивлением на изменения есть везде и в любой жизненной сфере (бизнес, командные процессы, переставление мебели дома, и так далее) , нужно просто уметь правильно объяснять цели изменений, а с сопротивлением планомерно работать, маленькими шагами, не надрывая психику людей резкими изменениями, внедряя их плавно.
Олицетворение того, как огромный процент программистов предлагает автоматизацию процесса, который стоит без автоматизации 10 рублей, а сама автоматизация миллион рублей.
nslookup ya.ru 8.8.8.8
Кажется ожил
habr.ru редиректит на habr.com, лично у меня не заходит с одного устройства, а с другого заходит
Многие (кто не знал) теперь будут знать, что такое DNS
P.S. С телефона не заходит на эту страницу, так как не было в кеша dns
У всех предметные области разные. Где-то можно пройти полное погружение за неделю, где-то и полгода не хватит. Я имею ввиду про погружение без ненужных деталей
Полностью поддерживаю докладчика.
Никто не отменял работу продактов, но разработчик, который более глубоко понимает предметную область, вероятно быстрее будет понимать поставленные задачи, и сможет эффективнее с ними работать.
Ну и если так подумать. Погружение в предметную область (поверхностно) не занимает какого-то огромного количества времени, а эффект может принести колоссальный.
язык программирования – это всего-лишь инструмент
за это отдельный +
Объемные тестовые задания могут отфильтровать как слабых специалистов, так и сильных - которых вы ищите. Считаю, что нет отчетливого ответа на вопрос - нужно тестовое задание или нет, везде индивидуально.
Иногда достаточно провести собеседование "качественно", в несколько этапов, причем это можно сделать за одну встречу.
Задача человека, который собеседует кандидата - постараться более точно оценить уровень специалиста, а так же его мышление, но сделать это так, чтобы человек захотел придти работать к вам.
Например, после технических вопросов можно дать код на ревью этому человеку, посмотреть как он его видит, послушать его рассуждения, иногда уже на этом этапе можно увидеть что специалист сильный, или слабый.
Возможно скажу очень цинично, но часто в компаниях боятся найти неподходящего специалиста, и готовы искать его год, лишь бы подошел по всем параметрам, тогда зачем нужен испытательный срок? За это время специалист оценивает, подходите ли вы ему, а вы оцениваете его. И за этот срок, пока он онбордится, вполне реально закрыть те пробелы, которых ему не хватало. Тестовое задание, может такой кейс отфильтровать, это будет, как мне кажется, неправильно. А если специалист оказался неподходящим, с ним вполне честно можно расстаться.
Но вот если компания понимает, что такой подход ей не подходит, тогда уже можно включать фильтр тонкой очистки в виде тестового задания.
Опять же повторюсь, все индивидуально. Специалист может быть нужен "срочно", а где-то вы можете позволить искать специалистов год и больше
+
Благодаря этой игре я понял, что жизнь не так проста, как кажется
Пойду скачаю Deus Ex, чтобы насладиться атмосферой, музыкой, ностальгией :)
Как мне кажется, важно уметь описывать свой богатый опыт лаконично, но наполнив текст всей глубиной смысла, чтобы резюме было понятно и HR'у, и разработчику, и тимлиду. Чтобы резюме можно было начать смотреть и снизу и сверху. А так же важно указывать, с помощью какого инструментария ты решал те или иные задачи, тогда резюме становится более ценным.
Еще важно помнить, что очень часто на первичный просмотр резюме человек может потратить от 10 до 30 секунд, и если он нашел для себя те ключевые навыки, инструменты или зацепился за интересный опыт, будет готов потратить больше времени на его изучение, для того, чтобы пригласить человека на собеседование.
Динамика неплохая!
Интересно, что будет с данной статистикой, если добавить людей из IT, которые не заполняют анкеты на habr по зарплате и не следят за актуальными трендами?
Здравствуйте! На сколько мне известно, Matomo умеет читать dataLayer.
Не очень понял конечную цель данных изменений
Не понимаю почему в самом начале статьи, где вы описываете кто такой Teamlead, через запятую приводите как синоним - Ведущий разработчик.
Ведущий разработчик != Тимлид
Ну и вообще в классическом скраме нет такой роли, как тимлид.
Но вообще было интересно почитать, и многое откликается.
По моему мнению, популярное "выгорание тимлидов" связано как раз с тем, что у многих людей на этой позиции невероятная любовь к программированию, без чего человек вообще не может.
Поэтому и написал - "как мне кажется".
Сужу исключительно по своему опыту и обратной связи коллег и знакомых. Встречи в живую фактически проходят дольше, как минимум - человек тратит время, чтобы дойти до переговорки, и обратно. Плюс личные встречи просто банально проходят дольше.
Вполне допускаю, что могу быть и не прав, плюс наверняка и в той и в другой ситуации могут быть частные случаи, но на моем опыте именно так.
Период пандемии вынуждено сдвинул развитие культуры удаленной работы вперед. Развитие информационных технологий к тому моменту уже давно достигло планки, когда человек мог работать удаленно, но многие работодатели, да и в целом сами люди очень медленно принимали этот факт. У многих "начальников" был страх потерять контроль над сотрудниками на удаленке, или страх уменьшения эффективности.
Принятие удаленки, как мне кажется, сильно ускорило многие рабочие процессы и развитие бизнеса в целом, например рабочие звонки в Zoom (раньше это были очные встречи), занимают гораздо меньше времени и на подготовку и на проведение звонка.
Удаленка это конечно хорошо, но есть огромное количество проблем, в том числе которые описаны в этой статье. Как мне кажется, культура удаленной работы развита еще очень слабо, и возможно многие проблемы нужно решать глобально, возможно даже на уровне общего образования. Очень остро стоит проблема переработок на удаленной работе, люди явно стали работать больше, а не меньше, и часто это не проблема работодателя, а самого работника (простите за такую жесткую позицию). Разделение работы от остальной жизни, часто является серьезной задачей, с которой очень многим сложно справиться - и это только один из больших кейсов, которые нужно решать, потому что культура удаленки не куда не денется, и теперь будет с нами всегда.
Но это очень хорошо.
Многим такое пригодится. Спасибо.
Самими лучшими шпаргалками всегда будут собственные шпаргалки, чтобы по 100 раз не вспоминать и не изобретать велосипеды. Лучше всего сохранять свои наработки или короткие команды в шпаргалки в условный github, чтобы через неделю, месяц или пару лет можно было вернуться и быстро использовать знания, которые могли подзабыться.
Статистике могу поверить, но все же, на основании каких данных делалась выборка по типу людей, готовым к изменениям?
Тут нужно понимать, что не всегда новаторы сами готовы на новые изменения, бывают разные ситуации.
Борьба с сопротивлением на изменения есть везде и в любой жизненной сфере (бизнес, командные процессы, переставление мебели дома, и так далее) , нужно просто уметь правильно объяснять цели изменений, а с сопротивлением планомерно работать, маленькими шагами, не надрывая психику людей резкими изменениями, внедряя их плавно.
Тема очень интересная, пожалуйста пишите больше. Я как раз планирую реализовать УД на своей дачи, и хотелось бы это сделать по уму, а не для галочки
Правила (теории вероятности) созданы, чтобы их нарушать ;)