Сразу скажу, что я так делал, и мои «простые и понятные задачки» (естественно, простые, если ты в теме… ну или если знаешь решение) ставили собеседующего в тупик. Неловко, не правда ли? Примерно так же, как получить простую задачку, собеседуясь на сеньора.
Обычно есть некоторое количество кандидатов из которых надо выбрать, и вакансия, на которую надо принять человека. После собеседования N кандидатов примерно понятен их уровень и выбирается уже из них. Если на задачке совсем все заваливаются она просто не достигает своей цели — подсказать кого выбрать из пула. Соответственно задача калибруется.
Они превращаются в какую-то угадайку о том, что хотел сказать интервьювер.
По-моему, в таком случае правильно задавать дополнительные вопросы и характр этих вопросов очень хорошо показывает на каком уровне человек решает задачу
Экспериме́нт (от лат. experimentum — проба, опыт), также о́пыт, в научном методе — метод исследования некоторого явления в управляемых наблюдателем условиях
…
Оскорбле́ние — это умышленное унижение чести и достоинства личности, выраженное в неприличной форме
Оскорбление заключается в негативной оценке личности либо внешности человека, его качествам, поведению, причём в форме, противоречащей установленным правилам поведения и требованиям общечеловеческой морали.
Мне кажется задавание любых вопросов в контроллируемых условиях есть эксперимент. Почему задвание нестандартных вопросов является оскорблением? Чем вопрос про танцующего пингвина унижает и в какой форме негативно оценивает вас?
Я просто не очень понимаю как именно кандидат будет подготовлен и почему тестирование подготовленного кандидата будет давать больше информации о нем, чем тестирование неподготовленного.
Если вас не затруднит, не могли бы вы с примером показать, как именно кандидат будет готовиться и что от этого получит работодатель?
UPD. Не сориентировался в цепочке ответов думал, что отвечали мне.
Мое мнение — это неправильная, конфликтная стратегия.
Перечить не надо. Надо уточнять. Идиотский ответ — это уже «перечить» (вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно. Кстати, тут возникает вопрос, почему он не понимает. Может быть софт не подсказывает как это делать правильно? У него нет инструкции?)
Четкое описание задачи — это навык. Обычно он появляется от опыта. Надо помогать коллегам его приобретать. Обычно люди, которые могут решать проблемы в целом, стоят дороже чем люди которые копают отсюда и до обеда.
Дорогой программист (при прочих равных) должен иметь приветливый дуракоустойчивый интерфейс с проверкой на ошибки. Или будте готовы к распределению стоимости в пользу более дорогого консультанта, тилида или кого-то еще кто будет вас понимать.
ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
Я думаю, для дела будет лучше написать, "не удалось воспроизвести, недостаточно информации" и привести ссылку на принятые рекомендации по оформлению ошибок типа https://geteasyqa.com/qa/write-bug-report/, но адаптированную для вашего продукта.
Очевидно по умолчанию считается ближайший медведь и он черный. Потому, что это биржевой игрок на понижение приехавший на южный полюс с туристическим визитом не снимая своего смокинга.
Также не сказано что стуны повернуты только на север. Возможно это кольцевой дом, единственная кольцевая стена которого повернута во все стороны. Или бутылка клейна.
Но на работу я бы принял чувака, который бы не стал отвечать формально а стал бы переспрашивать точно ли мы имеем ввиду медведя а не пингвина и предложил варианты решения прротиворечия :)
А то сделают формально по ТЗ не уточняя а потом всем плохо
Например я первой строчкой пишу на какой конкретно сборке был сделан тест (одна версия у нас содержит множество сборок, под разные платформы, языки и пр. )
А нельзя это делать не шаблонами, а обязательными полями в багтрекере?
Самой команде обычно всё это не нужно, фичи и фиксы, польза пользователям доставляются по мере готовности согласно намеченному плану.
Для того, чтобы так было нужна организация, обладающая определенными свойствами. Например, может быть организация разработки где принято делать релизы раз в год. Какие-то фичи готовы, но чтобы зарелизить, надо стабилизировать код — поэтому нельзя выкатить фичу отдельно.
Почему нужно именно описание тикетов? Если их много, можно обобщить.
Заголовок спойлера
Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
— What did I do yesterday that helped the Development Team meet the Sprint Goal?
— What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
— The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
Я думаю можно такое провести, если запретить разработку без лицензии.
В противном случае ни для кого из участников это не окупит. Есть разные исследования проессов на студентах — например TDD, кажется. Но на боевых задачах и квалифицированных специалистов это безумно дорого.
Обычно есть некоторое количество кандидатов из которых надо выбрать, и вакансия, на которую надо принять человека. После собеседования N кандидатов примерно понятен их уровень и выбирается уже из них. Если на задачке совсем все заваливаются она просто не достигает своей цели — подсказать кого выбрать из пула. Соответственно задача калибруется.
По-моему, в таком случае правильно задавать дополнительные вопросы и характр этих вопросов очень хорошо показывает на каком уровне человек решает задачу
Мне кажется задавание любых вопросов в контроллируемых условиях есть эксперимент. Почему задвание нестандартных вопросов является оскорблением? Чем вопрос про танцующего пингвина унижает и в какой форме негативно оценивает вас?
Если вас не затруднит, не могли бы вы с примером показать, как именно кандидат будет готовиться и что от этого получит работодатель?
А зачем это надо работодателю?
Мое мнение — это неправильная, конфликтная стратегия.
Перечить не надо. Надо уточнять. Идиотский ответ — это уже «перечить» (вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно. Кстати, тут возникает вопрос, почему он не понимает. Может быть софт не подсказывает как это делать правильно? У него нет инструкции?)
Четкое описание задачи — это навык. Обычно он появляется от опыта. Надо помогать коллегам его приобретать. Обычно люди, которые могут решать проблемы в целом, стоят дороже чем люди которые копают отсюда и до обеда.
Дорогой программист (при прочих равных) должен иметь приветливый дуракоустойчивый интерфейс с проверкой на ошибки. Или будте готовы к распределению стоимости в пользу более дорогого консультанта, тилида или кого-то еще кто будет вас понимать.
Я думаю, для дела будет лучше написать, "не удалось воспроизвести, недостаточно информации" и привести ссылку на принятые рекомендации по оформлению ошибок типа https://geteasyqa.com/qa/write-bug-report/, но адаптированную для вашего продукта.
Также не сказано что стуны повернуты только на север. Возможно это кольцевой дом, единственная кольцевая стена которого повернута во все стороны. Или бутылка клейна.
Но на работу я бы принял чувака, который бы не стал отвечать формально а стал бы переспрашивать точно ли мы имеем ввиду медведя а не пингвина и предложил варианты решения прротиворечия :)
А то сделают формально по ТЗ не уточняя а потом всем плохо
А нельзя это делать не шаблонами, а обязательными полями в багтрекере?
Вы хотите, чтобы разработать hello, world или бухгалтерию стоило столько же, сколько выпустить новое лекарство?
Для того, чтобы так было нужна организация, обладающая определенными свойствами. Например, может быть организация разработки где принято делать релизы раз в год. Какие-то фичи готовы, но чтобы зарелизить, надо стабилизировать код — поэтому нельзя выкатить фичу отдельно.
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
— What did I do yesterday that helped the Development Team meet the Sprint Goal?
— What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
— The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
В противном случае ни для кого из участников это не окупит. Есть разные исследования проессов на студентах — например TDD, кажется. Но на боевых задачах и квалифицированных специалистов это безумно дорого.
С учетом того, что большинство и не пытается, в этом нет противоречия.