На коммерческих проектах бизнес решает оплачивать написание тестов или не оплачивать. Хороший код может быть с тестами и без, также как плохой код. Не всегда процент покрытия тестами говорит о качестве кода.
Если востребованы знания столь низкого уровня, наверно речь идет о высоконагружаемых и высоконадежных проектах с неограниченным временем разработки и тестирования. Однако в большинстве случаев нужно было все сдать уже вчера, и слайс используется в отличие от массива только потому что он расширяется. Возможно лучше будет например способность найти оптимальное количество абстракций проекта под задачи бизнеса? Или исходя из перспектив тип фреймворка, ORM или RAW SQL, форматы обмена по шинам и т.п.? Вопросы вроде на синьора, но для синьора на мой взгляд важнее, что я написал. А подход к собеседованию самый адекватный из тех что я видел!
Если в вашем примере бэк следовал задачам бизнеса, то это нормальная история, но предоставить полную информацию фронту заранее и с обоснованием конечно было нужно. Есть у меня обратная история, SEO и бизнес потребовали большого ускорение отдачи данных, пришлось мигрировать одну базу на две с последующими изменениями. Частично поменялись точки реста. Я понимаю боль фронта, но как иначе?
Так как бэкам понятнее нормализация данных в базах, ядро бизнес логики, связи микро сервисов и т.п., и это все по сути ядро всего софта, то выглядит логичным если проектирование исходит от бэков.
Хороший разработчик или программист, у кого максимально сильно прокачена логика. Кто выбирает решения не какие модно, а какие нужны бизнесу, используя логику. И количество абстракций в коде тоже подбирается под желание бизнеса.
Бизнесу бы конечно хотелось синьора на зарплату джуна, но чудес не бывает, и за соответствующие деньги сгодиться человек способный написать 80 строк кода, там может проект такой. Яндекс свой практикум преподносит, как дорогая и лучшая альтернатива "обычным курсам", но на деле оказывается хуже.
Про первую часть, "доделать работу до конца", я не встречал чтоб людям платили за несделанную работу, если конечно такая завершённость не устраивает бизнес.
Как показывает практика, в коллективах редко одна задача надолго. Обычно наоборот нужно умение быстро переключаться. А еще есть вера в фулстеков, что быстро переключаются и между языками.
На коммерческих проектах бизнес решает оплачивать написание тестов или не оплачивать. Хороший код может быть с тестами и без, также как плохой код. Не всегда процент покрытия тестами говорит о качестве кода.
Если востребованы знания столь низкого уровня, наверно речь идет о высоконагружаемых и высоконадежных проектах с неограниченным временем разработки и тестирования. Однако в большинстве случаев нужно было все сдать уже вчера, и слайс используется в отличие от массива только потому что он расширяется. Возможно лучше будет например способность найти оптимальное количество абстракций проекта под задачи бизнеса? Или исходя из перспектив тип фреймворка, ORM или RAW SQL, форматы обмена по шинам и т.п.? Вопросы вроде на синьора, но для синьора на мой взгляд важнее, что я написал. А подход к собеседованию самый адекватный из тех что я видел!
Для ответственного человека кратчайший путь к выгоранию.
Зачем текст команд и т.п. картинками?
Сказ про то как развил софт скилы до уровня забывания хард скилов?
Если бизнес устраивает двойная валидация, и проброс ошибок в обоих направлениях, то это отличный вариант.
Если в вашем примере бэк следовал задачам бизнеса, то это нормальная история, но предоставить полную информацию фронту заранее и с обоснованием конечно было нужно. Есть у меня обратная история, SEO и бизнес потребовали большого ускорение отдачи данных, пришлось мигрировать одну базу на две с последующими изменениями. Частично поменялись точки реста. Я понимаю боль фронта, но как иначе?
Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник,
И дело не пойдет на лад.
Да и примечено стократ,
Что кто за ремесло чужое браться любит,
Тот завсегда других упрямей и вздорней:
Он лучше дело всё погубит,
И рад скорей
Посмешищем стать света,
Чем у честных и знающих людей
Спросить иль выслушать разумного совета.
И. А. Крылов
Так как бэкам понятнее нормализация данных в базах, ядро бизнес логики, связи микро сервисов и т.п., и это все по сути ядро всего софта, то выглядит логичным если проектирование исходит от бэков.
Департамент может быть в коммерческой не государственной организации?
При перечисленных выше подходах был случай с талидомидом. И как исключить подобное, при приведенном способе проверки?
Зачем код размещать в виде картинок?
Хороший разработчик или программист, у кого максимально сильно прокачена логика. Кто выбирает решения не какие модно, а какие нужны бизнесу, используя логику. И количество абстракций в коде тоже подбирается под желание бизнеса.
Похоже, что не появились специалисты по сертификации, а исчезли. Я вопрос задал, а ответа нет. Ну кроме подобных ответов конечно, мимо темы вопроса.
Авторы не уточнили, под вакциной имеется ввиду препарат прошедший все стадии предписанной проверки, чтоб получить название "вакцина"?
При плохих интернет каналах, весь обмен информацией сделали по интернету. :) А раньше часть по локальным сетям ходила. Логика...
Не менее интересно может быть и в любом другом месте, а терпеть "старость" компании, это на любителя. С развитием аналогично.
Зачем таким работать в Яндаксе, если им в любом месте предложат денег выше рынка?
Бизнесу бы конечно хотелось синьора на зарплату джуна, но чудес не бывает, и за соответствующие деньги сгодиться человек способный написать 80 строк кода, там может проект такой. Яндекс свой практикум преподносит, как дорогая и лучшая альтернатива "обычным курсам", но на деле оказывается хуже.
Про первую часть, "доделать работу до конца", я не встречал чтоб людям платили за несделанную работу, если конечно такая завершённость не устраивает бизнес.
Как показывает практика, в коллективах редко одна задача надолго. Обычно наоборот нужно умение быстро переключаться. А еще есть вера в фулстеков, что быстро переключаются и между языками.