Увеличит шанс попасть туда, где собеседование ведут такие же маньяки. :)
Мне больше всего понравилось собеседование на текущее место работы. Мило побеседовали с HR, а тех. собеседование должен был вести бывший тех. директор с прошлого место работы, так что обошлись без него.
Разработчики — дорогой ресурс. Если проект развивается — делать идеально mvp невыгодно, куда выгоднее проверить больше гипотез.
Если mvp показал результаты — можно либо улучшать его либо сразу распространить на всех.
Куда критичнее сливание в унитаз кучи человеко-часов из-за нечеткости требований, смены ТЗ в процессе работы/перед релизом. Отсутствие макетов до начала разработки.
А критичные места если вылезут — их как раз оптимизировать больших проблем не составит, если код изначально писался более менее адекватно. Нужно просто желательно при декомпозиции/разработке их наличие явно указать, если конечно, они не внезапны.
По сути эти задачи ничем не отличаются от остальных. Так же необходимо измерить эффект от изменений. Например, рефакторинг позволит делать типовые задачи на N часов быстрее, в беклоге X задач. Экономия Z человокочасов.
Ни разу не нанимал их, так что сложно сказать. Но скорее всего это были бы смоделированные реальные ситуации, чтобы посмотреть как кандидат поведёт себя в них, какие решения предложит.
Это только в случае если сортировка оказалась узким местом. Такое бывает крайне редко в реальной жизни. А если уж случилось — с этим реально справиться даже не помня алгоритмов сортировок до возникновения проблемы.
Пока вы там сортируете, сеньор решает реальные задачи, проектирует и пишет понятный код, оптимизирует проект, трезво оценивает сроки, задаёт нужные вопросы по ТЗ и учится.
У нас упал сервер, так давайте же… напишем свой сервер с блекджеком и!..
К слову, не очень понятно что мешает на самом дев сервере выдавать фейковые данные пока идёт разработка. Делаем так и все довольны.
Agile, scrum — авторы этих методологий и не скрывают, что почерпнули многое от Тойоты.
Несколько непонятно к чему это откровение в 2019 году.
В целом написано хорошо. Но поздновато.
Отладка должна занимать куда меньше (в большем числе случаев, всегда что-то может пойти не так). Даже если нет тестов. Если речь идёт о сеньере.
В остальном весьма дельно.
Увеличит шанс попасть туда, где собеседование ведут такие же маньяки. :)
Мне больше всего понравилось собеседование на текущее место работы. Мило побеседовали с HR, а тех. собеседование должен был вести бывший тех. директор с прошлого место работы, так что обошлись без него.
Результатом довольны все.
Разработчики — дорогой ресурс. Если проект развивается — делать идеально mvp невыгодно, куда выгоднее проверить больше гипотез.
Если mvp показал результаты — можно либо улучшать его либо сразу распространить на всех.
Куда критичнее сливание в унитаз кучи человеко-часов из-за нечеткости требований, смены ТЗ в процессе работы/перед релизом. Отсутствие макетов до начала разработки.
А критичные места если вылезут — их как раз оптимизировать больших проблем не составит, если код изначально писался более менее адекватно. Нужно просто желательно при декомпозиции/разработке их наличие явно указать, если конечно, они не внезапны.
Работать больше? Футакимбыть. Прямой путь к выгоранию.
Так вот кто обещает наказать водителя и выдаёт промокод в ответ на благодарность за поездку.
Только откатили через 17 часов примерно. :)
Напрашивается вывод, что весьма критичная метрика не мониторилась.
В 13 лет стоит наслаждаться жизнью, гулять с друзьями, мечтать. Если, конечно, нет богатых родителей, которые обеспечат стартовым капиталом.
*человеко-часов
По сути эти задачи ничем не отличаются от остальных. Так же необходимо измерить эффект от изменений. Например, рефакторинг позволит делать типовые задачи на N часов быстрее, в беклоге X задач. Экономия Z человокочасов.
Ни разу не нанимал их, так что сложно сказать. Но скорее всего это были бы смоделированные реальные ситуации, чтобы посмотреть как кандидат поведёт себя в них, какие решения предложит.
Если у нас бекенд на вебе — то никогда не поздно)
Это только в случае если сортировка оказалась узким местом. Такое бывает крайне редко в реальной жизни. А если уж случилось — с этим реально справиться даже не помня алгоритмов сортировок до возникновения проблемы.
Тогда возникает вопрос, а сеньоры ли они на самом деле.
Пока вы там сортируете, сеньор решает реальные задачи, проектирует и пишет понятный код, оптимизирует проект, трезво оценивает сроки, задаёт нужные вопросы по ТЗ и учится.
У нас упал сервер, так давайте же… напишем свой сервер с блекджеком и!..
К слову, не очень понятно что мешает на самом дев сервере выдавать фейковые данные пока идёт разработка. Делаем так и все довольны.
Здороваюсь за руку только с нашей командой, менеджерами и админами, иначе слишком много людей и запарно.
Человек 10 выходит, вполне приемлемо, кмк.
Agile, scrum — авторы этих методологий и не скрывают, что почерпнули многое от Тойоты.
Несколько непонятно к чему это откровение в 2019 году.
В целом написано хорошо. Но поздновато.