Как стать автором
Обновить
75
Карма
0
Рейтинг
Сергей Владимиров @vlsergey

Пользователь

Ретроспектива по шагам. Рецепт

Если каждый раз говорится одно и то же -- это явный признак проблем. Но вот где -- вопрос.

Ретроспектива по шагам. Рецепт

Валидация action point'ов как отдельный шаг не нужен. Потому что ретроспектива это не отчёт. Если у нас какой-то action point не решил проблему (и не важно -- потому что не был выполнен, или потому что не помог), мы заново вписываем проблему в список, и, если она по прежнему актуальна, ищем новые решения. Разумеется, если будет предложено то, что уже предлагалось ранее, то стоит обращать на это внимание и уточнять, а чем текущее предложение лучше несработавшего старого.

Присутствие PO это штука спорная. Очень много зависит от того, а кого вы называете владельцем продукта, и кем он сам себя считает. Если этот человек участвует в написании кода и ревью -- его 100% надо включать. Если человек что-то делает внутри команды (закрывает таски в Jira) -- тоже надо. Если же он только таски создаёт... будет зависеть от самого человека, в том числе его адекватности. Ну и загруженности. Если человек даже Jira не видит и только раздаёт ЦУ -- ему на ретро точно делать нечего.

Ретроспектива по шагам. Рецепт

Исходно обсуждалась не проблема, что не соблюдается процесс, а проблема, что слишком мягко/строго проводится ревью, потому что это вообще не было формализовано. То есть надо было выработать подход, как должно проходить ревью (сколько человек, как быстро, кто). У нас это вылилось не в формализацию в вики, а в написание скрипта, который часть этого процесса автоматизировал. Оставшуюся пока что помним в голове.

А вот если процесс не будет соблюдаться (когда процесс уже есть), тогда да, первый шаг -- его куда-нибудь записать. Но у нас такой проблемы пока не было.

Ретроспектива по шагам. Рецепт

А ретроспективу в общем то и необязательно проводить если команда не видит проблем которые ей мешают

При кажущейся очевидности этой мысли, я склонен считать, что так не бывает, и скорее всего команда просто не видит смысла высказывать свои проблемы в том формате, в котором у вас проходит ретро.

Ретроспектива по шагам. Рецепт

Процесс может быть и описан, а может быть и на словах. В последних двух командах он был "на словах и в скриптах". До этого было формальное описание, общее для десятка команд... на которое команды забивали и всё равно делали по своему.

Уменьшение тех. долга -- имеется ввиду добавление конкретной задачи, в которой по итогам ретроспективы уже понятно, что сделать. Тут в принципе можно сказать, что ответственным является тот, кто сформулирует задачу в Jira и добавит в следующий спринт. Но это может быть и не тот человек, который потом в спринте эту задачу будет делать.

Ретроспектива по шагам. Рецепт

Уточнение: не все action point'ы являются конкретными действиями. Это может быть изменение в процессе -- тогда оно просто принимается всеми членами команды. Или это может быть задача на уменьшение тех. долга в следующий спринт (в резерв мощности, которая команда себе на это оставляет). В этих случаях нет "владельца".

И не обязательно в этом случае описывать это на вики. Описывать правила проведения pull request'ов иногда это просто лишняя бюрократия. Ведь и так эти правила все помнят (пока что), а в случае сомнений можно посмотреть на список action point'ов. Разумеется, это только для маленькой команды со своими правилами.

Типобезопасность в JavaScript: Flow и TypeScript

Добавил строку с количеством issues на github.

Несмотря на то, что написано в документации, обе системы ведут себя примерно одинаково. При вызове типизированного кода из нетипизированного будут молчать, а при обратном вызове будут ругаться на использование any, если иное не указано в настройках.

По моему опыту flow ведёт себя «тише» по умолчанию.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Мне интересен не код хорошей функции, а требования к ней. Не то, как должна быть написана функция, с какими константами и операциями, а почему, исходя из каких требований, она должна быть так написана?

Какие функциональные (контракт) и нефункциональные требования есть к функции hashCode()?

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Это, очевидно, бонус, и знать не обязательно. Но бонус был бы приятный. Как, например, обсудить за кружкой пива, сколько бит в байте, и почему.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Нигде же не говорится, что эта ситуация реальная. Это модель некоторого рабочего процесса с целью выяснить знания человека. Данная модель нужна для решения задачи проведения собеседования.

Ну а как устроены CI-процессы можно рассказать отдельно.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Синтаксические ошибки это уровень junior'а. Вполне допустимо, если сразу переходим к другим проблемам. Однако, пару раз у меня было собеседование, когда человек ничего кроме синтаксических ошибок и не нашёл.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Именно с целью выяснить умение работать с JOIN и NULL

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Разумеется, если человек для начала ограничивается кратким ответом, то к полному ответу его нужно подводить наводящими вопросами. «А зачем нам HashMap?», «А как понять, хорошая hashCode() или плохая?», «будет ли работать HashMap в многопоточной среде?» и т.п.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

В качестве первого подхода можно, но потом попрошу переделать на JOIN.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Гик. Умный, но далекий от бизнеса.

Собеседую программистов на Java. Единый набор вопросов для любого уровня

INNER JOIN


«Обычным» называю потому, что во многих диалектах его можно заменить перечислением таблиц во FROM

Собеседую программистов на Java. Единый набор вопросов для любого уровня

Речь не про то, чтобы дать или не дать ответ кандидату, а про то, как для себя лично формулировать цель собеседования. Если формулировать жестко: «я должен принять решение», то это и себе стресс, и в случае, если кандидат «на границе», от субъективности больше зависит. Оценка же в «цифрах» всегда мягче, и упрощает процесс.

Для кандидата все остаётся по прежнему. В крупных компаниях на собеседованиях могут (редко) разобрать ошибки, но почти никогда не говорят итогового «принят» или «не принят».

Про SQL обсудить тоже много чего можно, но я ищу разработчика backend’а, а не DBA. Хотя о том, зачем вообще нужен SQL и современные СУБД и как они упрощают жизнь (и сравнение с NoSQL) я бы поговорил. Акцентируя внимание в том числе на ACID и оптимизаторах запросов. Главное помнить про время :-)

«Идеальный» надо взять в кавычки, правильное тут слово скорее «работающий».

Когда вредно хешировать

Разумеется, он не должен лежать рядом.

Когда вредно хешировать

Достаточно 128 бит энтропии. Примерно 25 случайных символов или же 160 букв произвольного текста.

Когда вредно хешировать

6+4 хранить можно. Но вот держать рядом с ними хешированное значение нельзя.

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность