How to take over an intern's task without him feeling defeated?

Question

Background: I was an intern at my current place of work for a year, until May when I was hired in full time. I am a programmer and I develop mostly mobile apps, but some web apps as well. Since then, we've hired several interns, and 2 of them are under my command. The reasoning here being that my boss wants me to learn to delegate and to solidify what I've learned by teaching it to another person.

So, the context is I gave my intern an important, but small task. He was to program something in the project I'm working on. Either he misunderstood the task or I did not do a well enough job explaining it, but he did it wrong. His work is so far incomplete, but I can tell from what he has written that it wont work and that he misinterpreted the task (or, it was not explained well enough) and the way he went about completing the incorrect task is not good. In his defense, he's in his second year of college and I am graduated, so I've a few years of education and a whole year of work experience ahead of him. I want to scrap his code, write my own, and explain to him how and why I coded it that way, but I don't want him to feel dumb or feel defeated about the failure. The reason I am worried he may feel dumb is because I have no idea how he intended it to work and also because to me it feels like a dumb way to do it, but I am acutely aware of the fact that I also wrote dumb stuff during my internship and I am still writing dumb stuff compared to many many other people. Yet, he failed. We all fail at some time or another.

So, how do I take over his task and explain how to do it right without him feeling defeated about the failure?

Answer 1

Best to ask him about it "Let's see what you've done for feature X. What was your overall plan? How were you collecting input, processing it, producing output? Why did you do ABC this way?". As a supervisor this doesn't have to be accusatory. It creates a dialog by which you can see what their plan is and let's you ask them about their solution to obstacles they will encounter.

Maybe they have a brilliant solution that you can't see, maybe they don't realize the upcoming obsticle. You can't know until you talk to them.

If they don't have a satisfactory solution for the given time frame then it doesn't have to be harsh. "Our timeframe is tight so I'm going to take this on myself. It was a good try, I made a similar mistake when I was an intern. Please (instruct some other task)."

Answer 2

In a word ... don't. (Yeah, okay that's a contraction.)

You stated that you oversee these interns because your boss wants you to learn to delegate. There's more to that than just "Here's some work, go do it." If you take over the intern's work now, it seems to me that you haven't learned what your boss wanted you to learn.

You've acknowledged that there were communication problems. To learn delegation, you're going to need to learn to communicate more effectively. The communication cycle involves telling, listening, feedback, and correcting/re-telling; in this last part the cycle begins anew and continues as long as needed. It seems that so far you've tried to use just the first two parts. However, you need the second two parts to ensure accurate communications.

My suggestion is to go back to the intern and let him know that the two of you miscommunicated. Review what the project is supposed to be, and make sure the intern has a good understanding of it; don't just let him say "Yeah, I understand." Ask him to re-state (in his own words) what he is supposed to do, and make corrections as needed. Then ask him to put together a plan and go over that before he starts coding. Also, keep an open mind; his approach isn't necessarily wrong, just because it isn't what you would have done; of course, it is possible his approach won't work, but it's your job to guide him to a working solution, not to do it yourself.

Answer 3

Never just scrap and rewrite the code for someone else. If the person works for you, sit down and explain what was wrong and what exactly you want and then force them to do the rewrite until they get it correct.

Otherwise you will be doing both your job and theirs and they will remain not competent. Many people get frustrated when this happens because they don't see why it was rewritten and just assume that everything they do will be rewritten because Joe is a control freak, not because it has problems.

They don't get any better when you do this and it does them a great disservice. It also means you aren't delegating correctly and that you will be overwhelmed and they will coast along happily thinking they are great and you are a jerk. It is harder to train someone than it is to rewrite. But once you have taken the time a couple of times. then you will get improvement because very few people enjoy having to redo their work.

Now it might be that you need to sit with this person and pair program if they really have very little knowledge. But in this specific case, you make them come up with a solution and you just stop the intern when he starts to go in the wrong direction. You keep asking questions like "Why did you choose this method? Have you considered...library? What do you think the impact over time of doing this would be?", etc.

And remember this is not just the intern's fault. If you were not clear in what you were asking for and if you didn't check on them every day and look at interim pieces of their code, then you were as much to blame as the intern. So don't make this a blame session, make it a productive, constructive criticism.

Answer 4

In short, sit down with the intern and have him/her watch as you code the project, explaining to him/her why you're coding the project the way you are, teaching the intern good coding practices along the way. Instead of reflecting on the intern's failure, you can make it a teaching experience. Failure is really one of the best ways to learn what doesn't work, and while you shouldn't be rude in bashing the intern over the head with their bad code, you do need to illustrate why their code won't work, and why the best plan at this point is to start over.

Whether the intern feels defeated or not is up to that intern. They'll need to be able to learn to deal with failure anyway, if they haven't already. However, if you treat the situation right, at the least the intern should come away with having learned something. In this situation, that's much more important than worrying about them feeling offended or humiliated.

Answer 5

Consider Pair Programming with the intern. Either pair program walk thru their incorrect code and try to fix it, or walk thru their code, explain its flaws, and discuss and Pair Program new, better code. Pair Programming is the best learning tool, knowledge transfer, code review, QA, all wrapped in one!

Sometimes, with time constraints, you may need to just scrap their stuff and get the job done. Have done this before, and it was with a senior developer. You could tell they felt slightly defeated, but they knew, we needed to get a job done.

if time permits, take the chance to learn together. they will learn how to program better, you will learn where the miscommunication happened. You will learn how to explain and write stories for tasks much better if you see how others interpreted the request.

Answer 6

I want to scrap his code, write my own, and explain to him how and why I coded it that way

Yes! Do it!

Err, maybe.

I've read the very sensible objections to this approach. Now that I just dumped a barrel full of gasoline onto this fire, I know I have some explaining to do. My quick summary is that this approach does have potential to be quite useful.

A widely quoted example is the U.S. Government training people how to detect counterfeit money. People have been taught this skill by becoming very familiar with what is right, rather than studying what is wrong. If the code created by your co-worker is sufficiently dismal, the best option may be to eliminate what is useless and demonstrate what is good, and discuss what is good and make sure that he can do what is good.

So, despite the objections other people have brought up, I would suggest that your plan may have merit, and might even be the best plan. However, it also might not be. When my career took on the role of being a college instructor, I got to see the quality of work that a bunch of students created. I also saw just how effectively people were learning some things, and not other things. I began to really see how different teaching styles are effective for different people.

I've also learned that delegating successfully involves giving someone a task that they can do successfully, and that involves determining their skill level. Case in point: some people are reluctant to make decisions, but they do know how things ought to be done. You could ask them, "Well, what do you think should be done?" By prodding them into taking the needed action, you may cause them to start to realize the power they could be utilizing, and may thrive. Yet if you ask the same question to a person who just joined an organization, and this person doesn't know enough details to have a basis to make a sensible decision, identical prodding may only have the effect of being disastrous.

If you're trying to train somebody, be sure to ask questions (early in a process) to verify understanding and determine what approach is helpfully working, and what approaches are not. Focus on giving them the structure that they need, with clearly defined desired results and maybe even clearly defined approaches, and then leave them to the task of accomplishing the simple-to-achieve goal you laid out. As for providing examples (made by you, and made by him), and providing instructions, the usefulness of a specific approach will vary by individual.

Answer 7

In the future, you need to let interns know that they are taking on a critical task, but if you are not able to approve their work by a certain time, it will get done by someone else. This is fair, open and honest. This doesn't mean they shouldn't take it seriously because you want to be able to give them a good recommendation. Interns shouldn't be burdened with mission-critical pressure.

Try to do some sort of debriefing so you can understand where you failed in explaining this problem to the intern or what assumptions you made about their skill level. There's no reason not to make this a learning experiences for you and your company as well.

Since you didn't do that, I would start with this explanation and apologize for not stating this in the first place. My guess is the intern will understand. Keep them in the loop about your approach. Take the time to explain as much as possible. If possible, don't redo everything. Hopefully there is some redeemable code there.

Give the intern something to so as soon as possible. Let them get back on the horse after they fall off. Maybe they can rewrite this project with your latest suggestions.

I just think if you approach it calmly and professionally, the intern won't beat himself up too much. It's important they understand that you want to stretch their skill set and there should be some realistic level of failure but not total failure. Sometimes you just run out of time.