Ваши действия, если джуниор не успевает выполнить задачу?

Контролировать в процессе исполнения, а не когда уже сроки поджимают.

Адекватный джуниор не должен ПРОСТО сидеть и не успевать в срок.

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

В этом заключается разница между чайником и ламером, между адекватным человеком, который со временем вырастет, и тем, за которым ВСЕГДА придется бегать.

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

А какие варианты? Не можешь грамотно поставить задачу - делай сам.
В данном случае все по ситуации. Если сроки оттянуть нельзя, садишься рядом и начинаешь ваять. Или садишь рядом с джуниором более опытного коллегу. В любом случае совместно можно что-то придумать
Я так думаю на собеседовании пытались выяснить кто вы, руководитель или исполнитель. Или типа того.
В любом случае я бы не парился. Если задают подобные вопросы, я бы сразу послал их подальше.

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

Во-вторых факт того, что новые сотрудники не справляются со своими задачами также намекает на то, что HR не справляется со своей - возможно ему следовало бы получше ознакомиться с тем, чем занимаются в их фирме и задавать на собеседованиях больше вопросов ближе к делу (проработав список вопросов с имеющимися программистами совместно, например).

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

У меня только один вопрос - в какой конторе на джуниора вешают настолько ответственные задачи, что они могут серьезно сорвать сроки?

Джуниор в американского - левый пацан, которого нужно эксплуатировать. А в русском это начинающий программист, будущий товарищ.

Если джуниор не справляется - уволить без выходного пособия. И нанять другого.

Если начинающий программист не справляется, ему надо помочь. И он быстро станет нормальным разработчиком, благодарным за помощь. Если не видишь у него желания справляться - наказать как либо для его же пользы (воспитательный момент). Если видишь, что лентяй при этом ещё и любит слова типа "джуниор", "сениор" - уволить за профнепригодность для коллектива, с объяснением причины.

Такова разница менталитетов и культур.

Очевидно, что если "подчиненный толком ничего не сделал", а вы, как умный начальник, правильно рассчитали сроки и сложность задачки для джуниора, которого хотите видеть - вам с ним не по пути.

Кстати, как вы думаете, если 30-летний идёт устраиваться на должность джуниора - как это воспринимается? В отрасли 6 лет, но больших знаний и опыта не приобрёл, а тут вот внезапно захотел и так как пишет плохой код, то хочет, чтобы был контроль и чтобы его ревьюили, поэтому идёт устраиваться джуном. Выскажитесь пожалуйста по этому поводу как вы смотрите на это как работодатель или тим лид, который собеседует такого.

Вопрос довольно каверзный, так как имеет несколько путей решения.
1) Можно сместить сроки (Они смещаются даже на самых дорогих и страшных проектах где казалось нельзя ничего сместить. Нужно лишь правильно аргументировать...);
2) Можно посадить помощь в пару (Ваш "запоздалец" будет излагать задачи и будет подсказывать по архитекутуре и логике проекта, а "новый" свежим взглядом окажет помощь. Помогает всегда, вопрос лишь в реалиях уложится конкретно в 1 день, если там трудозатрат на 3 дня. Тут уже надо подключать больше людей. Лишь бы хватило компетенции поделить задачу на это количество людей)
3) Упростить задачу (наверное, самое простое и применяемое на практике решение. Если по бизнесу задача критична, то её можно довыписать в доделку. Важно уловить на чем разработчик завис и постаратся эту сложность срезать но обеспечив задаче "сдачу" по требованию хотя бы в минимально подобном виде)
4) Перенести дедлайн (дедлайн он чем то обусловлен. релиз, показ, тест, либо же стопер для другой задачи. ну если речь про джуна, то необходимо избегать поручения зависимых задач на джунов. ну а если отойти от уровня и говорить о дедлайне, то можно исключить задачу из релиза или показа. Частенько такое практикуется. Ни кто пока от сотрудничества не отказался. Чаще всего на сдаче крупных годичных проектов у нас 5-15% требований не сделаны к релизу до конца и в него не включены. Да, кланяемся, извиняемся, работаем ночами но это все равно решение лучшее когда другое уже не поможет)

Грамотный менеджер должен понимать, что любой ресурс это ресурс. Важно лишь его правильно использовать. Если ваш джуниор жрет за мидла а далает как недоджуниор, то это не повод его выганять из команды, это повод платить ему соответствующие деньги.

Ресурс должен работать! Каким бы галимым он не был. Если издержки перевешивают профит от ресурса, то да, следует выгнать. Чаще всего, издержки мизерные. Нужно лишь правильно это построить.

Если речь о джунах, то я открыто им говорю, что рынок не может платить им зарплату за такую скорость решения задач, качество и т.д. и если они хотят удержатся на этом рынке, то пускай работают сколько им нужно (час после работы, два, три - ночь, выходные) пока не научатся и не сорганизуются так, что бы укладыватся во время. Чаще всего люди склоняют голову и работают после работы, дома, на выходных. Большинство справляется. Месяц, второй и получается вписыватся в нужные сроки.

С некоторыми даже происходили невероятные метаморфозы из-за этого. Кто то перестал курить по 15 раз на день бегая на балконы с кофе. Кто то перестал читать ленты вконтакте и лайкать смешные видео. И не пришлось никого наказывать или ставить жуткие правила в офисе. Сверхурочная работа выбила дурь из людей и они ходят с 9 до 18 что бы делать работу не показывая головы из неё пока не сделают.

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

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

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