Answer the question
In order to leave comments, you need to log in
What do you do if the junior does not have time to complete the task?
How many times already at interviews they ask the question: are you a team leader, your subordinate has been working on one task for the second or third day, deadlines are running out, what are your actions? I answered something like I will discuss with him what is specifically incomprehensible, I will try to solve these incomprehensible moments together. Following immediately the question from the interviewer: what if this does not help? What puts me in a stupor, really, what should I do if there is a day left before the task is completed, and the subordinate hasn’t really done anything? Transfer to someone else? He does not have time to delve into the problem and solve it in a day. Do it yourself? In general, a sour option, so I will do all the work for my subordinates. Your actions?
Answer the question
In order to leave comments, you need to log in
An adequate junior should not JUST sit and fail to meet the deadline.
He must understand in time that he does not have time and ask for help himself. Understanding priorities comes with experience, but it's not a programming skill, it's a human skill. He either is right away, or is unlikely to appear at the age when a person has already got a job.
This is the difference between a teapot and a lamer, between an adequate person who will grow up over time, and one that you will ALWAYS have to run after.
Personally, my actions - if Junior did not complete the task on time and I find out about it with the end of the deadline - what the hell is such a person in the team (well, except to try to give one more task to make sure that this is not an accident). And if Junior comes for help on time, the task will be solved on time.
What are the options? You can not correctly set the task - do it yourself.
In this case, everything depends on the situation. If the deadlines cannot be delayed, you sit next to me and start sculpting. Or you sit next to a junior more experienced colleague. In any case, you can come up with something together.
I think at the interview they tried to find out who you are, the leader or the performer. Or something like that.
Either way, I wouldn't bother. If they ask such questions, I would immediately send them away.
Firstly, the right task is solved in a very, very foreseeable timeframe. If we have a task that a deliberately problem-free programmer will solve in a week - it should be split into tasks that can be solved in half a day at most (even if it brings a day or two overhead) - in this case we will be able to detect the plug in time and quickly solve the problem, not to overthrow the project. As a result, an objective measure of trust in an employee is precisely how voluminous tasks can be given to him in one piece, this is the more, the higher his own experience in structuring tasks and resolving such situations and to what extent he proved his predictability over time.
Secondly, the fact that new employees are not doing their job also hints that HR is not doing their job - perhaps he should become more familiar with what they do in their company and ask more questions at interviews more to the point ( working through a list of questions with existing programmers together, for example).
Not only juniors can "lack in time", people with 10+ experience can also "miss" their grades.
Here it is necessary not only to discuss, but to understand the reason - to ask how he is going to solve the problem and it will be clear whether the person understands what needs to be done or not. If there is no complete understanding, add someone more experienced to the pair, or sit by yourself and go through the steps of the solution orally or on paper.
I have only one question - in which office do such responsible tasks hang on a junior that they can seriously miss the deadlines?
Junior in American is a left kid who needs to be exploited . And in Russian it is a novice programmer, a future friend.
If a novice programmer can not cope, he needs help. And he will quickly become a normal developer, grateful for the help. If you do not see his desire to cope, punish him somehow for his own good (educational moment). If you see that the lazy person at the same time also loves words like "junior", "senior" - dismiss him for unsuitability for the team, with an explanation of the reason.
Such is the difference between mentalities and cultures.
Obviously, if "the subordinate didn't really do anything", and you, as a smart boss, correctly calculated the timing and complexity of the task for the junior you want to see, you are not on the way with him.
By the way, what do you think, if a 30-year-old goes to get a job as a junior - how is it perceived? I have been in the industry for 6 years, but I haven’t gained much knowledge and experience, but then I suddenly wanted to, and since I write bad code, I want to have control and be reviewed, so I’m going to get a job as a junior. Please comment on this how you look at it as an employer or a team leader who interviews such a person.
The question is rather tricky, as it has several solutions.
1) You can shift the deadlines (They are shifted even on the most expensive and terrible projects where it seemed impossible to shift anything. You just need to argue correctly ...);
2) You can put help in a couple (your "belated" will set out the tasks and will prompt on the architecture and logic of the project, and the "new" with a fresh look will help. 3 days. Here we need to involve more people. If only there was enough competence to divide the task into this number of people)
3) Simplify the task (probably the simplest and most practical solution. If the task is business-critical, then it can be completed. It is important to catch what the developer is stuck on and try to cut this complexity, but providing the task with "delivery" on demand at least in minimal similar form)
4) Reschedule the deadline (the deadline is determined by something. Release, demonstration, test, or a stopper for another task. Well, if we are talking about a junior, then it is necessary to avoid assigning dependent tasks to juniors. Well, if we move away from the level and talk about the deadline, then you can exclude the task from the release or display. This is often practiced. No one has yet refused to cooperate. Most often, on the delivery of large annual projects, we have 5-15% of the requirements for the release to the end and are not included in it. Yes, we bow , we apologize, we work at night, but this is still the best solution when the other does not help anymore)
A competent manager must understand that any resource is a resource. It is only important to use it correctly. If your junior eats for a middle and gives as an under-junior, then this is not a reason to kick him out of the team, this is a reason to pay him the appropriate money.
The resource must work! No matter how dumb he was. If the costs outweigh the profit from the resource, then yes, you should kick it out. More often than not, the costs are negligible. It just needs to be built right.
If we are talking about juniors, then I openly tell them that the market cannot pay them a salary for such speed in solving problems, quality, etc. and if they want to stay in this market, then let them work as long as they need (an hour after work, two, three - night, weekends) until they learn and organize themselves in such a way that they fit in on time. Most often, people bow their heads and work after work, at home, on weekends. Most cope. A month, a second, and it turns out to fit in the right time frame.
Some even experienced incredible metamorphoses because of it. Someone stopped smoking 15 times a day, running to the balconies with coffee. Someone stopped reading VKontakte feeds and liking funny videos. And I didn’t have to punish anyone or set terrible rules in the office. Overtime has beaten the crap out of people and they go from 9 to 18 to do work without showing their heads out of it until it's done.
To draw up a competent plan for solving the problem, writing, literally point by point, the actions of the employee, since he is a junior, this will be useful to both parties.
If he understands what to do, but just does not have time. Some, independent, subtasks can be transferred to another. In any case, optimization is needed, debugging can be left for later, for example.
If there is simply not enough knowledge, also check the mastery of the material and the progress of work point by point.
You can push a little, hinting that the project is important, ata-ta. And if it works well, it will be good. But the main thing is not to overdo it, otherwise there will be no progress.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question