Валидация action point'ов как отдельный шаг не нужен. Потому что ретроспектива это не отчёт. Если у нас какой-то action point не решил проблему (и не важно -- потому что не был выполнен, или потому что не помог), мы заново вписываем проблему в список, и, если она по прежнему актуальна, ищем новые решения. Разумеется, если будет предложено то, что уже предлагалось ранее, то стоит обращать на это внимание и уточнять, а чем текущее предложение лучше несработавшего старого.
Присутствие PO это штука спорная. Очень много зависит от того, а кого вы называете владельцем продукта, и кем он сам себя считает. Если этот человек участвует в написании кода и ревью -- его 100% надо включать. Если человек что-то делает внутри команды (закрывает таски в Jira) -- тоже надо. Если же он только таски создаёт... будет зависеть от самого человека, в том числе его адекватности. Ну и загруженности. Если человек даже Jira не видит и только раздаёт ЦУ -- ему на ретро точно делать нечего.
Исходно обсуждалась не проблема, что не соблюдается процесс, а проблема, что слишком мягко/строго проводится ревью, потому что это вообще не было формализовано. То есть надо было выработать подход, как должно проходить ревью (сколько человек, как быстро, кто). У нас это вылилось не в формализацию в вики, а в написание скрипта, который часть этого процесса автоматизировал. Оставшуюся пока что помним в голове.
А вот если процесс не будет соблюдаться (когда процесс уже есть), тогда да, первый шаг -- его куда-нибудь записать. Но у нас такой проблемы пока не было.
А ретроспективу в общем то и необязательно проводить если команда не видит проблем которые ей мешают
При кажущейся очевидности этой мысли, я склонен считать, что так не бывает, и скорее всего команда просто не видит смысла высказывать свои проблемы в том формате, в котором у вас проходит ретро.
Процесс может быть и описан, а может быть и на словах. В последних двух командах он был "на словах и в скриптах". До этого было формальное описание, общее для десятка команд... на которое команды забивали и всё равно делали по своему.
Уменьшение тех. долга -- имеется ввиду добавление конкретной задачи, в которой по итогам ретроспективы уже понятно, что сделать. Тут в принципе можно сказать, что ответственным является тот, кто сформулирует задачу в Jira и добавит в следующий спринт. Но это может быть и не тот человек, который потом в спринте эту задачу будет делать.
Уточнение: не все action point'ы являются конкретными действиями. Это может быть изменение в процессе -- тогда оно просто принимается всеми членами команды. Или это может быть задача на уменьшение тех. долга в следующий спринт (в резерв мощности, которая команда себе на это оставляет). В этих случаях нет "владельца".
И не обязательно в этом случае описывать это на вики. Описывать правила проведения pull request'ов иногда это просто лишняя бюрократия. Ведь и так эти правила все помнят (пока что), а в случае сомнений можно посмотреть на список action point'ов. Разумеется, это только для маленькой команды со своими правилами.
Несмотря на то, что написано в документации, обе системы ведут себя примерно одинаково. При вызове типизированного кода из нетипизированного будут молчать, а при обратном вызове будут ругаться на использование any, если иное не указано в настройках.
По моему опыту flow ведёт себя «тише» по умолчанию.
Мне интересен не код хорошей функции, а требования к ней. Не то, как должна быть написана функция, с какими константами и операциями, а почему, исходя из каких требований, она должна быть так написана?
Какие функциональные (контракт) и нефункциональные требования есть к функции hashCode()?
Нигде же не говорится, что эта ситуация реальная. Это модель некоторого рабочего процесса с целью выяснить знания человека. Данная модель нужна для решения задачи проведения собеседования.
Ну а как устроены CI-процессы можно рассказать отдельно.
Синтаксические ошибки это уровень junior'а. Вполне допустимо, если сразу переходим к другим проблемам. Однако, пару раз у меня было собеседование, когда человек ничего кроме синтаксических ошибок и не нашёл.
Разумеется, если человек для начала ограничивается кратким ответом, то к полному ответу его нужно подводить наводящими вопросами. «А зачем нам HashMap?», «А как понять, хорошая hashCode() или плохая?», «будет ли работать HashMap в многопоточной среде?» и т.п.
Речь не про то, чтобы дать или не дать ответ кандидату, а про то, как для себя лично формулировать цель собеседования. Если формулировать жестко: «я должен принять решение», то это и себе стресс, и в случае, если кандидат «на границе», от субъективности больше зависит. Оценка же в «цифрах» всегда мягче, и упрощает процесс.
Для кандидата все остаётся по прежнему. В крупных компаниях на собеседованиях могут (редко) разобрать ошибки, но почти никогда не говорят итогового «принят» или «не принят».
Про SQL обсудить тоже много чего можно, но я ищу разработчика backend’а, а не DBA. Хотя о том, зачем вообще нужен SQL и современные СУБД и как они упрощают жизнь (и сравнение с NoSQL) я бы поговорил. Акцентируя внимание в том числе на ACID и оптимизаторах запросов. Главное помнить про время :-)
«Идеальный» надо взять в кавычки, правильное тут слово скорее «работающий».
Если каждый раз говорится одно и то же -- это явный признак проблем. Но вот где -- вопрос.
Валидация action point'ов как отдельный шаг не нужен. Потому что ретроспектива это не отчёт. Если у нас какой-то action point не решил проблему (и не важно -- потому что не был выполнен, или потому что не помог), мы заново вписываем проблему в список, и, если она по прежнему актуальна, ищем новые решения. Разумеется, если будет предложено то, что уже предлагалось ранее, то стоит обращать на это внимание и уточнять, а чем текущее предложение лучше несработавшего старого.
Присутствие PO это штука спорная. Очень много зависит от того, а кого вы называете владельцем продукта, и кем он сам себя считает. Если этот человек участвует в написании кода и ревью -- его 100% надо включать. Если человек что-то делает внутри команды (закрывает таски в Jira) -- тоже надо. Если же он только таски создаёт... будет зависеть от самого человека, в том числе его адекватности. Ну и загруженности. Если человек даже Jira не видит и только раздаёт ЦУ -- ему на ретро точно делать нечего.
Исходно обсуждалась не проблема, что не соблюдается процесс, а проблема, что слишком мягко/строго проводится ревью, потому что это вообще не было формализовано. То есть надо было выработать подход, как должно проходить ревью (сколько человек, как быстро, кто). У нас это вылилось не в формализацию в вики, а в написание скрипта, который часть этого процесса автоматизировал. Оставшуюся пока что помним в голове.
А вот если процесс не будет соблюдаться (когда процесс уже есть), тогда да, первый шаг -- его куда-нибудь записать. Но у нас такой проблемы пока не было.
При кажущейся очевидности этой мысли, я склонен считать, что так не бывает, и скорее всего команда просто не видит смысла высказывать свои проблемы в том формате, в котором у вас проходит ретро.
Процесс может быть и описан, а может быть и на словах. В последних двух командах он был "на словах и в скриптах". До этого было формальное описание, общее для десятка команд... на которое команды забивали и всё равно делали по своему.
Уменьшение тех. долга -- имеется ввиду добавление конкретной задачи, в которой по итогам ретроспективы уже понятно, что сделать. Тут в принципе можно сказать, что ответственным является тот, кто сформулирует задачу в Jira и добавит в следующий спринт. Но это может быть и не тот человек, который потом в спринте эту задачу будет делать.
Уточнение: не все action point'ы являются конкретными действиями. Это может быть изменение в процессе -- тогда оно просто принимается всеми членами команды. Или это может быть задача на уменьшение тех. долга в следующий спринт (в резерв мощности, которая команда себе на это оставляет). В этих случаях нет "владельца".
И не обязательно в этом случае описывать это на вики. Описывать правила проведения pull request'ов иногда это просто лишняя бюрократия. Ведь и так эти правила все помнят (пока что), а в случае сомнений можно посмотреть на список action point'ов. Разумеется, это только для маленькой команды со своими правилами.
Несмотря на то, что написано в документации, обе системы ведут себя примерно одинаково. При вызове типизированного кода из нетипизированного будут молчать, а при обратном вызове будут ругаться на использование any, если иное не указано в настройках.
По моему опыту flow ведёт себя «тише» по умолчанию.
Какие функциональные (контракт) и нефункциональные требования есть к функции hashCode()?
Ну а как устроены CI-процессы можно рассказать отдельно.
В качестве первого подхода можно, но потом попрошу переделать на JOIN.
Гик. Умный, но далекий от бизнеса.
INNER JOIN
«Обычным» называю потому, что во многих диалектах его можно заменить перечислением таблиц во FROM
Для кандидата все остаётся по прежнему. В крупных компаниях на собеседованиях могут (редко) разобрать ошибки, но почти никогда не говорят итогового «принят» или «не принят».
Про SQL обсудить тоже много чего можно, но я ищу разработчика backend’а, а не DBA. Хотя о том, зачем вообще нужен SQL и современные СУБД и как они упрощают жизнь (и сравнение с NoSQL) я бы поговорил. Акцентируя внимание в том числе на ACID и оптимизаторах запросов. Главное помнить про время :-)
«Идеальный» надо взять в кавычки, правильное тут слово скорее «работающий».