В Індії колись висували такі вимоги, результатом став т.зв. "індійський код" з купою непотрібних рядків.

Є такі "менеджери" які рахують єфективність програміста  по кількості комітів ))

Зараз кількість випущених різними курсами трейні така кількість, що це звісно навантаження на hr аби вибрати притомних, але завдання врешті do-able. Тобто приходить трейні, який вже закінчив курси, робив пет-проект, пройшов щось типу онлайн кодинг на hackerrank і виконав тестове завдання при прийомі на роботу. Далі починається те, що проходить будь-який програміст незважаючи на його рівень - отримати доступи, познайомитися з командою, з інфраструктурою і "що де лежить" в сенсі даних і доків. Зеленій людині дають робити щось таке що не критично впливає на весь процес - наприклад, розібратися з існуючим кодом (точково, щоб не загубився), щось типу переписати декілька функцій включаючи нові потрібні інпут параметри, переписати відповідні юніт тести, виправити відповідні доки, закомітити в свою бранчу і відправити на рев'ю. В такому режимі трейні може працювати поки не покаже що йому можна довірити щось більше. Стандартних очікувань "середніх в галузі" не існує, більше залежить що за команда, які вимоги щоб до неї потрапити - буває що більш і менш розслаблено.

На те є PM, скрам-мастер та інші нероби на галері, яка забирає в гребця добру половину заробітку. Це головний біль не рядового гребця. Хіба що є ціль (і це правильно) працювати напряму на замовника. Але це задачка по зубах для людей із хоча би деяким досвідом.

Якщо коротко, то це як із задачкою "з'їсти слона" - ми без керма коли це реалістично завершити, однак ми можемо його розчленувати, зберегти в морозилках (це теж етапи роботи - діскавері) і приблизно оцінити на скільки днів харчування нам вистачить однієї слонячої ноги, потім хобота (рівні складності з кісткою чи без). Десь в такому напрямку роздуми. Практично будь-яка велика задача дробиться на менші і ще менші, які можна реалістично оцінити. Ну й далі чи є для цього достатня команда для всіх ділянок роботи, чи ж робити все доведеться "в одне рило". Застосовується метод "скрам-покер" і т.д. За результатами тижня роботи робиться "ретроспектива" дрібних задач щоб зрозуміти що саме було невірно оцінене і як покращити.

Тут буває по-різному, можуть уявляти а можуть і не дуже. Тоді керівник проекту після аналізу вимог має дати свою оцінку скільки це займе часу. Або ж інакше - замовникам потрібно на конкретну дату, тоді під ці вимоги набирається більша команда і т.д. "Але є одне але" - дев'ять жінок не можуть спільними зусиллями народити одну дитину за один місяць, тобто є задачі які не масштабуються.

Також на галері безліч часу витрачається на цілком порожні справи. Наприклад, це з мого особистого досвіду, пройди онлайн тренінг з питань недискримінації осіб які вирішили змінити свою стать. Абсурд? Так! Але це реальне завдання, яке я проходив з різними видозмінами на декількох проектах і яке забрало декілька годин. І таких завдань з різним ступенем абсурду багато, також пусто-порожні мітинги типу "all hands" де з поважними мінами на морді лиця розповідають як потужно бороздить простори наша галера. Кодингу там нуль. Це потрібно враховувати.

====

Звідкіля взагалі такі запитання? Ні, вони загалом вірні, "але є одне але". Тут або є бажання працювати "соло" на фрілансі, або ж одразу скочити на менеджера проекту. Однак вірні відповіді на ці запитання приходять лише з особистим вистраждалим досвідом, на форумах чи навіть на спеціалізованих курсах можуть задати лише напрямок думок, бо все дуже індивідуально.

Трейні на проекті буде обов'язково під наглядом когось більш досвідченого. Якщо проста з точки зору сіньйора задача займає в трейні значно довше, то це ще не одразу проблема. Проблема якщо разом сіли, зробили задачу і потім вже інша, аналогічна задача все одно займає надто багато часу. Тут або погано пояснили (це можливо, бо в сіньйора крім дитячого садка з трейні ще й свої задачі), або ж трейні отримав вичерпний онбординг, однак за своїми вміннями не проходить випробувальний проект.