Почему?

Э, если у вас контекст и задача одно и то же и оно помещается в 2 часа, то мне грустно от ваших процессов.
И, наверно, в этом случае проще дать оплачиваемую задачу?

Я ровно про них, но если "это другое", то без проблем 🤗

Почему что? Можно как-то разворачивать свои вопросы?

В чём плохие практики?

Так уже обсудили же выше.
Фиксированный список вопросов ничего не даст понять про конкретного кандидата (кроме его памяти, что нафиг не интересно)
Программирование простых внеконтекстных задач говорит только о навыке решения примеров на собеседовании и не коррелирует с эффективностью сотрудника (вернее, корреляция обычно отрицательная)
Ну и обе эти практики обычно появляются при найме "по хард скиллам", без привязки к конкретным необходимым в команде ролям и компетенциям, которые в современной разработке гораздо важнее.
В результате куча потраченного без пользы времени.

Горячо поддерживаю

То есть я сам раньше так же поступал, а потом немножко подумал и перестал.

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

Ну я не про то.

Я предлагаю инструмент для удобства хранения типичных вопросов, задач и т.п. Вместе с инструментом для написания кода, сохранения всего. Видеочатом на худой конец. В одном месте.

К процессам и мотивам отношения вообще не имею. Если вам не нужна автоматизация, то инструмент в этом не виноват.

И в чём плохие практики?

В трелло хранят задачи, не в файлах на компе. Хотя можно и так

Ты просто ищешь неправильные сигналы вот и все, корректность решения всего лишь один из них

Один и даже не самый важный

Т.е. джун отличается от мидла умением решать алгоритмические задачки. Фейспалм.

Планирование на двухчасовой (а обычно и меньше) задаче? Не смешно.
Коммуникация - она проверяется еще до этой задачи
Умение воспринимать фидбек на тестовой задаче? Это, гм, как? Я уж не говорю, что в стрессе собеседования фидбек воспринимается не так, как обычно.
Умение тестировать - на тестовых задачах бесполезно, там просто другая ширина контекста
Умение получать решение - на тестовой задаче нет никакого "работающего решения" и близко.
Стурктурирование кода - на микрозадаче бесполезно
Понимание алгоритмической сложности - в разработке обычно нафиг не нужно, но проверяется одним вопросом без кода

Итого - бесполезная трата времени )

Я ещё раз говорю, когда участвуешь в интервью фаанга в лучшем случае как кандидат, то весь процесс воспринимается как каргокульт, но на самом деле люди просто не понимают как использовать такие интервью и у них самолеты не летают хотя машут палками как регулировщики на ввп

Ещё тимлиду надо уметь читать, но не каждому дано даже буквы сложить в слова

Эээ, просто проблемы фаанга и проблемы других компаний - принципиально разные.

Я думаю, тут больше про самозванцев, которые пишут в резюме - мидл. Их легко так остановить.

Иногда хочется всех тимлидов при выходе на должность пороть и приговаривать "у нас не фаанг"...

Конечно, вместо того, чтобы давать задачу на каждый день - мы дадим задачу, которая встречалась человеку в вузе. И ее скорее решит тот, кто готовился к собесу. Л - логика.